Почему ваши AI-агенты пишут плохой код: паттерны orchestration и ловушки prompt-инжиниринга в проде

Я — Denis Shokhirev, архитектор AI из Эрлангена (DennisCraft AI Studio, DACH, продакшн-стек: Claude, Supabase, n8n, Doppler, Postgres). Недавно за один вечер мне пришлось откатить три pull request от AI-агентов: все содержали SQL-инъекции и не проходили даже базовую валидацию через bandit и semgrep. В проде это не единичный случай, а системная проблема orchestration и prompt-инжиниринга.

Где orchestration ломает качество кода

В большинстве production-агентов orchestration реализован через связку n8n + self-hosted Postgres + Claude Code. Обычно схема выглядит так:

• n8n инициирует задачу, формирует prompt и отправляет в Claude через API
• Claude возвращает фрагмент кода (Python, SQL, иногда bash)
• n8n пишет этот код в репозиторий или сразу в runtime через Supabase

Проблема — orchestration pipeline часто не делает ни одного real-time quality gate. LLM выдаёт невалидный или опасный код, а orchestration просто прокидывает его дальше.

Ошибки orchestration

• Нет layer-2 валидации: LLM-выход не проходит через bandit, semgrep или gitleaks
• Логика проверки «на проде» — ловим баги уже у пользователя
• Отсутствие rollback-паттернов для частичных изменений

В реальном проекте для финтеха (2024, Германия) агент сгенерировал функцию, которая писала логи в открытый S3 bucket — gitleaks это сразу бы поймал, но orchestration пропустил.

Частые ловушки prompt-инжиниринга

В prompt-инжиниринге для production-агентов встречаются одни и те же фатальные ошибки:

Слишком общие инструкции

Фразы типа «напиши функцию для чтения данных из базы» приводят к небезопасному SQL (инъекции, отсутствие sanitation). LLM не видит контекст, а orchestration не добавляет ограничения.

Отсутствие explicit constraints

Если prompt не заставляет LLM использовать prepared statements, код будет уязвим. Пример плохого prompt:

# Плохой prompt
"""
Напиши функцию для поиска пользователя по email в Postgres.
"""

Результат — LLM генерирует:

def find_user(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    cur.execute(query)
    return cur.fetchone()

Это уязвимо для SQL-инъекций.

Слабая обратная связь с LLM

Без автоматизированного feedback-контуров (например, через semgrep + Claude) агент не учится на ошибках. В итоге паттерны уязвимостей повторяются.

Продакшн-паттерны для LLM orchestration

Реальный пример: Claude Code + n8n + Supabase

Я внедрил в pipeline промежуточный шаг:

import subprocess

def safe_exec(generated_code: str):
    with open("temp.py", "w") as f:
        f.write(generated_code)
    result = subprocess.run(
        ["bandit", "-r", "temp.py"], 
        capture_output=True, text=True
    )
    if "No issues identified." not in result.stdout:
        raise Exception("Unsafe code blocked")
    # Safe to execute or merge

Теперь даже если LLM генерирует небезопасный код, orchestration это ловит до попадания в прод.

Промежуточные human-in-the-loop проверки

В 5 из 14 production-агентов я добавил ручное ревью на этапе PR, если хотя бы один статический анализатор находит ошибку. Это снижает скорость, но спасает от критических уязвимостей.

Автоматизация human-in-the-loop

Можно подключить n8n workflow для автоматической эскалации на ревью:

// n8n custom node
if (staticAnalysis.findings.length > 0) {
  sendToHumanReview(prId, staticAnalysis.findings);
}

Реальный кейс: в логистическом проекте (2024) AI-агент пропустил hardcoded credentials, gitleaks сигнализировал — PR ушёл на ручную проверку.

FAQ

Можно ли полностью автоматизировать quality gate для LLM-кода?

В обычном пайплайне — нет. Даже лучшие статические анализаторы пропускают нестандартные паттерны; human-in-the-loop всё равно нужен на этапе security-sensitive кода.

Какие минимальные инструменты ставить в orchestration?

bandit, semgrep, gitleaks — обязательно. Если работаете с credentials — OWASP checker. Для SQL — отдельный sanitize-layer (например, через psycopg2 + prepared statements).

Как формулировать prompt для безопасного кода?

Добавляйте explicit constraints: «использовать только prepared statements», «не использовать eval», «логгировать только через стандартный logging».

Как быстро выявить повторяющиеся баги LLM-кода?

Собирайте статистику findings из стат-анализа, агрегируйте типы ошибок, корректируйте промпты и orchestration. Не полагайтесь только на тесты.

Что делать, если LLM стабильно генерирует уязвимый код?

Меняйте wording prompt, используйте system-level инструкции, доводите до fine-tuning если возможно, не забывайте про human review.

В какой момент вашего orchestration pipeline чаще всего всплывают баги — на этапе статического анализа, в runtime sandbox или уже в ревью? Поделитесь опытом. Провожу бесплатный 30-мин аудит стека для DACH-фаундеров с AI в проде. Пишите в LinkedIn или на @ger_dennis_ai.