Почему скорость написания кода не то же самое, что скорость разработки

AI-агенту не нужен отдых. Это понятно. Но порой из этого делают куда менее полезный вывод: разработка теперь может идти без пауз. Один агент пишет код, другой проверяет, третий обновляет документацию, четвёртый что-то ищет в web, пятый осуществляет сведение общего плана и тд. Закончили задачу - берём следующую, и так аж до самой технологической сингулярности.

Казалось бы, кожаные наконец избавились от необходимости иногда прекращать делать новое и возвращаться к уже сделанному - можно просто гнать вперёд. Но здесь, как водится, есть нюанс: что именно получится после нескольких месяцев такой работы - консистентная система или коллекция условно успешно закрытых задач?

Попробуем таки подумать об этот вопрос…

Как лиса сыр делила

В сказке “Два жадных медвежонка”, соответственно - два жадных медвежонка нашли головку сыра, но поделить её не смогли - каждый боялся, что другому достанется больше. На помощь пришла лиса и разломила сыр на два неравных куска, а затем принялась исправлять: откусила от большего - теперь больше другой, откусила от другого - опять не поровну. Так и выравнивала, пока медвежатам не остались два почти что ничего.

С кодом вот примерно то же самое. Подправили один сервис, подогнали под него второй, потом побежали к следующему - там теперь тоже надо кое-что подправить и так далее. Каждый раз есть конкретная задача и вполне конкретный результат. А вся цепочка потиху обрастает костылями, пока очередной фикс не поделит её на ноль.

И тут дело в том, что агент быстрее пишет код…но также и быстрее косячит. Причём даже не в плане каких-то банальных ошибок, а в плане консистентности кодовой базы и документации. И если время от времени не останавливаться и не разбираться (при помощи AI-агентов, разумеется, а как вы думали - 2026 год на дворе), как эти части вообще должны работать вместе, то вместо системы получим конгломерат.

Код не стирается, но система меняется

Код сам по себе не стирается. Зато требования меняются, зависимости обновляются, нагрузка растёт. Также со временем даже сами разработчики (это не точно) начинают лучше понимать, что они вообще строят. Временный костыль от этого, правда, сам не исчезает.

Ещё Уорд Каннингем, вводя метафору технического долга, писал о необходимости возвращаться к реализации с учётом нового понимания задачи: сделали, разобрались лучше - теперь надо переделать. AI ускоряет первый шаг, но вот второй и третий - всё равно придётся делать.

Также при исследовании внедрения Cursor рост активности разработки оказался кратковременным, а вот рост сложности кода и предупреждений анализатора - продолжительным. Удивительно, да? Хотя, это наблюдательное исследование открытых репозиториев, так что с обобщениями надо всё же аккуратнее. Но сам вопрос открыт: разработка ускорилась или же просто код стал писаться быстрее?

Ну…кто ж его знает, да? Может у агентов спросим и пусть сами разбираются? С математикой же у них вроде что-то получается.

Обслуживать придётся и тех, кто обслуживает (рекурсия, ага)

Теперь ещё один нюанс: у агентов есть модели, тулзы, скиллы, MCP, AGENTS.md, MEMORY.md и тд, и тп - вся та обвязка, которую принято называть харнессом. И она тоже устаревает - да каждый день летят стоящие апдейты! Модель обновили, а старые инструкции оставили. Когда-то десять промежуточных шагов были нужны, потому что иначе агент терял контекст. Теперь справляется за, условно, три, но по инструкции послушно делает десять. Или инструмент уже отвечает иначе, а агент всё ещё трактует ответ по старым правилам. Память у него есть, вот только помнит он уже не то, что нужно.

Кстати, у BAntropic есть разбор такой переработки харнесса: возможности модели изменились, часть обвязки удалось убрать. Правда, попытка разом всё сильно упростить сначала ухудшила результат - пришлось проверять, что именно можно удалять.

То есть обслуживать придётся ещё и тех, кто обслуживает. Поставить над ними ещё одного агента можно, но у него тоже будут инструкции и критерии проверки. И фразу “сервис восстановлен” в любом случае надо проверять реальной операцией: красивый отчёт клиентский запрос не обработает.

Получается, теперь нужно иногда останавливаться и “смазывать AI-станок”?

Вкратце - получается, что таки да.

Обслуживание легко оставить на потом: агент не устал, новая фича почти готова, а там ещё одна - можно пока не отвлекаться. Только это абстрактное “потом” - в реальное потом - обернётся упавшим продом.

Ну и вообще, хорошо бы (хотя бы гипотетически) делить dev-timeline на три куска:

1. Разобрать накопившееся - найти причины сбоев, закончить миграции, выкинуть отжившие костыли, согласовать изменения между сервисами.

2. Делать новое - сразу вместе с интеграцией и проверками, пока ещё понятно, что и зачем поменяли.

3. Проверить готовность - испытать именно ту систему и тех агентов, которые будут работать под нагрузкой. И оставить время что-то исправить, если вдруг выяснится, что что-то опять решило “уйти погулять”.

То есть, при агентной разработке порой придётся просто остановливаться и разбираться с тем, что имеем - даже ценой задержки очередной фичи.

Что значит “готовность”

“Всё готово” - это вообще к чему? К обычному дню, десятикратной нагрузке, отказу зависимости? Зелёные тесты мало что объясняют, пока мы не уточнили, что именно проверяли (и пока не увидели красные, конечно).

Ну вот например у Shopify, например, к Black Friday/Cyber Monday готовятся отдельно: проверяют запас мощности, гоняют нагрузку и отказы, заранее заканчивают крупные архитектурные изменения. При том, что над надёжностью работают круглый год. Вполне понятная логика: выяснять, что система не вывозит, лучше до распродажи.  А с AI-разработкой это соотносится следующим образом: иногда - особенно перед наиболее критичными событиями/ситуациями/периодами - внедрять новых фич при помощи агентов - вообще лучше не надо. А насчёт “ручного ревью” кода, написанного AI-агентами, то…если у вас реально есть на это время - вроде как лучше сразу руками и писать, а то весь профит теряется. И да, бэкапы тоже лучше делать, чем не делать, а также обязательно попробовать восстановить их. Чисто на всякий случай, ага…

Ну короче, агентам отдых действительно не нужен, а вот агентной разработке - очень даже. Иными словами, при текущем подходе порой придётся переставать разрабатывать и заниматься “смазкой AI-станка”.