tekBlueprint

Спонтанная статья об агентной разработке после некоторого времени и попыток использования этого подхода. Ниже общие тезисы, о части которых, наверное, около года назад ещё говорил. В целом, всё получается так, как и ожидалось. Революции не случилось, да и пузырь подсдувается то там, то здесь, хотя все делают вид, что всё “по плану”. Обещанный AGI, мир так и не захватил почему-то :)

Здесь не будет рекомендаций конкретных инструментов, моделей и так далее. Это всё постоянно меняется и нужно время, пока выйдут в лидеры открытые решения, а остальные отомрут по естественным причинам. Необходимо понимать, что это личный субъективный опыт и часть особенностей и проблем мог просто забыть уже, так как много всего было. Отдельная тема – это командная работа, которая тут тоже не затрагивается.

TL;DR

• Необходимо всегда явно оговаривать использование актуальной информации из интернета: актуальные библиотеки, подходы, архитектуры и так далее. Агент использует данные за тот срез времени, на котором обучался, что практически всегда не соответствует текущему состоянию. Исключение – базовые алгоритмы и подходы, которые устоялись за десятилетия и кардинально не меняются. Если этого не делать, то агент будет использовать устаревшие библиотеки или писать свои “велосипеды” (LLM очень любит это делать).

• При портировании или миграции необходимо всегда явно указывать, что референсный код или данные нужно использовать как пример функционала, а не инструкцию к действию. Не портировать один в один. LLM не мыслит абстракциями и не держит в контексте весь проект. Она будет пытаться повторить оригинал буквально даже в ущерб архитектуре и качеству кода или документации. Это же касается совместимости, LLM будет пытаться её сохранить даже если она не требуется и есть намного лучшие решения и подходы.

• Агент не помнит прошлые задачи и что было сделано. В результате постоянное дублирование кода, функций, документации. Сюда же относится невозможность вместить весь проект в контекст. Сессии, без дополнительных механизмов/плагинов для хранения постоянной памяти, никак не связаны друг с другом. Чтобы не дублировать, агент должен помнить контекст всего проекта, это невозможно без дополнительных механизмов. Сжатие при достижении лимита контекста, тоже не помогает, так как это сжатие с потерей информации.

• Сжатие при достижении лимита контекста теряет важную информацию и требует повторного перечитывания данных и кода. Часто ломает процесс. Похоже на предыдущую проблему, но в локальном контексте сессии. Может решаться использованием постоянной памяти или плагинами, сжимающими шаги рассуждений и вызовов инструментов (tools) для экономии контекста, но увеличивая расход токенов.

• Использование одной и той же модели для разных агентов ухудшает результаты рассуждений и постановки задач. Одна модель (или одного провайдера) того же поколения склонна делать неверные предположения или выводы. Второй агент чаще всего с ними будет согласен. Использование разных моделей от разных провайдеров заметно улучшает ситуацию, так как вносит больше вариативности в рассуждения и добавляет новые подходы решения.

• Рабочий процесс должен состоять из нескольких специализированных агентов со своими инструкциями и ограничениями. Это позволяет каждому из агентов быть более сфокусированным на своей области и задаче. Агент всё-в-одном склонен “облегчать” себе, вводя обходные пути или облегчая задачу в ущерб корректности и оптимальности решения. Плюс очень сильное влияние оказывает сжатие контекста, приводящее к общей деградации результата.

• Для полноценной работы требуется предварительная обкатка и настройка обвязки агентов: навыки, тулы, MCP, инструкции агентов и так далее. Инструментарий вокруг агентской разработки сильно влияет на финальное качество. Без него даже сильная модель будет ошибаться на средних/малых проектах. Обязательно нужно подбирать инструментарий под конкретный проект или предметную область.

• Для разного типа агентов требуется правильный выбор модели. Утверждение, что при правильном harness модель не очень важна – это обман. Модель очень сильно влияет на поведение агента и результат, особенно в сложных сценариях. В первую очередь это касается агентов-оркестраторов и агентов, составляющих план. Для них должна использоваться максимально умная модель с большим контекстом, которая не теряет фокус при многоэтапных рассуждениях и вызовах агентов. Остальные модели могут быть проще, так как выполняют узкоспециализированные задачи в ограниченном домене и контексте. Чаще всего так говорят те, которые “продают” свои платформы (IDP).

