Почему ваш AI-агент пишет слишком много кода — и как это исправить
Я — Денис Шохирев, Enterprise AI architect, работаю в Фрайбурге (Германия) и руковожу DennisCraft AI Studio. За последние полгода я внедрил 14 production AI-агентов для B2B-клиентов в логистике, финтехе и промышленной автоматизации — стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. За это время столкнулся с повторяющейся ошибкой: AI-агенты генерируют кода в несколько раз больше, чем реально нужно бизнесу. Это превращается в проблему поддержки и безопасности — и я покажу, как решаю это на практике.
Почему LLM-агенты склонны к избыточности
Большинство современных LLM (Claude, GPT-4, Gemini) обучены на огромных корпусах кода — от Stack Overflow до GitHub. Их внутренняя логика: лучше выдать «чуть больше», чем «чуть меньше». В результате в продакшн попадает тонна boilerplate, дублирования, ненужных промежуточных слоёв.
Реальный пример
В одном из недавних проектов для финтех-клиента агент на базе Claude сгенерировал 3000+ строк Python для простого ETL: вместо лаконичного ORM-класса — пять вспомогательных файлов, три слоя абстракций и десятки функций, которые не вызываются никогда. При этом требования к валидации были минимальными.
Чем опасен лишний код
| Риск | Описание | Последствия |
|---|---|---|
| Рост площади атаки | Чем больше кода, тем выше шансы на уязвимость | Больше false positives на bandit/semgrep, выше вероятность SQL-инъекций и XSS |
| Затраты на ревью | Ревью сильно замедляется на больших диффах | Больше времени QA и devops, медленнее релизы |
| Проблемы поддержки | Легко сломать что-то ненужное при рефакторинге | Рост багов в production, труднее объяснять поведение |
В 2023 году исследование Stanford CodeGen показало: 38% кода, сгенерированного LLM для задач CRUD, содержат паттерны CWE-89 (SQL injection). Источник: arxiv.org/abs/2307.07924. Мой опыт подтверждает: чем больше кода — тем выше риск.
Почему LLM-агенты так делают: корень проблемы
1. «Лучше перебдеть» — модель оптимизирует полноту, а не лаконичность
LLM-агенты не понимают бизнес-контекст, они фокусируются на «корректности» по их представлению. Это ведёт к обилию заглушек, дублирования, лишних слоёв. Даже простая задача может внезапно разрастись до многофайлового модуля.
2. Промпты без жёстких рамок
Если промптить Claude или GPT-4 без ограничений по длине/структуре, они всегда сгенерируют «максимально подробное» решение. Особенно если использовать инструкции типа «напиши production-ready код» — LLM перестраховывается.
3. Отсутствие автоматизированной пост-обработки
Большинство пайплайнов — промпт → ответ → сразу в PR. Нет этапа фильтрации, сокращения, удаления неиспользуемого. Много кто надеется на ручной рефакторинг, но это не масштабируется.
Как я решаю проблему: рабочие паттерны
1. Жёсткие ограничения в промптах
В каждом запросе к Claude или GPT-4 задаю лимит по длине (например, 80 строк), требую однострочные docstring и описание бизнес-логики в комментариях. Результат: код становится короче на 30-50% без потери функционала.
PROMPT = """
Напиши Python-класс для коннекта к Supabase.
Только 1 файл, не больше 80 строк.
Документируй только публичные методы.
Без тестов и лишних зависимостей.
"""2. Автоматизация пост-обработки: statical analysis + trimming
После генерации прогоняю код через semgrep и bandit — ищу dead code, небезопасные паттерны, неиспользуемые импорты. Потом использую скрипты на Python для авто-обрезки неиспользуемых функций.
import ast
def remove_unused_functions(code):
tree = ast.parse(code)
used = {node.id for node in ast.walk(tree) if isinstance(node, ast.Name)}
new_body = []
for node in tree.body:
if isinstance(node, ast.FunctionDef):
if node.name in used:
new_body.append(node)
else:
new_body.append(node)
tree.body = new_body
return ast.unparse(tree)
3. Ревью и автоматизация через n8n
В n8n собираю пайплайн: после генерации код обрабатывается автоматическими проверками (semgrep, bandit, gitleaks), затем отправляется ревьюеру. Только после ручной проверки код попадает в репозиторий.
- name: LLM Code QA
steps:
- run: semgrep --config=auto src/
- run: bandit -r src/
- run: gitleaks detect --source=src/
- assign: code-reviewer
- if: passed
then: merge
Сравнение инструментов для статического анализа
| Инструмент | Языки | Фокус | Интеграция в пайплайн |
|---|---|---|---|
| semgrep | Python, JS, TS, Go, др. | Поиск паттернов, dead code | CLI, n8n, CI/CD |
| bandit | Python | Безопасность, CWE | CLI, CI |
| gitleaks | Все | Поиск секретов | CLI, n8n |
FAQ
Почему нельзя просто вручную резать код после генерации?
Вручную это долго, дорого и не масштабируется. Автоматизация через статический анализ и trimming экономит часы на каждом релизе.
Есть ли смысл использовать ORM/фреймворки против boilerplate?
ORM (например, SQLAlchemy) помогает, но LLM всё равно склонны добавлять лишнее. Важно ограничивать промпты и делать финальный анализ.
Можно ли полностью доверять автоматическому trimming?
Нет — всегда нужен ручной этап ревью, особенно в критических системах. Но trimming убирает до 80% очевидного мусора.
Как это влияет на безопасность?
Меньше кода — меньше площадь атаки. Автоматизация проверки (bandit, semgrep) ловит критические баги до попадания в production.
Как внедрить это в существующий пайплайн?
Постройте автоматизацию вокруг n8n или CI/CD. Интегрируйте анализаторы, добавьте лимиты на уровне промптов. Это внедряется поэтапно.
На каком этапе вашей LLM-пайплайна чаще всего всплывают избыточные или небезопасные куски: генерация, статический анализ или ручное ревью? Я реально хочу узнать детали. Я делаю бесплатный 30-мин аудит стека для DACH-компаний, строящих AI в регулируемых нишах. Пишите в LinkedIn или на @ger_dennis_ai.
