ИГОП и поехали, или как меньше чистить и больше проверять
Год спустя после ассенизатор-driven development: что изменилось, и почему теперь можно проверять 20 гипотез в день вместо двух.
Год спустя
Примерно год назад я написал про ассенизатор-driven development - про то, как мы перестали писать код и начали разгребать то, что нам нагенерил ИИ. Тогда это было прямо так. Чистить приходилось много-много.
Сейчас это тоже частично так. Но становится лучше. И появились скиллы для чистки - линтеры, гейты, правила, ревью-агенты. Только не это главное.
Главное в другом: модели двигаются вперёд, а качество кода при использовании механизмов контроля и управления становится доступным. Не гарантированным - доступным. Разница принципиальная.
Идейная-идея
Теперь уже почти можно сказать, что у нас есть инструмент для идейно-гипотезо-ориентированного программирования.
Раньше как было. Есть гипотеза: “а если хранить не так, а вот эдак - станет быстрее?” Чтобы её проверить, надо написать код. Проверить. Добиться, чтобы он мне нравился. Пару дней на одну-две гипотезы - и это в хорошем случае, когда не уехал в рефакторинг соседнего модуля.
Теперь я проверяю 20 гипотез в день. Не потому что стал умнее. Потому что стоимость проверки упала на порядок. А когда убедился, что оно мне нравится - вот тогда довожу код до нужного уровня. Руками, вдумчиво, как раньше.
Ключевое смещение: код перестал быть способом проверки идеи. Он снова стал результатом принятого решения.
Почему TDD вдруг заработал
В прошлом посте я честно писал напротив каждого совета: “Не спасает :-)”. TDD, линтеры, security-сканы - всё не спасало.
Кое-что поменялось. Не сами практики - поменялось то, кто их исполняет.
Раньше цепочка была такая: я пишу спеку → ИИ генерит → я проверяю. Три шага, и на третьем я тонул, потому что проверять чужой многословный код тяжелее, чем написать свой.
Теперь: я пишу спеку → агент генерит → агент прогоняет тесты, линтер, типы → агент чинит сам → я смотрю на результат, который уже прошёл через ворота.
Тесты, написанные ДО генерации, наконец работают - но не как страховка для меня, а как функция вознаграждения для агента. Ему есть куда упереться. Это не “ИИ стал лучше писать код”, это “у ИИ появился способ понять, что он написал плохо, без моего участия”.
PS: Спека, кстати, тоже мутировала. Раньше это был документ для человека. Теперь это исполняемый контракт: что на входе, что на выходе, какие инварианты, чего категорически нельзя. Пишется дольше обычного тикета. Окупается с первого прогона.
Spec-driven, а не vibe-driven
Разница между Spec-driven development и вайб-кодингом - примерно как между инженерией и надеждой.
| Вайб-кодинг | Spec-driven | |
|---|---|---|
| Что на входе | “сделай мне красиво” | контракт: вход, выход, инварианты |
| Кто проверяет | никто, глазами | тесты, типы, линтер, свойства |
| Когда узнаёшь о проблеме | в проде | до первого коммита |
| Что делаешь при ошибке | промптишь заново | правишь спеку |
| Понимаешь ли код | не полностью | да, ты его спроектировал |
Правая колонка - не новая методология. Это ровно то, чему учат лет тридцать. Просто раньше на это не хватало времени, потому что всё время съедало написание кода. Теперь время есть.
Ирония в том, что ИИ вернул ценность старым скучным вещам: типам, контрактам, тестам, чётким границам модулей. Всё, что раньше было “ну надо бы, но некогда”, стало тем, без чего агент работать не может.
Агентная разработка: что реально изменилось
Три вещи, которые сдвинули картину сильнее всего:
Обратная связь без человека. Агент, который может запустить тесты и прочитать ошибку, отличается от автодополнения примерно как компилятор от справочника. Он итерируется сам, пока не сойдётся - или пока не упрётся и не признается, что не может.
Параллельность. Пять гипотез можно проверять одновременно, в изолированных ветках. Раньше это упиралось в меня как в узкое место: одна голова - один контекст. Теперь узкое место - сформулировать пять внятных гипотез.
Стоимость выброса. Вот это, пожалуй, главное. Код, который писался два дня, выбросить психологически тяжело - жалко. Код, который сгенерился за десять минут, выбрасывается легко. А лёгкость выброса - это и есть свобода экспериментировать.
PS: Отдельно про изоляцию. Пускать несколько агентов в один рабочий каталог - это вернуться в то самое коричневое из прошлого поста. Отдельные worktree, отдельные ветки, никакого общего состояния. Скучно, но работает.
Что не изменилось
Честно, чтобы не выглядело рекламой светлого будущего:
- Голова болит так же. Когнитивная нагрузка не исчезла, она переехала. Раньше я держал в голове код - теперь держу в голове систему, спеку и то, чего агент не понял. Не легче. Просто по-другому.
- Проверять всё равно надо. Тесты ловят то, что описано в тестах. Дизайн-дефект, дырку в авторизации, “формально работает, но архитектурно тупик” - это по-прежнему на мне.
- Джуны по-прежнему деградируют. Как преподаватель повторю то же, что писал год назад: понимание внутреннего устройства не появляется от того, что задача решена. Инструмент стал мощнее - вопрос “а ты понял, почему это работает?” стал только важнее.
- Security-critical пути - руками. Авторизация, платежи, работа с секретами. Тут ничего не поменялось и, надеюсь, не поменяется.
Заключение
Год назад я писал, что профессия мутирует: мы не пишем код, мы его курируем. Мутация продолжается, но вектор сместился.
Мы двигаемся от “разгребать сгенерированное” к “формулировать и проверять”. От ассенизатора - к исследователю с очень быстрым лабораторным оборудованием. Оборудование иногда врёт, реактивы протухшие, а половина экспериментов не воспроизводится - но двадцать проверенных гипотез в день против двух это всё равно другая профессия.
Проще ли это? Судить вам. Так же ли болит голова? У меня точно :-)
Навык, который дорожает - не “быстро промптить” и даже не “быстро читать чужой код”. А сформулировать гипотезу так, чтобы её можно было проверить. Это, вообще-то, определение инженерного мышления. Просто теперь за него наконец платят.
Всем бобра.