• Передача агентам задач в виде “сделай вот тут хорошо” – не работает. Как сказано выше, LLM очень чувствительна к постановке задачи. В большинстве случаев промпт является приказом на выполнение, если какие-то детали не указаны, то они будут додуманы и подстроены под основной промпт. Результат практически всегда неоптимален. Поэтому постановка задачи должна быть максимально чёткой: проблема, зависимости, ограничения, критерии приёмки, выходные результаты, прошлые ревизии.

• Использовать SpecKit, Openspec, BMAD в чистом виде не обязательно и не всегда эффективно. Данные фреймворки, как и сам SDD, это скорее рекомендация и точка старта для подстройки процессов по работе с ИИ в качестве ассистентов. Ни один из этих подходов не является серебряной пулей, которая сама по себе даст даже просто хороший результат. Часто просто является переусложнением. Необходимо проводить пилотные внедрения с подбором нужного фреймворка или адаптации/разработки своего (это не так сложно на самом деле)

• Если работа с UI/UX, то потребуются модели VLM. Модель должна “видеть” то, что получается, чтобы исправить или доработать. В противном случае она переключается на обходные пути с анализом DOM, изображений через пиксели и так далее. Обходные пути заметно усложняют решение задачи и приводят к некачественному результату.

• Для больших кодовых баз недостаточно тулов grep, rg, glob, read. Здесь нужно уточнить, что это справедливо в основном для моделей с небольшим контекстом. Модели с 1M контекстом могут оперировать большими данными, хотя и теряют фокус. В противном случае необходимо использование дополнительных инструментов вроде графовых RAG с MCP, чтобы модель могла быстро искать необходимые данные без перечитывания половины проекта.

• Высокое потребление токенов. Естественная проблема, если не используется постоянная память между сессиями и индексы проекта. Дополнительно можно использовать навыки с инструкциями для снижения “многословности” модели.

• Низкое качество сгенерированных решений. Джун/мидл/сеньор + LLM заменяет команду и даёт хороший результат – не соответствует истине. Главная проблема в том, что LLM выдаёт не лучшие и некорректные решения, а усреднённый или часто плохой результат. Не имея достаточного опыта для оценки, в том числе системного мышления, планирования на несколько шагов вперёд нельзя поймать LLM на “ошибках”. То есть код может работать, выполнять свою функцию, но будет содержать огромный технический долг, за который придётся платить позднее. Финальная стоимость проекта может оказаться не дешевле ручной разработки. Ошибку выжившего на небольших проектах-однодневках смысла брать в расчёт нет.
  
  Этот вывод основан не на теории, а на практике разработки и при портировании приложений (таблица ниже) на незнакомых языках и экосистемах. Если бы не долгий прошлый опыт разработки на разных языках с ручным разбором проблем ошибок, то большинство некорректных предложений и решений LLM попросту бы не заметил. И даже сейчас их много осталось в коде: понимание, что это неправильно, приходит только с опытом работы с новым языком разработки.

• LLM накапливает ошибки, что приводит к эффекту усугубления ошибок (compounding error effect). Даже маленькая неточность на раннем шаге генерации кода становится “истиной” для следующей итерации. Модель опирается на собственный сгенерированный некорректный код и факт как на базовый паттерн. Итогом становится полная деградация логики в коде или документации при отсутствии ручного контроля.
  Сама по себе агентская разработка без человека даёт плохой результат. Хайп вокруг, например, AI-платформ и разработки без человека (только постановка – intent), выглядит как инфоцыганщина и/или самореклама ИТ-компаний в попытке продать себя и свои продукты.

• Качественная разработка с LLM в конечном итоге стоит дороже по ресурсам и времени. Это кумулятивный эффект предыдущих проблем. По итогу внедрения LLM в процессы может оказаться, что добиться результата, который давали профессиональные сотрудники, сопоставимо или зачастую дороже, как ни странно, с LLM. Ничего кроме разумного подхода во внедрении здесь нельзя посоветовать, некоторым обязательно нужно испытать на себе все проблемы, чтобы понять как можно корректно встраивать ИИ в процессы.

• Стагнация и деградация профессиональных навыков. Тема сейчас спорная, и это нужно смотреть на горизонте в 1–2 года. Очевидно, что уже физически не получится ревьюить такие объёмы нейрослопа. А если это помножить на естественную человеческую лень, то всё часто будет сводиться к операторам консоли с LLM.

