План на 1700 строк, 24 задачи, критерии приёмки и команды для проверки у каждой: автор новой публикации на Habr фактически описал не приступ графомании, а новую норму инженерной работы. ИИ-агенты в разработке резко удешевили сам процесс написания кода, а самым дорогим местом сделали то, что раньше многим казалось обслуживающей функцией, — постановку задачи и проверку результата.
Как пишет Habr / Карьера, автор текста поймал себя на неприятной мысли: утро ушло не на код, а на редактирование документа о том, как этот код будет написан. Дальше он формулирует тезис без лишней романтики: код стал дешёвым, потому что агент может переписывать модуль сколько угодно раз, на любом языке и без усталости. Но вместе с этим резко выросла цена ошибок на входе и на выходе. Если задача сформулирована расплывчато, агент уверенно уедет не туда. Если проверка результата слабая, он столь же уверенно доложит, что всё готово и «тесты зелёные».
Главная мысль публикации хорошо попадает в нерв 2026 года: работа разработчика не исчезла, а переехала. Не в смысле «программистов заменили», а в более неприятном и более практичном смысле. Центр тяжести сместился от ручной реализации к созданию точного инженерного контекста. В тексте это описано через два края процесса. Первый край — план как документ, а не как быстрый промпт в чат. Автор собирает подробные планы с точными путями к файлам, фрагментами before/after, проверочными командами и acceptance criteria так, чтобы новая сессия, впервые увидевшая проект, могла выполнить шаг без уточняющих вопросов. Логика здесь простая: ошибка, пойманная на уровне текста, обходится дешевле, чем та же ошибка, пойманная на середине реализации.
План стал продуктом, а не прелюдией
Из заметки особенно хорошо видно, что длинный план в этой модели работы перестаёт быть бюрократией. Он становится полноценным артефактом разработки, почти как спецификация или контракт. Автор приводит показательный пример: после составления плана его дополнительно ревьюит модель другого класса. Если план собран в одной системе, то проверка уходит в другую. На практике это даёт не косметические правки, а десяток с лишним замечаний за проход, из которых несколько оказываются критичными: противоречивые критерии приёмки, сломанные инварианты между задачами, неописанное поведение в degraded-режиме. Для человека, который глазами идёт по 1700 строкам, такие дыры легко пропустить. Для команды, где агент уже пишет заметную часть кода, пропущенная дыра превращается в баг не через абстрактное «когда-нибудь», а через день-два работы.
На этом месте публикация цепляет не только разработчиков, но и продактов, техлидов, CTO и даже HR. Потому что речь уже не о навыке «уметь писать хороший промпт». Речь о том, кто в команде умеет превращать размытое пожелание в проверяемую инженерную правду. Условно, если раньше сильный разработчик был тем, кто быстрее и чище реализует функцию, то теперь в связке с агентами не меньше ценится специалист, который умеет заранее снять двусмысленность: где границы задачи, какие инварианты нельзя ломать, что считается успешным поведением, что делать при частичном отказе и как это проверить машиной, а не верой в красивый отчёт.
Это важный разворот и для бизнеса. Когда код становится дешёвым, соблазнительно поверить в лендинговую сказку про «автономную разработку», которую можно запустить на ночь и утром получить результат. Автор текста по сути спорит именно с этой идеей. Дополнительный агент-проверяльщик не решает проблему автоматически, если он мыслит в той же логике и наследует те же слепые зоны. Модель может убедительно подтвердить собственную ошибку, а оркестратор из нескольких моделей способен лишь масштабировать эту проблему. Для компаний это означает неприятную, но полезную вещь: эффективность ИИ-агентов в разработке растёт не там, где их больше, а там, где жёстче дисциплина постановки и верификации.
Зелёные тесты больше не аргумент
Второй край процесса в статье описан ещё жёстче: нужна такая машинная проверка, которую нельзя заболтать. Здесь автор опирается не на футуризм, а на старую добрую инженерную базу — типы, контракты, жёсткие тестовые гейты и проверку наблюдаемого поведения. Пример с несовпадающими строками CAMPAIGN_ABORTED и CAMPAIGN_ABORT показателен именно своей банальностью. Агент не заметил разницы и бодро сообщил об успехе, потому что обе версии выглядели для него правдоподобно. Контракту всё равно на правдоподобие: либо строка совпадает, либо нет. Та же история с TypeScript, который не даёт пройти сборке, если сломан контракт. С компилятором нельзя договориться формулировкой «почти работает».
Для русскоязычного IT-рынка это звучит как плохая новость только на первый взгляд. На деле здесь скорее происходит переоценка профессии. Рутинная реализация отдельных модулей действительно дешевеет. Зато дорожают архитектурное мышление, системный QA, продуктовая точность, способность собирать критерии приёмки и превращать поведение системы в формализованные проверки. Если команда по-прежнему меряет зрелость числом написанных строк или скоростью генерации pull request, она рискует очень быстро получить поток кода, который невозможно уверенно принять. Если же команда строит процесс вокруг планов, контрактов и жёстких гейтов, агенты становятся не заменой инженерам, а ускорителем для тех, кто умеет держать рамку.
Из этого следует и более приземлённый вывод для найма. Похоже, рынок будет всё выше ценить не просто «сеньоров, которые пишут быстро», а тех, кто умеет задавать структуру: формулировать задачу без тумана, видеть конфликт требований до реализации, ставить проверку на поверхность, которую видит пользователь, а не только на внутренний happy path. ИИ-агенты в разработке не отменяют инженерную ответственность, а делают её заметнее. Чем дешевле производство кода, тем дороже обходится самообман в процессе его приёмки.
Пожалуй, самый неудобный вопрос после этой публикации звучит так: если код уже стал дешёвым, то на чём именно держится ваш процесс — на реальных проверяемых тисках или на надежде, что очередной агент не ошибётся? У многих команд ответ на этот вопрос окажется не про технологии, а про дисциплину мышления. И именно она, похоже, становится новым дефицитом.