В 2024 году российские IT-компании, по опросам, в среднем уже генерируют от 30% до 60% нового кода с помощью AI-агентов. И вроде бы всё прекрасно: скорость поставки выросла в разы, команды дышат полной грудью. И ровно в этот момент начинает расти число инцидентов в проде — тех самых багов, которые «непонятно откуда взялись», потому что код, на первый взгляд, выглядел чистым. В действительности исчезла одна невидимая, но критически важная функция — та самая пауза, которая заставляла инженера думать. И думать не абстрактно, а о конкретной строчке перед ним.
То, что раньше делало медленное ручное письмо, не называлось контролем качества. Оно просто было им. И теперь, когда письмо исчезло, качеству нужна новая прописка. Иначе жить придётся в иллюзии, что AI-помощник всё проверит, хотя он, напротив, создаёт новые риски — только выше уровнем и быстрее прежнего.
Время, от которого зависело качество
Признаемся честно: бутылочным горлышком разработки никогда не была скорость печати. Хороший инженер пишет пару сотен строк в день, а физически набить их можно за полчаса. Остальные шесть-семь часов глубокой работы занимало то самое «замечание» — стопка умственных операций, неотделимых от процесса письма, но никогда за него не считавшихся.
Когда вы вручную пишете сигнатуру метода и вдруг понимаете, что структура данных, которую вы передаёте, противоречит самой себе — это не письмо. Когда читаете чужой код, чтобы вставить свою строчку, и тут же правите баг, на который никто не заводил тикет — это не письмо. Когда дописываете тест и видите, что у написанной функции три выхода, а не два, и один глушит ошибки без лога — это не письмо. Вся эта нагрузка держалась исключительно на медленном, физическом взаимодействии с кодом. И как только это взаимодействие исчезло, «замечание» исчезло вместе с ним.
По наблюдениям за работой старших инженеров, реальное написание символов занимает от силы 5–10% времени. Остальное — «замечание». Именно его мы и теряем, когда передаём написание агенту.
Медленность была несущей стеной
Попробуйте сравнить два сценария. Раньше инженер садился писать модельку данных и в середине осознавал, что одно поле нужно не опциональным, а размеченным объединением. Он менял две строчки, переключался в соседний файл — всё это занимало 90 секунд. Ни один менеджер не узнавал, что между делом инженер предотвратил продакшен-баг.
Теперь инженер пишет промпт, агент генерирует модель: optional стоит, выглядит прилично. Инженер пробегается глазами: «Ок, едем дальше». Через пару недель система падает, потому что модель не предусматривала вполне вероятного состояния. И ладно бы только модель — проблема ушла в данные на диске, испортив логику целого сервиса. Тот же самый баг, только распознан на поздней стадии, когда цена правки выросла в десятки раз.
Медленность естественно заставляла инженера проходить каждый участок кода с включённым «замечанием». Это был бесплатный QA-прогон, зашитый в процесс написания. Он нигде не учитывался, но без него всё сыпалось. Теперь, когда медленности нет, этот QA-прогон не проходит никто.
Стохастический инжиниринг был всегда
Часто говорят, что AI-агенты делают разработку непредсказуемой: один и тот же промпт — разный код в разное время. Но если вы управляли командой, в которой работали стажёры или недавние выпускники, вы знаете: та же стохастичность была там всегда. Вы составляете подробнейший тикет, прикладываете макеты, ссылаетесь на дизайн-документ, а в результате получаете код, который вас удивляет. Не потому, что разработчик плох. Просто у него в голове нет вашей модели системы, и его «правильный ответ» опирается на иной опыт. Опытный ведущий инженер всё равно вынужден проверять границы, интерфейсы, архитектурный каркас — и поправлять то, что выбилось из рамок.
AI-агент — это новый тип исполнителя. Быстрее и дешевле человека, и при этом готов с уверенностью закрепить неудачное решение, а затем строить на нём десятки фич, не испытывая дискомфорта. Роль старшего инженера здесь ровно та же, что и раньше: задавать ограничения, определять интерфейсы, владеть архитектурой и проводить код-ревью. Только теперь по другую сторону — не младший коллега, а безошибочно быстрый генератор текста, которому всё равно, насколько архитектура нелепа.
Формы, к которым тянется агент, когда никто не смотрит
Вот сценарий, который редко описывают. Для агента написать десять тысяч строк неправильного кода стоит столько же, сколько правильного. Он не чувствует сопротивления материала. В результате агенты способны создавать поразительно абсурдные решения и не сворачивать с пути. Скажем, слить все сущности предметной области в один гигантский union-тип, потому что так прошли первые тест-кейсы. Или построить иерархию манифестов над манифестами там, где нужен был простой плоский список. Или изобрести параллельную систему идентификаторов, дублирующую базу, и накрутить пару десятков фич поверх неё, пока никто не заметил.
Человек не стал бы писать ничего подобного, потому что медленность набора кривых конструкций давала обратную связь: «остановись, подумай». Агент этой обратной связи лишён. В результате код на уровне строк часто выглядит безупречно, а ошибки живут этажом выше: в структуре данных, в лишней абстракции, в enum’е, молча глотающем часть кейсов. И эти ошибки спокойно доезжают до ревью, потому что ревьюер тоже уже не обязан собирать модель системы в голове — скорость генерации убрала этот шаг из его рутины.
Именно этот паттерн — когда контроль за архитектурой перестал быть частью ежедневного рабочего ритма — мы всё чаще видим в проектах, где AI-инструменты внедрены без компенсирующих практик. В группе компаний «Алмаз», проектируя системы моделей компетенций для технологических команд, мы намеренно закладываем в них умение замечать архитектурные дыры — на всех ролях, от джуниора до техлида.
Скрытое QA было размазано по процессу — и это работало
Индустрия давно знала, что письмо кода — это не просто ввод символов. Техника «резиновой уточки» — когда проговариваешь код игрушке, и баг всплывает сам — держится на том же эффекте: артикуляция решения вовне принуждает осознать модель. Парное программирование, дизайн-документы, code review — всё это попытки воспроизвести медленное «замечание». Но раньше нам не приходилось защищать эту практику, потому что альтернативы не было. Сейчас альтернатива есть, и отказ от неосознанного QA бьёт прямо в качество.
Качество, растворённое в письме, должно теперь где-то жить. Если вы его никуда не поселите, его не станет. Это тот самый «верификационный долг», который команды начинают осознавать месяцев через шесть после внедрения AI-помощников, когда спотыкаются об архитектурные решения, возникшие будто сами собой. На практике это означает, что стандартные артефакты и ритуалы лида должны быть усилены и, главное, делаться вручную — там, где раньше хватало беглого взгляда.
Небольшой пример из практики: схемы данных — даже небольшие, на пару десятков полей — мы рекомендуем писать руками. Не потому, что агент не справится. А потому, что вам нужно, чтобы «замечание» случилось именно на уровне схемы, ведь каждый прод-баг, достойный отладки в два часа ночи, восходит к неправильной форме данных в критическом месте. Добиться верной схемы — значит убрать целый класс проблем, с которыми иначе пришлось бы разбираться в ночных чатах техподдержки.
То же касается интерфейсов на границах систем: protobuf, OpenAPI-спек, GraphQL-типы. Их тоже стоит писать или как минимум выверять без посредников. Ручная работа здесь — не архаизм, а осознанно выбранный предохранитель. Аналогично стоит поступать с перечислениями (enum): вручную проверять, покрыты ли все реальные состояния, и документировать неочевидные намерения прямо в коде.
Что изменилось — цена одного ввода
Фундаментально сложные части инжиниринга никуда не делись. Изменился метод принуждения к ним. Раньше необходимость набирать код заставляла инженера постоянно держать в голове модель системы. Теперь эту функцию нужно выполнять сознательно — а значит, лиду или руководителю надо в явном виде выстроить систему точек ручного контроля. В группе компаний «Алмаз» мы называем это «расстановкой предохранителей в ускоренном процессе» — и вокруг этого часто строятся тренинги для руководителей технологических команд.
Часть этих предохранителей — вполне конкретные ритуалы. Например, код-ревью должно быть медленным и архитектурным: смотреть не на форматирование, а на границы сервисов, форму данных и неочевидные допущения. Другой ритуал — specification review: проверка спецификации ещё до того, как она уйдёт агенту. Звучит бюрократично, но на деле это и есть восполнение утраченной QA-функции: вы закладываете время на то самое «замечание», которого больше не происходит в процессе написания.
И конечно, культура медленного анализа ошибок. Каждый инцидент стоит разбирать не только с вопросом «что пошло не так в коде», но и «на каком этапе мы перестали замечать». Эта мета-рефлексия — отдельный навык, которому нужно обучать так же, как раньше учили писать чистый код. И здесь важна обратная связь от тех, кто может объективно оценить, насколько инженер способен удерживать в голове архитектурную целостность, — а значит, нужна и система оценки персонала, заточенная под эти новые критерии.
Практические рекомендации
- Верните «ручные зоны». Определите минимум поверхностей, которые не доверяются агенту: схемы данных, внешние контракты, ключевые перечисления. Их пишет или детально выверяет человек. Затраты на это окупаются сторицей на этапе сопровождения.
- Сделайте ревью медленным и структурным. Перестаньте смотреть на стиль и мелкие ошибки. Сфокусируйте ревью на границах сервисов, полноте модели данных, корректности допущений. Выделите под это фиксированное время, не поддавайтесь гонке.
- Введите specification review как отдельный шаг. Перед тем, как отправлять промпт, проведите 15–30-минутную проверку спецификации: верна ли форма данных, учтены ли краевые случаи. Это заменит ту паузу, которую раньше давало письмо.
- Тренируйте «замечание» на ретроспективах. Разбирая инциденты, обязательно отвечайте на вопрос: почему это не было замечено на этапе проектирования? Какой именно момент упущен? Это формирует коллективный навык архитектурной рефлексии.
- Обучайте ведущих инженеров явному управлению качеством. Навык удерживать модель системы при работе с быстрыми агентами не появляется сам. Нужны целевые программы, включающие практику ручного моделирования и оценку этих компетенций, — по сути, развитие той самой роли «внутреннего архитектора».
Заключение
Мы сняли предохранитель, потому что он выглядел как потеря времени. Но за медленностью стоял главный фильтр, который предохранял архитектуру от незаметных, дорогих ошибок. Вернуть его можно только сознательно — распределив зоны внимательного контроля по ключевым артефактам и ритуалам. И тогда скорость агентов становится не проблемой, а конкурентным преимуществом, усиленным человеческой способностью замечать.
Часто задаваемые вопросы
Действительно ли ручная работа над схемами не замедлит проект?
Замедлит на этапе проектирования, но радикально ускорит на этапе эксплуатации и отладки. Баги, заложенные на уровне модели данных, обходятся в десять раз дороже. Инвестиция в медленное, но точное проектирование — это работа на опережение.
Можно ли автоматизировать те самые «предохранители»?
Частично. Автоматические линтеры и тесты всё ещё полезны. Но они не заменят взгляд человека на архитектурную целостность. Автоматизация умеет проверять соответствие правилам, но не оценивать сам дизайн.
Что делать, если в команде нет выделенного архитектора?
Назначить ответственного за архитектурные ограничения на уровне лида или самого опытного инженера. Вменить ему в обязанность медленное ревью границ, схем и интерфейсов. И дать ресурс на это — временной и полномочный.
Как обучить инженеров новому типу бдительности?
Через практику разбора инцидентов с вопросами «почему не заметили», через парное ручное моделирование новых фич, через тренинги, на которых развивается навык удержания модели системы параллельно с использованием AI-инструментов. Важна регулярность и обратная связь.
Подходит ли такой подход небольшим стартапам?
Да. В стартапе цена архитектурного промаха может быть фатальной из-за ограниченных ресурсов на рефакторинг. Внедрение ручного контроля ключевых артефактов окупается быстрее, чем если ждать, пока грабли сработают на продакшене.