Знания и контекст

Актуальная информация из актуальных источников

Необходимо всегда явно оговаривать использование актуальной информации из интернета: актуальные библиотеки, подходы, архитектуры и так далее.

Модель обучена на срезе интернета, и этот срез почти всегда отстаёт от текущего состояния экосистемы. В результате агент либо тянет устаревшие версии библиотек, либо, что хуже, выдумывает. Проблема не гипотетическая: исследование «Importing Phantoms» (arXiv 2501.19012) показало, что LLM систематически галлюцинируют несуществующие пакеты, а отдельное эмпирическое исследование (fabriziosalmi) нашло 1000 верифицированных несуществующих пакетов, закоммиченных в публичные репозитории. То есть агент с уверенным видом напишет импорт или библиотеку, а сборка упадёт – и это именно тот случай, когда “велосипед” от LLM ещё не самый плохой исход.

Что можно с этим делать:

• явно прописать в инструкциях агента (AGENTS.md, rules): перед использованием внешней зависимости проверить её существование и актуальную версию через веб-поиск или реестр пакетов;
• включить тулы веб-поиска и чтения документации по умолчанию для задач, связанных с внешними API и библиотеками;
• зафиксировать версии стека проекта в инструкциях, чтобы модель не “обновляла” версии посреди задачи;

Большие кодовые базы

Для больших кодовых баз недостаточно тулов grep, rg, glob, read.

На небольших проектах последовательного поиска через grep/rg/glob/read хватает: агент находит файл, читает, продолжает. На больших базах этот подход ломается: агент либо перечитывает половину проекта, либо работает без нужного контекста и выдаёт решения, додумывая.

Здесь важно уточнение: это справедливо в основном для моделей с небольшим контекстом. Модели с 1M-контекстом действительно могут оперировать большими объёмами, но “вмещается” не значит “используется”. Исследование Chroma «Context Rot» (2025) прогнало 18 LLM и показало: все без исключения деградируют с ростом входного контекста, и 10 000-й токен обрабатывается хуже 100-го. RULER от NVIDIA (arXiv 2404.06654) подтверждает: фактический полезный контекст у моделей заметно меньше заявленного.

Рабочие варианты:

• графовый RAG через MCP: индекс структуры проекта (модули, зависимости, ключевые сущности), по которому агент ходит точечными запросами, вместо перечитывания файлов;
• постоянная память уровня проекта (AGENTS.md, конспекты модулей), которую агент обновляет по мере работы – контекст подгружается, когда требуется;
• декомпозиция задач так, чтобы контекст каждой подзадачи помещался в “рабочий” диапазон модели, а не в теоретический максимум.

Память и сессии

Агент не помнит прошлые задачи

Агент не помнит прошлые задачи и что было сделано. В результате постоянное дублирование кода, функций, документации. Сюда же относится невозможность вместить весь проект в контекст.

Каждая сессия агента начинается с чистого листа: о том, что было сделано в прошлый раз, он не знает. Без дополнительных механизмов сессии никак не связаны друг с другом, а чтобы не дублировать, агент должен помнить контекст всего проекта.

На уровне кодовой базы это видно по данным GitClear (211 млн строк, 2020–2024): всплеск дублирующихся блоков кода, увеличение количества краткосрочных изменений в коде и продолжающееся снижение повторного использования кода – код, написанный на прошлой неделе, переписывается на этой.

Постоянная память в 2025–2026 стала стандартной фичей. У Claude есть память – обычные файлы, которые агент сам читает и пишет (документация), плюс память для команд. Отдельное ответвление, различные вспомогательные слои Letta (MemGPT), Mem0, Zep, LangMem и тому подобное.

Важный нюанс: память должна быть прозрачной – файлы, которые можно прочитать и отредактировать руками, а не чёрный ящик. Тогда агент ведёт её как рабочую документацию, и проблема дублирования решается на уровне процесса.

Сжатие контекста теряет информацию

Сжатие при достижении лимита контекста теряет важную информацию и требует повторного перечитывания данных и кода. Часто ломает процесс.

Похожая проблема, но в локальном контексте одной сессии. Когда агент приближается к лимиту контекста, начинается сжатие – суммаризация того, что было. Сжатие с потерей информации: важные детали, принятые решения, промежуточные выводы теряются, и агент начинает заново перечитывать данные и код, а то и просто ломает процесс.

