В этом году у нас в AI Data Extractor два проекта идут в новом режиме. В команде три человека: разработчик на полной ставке, который управляет агентами и релизами, менеджер продукта и бизнес-аналитик на полставки, который формулирует задачу так, чтобы ее мог проверить скрипт, и архитектор. На команду - восемь агентов. Год назад такой же проект тянули шесть-семь человек. Скорость та же, надежность поставки та же, просто руками код теперь не пишет никто.
Про ИИ в разработке и автоматизацию процессов разработки ПО за последний год написано много, но почти все это либо инструмент, либо лозунг. Нам было интересно другое: что должно быть верно в решении, чтобы оно не осталось демонстрацией и заработало внутри компании, где за код подписывается не тот, кто его написал. Чтобы ответить, мы нарисовали дом: крыша, балка, три колонны, фундамент. Дальше - что в нем внутри, с историями и цифрами из наших собственных проектов.
Почему готовые ИИ-агенты для разработки не решают всю задачу
Хороших публичных фабрик разработки на искусственном интеллекте уже несколько, и ни одна не строилась под задачу компании, где подписывает не тот, кто строил.
Первая - набор приемов соло-разработчика, который разошелся по YouTube: четыре текстовых файла с правилами и отдельная рабочая копия репозитория на каждую функцию, пятнадцать функций параллельно, доказательство прикладывается к pull request, бот-ревьюер выставляет оценку, и дальше остается нажать merge.
Вторая - PStack от Cursor: перед стартом агент загружает двадцать три принципа, и два из них прямо говорят, кому это адресовано - никогда не блокироваться на человеке и не использовать навыки планирования, потому что лучшая спецификация - это код.
Третья - облачный агент внутри GitHub: вы назначаете задачу, агент работает в одноразовом окружении GitHub Actions, открывает pull request, и каждая сессия логируется вместе с расходом токенов и длительностью.
Четвертая - облачный Codex от OpenAI: каждая задача идет в своем изолированном контейнере с вашим репозиторием, и весной OpenAI опубликовали, как сами используют Codex внутри компании - с конфигурациями, которые задает администратор, сетевой политикой и телеметрией для службы безопасности.
Пятая появилась в конце сентября: компания, которая выпускает терминал с агентами, открыла код продукта и вместе с ним публичную фабрику. Идеи поступают на вход, агент сортирует их, по сложным пишет продуктовую и техническую спецификацию, человек ее подтверждает, агент реализует, другой агент проводит первое ревью, проверка идет через управление компьютером и CI, а мониторинг возвращает результат на вход. Основатель компании описывает эту перемену короче всех: инженер теперь строит машину, которая строит продукт, а такую фабрику компании стоит купить и настраивать под себя, тратя силы на сам продукт.
Облачные агенты GitHub и OpenAI ближе всего к тому, что могла бы использовать компания. И в обоих проверка устроена одинаково: человек читает дифф. Пятая по форме цикла ближе всех к нашему дому, и разница с ней в том же месте: кто подписывает в конце и чем это доказано. Первые две исходят из того, что человек, который управляет агентом, сам же отвечает за результат. Правило "никогда не блокируйся на человеке" отлично работает, если этот человек - вы сами. Это и есть вайб-кодинг в чистом виде: один человек, один агент, и отвечает за результат тот же человек. Как только подписывает кто-то другой, правило переворачивается: человек становится проверяющим, а значит, сначала должна появиться спецификация, которую он согласует, и только потом код.
Разработчики моделей тоже начали публиковать, как строят продукты собственными агентами. OpenAI в статье о том, как они выстраивают рабочую среду для агентов, описывает продукт, собранный без единой строки кода, написанной руками, и прямо называет распределение ролей: люди управляют, агенты исполняют. Ревью там не обязательно, потому что, по их словам, "исправления дешевы, а ожидание дорого". На такое распределение и мы бы согласились, если бы за результат отвечали только мы сами.
У Anthropic похожие заметки о рабочей среде для агентов, которые долго работают над одной задачей, устроены так же: сначала инициализатор готовит окружение, потом агент шаг за шагом доводит работу. Оба текста про одну и ту же часть дома, сборочную линию, и оба написаны в лаборатории, где тот, кто строит, и тот, кто подписывает, - один и тот же человек. Стоит убрать это условие, и без подписи человека уже не обойтись.
Спецификация в основе решения - вторая идея, которая уже описана в публикациях, и это первая половина колонны "проверка". Spec Kit от GitHub делает спецификацию источником, из которого агент строит код, а не документом, который лежит рядом. Thoughtworks включили эту технику в свой Technology Radar и добавили предупреждение, к которому мы относимся серьезно: детальные правила для ИИ, написанные вручную, рано или поздно перестают масштабироваться. Мы убедились в этом на себе: свод правил, верный в июле, к августу устарел. Поэтому в нашей линии проверки на моделях идут по расписанию, а не дописываются в свод правил бесконечно.
Аналитики и регулятор пишут о другой части дома. Опрос McKinsey за 2025 год показывает, что 62 процента компаний уже как минимум экспериментируют с агентами, и один из признаков, который сильнее всего отличает лидеров, - четкий порядок, по которому решают, когда результат модели должен проверить человек. На нашем языке это и есть таблица подписей.
Gartner в обзоре рынка за 2026 год оценивает корпоративный рынок агентов для разработки примерно в 10 миллиардов долларов в год и пишет, что внедрение без операционной модели добавляет затраты без пропорциональной пользы - это в одном предложении та история про ревью-ритуал, о которой ниже. Статья 14 закона ЕС об ИИ, хоть и написана для систем высокого риска, содержит самую четкую формулировку человеческого надзора, какую мы встречали: человек должен иметь возможность не использовать результат системы, проигнорировать его, отменить решение или откатить его. Наше подтверждение выполнения задачи - это то же предложение, только с именем человека в таблице подписей.
Консалтинговые компании тоже подключились. Летом BCG Platinion выпустили трехминутный ролик The Agentic Software Factory, и вся формула уместилась в одну фразу: полная автоматизация от А до Я, люди управляют результатом, агенты делают работу. Они сообщают о росте продуктивности в три-пять раз и о сокращении очереди накопленных задач по устаревшим системам с тысяч человеко-дней до сотен. Мы работаем по той же модели вместе с командами клиентов. А эта статья - про то, что формула пропускает: какой именно человек, каким именно результатом управляет, и что у него в руках в момент подписи.
В том же месяце доклад на сцене AI Engineer с названием "Почему софтверные фабрики проваливаются" рассказал обратную историю. В июле 2025 года команда отдала агентам всю работу, перестала читать код, и фабрика развалилась за несколько месяцев, потому что модели для кода учат добиваться, чтобы тест прошел, а не чтобы кодовую базу можно было поддерживать. Решение докладчика - планировать заранее и потом читать каждую строку заново. Мы берем первую половину и меняем вторую: план - это спецификация, которую держит подписант, а читают за человека проверки, которые по умолчанию говорят "нет", и человеку остается доказательство вместо диффа.
Конференция, которая дала название всей области, поддержала обе стороны сразу. AI Engineer World's Fair в июне назвала главный день конференции Software Factories и открыла его докладом Microsoft, а команда OpenAI на той же сцене избегала этого слова и говорила, что цель точно не в том, чтобы автоматизировать инженеров. Самое точное определение дал докладчик из компании, которая продает такую фабрику: фабрика - это весь цикл целиком, оркестратор пишет контракт проверки еще до того, как появился код, и проверка занимает сорок процентов всего процесса. Люди решают, что строить, а не как. Мы с этим согласны.
Никто из перечисленных не связывает эти две части. Лаборатории публикуют машину и оставляют подпись оператору. Аналитики публикуют операционную модель и оставляют машину поставщикам. Наш дом соединяет обе части на одной картинке, в точке, где рождается доказательство, и начинается все с условия, которого у лабораторий нет: человек, который подписывает, не строил то, что подписывает.
На практике внедрение ИИ в разработку без этого условия бьет по компании тремя способами. Ревью превращается в ритуал: агентов ставят, а старый процесс проверки оставляют как есть, код идет в пять раз быстрее, ревьюеры не успевают, и через полгода CTO решает, что агенты не работают, хотя просто никто не решил, кто имеет право сказать, что задача готова. Политика без линии ничего не меняет: компания объявляет ИИ приоритетом, проводит день обучения, но у работы нет маршрута - у нас по итогам прошлого года из тридцати пяти старших разработчиков и разработчиков выше среднего уровня семьдесят процентов ни разу не заходили в агентный режим, и причина в доверии, а не в квалификации. И третий способ - фабрики просто нет: блестящий инженер собирает рабочую связку агентов за выходные, а когда CTO спрашивает, где хранятся учетные данные, какая модель видела данные клиента и по какой лицензии используются навыки, ответа нет, а значит, фабрики нет, есть чей-то личный проект.
Пять категорий решений, и ошибка в любой из них стоит компании всей фабрики. Поэтому мы нарисовали их в виде дома.
Дом Self-Service Software Factory: пять решений для агентной разработки
Правило чтения картинки простое: о крыше решает компания, три колонны строит команда фабрики, фундамент - то, что у компании уже есть. Балка проходит через всю конструкцию: в каждой колонне есть требование безопасности, и оно не принадлежит ни одной колонне по отдельности.
Крыша: политика компании и локальный ИИ для программирования
Если вы CTO, эту часть дома стоит прочитать дважды. Это самый короткий документ во всей методологии. Он называет классы изменений - документация, внутренний инструмент, что-то, что видит клиент, миграция данных, что-то, что касается безопасности - и назначает каждому маршрут: полную линию, линию с дополнительными ручными проверками, или путь вообще без агентов. Он же фиксирует, чего автоматизация не касается никогда.
На нашей линии это подтверждение выполнения задачи, релиз в продакшен и любое изменение данных. И код, и CI отклоняют попытку подтвердить выполнение задачи автоматически. Машина может выполнить любой другой шаг, но не может произнести это единственное слово.
В крыше есть и политика по моделям, какой ИИ для написания кода допускается к какому репозиторию, и вот здесь она перестает быть бумагой и начинает приносить пользу. Чем жестче остальные проверки, тем более дешевую модель можно себе позволить. Три месяца назад разница между передовой моделью и дешевой внутри нашей линии была огромной. Сегодня она небольшая.
Мы протестировали перенос части задач разработки на одну из недорогих открытых моделей, чтобы снизить стоимость и увеличить скорость, и проверки ловят одни и те же ошибки на обеих моделях. Отсюда следствие, важное для CTO: раз качество держится на проверках, всю линию можно развернуть внутри периметра компании, вообще не обращаясь к внешним передовым моделям. Часть корпоративных клиентов и просит именно об этом - локальный ИИ для программирования, без выхода данных за периметр. Крыша фиксирует это решение, а остальные части дома его обеспечивают.
"Локальный" здесь означает не только передовую модель на собственном сервере. Линия рассчитана на модели заметно слабее передовых: открытые модели, которые ставятся на свое железо, и модели местных провайдеров, которые держат их в своих центрах обработки данных. Для компаний в нашем регионе это не техническая деталь, а условие сделки. Данные и код американским моделям не отправляют, а китайские открытые модели готовы использовать только внутри своего периметра.
Законы подталкивают в ту же сторону, и их стоит прочитать до того, как линию соберут вокруг внешней модели.
- В России с 1 сентября 2026 года действует закон 243-ФЗ о поддержке развития технологий искусственного интеллекта. С 1 марта 2027 года правительство получает право устанавливать случаи, в которых допускается применение исключительно суверенных или национальных больших фундаментальных моделей. Для обеих категорий ответы на запросы пользователей и хранение данных должны обеспечиваться в центрах обработки данных на территории страны, принадлежащих российским юридическим лицам. Системам, которые уже работают к 1 марта 2027 года, дан переходный период до 1 сентября 2032 года, но только при условии обработки и хранения данных внутри страны. Национальной моделью может быть и модель, собранная из открытых компонентов, в том числе зарубежных, если они распространяются по открытой лицензии.
- В Казахстане закон об искусственном интеллекте (230-VIII от 17 ноября 2025 года) ввел понятие локальной системы искусственного интеллекта: обучение и эксплуатация в пределах инфраструктуры владельца, без подключения к сетям общего пользования. Именно такие системы закон предписывает для данных, доступ к которым ограничен законом. А закон о персональных данных (94-V, статья 16) по общему правилу разрешает трансграничную передачу только в страны, обеспечивающие защиту персональных данных, а прочие случаи допускает лишь при отдельном основании: согласии субъекта, международном договоре или прямой норме закона.
- В Узбекистане закон ЗРУ-1115, подписанный 21 января 2026 года, вписал искусственный интеллект в закон об информатизации и в кодекс об административной ответственности, а стратегия развития технологий искусственного интеллекта до 2030 года утверждена постановлением ПП-358 еще в октябре 2024 года.
Ни один из этих документов не запрещает пользоваться внешней моделью для разработки. Они делают другое: список случаев, где внешняя модель недопустима, теперь пишет государство, а не служба безопасности компании, и этот список может расшириться. Линия, у которой качество держится на проверках, выдерживает такое расширение заменой одного блока. Линию, построенную вокруг одной передовой модели, придется переделывать.
Балка: безопасность и соответствие требованиям
Балку мы не проектировали заранее. Она появилась после того, как агент прогнал сквозные тесты в браузере и оставил на диске 790 мегабайт действующих сессий в папке, которую не отслеживает git и куда никто бы не заглянул. Тесты были хорошими.
Эти сессии лежали рядом с репозиторием. Балка существует ровно для таких находок - требований, которые обнаруживаются только после того, как агент сделает что-то, за что уволили бы сотрудника. Ее задача простая: как пускать агентов к коду и данным и не получить при этом утечку, проблему с лицензией или аудит, который не пройти.
Сегодня каждая команда агента на нашей линии работает внутри файловой системы, где по умолчанию запрещено все, кроме явно разрешенного, за сетевым белым списком. Учетные данные агенту недоступны в принципе, а исходящий трафик разрешен только к провайдеру модели. Прежде чем что-то двинется дальше, каждый артефакт линии - код, документация, вердикты - проходит сканирование на секреты. Если ваши агенты видят все файлы, которые видите вы, этой части еще нет.
Остальное в балке - это бумажная работа, и это ровно то, из чего состоит аудит:
- реестр всех компонентов с их лицензиями,
- таблица, какие репозитории доступны каждому классу моделей,
- журнал, который связывает каждый вердикт, прогон тестов и merge с версией спецификации, моделью, коммитом и временем.
Подтверждение выполнения и таблица подписей заодно дают доказательства человеческого надзора, которые запросит регулятор. Если колонны построены правильно, балка в основном просто фиксирует то, что и так происходит.
Первая колонна: сборочная линия
Те, кто строит такие системы, называют эту часть харнессом (от английского harness), то есть рабочей средой агентов, и это единственная часть дома, которую ваши разработчики захотят обсуждать сами. Вопрос здесь - из чего состоит машина, и какие части можно заменить, не перестраивая все заново. Форма линии фиксирована: аналитик, архитектор, автор тестов, разработчик, независимый тестировщик, проверка безопасности, бизнес-валидация, плюс раннер, который передает работу между ролями, а трекер и репозиторий служат двумя источниками истины.
Все остальное - заменяемые части: модель на каждую роль, агент на каждую роль, сам трекер, хостинг репозитория, песочница, и раннер - у нас пока это собственный скрипт на Python, позже, возможно, открытая система управления.
Мы научились разделять форму и компоненты на опыте, потому что компоненты устаревают. Модели меняются, правила меняются, агенты со временем начинают вести себя иначе. То, что работало в июле, к августу стало неверным. Поэтому линию сейчас перечитывают и перезапускают по расписанию, раз в одну-две недели, вместе с правилами, навыками и проверками моделей.
Журнал прогонов хранит цифры, по которым линию оценивают: стоимость изменения, срок от спецификации до подтверждения выполнения, доля ошибок, которые долетели до продакшена, и доля изменений, прошедших без участия человека. Правила, которые может проверить машина, собраны в одном скрипте - сегодня в нем двенадцать проверок, и этот же скрипт запускается в CI. Внутри - требование, что покрытие тестами может только расти, тест на живой базе для каждого изменения SQL, и правило, что фича считается доказанной только помеченным браузерным тестом - таких сегодня сорок восемь.
Смена модели - это правка конфигурации, подкрепленная данными журнала прогонов, а не импровизированная правка во время прогона. Если вы не можете заменить модель в одном файле и посмотреть на результат, у вас нет сборочной линии. У вас есть очень дорогой скрипт.
Вторая колонна: проверка
На первой реальной задаче, которая прошла через всю нашу линию, проверка ответила "нет". С кодом все было в порядке. Линия просто не могла показать, какую версию спецификации она реализовала. Без доказательства прохождения не было.
Задача вернулась в работу, агент добавил доказательство, открыл новый merge request и прошел. Именно тогда мы поняли, что проверка настоящая. Контрольная точка, которая всегда отвечает "да", ничего не проверяет.
Вся колонна держится на доказательстве, а не на доверии, потому что отвечает на вопрос, как компания узнает, что изменение работает, если ни один сотрудник не писал и не читал код. До того как появится код, две независимые роли читают задачу, и обе должны подтвердить, что она готова. Еще одна роль пишет тесты до кода и доказывает, что они падают.
Разработчику запрещено менять эти тесты, потому что переписать тест - самый дешевый способ получить зеленый статус, а агент найдет самый дешевый способ. Если агент-разработчик может менять файлы тестов, ваша проверка - это просто пожелание. После этого независимый тестировщик прогоняет все заново с нуля и готовит документацию со скриншотами.
Этот последний шаг снизил долю ошибок сильнее, чем любая правка промпта, которую мы когда-либо делали. Сломанный экран не дает агенту закончить документацию. Документация сама стала тестом.
Инструменты для ревью движутся туда же. Осенью вышел открытый инструмент, который просит агента нарисовать карту изменения, последовательность вызовов со ссылкой в код на каждом шаге, и прячет из диффа тесты и документацию, чтобы ревьюер шел по карте и открывал строки только там, где это нужно. Карта остается утверждением, которое надо проверить, перейдя в код, а авторы инструмента сами предупреждают, что телеметрию стоит выключить, прежде чем направлять его на закрытый репозиторий. Направление при этом верное: человек читает объяснение и доказательство, а не каждую строку.
Никто не закладывает в бюджет стоимость этой колонны. У нас на проектах тестов и проверок по строкам больше, чем самого продукта. Полный прогон раньше занимал пятьдесят минут. Наш архитектор потратил несколько недель, чтобы довести один проект до семи минут - чистой инженерией, без участия моделей. Дело было в порядке проверок, а не в железе: быстрые проверки сначала, длинные сквозные наборы - только на финальной точке, и один конвейер проверок на задачу, после того как два агента дважды отменили и перезапустили прогоны друг друга, и мы чуть не купили больше вычислительных мощностей.
Представьте пять параллельных задач, каждая из которых может упасть и перезапуститься. Без оптимизации выкатка занимает дни. Реальную скорость фабрики определяет именно проверка.
Третья колонна: организация
Заметьте, что в этой колонне нет софта. Здесь вопрос другой: кто что делает, когда писать код стало почти бесплатно, и как компания переходит из текущего состояния в новое. Вот цепочка ролей коротко:
- бизнес-инициатор формулирует намерение и критерии приемки,
- аналитик и архитектор уточняют спецификацию,
- CTO управляет проверками и правом вето,
- ревьюеры читают доказательство, а не код,
- владелец продукта подтверждает выполнение задачи.
Никого не оценивают по количеству строк кода. Каждого оценивают по изменениям, которые дошли до подтверждения выполнения без переделок.
Линия видна через тот же трекер, которым команда уже пользуется. Учить нечего: та же доска, те же колонки, канбан, если так было раньше. Агенты двигают карточку, и каждый шаг оставляет на ней след: версия спецификации, упавший тест, merge request, отчет тестировщика, вердикт. Владелец продукта, ревьюер или CTO открывает карточку и видит, где изменение находится и чем это доказано - в инструменте, который и так открывают каждое утро.
Команда выстраивается под эту цепочку. На втором месяце пилота старшего разработчика заменили разработчиком среднего уровня. Система продолжила работать, а архитектурной ответственности у нашего архитектора стало больше. Вот что на самом деле значит "старшего заменили на среднего": ответственность сместилась наверх, а не исчезла.
Еще одна цифра касается адаптации. Мотивированному человеку нужно от двух до четырех месяцев, чтобы перейти от написания кода к управлению агентами. Немотивированному - сколько угодно, и день обучения этот срок не сокращает.
У первого месяца пилота есть барьер, который никаким инструментом не убрать. Инженеры доверяют собственному коду и судят о чужом коде, читая его. Код агента - это чужой код, а линия производства просит перестать его читать. Помогло не убеждение. Мы перенесли предмет доверия с кода на доказательство: спецификация, закрепленная хешем, упавший тест, который стал зеленым, скриншоты тестировщика - все рядом с диффом, и читать код разрешалось ровно столько, сколько кто-то хотел. Как вести этот месяц, кто с кем работает в паре и что делать с человеком, который так и не перестал читать код, - тема отдельного материала.
Фундамент: инфраструктура
Это самый скучный раздел, и большая часть его у вас, скорее всего, уже есть. Он про то, на чем фабрика физически работает:
- вычислительные мощности для рабочих процессов и песочниц, доступные через туннель, а не через публичный порт,
- доступ к моделям по подписке или ключу для каждой роли, включая резервные варианты и стоимость изменения,
- существующие репозитории и CI, где защита ветки следит, чтобы подтвердить выполнение задачи мог только человек,
- трекер как источник истины для спецификаций и вердиктов,
- хранилище секретов, которое держит их подальше от агентов,
- мониторинг - у нас он почти неприлично простой: тишина ботов в трекере или в Telegram сама по себе значит, что что-то сломалось.
Однажды фабрика закончила две задачи и передала их человеку, но никто не получил сообщение, потому что оповещения были настроены только на сбои. Теперь у каждой передачи человеку есть размеченный маршрут. Пока маршрут передачи не размечен, задачу не запускают.
Проект с нуля выбирает стек, под который линия уже собрана, один раз. Проект на существующей системе сохраняет ваши репозитории, CI и трекер, а раннер подстраивается под них.
Зачем нужна картинка
Потому что любой разговор про использование ИИ в разработке рано или поздно сводится к одному из этих пяти элементов, а собеседник напротив обычно сосредоточен на другом. Инженеры хотят обсуждать сборочную линию. CTO волнуют крыша и балка. Менеджерам продукта нужна третья колонна, хотя они этого еще не осознали. Когда перед глазами дом, каждый может показать на картинке часть, которая его беспокоит.
Дом мы нарисовали один раз, когда писали эту статью. В компании мы его не рисуем, а заполняем: подбираем под нее готовые блоки, которые у нас уже есть - роли, проверки, раннер, песочницы, интеграцию с трекером. Особенности у каждой компании свои, они не меняют конструкцию, но влияют на каждый проект.
Машина умеет все, кроме одного: подтвердить выполнение задачи. Весь этот дом существует для того, чтобы человек, который это подтверждает, мог отвечать за свои слова.
Домашнее задание на полдня
Прежде чем звать консультантов или покупать очередной агентный фреймворк, есть одна вещь, которую можно сделать самостоятельно, и на нее хватит половины дня. Написать крышу.
- Уместите ее на одну страницу.
- Перечислите классы изменений, которые вы выпускаете, и все, чего автоматизация не должна касаться никогда.
- Добавьте таблицу с тем, кто подписывает каждый класс.
Если таблицу подписей заполнить не получается, вы нашли недостающий элемент, и это не сборочная линия.
Мы строим такие линии вместе с командами клиентов как архитекторы процесса, с той же структурой дома и тем же правилом: скорость и право подписать - разные вещи. Если вам интересно, как это выглядит в виде готового решения, у нас есть управляемая разработка на приватном ИИ.