Скорость кодинга превысила скорость осмысления. Что происходит, когда AI ускоряет разработку в 5 раз, а процессы остались из 2022 года

В январе мой разработчик закрыл месячный бэклог за 4 дня. Claude Code написал 80% кода, он отревьюил, поправил архитектуру, задеплоил. Я обрадовался. Через неделю клиент прислал 9 багов. Через две — мы откатывали релиз, потому что фича, которую «агент написал за вечер», сломала авторизацию на проде. Ещё через месяц QA, который параллельно тестирует, сказал, что не успевает проверять — фичи прилетают быстрее, чем он открывает тикеты.

Я руковожу веб-студией АП-ИМ с 2008 года. За 17 лет я пережил переход с PHP на Node.js, с jQuery на React, с монолитов на микросервисы. Каждый раз менялись инструменты, но скорость разработки росла плавно — на 20-30% за технологический цикл. То, что происходит сейчас с ИИ в разработке — это не плавный рост. Это скачок в 3-5 раз за один год. И впервые в моей практике проблема не в том, что мы медленно пишем код, а в том, что мы пишем его быстрее, чем успеваем думать.

Андрей Карпати в январе 2026 года описал переход с 80% ручного кодинга на 80% агентского и ввёл термин agentic engineering. Борис Черни, создатель и руководитель Claude Code в Anthropic, рассказал, что практически не правит код руками и отгружает десятки pull request в день через агентов. На Hacker News тред «Identity crisis as a software engineer because of AI» за сутки собрал тысячу комментариев от разработчиков, которые описывают одно и то же чувство: код пишется, продукт работает, а из процесса исчез момент, в котором ты был нужен.

Красивая картинка. Но за ней — четыре системных поломки, которые я вижу в реальных проектах.

Поломка 1: бэклог опустел — и начался хаос. Раньше бэклог продукта исчислялся месяцами, иногда годами работы. Приоритизация была критически важна, потому что ресурс разработки был дефицитом. С появлением Claude Code, Cursor и аналогов команда начала закрывать задачи в 3-5 раз быстрее. Бэклог «подизмельчал», и впервые руководство обнаружило себя в ситуации, когда разработке нечем заниматься. Реакция предсказуемая: в бэклог начали кидать всё подряд — «а давайте ещё вот эту фичу», «а давайте перепишем вот это». Не потому что нужно, а потому что нужно чем-то загрузить команду, которая вдруг стала слишком быстрой.

Поломка 2: технический долг растёт быстрее, чем раньше. Парадокс: ИИ программирование ускоряет написание кода, но не ускоряет его осмысление. AI-агент генерирует решение за 15 минут, разработчик бегло просматривает, мержит. Через месяц 15 таких мержей превращаются в кодовую базу, которую никто не понимает целиком. Раньше разработчик, который писал код вручную, держал в голове архитектуру — потому что он её строил руками. Сейчас архитектуру строит агент, а разработчик её «одобряет». Разница — как между архитектором, который рисует дом, и человеком, который ставит штамп «утверждаю» на чужой чертёж.

Поломка 3: фичи выпускаются быстрее, чем тестируются. QA не масштабируется с той же скоростью, что и разработка. Если раньше на спринт приходилось 3-5 фич, и QA успевал их протестировать, то сейчас — 10-15 за тот же спринт. Автоматизация разработки произошла, автоматизация тестирования — нет (или произошла частично). Результат: больше багов на проде, больше откатов, больше времени на фиксы. Суммарная скорость доставки ценности клиенту не выросла — просто сдвинулась из фазы «написать код» в фазу «починить то, что написали».

Поломка 4: маркетинг и продукт не успевают за разработкой. Фича выпущена, но маркетинг ещё не написал про неё landing page. Аналитик ещё не настроил отслеживание. Продакт ещё не провёл A/B-тест предыдущей фичи — а уже прилетела новая. Скорость разработки превысила пропускную способность всех остальных функций в компании. Код есть. Ценности для клиента — нет, потому что до клиента фича не дошла в упакованном виде.

Типичная реакция руководителя на эти поломки — попытаться ускорить всё остальное. Наймём больше QA. Ускорим маркетинг. Добавим ещё одного продакта. Это не работает по простой причине: проблема не в скорости остальных функций. Проблема в том, что разработка перестала быть бутылочным горлышком — и все процессы, которые были выстроены вокруг этого горлышка, потеряли смысл.

Agile, Scrum, спринты — всё это было спроектировано для мира, где разработка — дефицитный ресурс. Да, спринты решают не только это — они дают ритм обратной связи, синхронизацию со стейкхолдерами, регулярность планирования. Но в первую очередь двухнедельный спринт существует потому, что за две недели команда может написать предсказуемое количество кода. Стори-пойнты существуют потому, что нужно оценивать объём работы разработчика. Ретроспективы существуют потому, что нужно оптимизировать использование дефицитного ресурса — рук программиста.