«Context Rot» (Chroma) тоже в тему. Деградация с ростом контекста у всех моделей, так что “просто увеличим контекст” не спасает. Anthropic в своём исследовании мульти-агентных систем прямо описывает эту механику. При обрезке длиннее 200K токенов план задачи сохраняется во внешнюю память, чтобы после сжатия агент не терял направление (anthropic.com).

Варианты решения:

• постоянная память: ключевые решения и состояние задачи агент записывает в файлы по ходу работы, а не держит “в голове”;
• плагины, сжимающие шаги рассуждений и вызовы инструментов (tools) – это экономит контекст, но увеличивает расход токенов, так что это плата за продолжительность сессии;
• декомпозиция, разбить длинную задачу на этапы с явными контрольными точками, чтобы каждый этап начинался с чистого, но подготовленного контекста.

Высокое потребление токенов

Высокое потребление токенов.

Это не самостоятельная проблема, а следствие двух предыдущих: без постоянной памяти агент перечитывает одни и те же файлы в каждой сессии, без индексов проекта переоткрывает структуру заново, без контроля сжатия зацикливается на повторном чтении.

Масштаб расхода Anthropic показал в том же исследовании, что расход токенов объясняет около 80% дисперсии результатов, агенты съедают примерно в 4 раза больше токенов, чем чат, мульти-агентные системы – в 15 раз. “Агентный” способ работы объективно дороже на единицу задачи, и без оптимизаций счёт за токены растёт быстрее, чем продуктивность.

Что снижает расход:

• постоянная память между сессиями и индексы проекта – меньше повторных чтений;
• навыки с инструкциями, снижающие “многословность” модели: чёткий формат ответа, запрет на пересказ исходного кода, ограничение на объём вывода;
• кэширование системных инструкций;
• честный выбор модели под роль, так как узким исполнителям не нужна самая дорогая модель.

Архитектура агентов

Одна модель для всех агентов

Использование одной и той же модели для разных агентов ухудшает результаты рассуждений и постановки задач.

Одна модель (или одного провайдера) того же поколения склонна делать одни и те же неверные предположения или выводы. Если второй агент с такой же моделью смотрит на результат первого, он чаще всего с этими предположениями согласится – ошибки коррелируют. Разные модели от разных провайдеров вносят вариативность в рассуждения и добавляют новые подходы решения.

Cognition в статье «Don’t Build Multi-Agents» (июнь 2025) как раз о таком сценарии: параллельные агенты с общим контекстом делают одинаковые ошибки, результат хрупкий. Исследование MAST «Why Do Multi-Agent LLM Systems Fail?» (arXiv 2503.13657, NeurIPS 2025) на 1600+ аннотированных логах (трассировке) из 7 фреймворков показало, что прирост мульти-агентных систем на бенчмарках часто минимален, а координация сама по себе – новый класс отказов.

С другой стороны, разное распределение моделей по ролям работает. В исследовании от Anthropic ведущий-агент (Opus 4) и субагенты (Sonnet 4) показали результат на 90,2% лучше, чем одиночный Opus 4 на исследовательских задачах.

Специализированные агенты и зоны ответственности

Рабочий процесс должен состоять из нескольких специализированных агентов со своими инструкциями и ограничениями.

Здесь важно развести две вещи, которые обычно смешивают в одном слове «мульти-агентность».

Параллельные “писатели” – это проблема. Несколько агентов, одновременно пишущих код в одном пространстве, хрупки: конфликты изменений, одинаковые ошибки, несовместимые решения. Cognition в 2025 году это сформулировал явно – “Don’t Build Multi-Agents”, MAST на трассировке работы агентов показал, что координация – самостоятельный источник отказов.

Разделение зон ответственности – это решение. Оркестратор, исполнитель, ревьюер – каждый со своими инструкциями и ограничениями, с узкой областью. Агент всё-в-одном склонен “упрощать” себе задачу, вводя обходные пути или облегчая её в ущерб корректности и оптимальности, а специализация снимает эту нагрузку.

