Почему обычный ChatGPT не пишет хороший код (и никогда не напишет)
Вы открываете ChatGPT, пишете "напиши микросервис на FastAPI для обработки платежей", получаете 150 строк кода. Красиво. Запускаете — падает на первой же транзакции. Почему? Потому что ChatGPT — это просто большая языковая модель, обученная предсказывать следующее слово. Не писать работающий код. Не понимать архитектуру. Не отлаживать.
AI-кодинг-агенты вроде GitHub Copilot, Cursor или Tabnine работают иначе. Они не просто дополняют код — они его проектируют, тестируют, исправляют. Но чтобы использовать их эффективно, нужно понимать, как они устроены изнутри. И главное — где они ломаются.
Важно: AI-агент ≠ LLM. LLM — это движок, агент — это система с памятью, планированием и инструментами. Как в статье про Production-ready AI-агент с нуля, где мы разбирали ReAct и Advanced RAG.
Архитектура: что скрывается за кнопкой "Generate"
Когда вы нажимаете "Сгенерировать код" в Cursor, запускается цепочка из пяти компонентов. Каждый — отдельная система со своими сбоями.
1 Planning Engine — мозг агента
Сначала агент не пишет код. Он строит план. "Сначала создам модель данных, потом эндпоинты, потом интеграцию с платежным шлюзом, потом обработку ошибок". Это называется reasoning — моделирование рассуждений.
Вот как это выглядит внутри (упрощенно):
# Внутренний диалог агента
plan = [
"Проанализировать требования: микросервис для платежей",
"Определить необходимые эндпоинты: /pay, /status, /refund",
"Спроектировать модель данных Payment, Transaction",
"Интегрировать Stripe API",
"Добавить обработку ошибок и логирование",
"Написать тесты для каждого компонента"
]
Проблема в том, что planning engine часто ошибается. Он может пропустить критически важный шаг — например, валидацию входных данных или rate limiting. Потому что обучался на открытых репозиториях, где эти вещи часто отсутствуют.
2 Code Generation Model — руки агента
Это та самая LLM, но специально дообученная на коде. Не на общих текстах, а на миллиардах строк из GitHub, Stack Overflow, документаций. Fine-tuning делает её экспертом в синтаксисе, но не в семантике.
| Модель | Основа | Специализация | Проблема |
|---|---|---|---|
| Codex (Copilot) | GPT-3 | Мультиязычный код | Устаревшие паттерны (обучен на коде до 2021) |
| Code Llama | Llama 2 | Python, Java, C++ | Слаб в нишевых фреймворках |
| StarCoder | Собственная | 80+ языков | Галлюцинирует в сложной логике |
3 Context Manager — рабочая память
Агент помнит не только ваш текущий запрос, но и весь разговор, открытые файлы, структуру проекта. Это реализовано через векторные базы данных и кэширование эмбеддингов — как в статье про Персональную базу знаний на 106K векторов.
Но контекст ограничен. Обычно 8K-128K токенов. Если ваш проект больше — агент "забывает" начало. Он может генерировать код, который конфликтует с уже написанным, потому что не видит всей картины.
4 Tool Integration — руки вне IDE
Современные агенты умеют запускать shell-команды, делать HTTP-запросы, работать с БД. Это превращает их из генераторов кода в автономных разработчиков. Но с ограничениями:
- Безопасность: агент с доступом к shell может удалить папку node_modules и сломать проект
- Контекст: команда "docker compose up" требует предварительно собранных образов
- Ошибки: если команда падает, агент часто не понимает почему и предлагает неверные решения
5 Feedback Loop — обучение на ошибках
Когда вы принимаете или отклоняете сгенерированный код, агент запоминает это. Не в глобальном смысле (ваши предпочтения не попадают в общую модель), а в рамках сессии. Это reinforcement learning from human feedback (RLHF) в миниатюре.
Но эта система хрупкая. Если вы один раз приняли плохой код (потому что торопились), агент решит, что такой стиль вам нравится, и будет генерировать похожий. Как сотрудник, который перенимает плохие привычки начальника.
Как модели учатся писать код: fine-tuning, RLHF и simulated reasoning
Базовые LLM типа GPT-4 знают синтаксис, но не понимают, что код должен работать. Превращение их в кодинг-агентов — это три этапа, каждый со своими артефактами.
Fine-tuning на code datasets
Берут модель, дообучают на миллионах пар "запрос-код". Например:
# Пример данных для fine-tuning
{
"instruction": "Напиши функцию, которая проверяет валидность email",
"input": "",
"output": "import re\ndef is_valid_email(email):\n pattern = r'^[\\w\\.-]+@[\\w\\.-]+\\.[a-z]{2,}$'\n return bool(re.match(pattern, email, re.IGNORECASE))"
}
Проблема: датасеты содержат устаревший код, уязвимости, плохие практики. Модель учится не только хорошему, но и плохому. Если в данных много SQL-инъекций (да, они есть на GitHub), модель может сгенерировать уязвимый код.
Reinforcement Learning from Human Feedback (RLHF)
После fine-tuning модель пишет код, но он может быть нечитаемым, неэффективным или небезопасным. RLHF решает это: люди-разработчики оценивают сгенерированный код по шкале от 1 до 5, модель учится предсказывать оценки и генерировать то, что понравится людям.
Но RLHF имеет побочный эффект — overoptimization. Модель начинает генерировать слишком "вежливый" код: избыточные комментарии, излишняя обработка ошибок, консервативные паттерны. Код работает, но выглядит как написанный стажером, который боится ошибиться.
Simulated Reasoning — обучение думать, а не угадывать
Самая интересная часть. Модель учат не сразу выдавать ответ, а размышлять цепочкой мыслей (chain-of-thought). Для кодинга это выглядит так:
Запрос: Напиши функцию для поиска дубликатов в списке
Мысли модели:
1. Нужно понять, что считать дубликатом — одинаковые объекты или одинаковые значения
2. Для простых типов можно использовать set()
3. Для сложных объектов нужна функция сравнения
4. Эффективность: O(n²) для наивного решения, O(n) для использования хэш-таблицы
5. Возвращать список дубликатов или булево значение?
Код:
def find_duplicates(items):
seen = set()
duplicates = []
for item in items:
if item in seen:
duplicates.append(item)
else:
seen.add(item)
return duplicates
Simulated reasoning требует огромных вычислительных ресурсов, но даёт качественный скачок. Модель реже галлюцинирует, лучше понимает edge cases. Проблема в том, что reasoning иногда ошибочный — модель может пойти по неправильному пути рассуждений и не заметить этого.
Практические ограничения: что агенты НЕ умеют делать (и не научатся скоро)
Вот список вещей, которые AI-кодинг-агенты делают плохо. Зная их, вы избежите часов отладки и разочарований.
| Ограничение | Пример | Почему возникает | Как обойти |
|---|---|---|---|
| Контекст проекта | Генерирует код, который не вписывается в существующую архитектуру | Ограничение токенов контекста (обычно 8K-128K) | Давать явные инструкции по стилю и архитектуре |
| Бизнес-логика | Неправильно реализует специфичные для домена правила | Модель не знает вашего бизнеса | Сначала описывать логику текстом, потом просить код |
| Производительность | Генерирует O(n²) алгоритм вместо O(n log n) | Обучалась на учебных примерах, а не production коде | Явно указывать требования к сложности |
| Безопасность | Не экранирует SQL-запросы, не валидирует входные данные | В тренировочных данных много уязвимого кода | Использовать статический анализ после генерации |
| Совместимость | Использует API, которое устарело в текущей версии фреймворка | Обучалась на коде до 2021-2023 года | Указывать точные версии зависимостей |
Главная проблема: технический долг в квадрате
AI-агенты генерируют код в 10-100 раз быстрее человека. Но технический долг накапливается не линейно, а экспоненциально. Одна недосмотренная сессия — и в проекте появляются 500 строк кода с тремя разными стилями, противоречивыми архитектурными решениями и скрытыми уязвимостями.
Как в статье AI-агенты генерируют код быстрее, чем вы успеваете его проверить, классическое ревью не работает. Разработчик тратит час на проверку кода, который агент сгенерировал за две минуты. Экономика не сходится.
Решение: не пытаться проверять весь сгенерированный код. Вместо этого установить жесткие правила на этапе генерации — whitelist архитектурных паттернов, blacklist антипаттернов, лимиты сложности. Лучше потратить время на настройку агента, чем на исправление его ошибок.
FAQ: частые вопросы разработчиков
Можно ли доверять AI-агенту безопасность кода?
Нет. Модели обучались на открытых репозиториях, где полно уязвимостей. Они не понимают концепций безопасности, только копируют паттерны. Всегда проверяйте сгенерированный код на уязвимости статическими анализаторами.
Почему агент иногда пишет отличный код, а иногда ерунду?
Из-за стохастичности генерации. Модель не детерминирована — один и тот же промпт может дать разный результат. Температура (параметр случайности) обычно настраивается балансировано, но иногда агент "срывается". Решение: перегенерировать ответ или снизить температуру.
Стоит ли учиться программировать, если есть AI-агенты?
Да, больше чем когда-либо. AI-агенты — это инструменты, которые усиливают разработчика, но не заменяют его. Без понимания архитектуры, алгоритмов, системного дизайна вы не сможете ни правильно сформулировать задачу агенту, ни оценить качество его работы. Как сказано в статье про AI-агентов как сотрудников, они требуют грамотного управления.
Можно ли использовать AI-агенты для legacy кода?
Осторожно. Агенты плохо понимают устаревшие фреймворки и парадигмы. Они могут предложить "современное" решение, которое сломает совместимость. Лучше использовать их для документации, написания тестов или изоляции legacy-компонентов, а не для рефакторинга.
Что будет дальше: три прогноза
- Специализированные агенты для нишевых стеков. Сейчас агенты лучше всего справляются с Python, JavaScript, Java. Через год появятся эксперты в COBOL для банков, Verilog для hardware design, даже для 1C (как бы страшно это ни звучало).
- Локальные модели вытеснят облачные. Как в статье про локальный AI-агент на стероидах, приватность и скорость станут критичными. Компании не захотят отправлять свой код в облако OpenAI.
- AI-агенты станут обязательным навыком в резюме. Умение "управлять" AI-агентом будет цениться так же, как знание Git или умение работать в команде. Не "пишет код", а "формулирует задачи, оценивает результат, интегрирует в проект".
Самый неочевидный совет: начните вести журнал ошибок агента. Записывайте, когда и почему он сгенерировал плохой код. Через месяц вы увидите закономерности — может, он всегда ошибается с асинхронностью или не понимает вашу архитектуру микросервисов. Эти данные бесценны для настройки промптов и выбора инструментов.
AI-кодинг-агенты — не волшебная палочка. Это сложные системы с конкретными ограничениями. Понимая их архитектуру, вы перестанете бороться с агентами и начнёте ими управлять. Как опытный разработчик управляет компилятором: знает его баги, обходит ограничения, использует сильные стороны.
