Почему ваш 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-класса — пять вспомогательных файлов, три слоя абстракций и десятки функций, которые не вызываются никогда. При этом требования к валидации были минимальными.

Чем опасен лишний код

В 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

Сравнение инструментов для статического анализа

FAQ

Почему нельзя просто вручную резать код после генерации?

Вручную это долго, дорого и не масштабируется. Автоматизация через статический анализ и trimming экономит часы на каждом релизе.

Есть ли смысл использовать ORM/фреймворки против boilerplate?

ORM (например, SQLAlchemy) помогает, но LLM всё равно склонны добавлять лишнее. Важно ограничивать промпты и делать финальный анализ.

Можно ли полностью доверять автоматическому trimming?

Нет — всегда нужен ручной этап ревью, особенно в критических системах. Но trimming убирает до 80% очевидного мусора.

Как это влияет на безопасность?

Меньше кода — меньше площадь атаки. Автоматизация проверки (bandit, semgrep) ловит критические баги до попадания в production.

Как внедрить это в существующий пайплайн?

Постройте автоматизацию вокруг n8n или CI/CD. Интегрируйте анализаторы, добавьте лимиты на уровне промптов. Это внедряется поэтапно.

На каком этапе вашей LLM-пайплайна чаще всего всплывают избыточные или небезопасные куски: генерация, статический анализ или ручное ревью? Я реально хочу узнать детали. Я делаю бесплатный 30-мин аудит стека для DACH-компаний, строящих AI в регулируемых нишах. Пишите в LinkedIn или на @ger_dennis_ai.