Подтверждений у второй интерпретации больше. Работа «United Minds or Isolated Agents?» (arXiv 2506.06843) показывает, что у LLM есть потолок производительности на сложных многоаспектных задачах, тяжёлый контекстный инжиниринг превышает эффективный бюджет внимания – и это прямая аналогия с теорией когнитивной перегрузкой. Агент “всё-в-одном” когнитивно перегружается, а роли с узкой зоной ответственности снижают нагрузку и поднимают качество. Anthropic строит свою исследовательскую систему именно на разделении концепций – у каждого субагента свой контекст и своя задача. А в исследовании 2026 года Cognition («Multi-Agents: What’s Actually Working») признаёт, что работает узкий класс задач по формуле “интеллектуальная обработка – параллельно, редактирование – однопоточно”. Например, review-агент с чистым контекстом (без общего контекста задачи) в среднем ловит 2 бага на PR, из них 58% критических – лучший результат именно без разделяемого контекста (cognition.com).

То есть: параллельное написание кода несколькими агентами – проблема. Специализация ролей с разделением зон ответственности – решение, и она снижает когнитивную нагрузку на каждого агента.

Выбор модели по роли

Для разного типа агентов требуется правильный выбор модели. Утверждение, что при правильном harness модель не очень важна – это обман.

Модель очень сильно влияет на поведение агента и результат. В первую очередь это касается агентов-оркестраторов и агентов, составляющих план. Для них нужна максимально умная модель с большим контекстом, которая не теряет фокус при многоэтапных рассуждениях и вызовах агентов. Остальные модели могут быть проще, так как выполняют узкоспециализированные задачи в ограниченном домене и контексте.

Противоположный тезис – “правильный harness важнее модели” – продвигается активно. Один из примеров “AI-Disrupt PDLC” (ЦИПР-2026, ai-pdlc.com): 98/2 – 98% инженерной ценности пайплайна даёт детерминированная обвязка (permission gates, recovery, evals, audit, context management, tool routing), и лишь ~2% – модель. Но это их специфичный документ с продуктовой витриной (внутренняя платформа: Agent Runtime, Agent Marketplace, Context Supply Chain), и разбор на Habr (23.05.2026) оценивает 98/2 как “инженерную риторику, неизмеримую метрику”. То есть факты подогнаны под тезис, который продаёт платформу. Звучит убедительно, проверить нельзя – классическая инфоцыганщина.

Контр-факты в пользу “модель важна” конкретные:

• Anthropic в том же исследовании фиксирует: апгрейд модели даёт больший прирост, чем удвоение расхода токенов;
• mini-SWE-agent (100 строк Python) с сильной моделью дал 65% на SWE-bench Verified (июль 2025) – harness минимальный, а результат топ-уровня;
• на SWE-bench в 2025–2026 разрыв между топовыми и средними моделями остаётся существенным – новые оценки CodeClash (ноябрь 2025) и ProgramBench (май 2026) это подтверждают.

Вывод: правильный harness не компенсирует слабую модель. Для оркестратора и планировщика модель критична, обвязка – для исполнителей. Оба слоя важны, но вес модели выше, чем рисуют продавцы своих платформ. Со своей стороны это тоже очень хорошо увидел при разработке, разница может быть кардинальной между моделями.

Постановка задачи

“Сделай хорошо” не работает

Передача агентам задач в виде “сделай вот тут хорошо” – не работает.

И это, наверное, самый частый способ пострадать от агентской разработки. Промпт для LLM – это приказ на выполнение. Всё, что не указано, модель додумает и подстроит под основной промпт. Результат практически всегда неоптимален, потому что “додуманное” – это усреднённое по обучающим данным, а не то, что нужно проекту.

Поэтому постановка задачи должна быть максимально чёткой:

• проблема – что именно не так и какой результат ожидается;
• зависимости – что уже есть, на что опираться, что нельзя трогать;
• ограничения – стек, версии, архитектурные решения, стилистика;
• критерии приёмки – как проверить, что задача сделана;
• выходные результаты – конкретный артефакт, а не “улучшить”;
• прошлые ревизии – что уже попробовано и почему отклонено.

Чем точнее постановка, тем меньше “додумывания”, а значит, и меньше накопления ошибок дальше по цепочке. Это же, по сути, фундамент SDD подходов, о которых ниже в разделе про фреймворки.

Портирование: референс – пример, а не инструкция

При портировании или миграции необходимо всегда явно указывать, что референсный код или данные нужно использовать как пример функционала, а не инструкцию к действию. Не портировать один в один.

