18 октября 2026 года разработчик Oliver Zehentleitner опубликовал подробный отчёт об эксперименте, в котором приложение уровня NotebookLM создавалось не обычной командой разработчиков, а семью параллельно работающими ИИ-агентами. Шесть из них отвечали за отдельные части системы, а седьмой координировал их работу, распределял задачи и объединял изменения.
От первого коммита до завершения основной фазы разработки прошло около 78 часов. За это время в репозитории появилось 648 объединённых pull request, 1 911 коммитов, 81 релиз и примерно 81 тысяча строк Python, TypeScript и JavaScript. Автор также насчитал 208 файлов с тестами, около 300 зафиксированных инженерных решений и 13 703 обращения к моделям. Собственное участие Zehentleitner он оценивает примерно в 20–24 часа.
Такие цифры легко превратить в заголовок о том, что один разработчик с ИИ за три дня заменил полноценную команду. Но сам эксперимент этого не доказывает. В нём нет контрольной группы из обычных разработчиков, неизвестна полная стоимость работы моделей, а количество строк кода и pull request само по себе ничего не говорит о бизнесовой ценности результата.
Гораздо интереснее другое: Zehentleitner фактически собрал небольшую инженерную организацию из ИИ-исполнителей и довольно подробно описал, что потребовалось, чтобы она вообще работала.
Не семь чатов, а настоящая структура команды
Проект называется lasteverLM. Это приложение для работы с документами и источниками в духе NotebookLM: пользователь может загружать PDF, текст, веб-страницы, изображения и аудио, задавать вопросы по материалам, получать ответы со ссылками на источники и генерировать на их основе отчёты, таблицы, тесты, диаграммы и другие материалы.
Архитектура проекта была заранее разделена на относительно самостоятельные области. Один агент занимался инфраструктурой и развёртыванием, другой — загрузкой и обработкой документов, третий — поиском и генерацией ответов, четвёртый — интерфейсом, пятый — учётными записями и биллингом, шестой — общей библиотекой и внутренними компонентами. Седьмой агент не отвечал за отдельный сервис, а выступал координатором.
Каждый исполнитель работал в собственной копии одного Git-репозитория. Изменения оформлялись через отдельные ветки и pull request. Перед слиянием запускались автоматические проверки, а координатор контролировал интеграцию изменений в общую систему. То есть эксперимент гораздо меньше похож на популярный образ «семь нейросетей одновременно что-то вайбкодят» и гораздо больше — на обычный процесс разработки с распределением ответственности, review, CI и релизами.
Это, пожалуй, один из самых важных выводов всего эксперимента. Чем больше ИИ получает реальной самостоятельности, тем меньше разработка похожа на один хороший промпт и тем больше зависит от нормальной инженерной организации.
Человеку не пришлось управлять семью агентами напрямую
Zehentleitner специально построил процесс так, чтобы не держать семь параллельных разговоров. Основное общение шло через управляющего агента. Человек ставил задачу ему, а координатор уже решал, какие исполнители должны участвовать, собирал результаты и возвращал наверх только вопросы, требующие решения владельца проекта.
Это принципиально важная деталь. Если человек вынужден отдельно следить за каждым агентом, помнить состояние каждой задачи и вручную согласовывать их действия, выигрыш от параллельности быстро исчезает. Вместо разработчика он превращается в оператора нескольких чат-окон.
В lasteverLM координация частично была передана самому ИИ. Управляющий агент выполнял функции, похожие на смесь технического руководителя и менеджера проекта: декомпозировал работу, отправлял задачи исполнителям, следил за зависимостями и объединял результаты.
Но полная автономность всё равно не получилась. И это не недостаток эксперимента, а как раз одна из самых интересных его частей.
Агенты столкнулись с теми же проблемами, что и обычная команда
Параллельные исполнители довольно быстро начали конфликтовать в общих частях проекта. Несколько pull request одновременно меняли одни и те же файлы, серверная часть могла отставать от интерфейса, а изменения одного компонента нарушали ожидания другого. Возникали проблемы и в инфраструктуре выпуска: параллельные релизы конфликтовали, отдельные скрипты некорректно обрабатывали ошибки, а фоновые задачи прерывались во время развёртывания новой версии.
Ничего специфически «нейросетевого» здесь нет. Это классические проблемы командной разработки: общие зависимости, плохие контракты между компонентами, гонки изменений и необходимость синхронизации. Разница лишь в скорости. Если несколько людей создают конфликтующие изменения в течение недели, команда обычно успевает заметить проблему постепенно. Несколько ИИ-агентов способны создать тот же объём пересечений за несколько часов.
В этом смысле агенты не отменяют необходимость хорошей архитектуры. Скорее наоборот: высокая скорость исполнителей делает плохие границы между компонентами заметными гораздо раньше.
Если агент интерфейса рассчитывает на новый API, а агент серверной части его ещё не реализовал, оба могут идеально выполнить собственные задачи и всё равно получить неработающую систему. Поэтому для мультиагентной разработки особенно важны контракты: кто владеет схемой данных, как меняются общие интерфейсы, какие изменения можно объединять независимо, а какие должны идти в определённом порядке.
Память проекта оказалась отдельной инфраструктурой
При такой скорости разработки появилась ещё одна проблема: следующему агенту мало видеть текущий код. Ему полезно понимать, почему система устроена именно так.
Для этого в проекте использовался механизм Keep the Why. Архитектурные решения записывались рядом с кодом: что выбрали, какие альтернативы рассматривали, почему их отвергли и при каких условиях решение нужно пересмотреть. В итоге накопилось около 300 таких записей.
Это разумный подход не только для ИИ-команд. Обычные разработчики тоже постоянно сталкиваются с ситуацией, когда через несколько месяцев кто-то «исправляет» странный кусок системы, не зная, что он был сделан намеренно. Для агентов риск выше: модель видит код и может вполне убедительно решить, что нашла очевидную ошибку, хотя перед ней результат уже принятого компромисса.
При этом автоматическая документация тоже быстро устаревала. Zehentleitner пришлось несколько раз сверять сохранённые решения с реальным состоянием проекта. Это показательный момент: ИИ способен очень быстро создавать документацию, но с той же скоростью он способен создавать красиво оформленную устаревшую документацию. Поэтому корпоративная память тоже требует жизненного цикла и проверки актуальности.
648 pull request не означают 648 готовых функций
Большие цифры эксперимента выглядят впечатляюще, но интерпретировать их нужно осторожно. В среднем за 78 часов получалось больше восьми объединённых pull request в час. Однако pull request в таком процессе нельзя считать эквивалентом отдельной пользовательской функции или задачи обычного разработчика.
Часть изменений была небольшой. Часть исправляла предыдущие изменения. Другие касались тестов, инфраструктуры, документации, CI/CD или выпуска версий. Поэтому 648 PR и 81 тысяча строк кода прежде всего показывают интенсивность изменений, но не позволяют оценить производительность в привычном смысле.
То же касается строк кода. Большая кодовая база не обязательно лучше маленькой. Иногда большое количество кода означает развитую функциональность, а иногда — лишнюю сложность и будущую стоимость сопровождения. Для бизнеса строка кода сама по себе не имеет ценности. Ценность имеет работающая функция, которая решает задачу и не создаёт неприемлемых расходов дальше.
Сам автор отдельно предупреждает об этом в отчёте. Он использует объём кода и количество изменений как характеристику масштаба эксперимента, а не как доказательство того, что ИИ-команда была в несколько раз производительнее людей.
Более содержательный результат — работающий процесс поставки
Гораздо интереснее то, что проект не остался набором сгенерированных файлов. В репозитории есть автоматические тесты, миграции базы данных, правила безопасности, учёт стоимости моделей, документация, CI/CD и автоматическое развёртывание.
Каждый релиз собирал контейнеры, применял миграции, разворачивался в Kubernetes и проходил smoke test уже на опубликованной версии. По данным автора, медианное время от создания тега до развернутого и проверенного релиза составляло около 3,6 минуты.
Это важнее числа строк, потому что показывает: агенты участвовали не только в написании функций, но и в полном инженерном цикле доставки продукта. Система постоянно переходила из состояния «изменён код» в состояние «новая версия развёрнута и доступна для проверки».
Но даже такой контур не решил проблему качества полностью.
Автоматических тестов оказалось недостаточно
В проекте было 208 файлов с тестами, а pull request проходили обязательные автоматические проверки. Тем не менее во время ручного использования Zehentleitner продолжал находить дефекты, которые тесты не заметили.
Например, одна из диаграмм использовала источники, которые пользователь исключил из выборки. В другом месте длительность аудиофайла считалась только по первому сегменту. Некоторые части генерируемых отчётов обходили механизм проверки. Система обработки изображений могла принять некачественный результат модели как пригодный источник.
После обнаружения такие ошибки исправлялись и превращались в новые регрессионные тесты. Это нормальный инженерный процесс, и именно поэтому эксперимент полезно рассматривать без магии. ИИ заметно ускорил цикл «нашли ошибку — исправили — добавили тест — выпустили новую версию», но не отменил необходимость реального использования продукта человеком.
Особенно показателен один случай с распознаванием изображений. Система плохо читала большой насыщенный скриншот, и первой реакцией могло бы быть желание взять более сильную vision-модель. Автор протестировал десять моделей и обнаружил, что проблема повторяется у многих. Тогда он изменил не модель, а сам процесс: изображение начали делить на перекрывающиеся участки. На одном тесте количество правильно извлечённых строк выросло с 68 из 160 до 159, на другом — с 37 из 60 до 60.
Это очень хороший пример того, почему качество ИИ-системы нельзя сводить к качеству модели. Иногда проблема решается архитектурой вокруг неё.
Координатор тоже оказался ограниченным исполнителем
Управляющий агент сокращал нагрузку на человека, но сам не был безошибочным. В одном случае он поручил другому агенту действие, для которого правила проекта требовали прямого разрешения человека. Исполняющий агент отказался выполнять команду, потому что согласование от другого ИИ не считалось достаточным.
Это мелкий эпизод, но он хорошо показывает важный принцип агентных систем: иерархия не должна автоматически расширять полномочия. Если определённое действие разрешает только человек, управляющий агент не должен иметь возможность сказать подчинённому: «Человек разрешил, можешь делать».
В проекте Zehentleitner несколько классов действий были специально оставлены за владельцем: доступ к реальным пользовательским данным, изменения прав, некоторые операции в production и расширение области проекта после введения feature freeze. Агенты могли готовить решение, но не самостоятельно переступать эти границы.
Поэтому назвать lasteverLM полностью автономной разработкой было бы неверно. Это скорее высокоавтоматизированная команда внутри заранее определённого человеком контура.
Роль разработчика изменилась, но не исчезла
Оценка автора в 20–24 часа собственного участия на фоне 78 часов календарного времени действительно выглядит впечатляюще. Но важно посмотреть, чем именно он занимался.
Он определял продукт и архитектурные ограничения, принимал решения, которые агенты не могли принять самостоятельно, тестировал систему на компьютере и телефоне, разрешал доступ к чувствительным ресурсам, находил дефекты, пропущенные автоматическими проверками, и решал, какие риски являются допустимыми.
То есть значительную часть ручного написания кода действительно удалось убрать. Но оставшаяся работа сместилась туда, где нужно определять правильность результата.
Это похоже не столько на исчезновение разработчика, сколько на изменение его роли. Он меньше занимается непосредственным набором кода и больше — постановкой задачи, архитектурой, контролем качества, разрешением спорных ситуаций и управлением быстро работающими исполнителями.
И здесь возникает новый предел масштабирования.
Узким местом стало внимание человека
Семь агентов могут работать параллельно. Человек — нет.
Если каждый исполнитель начнёт постоянно запрашивать подтверждения, задавать вопросы и приносить спорные решения, человек быстро превратится в диспетчера. Тогда увеличение количества агентов перестанет давать пропорциональное ускорение.
Zehentleitner сам приходит примерно к этому выводу. Вместо семи отдельных разговоров ему нужен единый интерфейс, который показывает только то, что действительно требует человеческого решения: блокирующие вопросы, спорные действия, запросы на расширение полномочий и критичные изменения. Всё остальное система должна решать самостоятельно.
Это, возможно, важнее большинства цифр эксперимента. Когда стоимость исполнения работы резко снижается, дефицитным ресурсом становится способность принимать решения.
Технически можно запустить ещё одного агента почти мгновенно. Добавить ещё одного человека, способного понимать контекст продукта и качественно принимать спорные решения, намного сложнее.
Экономика эксперимента остаётся неизвестной
При всей подробности отчёта в нём нет одного показателя, без которого нельзя делать вывод об экономической эффективности: полной стоимости работы агентов.
Известно, что было выполнено 13 703 обращения к моделям и что суммарная активность семи агентных сессий составила около 138,5 часа. Но это не человеческие часы и не денежная стоимость.
Мы не знаем полного количества входных и выходных токенов, распределения запросов по моделям, стоимости подписок или API, влияния кэширования и других параметров. Поэтому посчитать цену проекта по опубликованным данным нельзя.
Тем более нельзя честно сравнить её со стоимостью команды из нескольких инженеров. Для этого пришлось бы учитывать не только разработку, но и последующее сопровождение.
Это особенно важно для большой кодовой базы. Если систему удалось создать очень быстро, но через несколько месяцев её сложно изменять или понимать, первоначальная экономия может исчезнуть. 81 тысяча строк кода в таком случае становится не только активом, но и обязательством, которое кто-то должен сопровождать.
Нужна контрольная группа, которой в эксперименте нет
Чтобы утверждать, что такой способ разработки действительно эффективнее, эксперимент пришлось бы строить иначе. Например, дать одинаковую задачу одному разработчику с ИИ, одному агенту, нескольким агентам и небольшой обычной команде.
После этого сравнить не строки кода и количество коммитов, а полный результат: сколько функций действительно принято, сколько осталось дефектов, сколько времени потребовалось человеку, сколько стоили модели, как быстро исправлялись ошибки и насколько удобно развивать систему спустя месяц.
Таких данных в lasteverLM нет. Поэтому эксперимент доказывает скорее техническую возможность масштабировать агентную разработку, чем экономическое превосходство над обычной командой.
Но это всё равно очень ценный результат.
Что из эксперимента можно перенести в обычную компанию
Для начала точно не нужны семь агентов. Можно взять два или три параллельных ИИ-исполнителя и один небольшой внутренний проект.
Например, один агент работает с серверной частью, второй — с интерфейсом, третий занимается тестированием и проверкой интеграции. Человек остаётся владельцем результата и получает только те вопросы, которые действительно требуют решения.
Важно заранее определить границы ответственности между агентами, автоматические проверки, правила работы с production и критерии приёмки. После этого можно взять 10–15 реальных задач и сравнить процесс с обычной разработкой.
Измерять стоит не количество activity в Git, а время от постановки до принятого результата, стоимость моделей, участие человека, число повторных исправлений, дефекты после приёмки и количество решений, которые пришлось эскалировать.
Если при тех же требованиях один человек с несколькими агентами действительно выдаёт больше принятой работы при сопоставимой стоимости и качестве — это уже аргумент.
Возможно, самый важный продукт эксперимента — не lasteverLM
Само приложение интересно, но архитектура процесса вокруг него, пожалуй, интереснее.
Последние несколько лет мы в основном обсуждали, какая модель лучше пишет код, насколько она умна и сколько стоит миллион токенов. Эксперимент Zehentleitner показывает следующую проблему уровнем выше: что делать, когда достаточно способных исполнителей становится много.
Как между ними распределять работу? Как они узнают о решениях друг друга? Кто отвечает за общие интерфейсы? Какие изменения можно принимать автоматически? Какие решения должен видеть человек? Как сохранить историю причин, а не только историю кода? Как сделать так, чтобы руководитель не стал главным тормозом всей системы?
Эти вопросы очень похожи на обычное управление командой. И это, возможно, не совпадение.
Чем самостоятельнее становятся ИИ-агенты, тем меньше проблема похожа на работу с чат-ботом и тем больше — на управление организацией, пусть пока и очень небольшой.
Что на самом деле показали эти 78 часов
Эксперимент lasteverLM не доказывает, что семь ИИ-агентов заменили семь разработчиков. Он не позволяет утверждать, что 81 тысяча строк кода была создана дешевле обычной разработки, и не показывает, насколько хорошо эта система будет сопровождаться через год.
Полный отчёт автора опубликован в его блоге, фактическая хроника сборки с цифрами и списком проблем — на странице how it was built; все ключевые числа этой статьи сверены с этими источниками.
Но он довольно убедительно показывает, что несколько ИИ-исполнителей уже можно организовать для параллельной работы над достаточно сложным продуктом. И что для этого им нужны примерно те же вещи, которые нужны человеческой команде: понятная архитектура, зоны ответственности, история решений, автоматические тесты, процесс выпуска и ограничение полномочий.
Меняется другое: скорость исполнителей.
Когда код, исправления и новые версии появляются гораздо быстрее, сама разработка перестаёт быть главным ограничением. Дефицит смещается к архитектурным решениям, проверке качества и человеческому вниманию.
Поэтому главный вывод эксперимента я бы сформулировал не как «семь ИИ-разработчиков построили продукт за 78 часов».
Он интереснее:
если исполнение становится очень дешёвым и быстрым, главным ограничением компании становится способность правильно ставить задачи, принимать результаты и вовремя принимать решения.