Когда vibe coding и AI-агенты ускоряют кодинг в 5 раз, спринт заканчивается за 3 дня. Стори-пойнты теряют смысл — задача на 8 пойнтов теперь занимает столько же, сколько задача на 2. Ретроспектива обсуждает не «как мы пишем код», а «почему мы выпустили 15 фич, а клиент не заметил ни одну».

Это не проблема инструментов. Это кризис операционной модели.

Я не претендую на универсальный рецепт — делюсь тем, что мы внедрили у себя за последние полгода и что работает для студии из 10 человек. Три принципа, которые изменили процессы.

Принцип 1: бутылочное горлышко — теперь осмысление, а не кодинг. Мы перестроили процесс так, чтобы 70% времени разработчика уходило на проектирование (plan mode) и 30% — на кодинг (agent mode). Раньше было наоборот. Конкретно: перед каждой значимой задачей разработчик пишет ADR (Architecture Decision Record) — документ на 1-2 страницы, где описывает: какую проблему решает фича, какие альтернативные подходы рассмотрены, какие компромиссы сделаны, как это повлияет на существующую архитектуру. Только после ревью ADR задача уходит в кодинг (и тогда уже AI-агент пишет код по проверенному плану). Это замедляет выход фичи на 1-2 дня, но сокращает количество откатов с 3-4 в месяц до нуля.

Принцип 2: выпускаем меньше, но осмысленнее. Раньше мы гнались за количеством закрытых задач. Сейчас у нас правило: не больше 5 фич за спринт, даже если разработка может выдать 15. Оставшееся время — рефакторинг, документация, ревью архитектуры. По нашим замерам, за 4 месяца количество багов на проде сократилось на 60%, а time-to-value (от идеи до работающей фичи, которую клиент реально использует) уменьшился, несмотря на то что мы выпускаем меньше. Потому что каждая фича дошла до клиента в упакованном виде — с документацией, с аналитикой, с маркетинговым материалом.

Принцип 3: AI ревьюит AI. Мы перестали полагаться на одного человека для ревью кода, сгенерированного агентом. Вместо этого: агент пишет код, второй агент ревьюит (с другим промптом и фокусом на безопасность и архитектуру), человек ревьюит ревью — не код целиком, а выводы агента-ревьюера. Это снимает 70% нагрузки с человека и при этом ловит паттерны, которые беглый human review пропускает: неочевидные зависимости, дублирование логики, нарушение принципов архитектуры. Технически мы используем Claude Code с субагентами — это работает нативно.

Не багов и не техдолга. Я боюсь, что через 2-3 года на рынок выйдет поколение разработчиков, которые никогда не проектировали архитектуру руками. Они сразу начали с промтов в Claude Code — и делают это отлично. Но когда агент ошибётся в фундаментальном решении (а он ошибётся — это вопрос времени, не вероятности), у них не будет опыта, чтобы это заметить.

Это тот же аргумент, который Тимоти Кук из Connected Classroom сделал про образование: атрофия навыка обратима — потренировался, восстановил. Отсутствие фундамента — нет. Нельзя атрофировать мышцу, которой не было. В разработке фундамент — это не умение написать цикл for. Это умение увидеть, почему этот конкретный цикл for в этом конкретном месте создаст проблему через 6 месяцев, когда данных станет в 100 раз больше.

AI-агент не видит этого. Он оптимизирует под текущий промпт, а не под будущее продукта. И если за ним некому проверить — продукт рассыпется. Не сразу, но неизбежно.

Раньше руководитель разработки управлял ресурсом — кто какую задачу берёт, сколько времени нужно, как распределить нагрузку. Сейчас ресурс стал почти бесконечным — AI-агент может кодить 24/7. Управлять нечем.

Новая роль — управление качеством решений, а не скоростью исполнения. Не «сколько задач мы закрыли за спринт», а «какие решения мы приняли и почему». Не «как быстро мы выпустили фичу», а «уверены ли мы, что эта фича нужна, и знаем ли мы, как измерим её успех».

Это смена профессии. Тимлид 2022 года — это координатор разработчиков. Тимлид 2026 года — это главный редактор кодовой базы. Он не пишет и не заставляет писать. Он решает, что публикуется, а что отправляется в корзину. Как главред газеты, который получает 50 статей в день и публикует 5 — не потому что остальные плохо написаны, а потому что не нужны читателю.

Если вы руководитель или CTO: проверьте, не случилось ли у вас тихой катастрофы. Бэклог пуст, а техдолг растёт? Фичей стало больше, а жалоб клиентов — не меньше? Разработка закрывает тикеты быстрее, чем продукт успевает их осмыслить? Это симптомы. Инструмент (Claude Code, Cursor, Codex) работает. Процесс вокруг него — нет.

Решение не в том, чтобы замедлить AI. Решение — в том, чтобы перестроить процесс вокруг нового бутылочного горлышка. Горлышко теперь — не руки программиста, а голова продакта, тимлида и архитектора. И если эта голова не успевает думать быстрее, чем руки агента пишут код — скорость разработки не ускоряет бизнес, а создаёт хаос, который придётся разгребать вручную.

Самое дорогое в 2026 году — не код. Код стоит почти ноль. Самое дорогое — понимание того, какой код нужен.