LLM не мыслит абстракциями и не держит в контексте весь проект, поэтому при портировании она пытается повторить оригинал буквально – даже в ущерб архитектуре и качеству кода. Референсный код воспринимается как инструкция, а не как пример функционала. Это же касается совместимости: модель будет пытаться её сохранить даже там, где она не требуется и есть намного лучшие решения и подходы.

На практике это выглядит так: портируешь приложение на незнакомый язык и получаешь не “то же приложение на Rust”, а дословный перевод – с архитектурными огрехами оригинала, ненужной совместимостью и идиомами исходного языка.

Решение – всегда явно указывать в задаче:

• референсный код и данные – пример функционала, а не инструкция к действию;
• не портировать один в один, целевая архитектура и идиомы целевой экосистемы приоритетнее;
• совместимость сохраняется только там, где она явно требуется;
• критерии приёмки – по функционалу, а не по совпадению структуры с оригиналом.

Обвязка

Навыки, тулы, MCP

Для полноценной работы требуется предварительная обкатка и настройка обвязки агентов: навыки, тулы, MCP, инструкции агентов и так далее.

Инструментарий вокруг агентской разработки сильно влияет на финальное качество, и “из коробки” почти ни один агент не готов к конкретному проекту. Навыки (skills), тулы, MCP-серверы, инструкции – всё это нужно обкатать и настроить под предметную область до того, как отдавать реальные задачи.

Сам MCP за это время перестал быть экспериментом Anthropic и стал индустриальным стандартом. В декабре 2025 протокол передан в Agentic AI Foundation – прямое финансирование под эгидой Linux Foundation. К этому моменту SDK скачивали по 97 млн раз в месяц, а публичных MCP-серверов было больше 10 000 (анонс).

При этом зрелость внедрения разная. По данным JetBrains AI Pulse (январь 2026, 11 000 разработчиков) 90% используют AI на работе, но только 22% уже используют AI coding agents, и лишь ~25% регулярно пользуются agentic-тулами (официально). Разрыв между “используют AI” и “используют агентов” – это и есть зрелость внедрения, и в основном она определяется обвязкой.

Практика:

• до реальных задач – пилотная обкатка обвязки на типовых задачах проекта;
• подбор тулов и MCP-серверов под конкретный проект или предметную область, а не “всё подряд”;
• инструкции агентов (AGENTS.md, rules, skills) как часть кодовой базы: ревьюятся, обновляются, живут в репозитории.

VLM для UI/UX

Если работа с UI/UX, то потребуются модели VLM.

Модель должна “видеть” то, что получается, чтобы исправить или доработать. В противном случае агент переключается на обходные пути – анализ DOM, “пиксельные” проверки изображений, чтение CSS – и это заметно усложняет решение задачи и приводит к некачественному результату.

С VLM (vision-language model) цикл “сгенерировал → посмотрел скриншот → поправил” становится прямым: модель видит рендер, сравнивает с ожиданием и вносит точечные правки. Это же работает в ревью: агент, который может посмотреть на результат, ловит дефекты, невидимые в разметке.

Отдельный момент – скриншоты дают единый “источник правды” для итераций. Не нужно держать в промпте описания интерфейса, которые быстро устаревают. Для фронтенд-задач VLM закладывается в обвязку с самого начала.

Фреймворки

SpecKit, OpenSpec, BMAD – точка старта

Использовать SpecKit, OpenSpec, BMAD в чистом виде не обязательно и не всегда эффективно.

Данные фреймворки, как и сам SDD, это скорее рекомендация и точка старта для подстройки процессов по работе с ИИ в качестве ассистентов. Ни один из этих подходов не является серебряной пулей, которая сама по себе даст даже просто хороший результат. Часто это просто переусложнение.

Все три живы и развиваются в 2026 году:

• Spec Kit – тулкит для SDD-разработки, работает с любым AI-агентом;
• OpenSpec – отслеживание изменений для проектов, легче встраивается в существующую кодовую базу;
• BMAD – мульти-агентный метод с ролями и артефактами.

На этом сайте уже есть статья про Spec-Driven Development, где разобран сам подход и его риски.

