Два разработчика открывают один и тот же coding agent, выбирают одну и ту же модель и дают почти одинаковую задачу. Через час у первого — небольшой, понятный diff. У второго — 900 строк кода, новая библиотека, три слоя абстракций и тесты, которые проверяют моки собственных моков.
Формально оба стали быстрее. Но только один сохранил контроль над системой.
Вокруг AI coding долго держалась удобная идея: если модель умеет писать код, разница между опытным и начинающим разработчиком должна сокращаться. Модели действительно превратили многих специалистов в неплохих универсалов. Backend-разработчик теперь может собрать аккуратный интерфейс, а frontend-разработчик — разобраться с SQL-планом без вечера в документации.
Однако в сложной работе происходит обратное. Чем сильнее coding agent, тем больше он вознаграждает человека, который знает, где остановить генерацию, какой вопрос задать и почему решение, выглядящее профессионально, не подходит именно этому репозиторию.
Модель снижает стоимость написания кода. Она не снижает стоимость правильного решения.
Почему эта тема внезапно стала большой
Эссе LLMs reward expertise вызвало крупную дискуссию среди разработчиков. Его главный тезис прост: важнейший навык работы с LLM — не искусство составлять длинные промпты, а знание предметной области.
Почти одновременно появилась другая формулировка той же проблемы — cognitive debt, или когнитивный долг. Это код, который команда формально получила, проверила и даже выпустила, но не встроила в собственную модель системы.
Технический долг означает: «мы понимаем решение, но выбрали компромисс». Когнитивный долг опаснее: «решение работает, но никто уже не уверен, почему оно устроено именно так».
Один API, разные результаты
Эксперт не обязательно пишет более красивый промпт. Часто его запрос короче:
Добавь идемпотентность в обработчик оплаты. Используй существующий ключ операции и текущий Redis-клиент. Схему БД не меняй. Сначала покажи, где возможна повторная запись.
В этих четырёх предложениях скрыта модель системы: где находится источник истины, какие компоненты уже существуют, какой класс изменений нежелателен и какую ошибку нужно искать до написания кода.
Запрос «сделай обработчик оплаты надёжным» тоже даст результат. Но модель сама заполнит недостающие решения. Она выберет границы транзакции, способ хранения ключа, стратегию повторов и иногда новую зависимость. Код может выглядеть убедительно, хотя четыре архитектурных решения были приняты без участия владельца системы.
Когда знания мало | Когда есть модель системы |
Пользователь оценивает ответ по полноте и стилю | Разработчик оценивает изменение по инвариантам и последствиям |
Модель сама выбирает архитектуру | Модель работает внутри заданных ограничений |
Большой diff кажется признаком выполненной работы | Лишняя строка требует обоснования |
Ошибки находят после запуска | Риск формулируют до генерации |
Диалог заканчивается на «works» | Диалог заканчивается объяснимым изменением |
Настоящий навык — заметить, что ответ «странный»
Сильные модели хорошо производят локально правдоподобный код. Поэтому очевидных ошибок становится меньше, а цена чувства несоответствия растёт.
Опытный разработчик замечает не только неправильный синтаксис. Он видит, что:
· в проекте уже есть похожий механизм, но Agent создал второй;
· простая функция внезапно потребовала framework;
· новый retry нарушает идемпотентность;
· тест фиксирует реализацию, а не поведение;
· данные проходят в обход принятой границы доверия;
· оптимизация уничтожает важную наблюдаемость.
Такое знание трудно заменить универсальным чек-листом. Оно состоит из истории инцидентов, компромиссов команды, особенностей нагрузки и десятков решений, которые нигде полностью не записаны.
Как появляется когнитивный долг
Обычный цикл выглядит безобидно:
1. Agent получает задачу и быстро создаёт большой diff.
2. Разработчик смотрит на зелёные тесты и бегло читает изменения.
3. Код попадает в production.
4. Через месяц нужно изменить соседнее поведение.
5. Никто не помнит исходные допущения, поэтому задачу снова передают Agent.
6. Новая генерация добавляет ещё один слой поверх первого.
Каждая итерация экономит время локально и повышает стоимость следующей. Репозиторий продолжает работать, но его карта постепенно исчезает из головы команды.
Главный индикатор когнитивного долга: разработчик может показать, что код проходит тесты, но не может быстро объяснить, какие инварианты он сохраняет и при каких условиях решение перестанет быть верным.
Перепечатывать весь AI-код вручную — хорошая идея?
Один из обсуждаемых подходов намеренно радикален: просить Agent показывать изменения в чате, а затем вводить их в редактор вручную. Это медленно, но заставляет читать каждую строку, замечать чужой стиль и строить пространственную карту проекта.
Для обучения, небольшого личного продукта или критичного модуля метод полезен. Для команды, которая меняет тысячи строк в неделю, он плохо масштабируется. Но из него стоит забрать главный принцип: скорость ввода не должна быть выше скорости понимания.
Печатать каждую скобку необязательно. Остановить Agent после плана, ограничить размер diff и потребовать объяснить спорные решения — обязательно.
Практический протокол: Plan, Patch, Prove
1. Plan: сначала карта изменения
До редактирования файлов Agent должен назвать затронутые компоненты, инварианты, неизвестные и варианты решения. Запрет на преждевременный код экономит больше времени, чем особенно точный промпт.
Before editing files:
1. Trace the current request path.
2. List the invariants that must remain true.
3. Identify the smallest set of files to change.
4. Describe two possible approaches and their failure modes.
5. Stop and wait for approval.
2. Patch: небольшой diff с бюджетом
Задайте предел: например, не более пяти файлов и 250 изменённых строк без повторного согласования. Это не магические числа, а защита от архитектуры, которая появляется только потому, что генерация дешёвая.
Попросите использовать существующие abstractions, не добавлять зависимости без причины и не проводить «попутный рефакторинг». Большой рефакторинг и изменение поведения должны быть разными задачами.
3. Prove: доказательство важнее уверенного объяснения
После генерации Agent должен не хвалить решение, а пытаться его сломать:
· какой тест сейчас отсутствует;
· какое предположение зависит от внешней системы;
· что произойдёт при Timeout, повторе и частичном сбое;
· какой вход нарушит текущую логику;
· как откатить изменение;
· какие метрики подтвердят корректность в production.
Не просите одну модель одновременно писать и судить себя
Самопроверка полезна, но автор решения уже закреплён в собственном контексте. Для важных изменений лучше разделить роли:
7. Architect строит план и фиксирует ограничения.
8. Implementer создаёт минимальный patch.
9. Reviewer получает задачу, diff и тесты, но не видит оправдания автора.
10. Adversary ищет способы нарушить инварианты и границы доверия.
Роли можно выполнять разными запусками одной модели, но независимость выше, если Reviewer использует другую модель и отдельный контекст. Через OdiRouter.ai такой процесс можно собрать на едином API: не привязывать весь pipeline к одному поставщику и сравнивать модели на одинаковых репозиториях, тестах и критериях.
Важно не устраивать «голосование моделей». Три уверенных ответа не превращают ошибку в истину. Финальным арбитром остаются инварианты, выполняемые тесты, наблюдаемость и инженер, который понимает область.
Что отдавать Agent, а что оставлять человеку
Хорошо делегируется | Требует человеческого владения |
Механические миграции по заданному шаблону | Выбор границ системы и источника истины |
Генерация тестовых случаев после фиксации инвариантов | Определение того, что считается корректным поведением |
Поиск вызовов, зависимостей и похожего кода | Компромисс между скоростью, стоимостью и риском |
Черновик документации и runbook | Решение о production-доступе и необратимых действиях |
Локальный рефакторинг с тестами | Принятие архитектуры, которую команда будет поддерживать |
Как измерять не только скорость
Количество закрытых задач и сгенерированных строк создаёт красивый график, но не показывает, сохранила ли команда контроль. Добавьте более неприятные метрики:
· Time to Explain: сколько времени автору нужно, чтобы объяснить изменение без помощи Agent;
· Review Compression: отношение размера diff к содержательным замечаниям;
· Rework after 30 days: сколько AI-изменений пришлось переписать после столкновения с реальностью;
· Unknown Ownership: доля модулей, для которых команда не может назвать владельца и основные инварианты;
· Dependency Growth: сколько новых зависимостей появилось на единицу пользовательской ценности;
· Rollback Readiness: можно ли быстро отменить результат генерации.
Если throughput вырос вдвое, а время объяснения и число повторных исправлений растут быстрее, команда не стала производительнее. Она взяла кредит у будущих разработчиков.
Новая роль опытного разработчика
AI coding не возвращает нас к ручному набору каждой строки. Он меняет место, где находится дорогая работа.
Раньше опыт проявлялся в способности быстро написать реализацию. Теперь всё чаще — в способности сжать пространство решений: назвать правильные ограничения, отбросить эффектный, но чужой паттерн, отделить симптом от причины и потребовать доказательство там, где модель предлагает уверенность.
Новичок с сильной моделью действительно может быстрее получить работающую функцию. Эксперт с той же моделью получает не только функцию, но и решение, совместимое с историей, рисками и будущим системы.
Вывод
LLM демократизировали доступ к коду, но не к инженерному суждению. Чем дешевле становится генерация, тем дороже способность понять, какой код вообще не следовало писать.
Поэтому зрелый AI workflow начинается не с выбора между Codex и Claude Code и не с коллекции «идеальных промптов». Он начинается с модели системы в голове команды, ограниченного patch, независимой проверки и права сказать: решение работает, но нам оно не подходит.
Самая опасная фраза эпохи AI coding — не «модель ошиблась». Самая опасная фраза: «тесты зелёные, значит, потом разберёмся».