Агент пишет быстро, а вы замедляетесь: долг понимания вместо «плохого кода»

Соло-разработчик с агентом для кода в ежедневном цикле легко выигрывает по скорости генерации — и проигрывает по темпу, когда перестаёт объяснять систему своими словами. Скрытая цена AI-assisted coding здесь не в качестве diff, а в comprehension debt — долге понимания между кодовой базой и вашей ментальной моделью. Автор bluelobster_agent предлагает облегчённый протокол с явным результатом «понимание»: через agent skill, правила в AGENTS.md и self-review без отдельного ревьюера.

Почему «тесты зелёные» — не конец разговора с агентом

Типичный кейс из материала: агент за минуты выдал реализацию, типы и тесты прошли, diff выглядел разумно — но автор не смог объяснить изменение, не глядя в код. Измерялось время до working code, а не до understanding: первое сжалось, второе выросло.

Comprehension debt — отдельно от technical debt. Можно иметь элегантный, протестированный код и при этом нести опасный разрыв между тем, что лежит в репозитории, и тем, что вы реально понимаете.

Фраза агента вроде «Implementation complete. All 84 tests pass» в примере поста должна открывать review, а не закрывать его. Тесты — evidence, не understanding. Для соло-workflow это означает: зелёный CI не заменяет ответ на вопрос «почему эта абстракция здесь и что сломается в проде в 2 a.m.».

Автор вводит эвристику (прямо помечает как не научную формулу):

comprehension debt = change surface × unfamiliarity × time since explanation

Чем шире поверхность изменений и дольше вы не проговаривали модель системы, тем дороже обходится каждый следующий запрос к агенту.

Старый цикл разработки и агентный «просмотр и принять»

Раньше трение учило систему: understand → design → write → debug → understand better. Каждый баг и каждый рефакторинг возвращали вас к модели.

Агентный цикл чаще выглядит иначе:

request → generate → skim → accept → next task

Артефакты появляются быстро, но дефицитом становится суждение (judgment), а не производство кода. После merge AI-изменения автор предлагает пять контрольных вопросов: почему выбрана абстракция, какой инвариант защищён, вероятный failure mode в проде, что агент не менял, как дебажить ночью. Нет ответов — работа не исчезла, а отложена с процентами.

Если пять агентов шлют пять PR, а один человек ответственно ревьюит один, узкое место — не keystrokes, а judgment bottleneck. Для одного разработчика с параллельными agent task тот же эффект: скорость генерации обгоняет скорость осмысления.

Протокол Explain → Plan → Patch → Prove → Teach

Автор называет workflow Explain → Plan → Patch → Prove → Teach и применяет его к любой нетривиальной задаче агента. Пять шагов — не бюрократия ради бюрократии, а способ вернуть понимание в конвейер до того, как diff разрастётся до иллюстративных «700 строк» из примера в посте.

Шаг	Суть	Ограничение
Explain	Агент объясняет систему plain language до правок: flow, инварианты, change surface, допущения, зона неуверенности. Код писать нельзя.	Поймать неверную модель до diff.
Plan	План описывает решения, не список файлов. File list ≠ decision list.	Auth boundary, parsing, contract test — как примеры «хорошего» плана.
Patch	Минимальное обратимое изменение: править существующий код, не трогать unrelated formatting.	Стоп после 5 файлов; новая зависимость — только с approval.
Prove	Не только green tests: узкие тесты, один failure-path test, что осталось непротестированным, diff на scope creep.	Агенты сильны в confirmation; инженерия ищет опровержения.
Teach	Передача владения: объяснение патча до 250 слов (problem, key decision, data flow, отвергнутая альтернатива, debug entry point), затем 3 вопроса на проверку понимания.	Если вы сами не отвечаете — задача не done.

Stop conditions важнее «умных» промптов: автономным агентам нужен budget — по файлам, зависимостям, миграциям, permissions. Без лимитов скорость агента превращается в скорость накопления непонятного кода.

Agent skill и rules вместо хрупкого повторного prompting

Повторный prompting на каждую задачу хрупок. Автор хранит workflow в небольшом reusable instruction file с YAML-frontmatter:

name: comprehension-first-change
description: Use for non-trivial code changes where maintainability and human understanding matter.

Внутри — секции Before editing / While editing / Verification / Handoff с теми же ограничениями: 5 files, dependencies с approval, 250 words, 3 comprehension questions. Формат для вас может быть skill, repository instruction, AGENTS.md rule или чеклист — «format matters less than making understanding an explicit deliverable».

Для соло-разработчика это практичный вынос: не надеяться, что агент «сам догадается», а зафиксировать comprehension-first как постоянное правило в репозитории. Повторяющийся prompting заменяется одним артефактом, который агент подхватывает на каждой нетривиальной задаче.

Три полосы: Green, Yellow, Red

Не всё требует полного пятиступенчатого протокола. Автор делит работу на три lane:

Lane	Тип	Процесс
Green	typo, formatting, mechanical rename	generate, diff, merge
Yellow	local feature, bug fix, small refactor	plan, patch, prove
Red	auth, payments, data migration, concurrency, public API	explain, approve, patch, prove, teach

Цель — не замедлить всё подряд, а тратить human attention там, где misunderstanding дорого. Соло-разработчик без отдельного продакта особенно выигрывает от явной классификации: агент не должен выполнять полный Teach на опечатке, но и не должен мержить auth-изменение по шаблону «тесты прошли».

Что измерять вместо сгенерированных строк

«Lines of code generated» почти бессмысленны; «tasks completed» лучше, но неполны. Автор предлагает четыре вопроса владения (ownership):

1. Может ли другой разработчик объяснить изменение?
2. Может ли он указать failure boundary?
3. Может ли модифицировать без перезапуска agent conversation?
4. Может ли команда ревьюить со скоростью производства PR?

Для одного человека с агентами переформулировка проста: можете ли вы ответить на эти вопросы сами — без открытия diff и без нового чата с моделью. Если нет, агент был быстрым, а вы — медленнее, потому что каждый следующий шаг требует заново «сканировать» чужой код.

В конце поста автор спрашивает читателей: какое у вас правило принятия AI-generated code — достаточно ли passing tests или нужно, чтобы изменение было объяснено команде (или вам самим, в соло-режиме). Это не риторика: от ответа зависит, останется ли agent workflow ускорителем или превратится в конвейер comprehension debt.

Источники

• Your AI Coding Agent Is Fast. You're Still Getting Slower. — Dev.to, автор bluelobster_agent, опубликовано 13 июля 2026. Дата доступа: 14 июля 2026.