Практический вывод: проводить пилотные внедрения с подбором нужного фреймворка под размер и тип проекта. Если ни один не подходит – адаптировать или разработать свой. На самом деле это не сложно. По сути это набор шаблонов спецификаций, инструкций для агентов и скриптов, связывающих этапы. Своя обвязка может выходить короче и точнее – она сделана под конкретный процесс, а не под “средний проект”.

Качество и стоимость

Джун/мидл/сеньор + LLM не заменяет команду

Низкое качество сгенерированных решений. Джун/мидл + LLM заменяет команду и даёт хороший результат – не соответствует истине.

Главная проблема в том, что LLM выдаёт не лучшие и не всегда корректные решения, а усреднённый, часто плохой результат. Не имея достаточного опыта для оценки – системного мышления, привычки думать абстракциями на несколько шагов вперёд, – нельзя поймать LLM на “ошибках”. То есть код может работать, выполнять свою функцию, но будет содержать огромный технический долг, за который придётся платить позднее. Финальная стоимость проекта может оказаться не дешевле ручной разработки.

Разрыв восприятия уже измерен. METR в июле 2025 провёл RCT: 16 опытных OSS-разработчиков, 246 задач, зрелые кодовые базы – с AI-тулами они работали на 19% медленнее, при этом сами оценивали свой прирост в +20% (metr.org, arXiv 2507.09089). Ошибки не видны без опыта – и это главная ловушка “Разработчик + LLM”.

Данные опросов в ту же сторону. Stack Overflow Developer Survey 2025 (49 000 респондентов): 84% используют или планируют использовать AI-тулы, но доверия к точности – всего 3,1%, и самые осторожные – опытные разработчики: высокий уровень доверия 2,5%, высокий уровень недоверия 20,7% (survey). DORA 2025 фиксирует, что AI – усилитель, сильные команды получают мультипликативный эффект, слабые – усугубление своих проблем: 45% экономят время на коде, но 42% тратят больше на ревью (dora.dev).

И самое интересное – “возвратный найм” (CNBC, июль 2026). Компании, сократившие людей ради AI, начали откатывать решения. Ford вернул сотни опытных инженеров после провала AI-эксперимента с качеством (~350 нанял, BBC). Commonwealth Bank of Australia откатил сокращение 40+ операторов, когда голосовой бот не справился. IBM не справился с оставшимися 6% HR-запросов, которые не закрыл AI, и в 2–3 раза увеличит найм в 2026. Orgvue: 55% лидеров, сокращавших персонал из-за AI, признают, что решение было ошибочным. Robert Half: 32% нанимающих менеджеров убрали роль из-за AI и потом наняли обратно (cnbc.com).

Для масштаба: на Google Cloud Next 2026 Сундар Пичаи заявил, что 75% нового кода в Google генерируется AI – но с оговоркой “approved by engineers”. Человеческий слой ревью сохраняется, и 75% не значит “команду заменили” (blog.google).

Этот вывод основан не на теории, а на практике разработки и при портировании приложений (таблица ниже) на незнакомых языках и экосистемах. Если бы не долгий прошлый опыт разработки на разных языках с ручным разбором проблем ошибок, то большинство некорректных предложений и решений LLM попросту бы не заметил. И даже сейчас их много осталось в коде: понимание, что это неправильно, приходит только с опытом работы с новым языком разработки. Ошибку выжившего на небольших проектах-однодневках смысла брать в расчёт нет.

Для понимания размера: приложение, написанное по большей части через ИИ (+ чистка человеком), потом портировалось на Rust.

───────────────────────────────────────────────────────────────────────────────
Language            Files       Lines    Blanks  Comments       Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go                    225      61,086     8,201     3,231     49,654     12,415
TypeScript             56       1,801       164        71      1,566         64
Markdown               42      10,239     2,250         0      7,989          0
MDX                    40       4,862     1,145         0      3,717          0
JSON                   20         663         0         0        663          0
CSS                    19       2,807       399       273      2,135          0
YAML                    7         575        53       110        412          0
SQL                     5         163        21        17        125          3
XML                     5         511        51        80        380          0
Go Template             4         120        19         0        101         14
SVG                     3          34         5         0         29          2
Shell                   2         168        25        30        113         12
Dockerfile              1          43        13        12         18          0
License                 1         202        33         0        169          0
Makefile                1         117        24        16         77          3
Plain Text              1          36         0         0         36          0
───────────────────────────────────────────────────────────────────────────────
Total                 432      83,427    12,403     3,840     67,184     12,513
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $2,239,878
Estimated Schedule Effort (organic) 18.69 months
Estimated People Required (organic) 10.65
───────────────────────────────────────────────────────────────────────────────
Processed 5098527 bytes, 5.099 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

