State of AI4SDLC: от AI-ассистентов к агентной разработке

Ведущий представил Александра как давнего друга и нового члена программного комитета: канал с обзорами исследований и «дистиллированной выборкой» он назвал наследием «Книжного куба», а SDLC на уровне всей компании — большой ответственностью без прямых подчинённых, то есть отдельным leadership-вызовом. Сам Александр объяснил, откуда взялась тема: с начала года он перешёл заниматься искусственным интеллектом в разработке, и одной из задач было поставить цели на год — куда компания идёт и почему; доклад стал ответом на тот же вопрос. План на тридцать минут он разбил на пять частей: исследование конца прошлого года, сдвиг software engineering 1.0 в сторону 2.0, изменение управления самой работой, spec-driven development, который он назвал «империя наносит ответный удар», и оценка качества работы автономных агентов.

Исследование собрано из обзора мировой картины, метаанализа крупных работ за три года и собственного опроса по России: публичные зарубежные исследования с какого-то момента перестали показывать, что происходит в России, и часто стали недоступны без специальных средств. Главная цифра — около 90% проникновения AI в разработку к концу прошлого года по опросам DORA, Stack Overflow и JetBrains. Но сценарии чувствовали это по-разному: код генерировался уже часто, а код-ревью и безопасность были распространены далеко не у всех, и в итоге кодинг ускорился, а поставка — не у всех и не всегда. Ограничения Александр проговорил сразу: опросы — это селф-репорт, эффект зависит от процессов и задач компании, а командный результат часто не менялся, потому что разработчик отвечал про своё личное использование инструментов. Тогда же возник управленческий вопрос: как померить, что процесс идёт по плану, — и нужен подход умнее, чем количество сожжённых токенов или строк сгенерированного кода.

Выводы и внешних работ, и внутреннего опроса сошлись: качество улучшается неоднозначно, доверие к AI-инструментам недостаточно высокое, ROI считать сложно, а раздать всем лицензии мало — нужно перестраивать сами процессы разработки. Отсюда и переход к схеме software engineering 1.0, где под каждую роль есть отдельные люди: продакты, аналитики, разработчики, QA- и SRE-инженеры. В 2025 году AI внедряли именно внутри профессий, и почти каждый научился выдавать больше аутпута — требований, кода, тестов на покрытие, — но end-to-end работа не ускорилась: потери сидели на передачах, каждый оптимизировал свою метрику, а не сквозную. Ставка этого года другая: роли остаются, но платформенные инструменты должны помогать закрывать их ответственность. Примеры — агент код-ревью, про которого рассказывали в подкасте этой же конференции; агент для требований; агент вокруг observability-платформы, который отслеживает проблемы и определяет причины инцидентов.

На greenfield-проектах пробовали двинуться к агентной разработке, где роль инженера расширяется: поставить задачу, сформулировать цель, ограничить контекст, «чтобы агент не лопнул», задать границы и критерии выполнения, оркестрировать части большой задачи и проверить результат. Команде нужны контекст репозитория, архитектурные правила, зрелые практики вокруг CI/CD — где они были крутыми, всё затягивается легко, — и договорённости, чтобы параллельные агенты не нагенерили конфликтующих изменений, иначе бутылочное горлышко просто переедет на ревью. Меняется и управление работой: вместо доски, где задачи пишет человек, а контекст размазан по чатам и вики, членами команды становятся агенты, привязанные к этапам workflow, — картина, которую рисуют Jira и особенно Linear, объявивший, по пересказу Александра, классический таск-менеджмент мёртвым. Пример — агент, который выгребает баги: смотрит задачи с типом «баг», проверяет описание, берёт в работу и доводит до пул-реквеста. Сами задачи при этом может завести другой агент по итогам груминга, но держится смешанная команда на единых правилах и гардрейлах: иначе агент сожжёт бюджет на токены и подход превратится в неуправляемый хаос.

Четвёртую часть Александр назвал «империя наносит ответный удар»: он вспомнил V-модель, с которой начинал сам, — требования, архитектура, детальный дизайн, большая имплементация и поднимающаяся вверх половина буквы с верификацией и валидацией. Трассировка от ожиданий бизнеса до результата была, но документы писались для людей, превращались в меморандум о намерениях, код от них отрывался, и к концу проекта они годились разве что как музейные экспонаты. Теперь спецификация — интерфейс между людьми и агентами и исполняемый контекст: что делать, чего не делать, по каким критериям приёмки проверять сделанное. Работает это, только если увязаны все артефакты: что должно измениться, что нельзя сломать, как доказать готовность. Агент, которому сказали «сделай фичу» или «сделай хорошо», скорее всего сделает не то, а имплементация уже не проблема — вопрос в верификации результата.

Единого фреймворка внутри нет, команды экспериментируют: Александр назвал agent-agnostic Spec Kit от GitHub с цепочкой «спека — план — таски — имплементация — чек-листы», более продуктовый подход другого вендора с документами вида design.md и tasks.md и Codex с AGENTS.md, которым пользуется в личных проектах. Но хайп сам по себе не помогает: без проработанных критериев приёмки агент уверенно отчитается, что молодец, а тонны кода придётся разбирать вручную. Отсюда пятая часть — валы: меняя версию агента или модель под ним, надо понимать, стало лучше или нет. Набор он предлагает собирать по образцу бенчмарков: frozen state из репозитория, задачи и окружения, контракт того, что агенту можно, и скрытый судья из регрессионных тестов — на багах это версия, шаги воспроизведения, ожидаемое поведение и тест, который когда-то написал человек, чинивший этот баг. В финале зрители — Максим, Егор Гаврилов, Сергей — накидали вопросов про фреймворки вроде Superpowers, Open Spec, GSD и Taskmaster, и Александр ответил, что централизованно ничего не раскатывают: скорость изменений такая, что никто не знает, какой из них лучше, поэтому он собирает у команд, что у кого получается, и делится дальше.