За последние пару лет велосипед разработки с использованием ИИ прошел путь от автодополнения кода до «шесть агентов пишут код, седьмой его ревьюит, а человек применяет, даже не открывая diff».
Каждый новый подход добавлял велосипеду то руль побольше, то более круглое колесо, то спидометр, то моторчик. Седло при этом каждый раз забывали. Ехать можно, даже быстро и эффектно. Просто через несколько месяцев выясняется, где именно болит.
Я не против ИИ в разработке и сам им пользуюсь. Но давайте пройдемся по хронологии и посмотрим, как мы радостно раз за разом давили на педали такого велосипеда.
Эпоха умного «T9»
Все начиналось скромно: подсказки в IDE, потом чат в соседней вкладке. Копируем ошибку, вставляем в чат, получаем уверенный ответ, копируем обратно, получаем новую ошибку.
Ответственность за результат целиком лежала на человеке, потому что он был единственным, кто запускал и проверял код. Это был велосипед с седлом, но маленький, детский, с боковыми колесиками. Именно поэтому никому не было страшно, но и разогнаться на нем было невозможно.
Вайбкодинг
В феврале 2025 года Андрей Карпати описал стиль работы, при котором вы отдаетесь «вайбам», принимаете все предложения агента и забываете, что код вообще существует. Термин взлетел и стал словом года. Все как‑то пропустили момент, что в оригинале это была шутливая зарисовка про выходные и одноразовые проекты. Дядя пошутил, а индустрия прочитала это как методологию.
Основатели без технического бэкграунда начали брать no‑code/low‑code платформы или просить ИИ написать приложение «как Uber, только для собак», забыв про базовую цифровую гигиену. Это даже не упрек, ведь гигиену никто и не обещал.
Никто в чат‑интерфейсе не спрашивает: «а у нас точно закрыт доступ к базе?». Зато чат‑интерфейс с радостью сообщает, что приложение готово, и это главное. MVP собирается за вечер, в пятницу его выкладывают в прод, в понедельник в него приходят первые пользователи, а во вторник появляются первые вопросы, которые начинаются словами «а почему я вижу чужие данные» и «где моя собака?».
Показательна история Enrichlead. Основатель публично хвастался, что написал продукт целиком через Cursor без единой строки собственного кода. Через несколько дней пользователи обошли платные подписки, в системе нашли элементарные уязвимости, а сервис пришлось закрыть. Это хорошая иллюстрация того, что проблема не в ИИ, а в том, что за результат отвечал человек, который не мог его (результат) проверить.
Другой известный эпизод: в июле 2025 года основатель SaaStr Джейсон Лемкин рассказал, что агент Replit удалил рабочую базу данных в период, когда ему прямо запретили изменения кода, а потом еще и неверно описал, что произошло.
Инструкция «никогда не трогай прод» в промпте оказалась не такой уж надежной, если агент имеет доступ к боевой базе, то однажды он ею воспользуется, и защита должна быть в правах доступа, а не в вежливой просьбе в промпте.
Отдельным интересным явлением стал slopsquatting, основанный на том, что модель уверенно предлагает подключить пакет, которого не существует. В исследовании 2025 года на сотнях тысяч сгенерированных фрагментов доля таких галлюцинированных зависимостей в среднем составила порядка 20%. Злоумышленнику достаточно было зарегистрировать пакет с таким именем и подождать. Вайбкодер сам выполнит npm install, потому что «оно же предложило».
Но самая большая проблема начинается после MVP. Код, который никто не читал, внезапно приходится поддерживать. Агент чинит одно и ломает другое, потому что не помнит, зачем что‑то было написано, а человек, который «просто описал идею», сам не может сказать, где искать проблему. Промпт «почини» превращается в лотерею: иногда помогает, иногда добавляет еще триста строк, которые тоже никто не откроет. Так вайбкодинг стал скоростным способом создавать технический долг.
Справедливости ради, для прототипа, лендинга, внутреннего скрипта или проверки гипотезы вайбкодинг замечателен. Быстро проверить идею действительно можно. Проблемы начинаются в тот момент, когда прототип получает пользователей, платежи или персональные данные, а рассуждать в духе «потом перепишем» уже поздно: не перепишете. Попытка отпустить руль на длинной дистанции, после PoC или MVP, ни к чему хорошему не приводит.
Агенты
Затем пришла мода приделывать к велосипеду моторчик в виде различных агентных инструментов: Cursor, Claude Code, Codex, режимы агента в Copilot и десяток других. Агент сам читает репозиторий, правит файлы, гоняет тесты и коммитит. У всех выросла уверенность в том, что выросла производительность.
Здесь стоит вспомнить исследование METR 2025 года. Опытные разработчики работали в собственных зрелых репозиториях, и с ИИ‑инструментами задачи у них занимали примерно на 19% дольше. При этом сами участники были убеждены, что стали быстрее.
Из этого нельзя сделать вывод, что ИИ замедляет всех, ведь тогда агенты были довольно сырыми. Но вывод о том, что ощущение скорости и реальная скорость это разные вещи, сделать вполне можно. По мере взросления агентов детские болезни ушли, но появились взрослые.
Сначала мы искали «магические слова» для промпта. Потом выяснилось, что в промпте главное контекст, и в моду вошла контекст‑инженерия. Появились файлы правил: .cursorrules, CLAUDE.md, AGENTS.md.
Через месяц в них уже тысяча строк, половина написана капслоком («НИКОГДА», «ВСЕГДА», «НЕ ЗАБУДЬ»), а еще примерно треть противоречит остальному содержимому. Агент читает все это внимательно и старается следовать тому, что написано. Нужно было как‑то помочь ему отделять мух от котлет, и тут появились скиллы.
Логика понятная: раз уж монолитный файл правил превратился в нечитаемую свалку, давайте применим микросервисный подход. Разобьем контекст на компактные узкоспециализированные модули, дадим им описания и будем подгружать их в память модели строго по требованию.
Пишешь тесты, значит агент подтягивает инструкцию для тестирования. Рефакторишь базу данных, значит подключаешь скилл работы с ORM и принципами Extract/Inline/Replace. Модель больше не захлебывается в километрах текста и старается фокусироваться на том, что делает прямо сейчас.
Идея сама по себе здравая: агенту нужны правила, стиль проекта и границы. Но «дать агенту хороший контекст» свелось к «написать ему трактат, который он забудет на пятом шаге». Если контекст никто не проверяет и не тестирует, это просто новая цепь на трещотке, которая провисает чуть меньше.
MCP
Набирает популярность Model Context Protocol, который выглядит как «USB‑C для ИИ»: единый способ подключить агента к базе, трекеру, почте, браузеру и файловой системе. С одной стороны, это удобно, а с другой стороны MCP‑серверы плодятся быстрее, чем успевают проводить их аудит.
Типичный агент в типичной команде теперь имеет доступ к десятку MCP‑серверов, из которых половину поставил коллега «на попробовать», а у трети описание инструментов занимает больше места, чем сама задача. Такой набор из кучи разных звездочек для скоростей не мог не ухудшить ситуацию с безопасностью: расцвел prompt injection, ведь если агент читает почту, сайты и репозитории, любой текст оттуда потенциально становится командой.
Подобных инцидентов было немало, но вывод раз за разом сводился к «надо аккуратнее». Аккуратнее не получается, потому что выдавать права агенту приятно, а рассказывать потом, как у тебя крутятся агенты, которые сами все делают, не стыдно.
SDD
Когда стало ясно, что «просто скажи агенту, что нужно» работает нестабильно и цепь на звездочке проскальзывает, индустрия открыла для себя натяжитель цепи в виде постановки задачи. Так родился Spec‑Driven Development, снова (ему уже 22 года). AWS выпустила Kiro, GitHub выпустил Spec Kit, появились OpenSpec, BMAD и десятки других.
В теории это разумно: сначала спецификация, потом план, потом код. Зафиксировать намерение до реализации это старая, хорошая практика еще со времен, когда ИИ‑велосипедов не было и все прыгали по граблям старым дедовским способом, то есть ногами. Но и тут есть нюансы.
Во‑первых, мы заново изобрели техническое задание, причем в формате Markdown и с генерацией от того же агента. Ирония в том, что вместо вороха документов, который пишет человек, мы получили ворох документов, которые пишет LLM. Прочитать и проверить их все равно нужно человеку.
Во‑вторых, для тривиальных задач спецификация повторяет код, раздувая контекст. Требование «система должна возвращать список всех записей», если подумать, то это буквально сигнатура метода в виде прозы.
В‑третьих, встает вопрос дрейфа данных. Код, тесты и спецификации это три источника истины, и связать их автоматически удается редко. Если спецификация не проверяется в CI, она устаревает так же, как любая вики, только быстрее, потому что документов больше.
В‑четвертых, есть проблема параллельных изменений. Две «дельты» на одно и то же требование при слиянии дают конфликт: либо текстовый, либо, что хуже, семантический, который git даже не заметит.
Это не значит, что SDD бесполезен. Для неоднозначных требований, командной работы и долгоживущего поведения он может окупаться. Но по большинству публикаций про него трудно понять, где именно, потому что сравнений, измерений и честных провалов там почти нет.
Сравнить его с обычным plan mode никто не удосужился, а это единственное сравнение, которое имело бы смысл.
Harness
Когда стало понятно, что сама модель не превращается в надежного исполнителя от мотивирующих промптов, индустрия сделала логичный инженерный шаг: если нельзя починить весь велосипед, то давайте хотя бы смажем все трущиеся части, включая шток.
Так появился харнесс, то есть упряжь. Это обвязка вокруг модели, которая превращает ее в агента: набор инструментов, права, песочница, управление контекстом, циклы сделал‑проверил‑исправил, хуки, автоматические тесты, линтеры, ограничения на действия и так далее.
Идея правильная, и именно здесь произошел самый настоящий прогресс. Хороший харнесс превращает модель, которая иногда угадывает нужное решение, в систему, которая хотя бы обнаруживает свои ошибки. Тесты, типы, статический анализ, песочница и работа в цикле это та самая смазка, которой не хватало при езде.
Но у подхода есть побочный эффект: смазывать можно бесконечно. Каждый раз, когда агент делает что‑то не то, в харнесс добавляется еще одно правило, еще один хук, еще один проверяющий шаг.
Через полгода система напоминает поршневой шток у вилки, который обмазали всеми видами смазки сразу: он скользит, но никто уже не помнит, какая из смазок делает работу, а какая просто липнет.
Это классическая проблема изоляции, древнее знание, которое исчезло вместе с мамонтами: вклад каждого слоя не отделен от других. Улучшилось качество от нового хука или от того, что вышла новая версия модели? Ответа обычно нет, ведь абляций никто не делает, потому что на это нет времени: все несутся с горы на велосипедах.
Сформировалась даже отдельная небольшая секта любителей цикличности: агента запускают в бесконечном цикле с одним и тем же промптом, пока тесты не позеленеют, в народе такие схемы называют «Ральфами» (по мотивам популярной в прошлом году идеи).
Иногда это работает, а иногда тесты позеленели просто потому, что агент дотянулся и изменил сами тесты. Метод «крутить, пока не получится» хорош только тогда, когда результат проверяет не тот, кто крутит цикл. На практике все больше людей приходят к выводу, что обмазывание тестами со всех сторон полезно, но скорее маскирует проблему, чем исправляет ее. Скорость растет, технический долг растет, а времени разбирать лапшу, которую написал ИИ, у разработчика остается все меньше.
Мультиагентные системы
Следующий шаг очевиден: если один агент хорош, пусть будет два, а лучше семь. Один планирует, второй пишет, третий тестирует, четвертый ревьюит, пятый ревьюит ревьюера, шестой пишет отчет о том, как всем было хорошо, а седьмой потом всех проверяет. Есть оркестраторы и субагенты, параллельные рабочие ветки и команды агентов, которые работают днем и даже ночью, пока люди спят.
Зачастую это действительно работает. Разные модели находят разные ошибки, перекрестное ревью полезнее самопроверки, а независимые подзадачи хорошо параллелятся. Это отличная попытка сделать колеса велосипеда круглыми, но и здесь не обошлось без проблем.
Главная проблема в токенах и деньгах. По публикациям самих разработчиков таких систем, мультиагентные схемы могут расходовать в разы, а то и на порядок больше токенов, чем один агент, и окупаются далеко не на любой задаче.
Дальше идет проблема общего контекста: агенты, которые работают параллельно и не знают решений друг друга, принимают несовместимые допущения. С отладкой тоже сложно: когда результат неверен, приходится выяснять, какой из семи агентов и на каком шаге принял неверное решение.
Отдельно стоит ритуальное ревью, когда подход «ИИ проверил ИИ» легко превращается в церемонию: человек видит зеленые галочки и применяет код, а задача ревью никуда не делась, просто стала менее заметной. И наконец, конфликты изменений: параллельные агенты пишут в одни и те же файлы, а слияние все равно делает человек или еще один агент.
Раз уж у нас все смазано, колесики более‑менее ровные, есть руль и педали, самое время прикрутить спидометр, заодно и одометр. Примерно так думает руководство, когда озвучивает метрики внедрения.
«Доля кода, написанного ИИ» и «сколько токенов потратила команда» это измерения активности, которые не имеют отношения к результату. По закону Гудхарта такие цифры быстро становятся целью, и разработчики начинают генерировать ради цифры, как до них практиковали улыбчивые ребята из Бангалора при оплате за строки кода. Красиво отчитаться можно, но это все тот же велосипед без седла, только теперь на нем висит индикатор километража (одометр).
RAG
Сейчас ни один корпоративный ИИ‑проект не обходится без RAG. Логика проста: берем документы, режем на куски, кладем в векторную базу, находим похожее и отдаем модели.
Отличная фара, чтобы видеть, куда ехать. В презентации это выглядит как одна стрелка, в реальности за ней прячется десяток решений: парсинг PDF, чанкинг, роутинг, эмбеддинги, реранкер, права доступа, обновление индекса, оценка качества.
Типичный путь такой системы выглядит примерно так. Первую версию собирают за выходные, и она отвечает на три демо‑вопроса. Потом выясняется, что таблицы из PDF превратились в кашу, что чанки размером в пятьсот токенов разрезали предложение посередине, что система показывает сотруднику документы, которые ему видеть нельзя, и что никто не знает, насколько хорошо она вообще отвечает, потому что оценочного набора нет. Зато есть дашборд с красивым графом.
RAG‑стек собирают на коленке из чужих компонентов, и мало кто читает лицензии. Это касается и внутренних команд, и больших интеграторов, собирающих RAG‑системы на заказ.
Возьмем парсер PDF на PyMuPDF. Библиотека популярна в RAG‑пайплайнах, распространяется под AGPL или по коммерческой лицензии от Artifex. Если вы разработали сервис, положили его в основу закрытого продукта и не купили коммерческую лицензию, у вас возникает интересный разговор с юристами клиента.
Напомню суть проблемы: если вы распространяете свое приложение как десктопное ПО, мобильное приложение или Docker‑контейнер, или предоставляете к нему доступ через сеть как SaaS или веб‑сервис, вы обязаны открыть исходный код всего своего продукта под той же лицензией AGPL-3.0.
Похожая история с S3-совместимым хранилищем MinIO, оно тоже под AGPL. Хранилище тихо сидит в докере, пока не наступает момент продажи продукта заказчику «в коробке».
Платформа для оркестрации n8n использует собственные лицензии с ограничениями на коммерческое использование и перепродажу, так что код открыт лишь формально.
С моделями Llama та же история: лицензия распространяется на собственных условиях с дополнительными требованиями, и по критериям OSI это не открытая лицензия. Как минимум нужно разместить заметную надпись «Built with Llama» или «Built with Meta Llama 3 / 4» на сайте вашего продукта, в пользовательском интерфейсе, документации или блоге, и не забыть указать, что компания Meta признана экстремистской организацией и запрещена в РФ.
Часть популярных эмбеддингов и реранкеров тоже выходит под некоммерческими лицензиями вроде CC BY‑NC, и хотя они свободно лежат на HuggingFace, использовать их в коммерческом продукте запрещено. Наконец, если вы дообучаете модель на коде из публичных репозиториев, у кода в этих репозиториях тоже есть свои лицензии.
В наших реалиях это что‑то на уровне катафотов, то есть световозвращателей, на велосипеде. Все ездят как есть и надеются, что именно их инспектор ДПС не тормознет. Хотя есть качественные и даже более быстрые аналоги различных элементов RAG‑системы с полностью открытой лицензией, но это же нужно разбираться. Когда несешься с горы, на это просто нет времени, просто не заложено в бюджет.
Итоговая картина такая. Команда интегратора собирает RAG‑платформу из компонентов с копилефтом и NC‑лицензиями, добавляет свой слой, оформляет все в SaaS и продает как закрытый enterprise‑продукт.
Про лицензии вспоминают, когда клиент присылает опросник по безопасности с пунктом «перечень используемого ПО и лицензий». Тут обычно и выясняется, кто ехал без седла.
Внутренним командам проще: их систему вне закрытого периметра никто не видит, достаточно лишь регулярно заказывать молебен в ближайшей церкви, чтобы руководству не взбрело в голову упаковать «нашу замечательную систему» в коробку и продавать как платформу соседям по рынку.
Имаго‑кодинг
Пока индустрия смазывает шток и разводит агентов, находятся люди (вроде меня), которые говорят: а давайте хотя бы дощечку вместо сидения прикрутим, пусть кривую. Суть идеи, если пересказать своими словами, не пытаться бесконечно улучшать запрос, как это делает SDD, а улучшать самого исполнителя с помощью двух элементов. RAG приносит факты: документацию проекта, схемы данных, свежие статьи, историю коммитов. А LoRA или QLoRA‑адаптация приносит привычки: это небольшой адаптер, дообученный на нескольких сотнях аккуратно отобранных примеров, чтобы модель писала код «как принято в этом проекте», использовала существующие хелперы и не изобретала собственные.
И тут тоже не все так здорово: дощечка намертво прибита к конкретной раме. Выйдет новая базовая модель, и дощечку нужно строгать заново. А если у вас десять клиентов, у вас десять дощечек и нужен человек, готовый стать Папой Карло. Дощечка получается неказистой, зато под конкретного седока. Она не спасет от ям на дороге, но на ней хотя бы можно сидеть, хотя, конечно, хочется большего комфорта.
Так что же такое седло в нашем случае? Не знаю, мы его еще не придумали. Колесо придумали, руль тоже, даже педали, а седло пока нет.
Заключение
Оглядываясь на происходящее с высоты осени 2026 года, замечаешь несколько проблем нашей велосипедной гонки.
Первая заключается в том, что инструменты появляются быстрее, чем команды успевают прочитать релиз‑статьи, а по компаниям и по людям развитие идет чудовищно неравномерно.
Если очень коротко, есть три основных марки велосипедов.
Владельцы первой марки живут на переднем крае: подписки на несколько фронтирных моделей, свои харнессы, MCP‑серверы, субагенты, хуки, ночные запуски. Они пишут посты про «10x ускорение» и искренне не замечают, что 30% времени тратят на настройку инструментов, а еще 30% на ревью того, что нагенерировали, либо забивают на вдумчивое ревью и тратят это время на разговоры о том, как все стало быстро.
У пользователей второго бренда ИИ разрешен в ограниченном режиме: облако запрещено из‑за персональных данных, коммерческой тайны и санкций, разрешен один одобренный ассистент, и то через согласование, а локальную модель пилотируют уже полгода. Разработчики пользуются личными аккаунтами, а служба безопасности узнает об этом из новостей про очередную утечку.
У третьего бренда, куда входят госсектор, промышленность, банковский legacy и подобные среды, ИИ используют в виде автодополнения или вкладки чата, если вообще используют. Им тоже хочется прокатиться на велосипеде, но у них нет ни прав, ни бюджета, ни времени.
Вот такая неравномерность: в одном офисе разработчики запускают агентов на ночь, а в соседнем ждут согласования доступа к чату. При этом в новостях, на конференциях и в корпоративных презентациях владельцы всех трех марок выглядят так, будто едут на одном и том же велосипеде в одну и ту же «эпоху ИИ».
Вторая проблема в перекосе по этапам разработки. ИИ сильно ускорил ту часть работы, где непосредственно пишется код, а это в реальной разработке далеко не все. Требования, согласования, ревью, релизы, инфраструктура, безопасность, поддержка и общение с заказчиком ускорились гораздо слабее.
Получилась классическая история, которую описывает закон Амдала: если один этап ускорить в десять раз, а остальные оставить как есть, система в целом ускорится заметно меньше, а очередь перед следующим этапом вырастет.
Код теперь появляется быстрее, чем его успевают читать. Пропускная способность ревью стала новым узким местом, ведь у каждого ответственного до сих пор есть фамилия, имя и отчество, а не название модели и количество параметров.
Третья проблема заключается в перекосе по людям. Опытные разработчики получили усилитель: они знают, что проверять, где ловушки, и умеют сформулировать задачу. Начинающие получили мощный генератор, но не получили опыта, необходимого, чтобы отличать хороший код от правдоподобного.
Индустрия при этом спорит, будут ли джуниоры вообще нужны, если «набивание шишек» теперь делает агент. А вот о том, как вырастить будущих сеньоров, почти никто не думает, и на этот вопрос не смогут ответить ни харнессы, ни спецификации.
Четвертая проблема относится к перекосу по измерениям. У нас есть красивые метрики использования и почти нет метрик результата. Мы знаем, сколько токенов сожгли и сколько строк сгенерировали. Мы плохо знаем, сколько из этого дошло до прода, сколько потом переписали и сколько инцидентов было связано с этим ИИ‑кодом.
И вот на всем этом хозяйстве индустрия радостно несется в сторону обещанной ИИ‑сингулярности. Стоя на педалях, с закрепленным на руле красивым дашбордом токенов.
Кто‑то смазывает шток, кто‑то прибивает дощечку, кто‑то читает лицензии (это редкие герои), а большинство просто жмет вперед, потому что остановиться сейчас значит, как кажется, безнадежно отстать.
Отстать, впрочем, не так страшно, как кажется.
Сингулярность, если верить сегодняшнему опыту, пока откладывается по вполне земным причинам: агент завис на диалоге подтверждения, MCP‑сервер снова потребовал авторизацию, а безопасник спрашивает про лицензию на векторную базу.
И это, пожалуй, хорошая новость: значит, у нас есть время докрутить все то, о чем говорилось выше. Пристегнуть тесты. Прочитать лицензии. Померить, что на самом деле стало быстрее. Оставить человека там, где цена ошибки высока. Выбирать инструмент под задачу, а не задачу под модный инструмент.
И поставить, наконец, седло.
Автор: ToxaBes