Накопительный эффект ошибок

LLM накапливает ошибки, что приводит к эффекту усугубления ошибок (compounding error effect).

Даже маленькая неточность на раннем шаге генерации кода становится “истиной” для следующей итерации. Модель опирается на собственный сгенерированный некорректный код и факт как на базовый паттерн. Итогом становится полная деградация логики в коде или документации при отсутствии ручного контроля.

Математика простая – 10 шагов пайплайна с точностью 95% на каждом дают 0,95^10 ≈ 60% успеха всего пайплайна. Исследование MATC “Multi-Agent Taskforce Collaboration: Self-Correction of Compounding Errors” (arXiv 2508.04306) описывает именно это. Многошаговые LLM-процессы неизбежно накапливают ошибки, и частично это лечится явной самокоррекцией – отдельными агентами проверки на этапах, а не одним “большим прогоном”.

Сама по себе агентская разработка без человека даёт плохой результат.

Стоимость качественной разработки

Качественная разработка с LLM в конечном итоге стоит дороже по ресурсам и времени.

Это кумулятивный эффект всех предыдущих проблем: дублирование, перечитывание, сжатие, усреднённое качество, техдолг. По итогу внедрения LLM в процессы может оказаться, что добиться результата, который давали профессиональные сотрудники, сопоставимо или зачастую дороже, чем с LLM, как ни странно.

Внешние данные это подтверждают. DORA 2025: 45% экономят время на коде, но 42% тратят больше времени на ревью – экономия на генерации переезжает в ревью. Gartner (июнь 2025) прогнозирует, что более 40% агентных AI-проектов будут отменены к концу 2027 – растущие затраты, неясная бизнес-ценность, недостаточный контроль рисков (press release). Пузырь подсдувается – это не мнение, а прогноз аналитиков.

Ничего кроме разумного подхода во внедрении здесь нельзя посоветовать. Некоторым обязательно нужно испытать на себе все проблемы, чтобы понять, как можно корректно встраивать ИИ в процессы.

Навыки

Стагнация и деградация профессиональных навыков

Стагнация и деградация профессиональных навыков.

Тема сейчас спорная, и это нужно смотреть на горизонте в 1–2 года. Очевидно, что уже физически не получится ревьюить такие объёмы нейрослопа. А если это помножить на естественную человеческую лень, то всё часто будет сводиться к операторам консоли с LLM.

METR RCT (июль 2025) – опытные OSS-разработчики (16 чел., 246 задач, зрелые кодовые базы) с AI-тулами работали на 19% медленнее, при этом сами оценивали прирост в +20%. → metr.org, arXiv 2507.09089. Подтверждает: разрыв восприятия, «ошибки не видно без опыта», деградация навыков.

Опорные данные уже есть. METR: опытные разработчики с AI-тулами работали медленнее, но сами это не замечали – разрыв восприятия. Если не писать код руками и не ревьюить его вдумчиво, способность отличить хороший код от плохого просто атрофируется. JetBrains Ecosystem 2025: 11% разработчиков указывают на негативное влияние AI на навыки как на источник беспокойства. DORA: AI – усилитель, и для слабых команд он работает против них.

Заключение

Ещё один момент. Когда-то давно в ИТ и разработку шёл, потому что интересно было, а не за деньгами (8-10к ЗП была первые пару лет). Одним из важных мотиваторов были интересные задачи, которые делались своими руками, а финансовая сторона приоритетом ниже. С агентской разработкой по ощущениям пропадает интерес к задаче и работе, возможно, нет чувства авторства и в приоритеты выходит финансовая составляющая. Плюс нет принадлежности к сгенерированному результату, да и в целом это ощущается как унылый конвейер с бесконечными попытками добиться качественного результата. Получается странный парадокс: агентская разработка должна была удешевить труд, но за дёшево этим заниматься что-то нет желания. Приоритетом в подобной работе становится финансовая и карьерная составляющая.

Если перефразировать нетленную классику – “Счастливой отладки после вайбкодинга, {цензура}” :)