Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers (Рубрика #AI)

Прочитал интересный и короткий whitepaper про изменения в разработке софта, готовясь к выступлению "AI в SDLC: от ассистентов к агентам". Если кратко, то это статья далекого 2024 года (а для AI прошлогодняя статья - это реально далеко), в которой авторы A. E. Hassan, G.A. Oliva, D. Lin, B. Chen, Z. M. Jiang предлагают уйти от task‑driven copilot‑инструментов к goal‑driven AI‑напарнику, который понимает цели разработки, помогает с архитектурой, кодом и проверкой результата.

Если присмотреться, то ключевые моменты такие
- Goal‑driven AI pair programmer, где ИИ не автодополнение, а партнёр по достижению цели (фичи, баг-фикса, миграции)
- Инженерный процесс EDD (evaluation‑driven delivery), который аналогичен TDD (test-driven development), но фокус на постоянной проверке прогресса к цели на основе evals
- В основе мультиагентная схема из четырех агентов:
-- Агент целей - помогает выяснить цели инженера, общаясь с ним и собирая информацию (работает как аналитик)
-- Агент архитектуры - умеет дизайнить под выясненные требования, знает архитектурные паттерны и может использовать ATAM (architecture tradeoff analysis method) или его аналоги
-- Агент кода - рабочая лошадка, что умеет писать хороший код (и не только добавлять, но и рефакторить и удалять мертвый код)
-- Goal delivery агент - агент, что отвечает за интеграцию работы всех остальных агентов для доведения проекта до успешного завершения. Он отслеживает выполнение конечных требований: превращение требований в тесты, актуальность тестов при изменении требований, и финальное прохождение всех тестов. Этот агент, помимо прочего, накопливает историю выполненных целей и прогресса, что затем может использоваться для наставничества: по мере работы он отмечает, какие навыки приобретает человек, где делает ошибки (связано с задачей обучения разработчика, см. Challenge 4). (Проще говоря, агент контролирует, чтобы всё задуманное действительно реализовано и проверено тестами, и фиксирует уроки для будущего).

Для успешной работы такой системы есть следующие вызовы
-Выравнивание целей человека и ИИ (минимум уточняющих вопросов, максимум понимания контекста) - тут мы видим пресловутый вопрос alignment
- Общение на естественном языке вместо “промпт‑инжиниринга” (лучшие промпты машины пишут сами себе)
- Доступные и умные code‑LLM (качество понимания проекта при умеренных ресурсах)
- Роль ИИ‑наставника: адаптивное обучение разработчика “в паре” (AI не только исполнитель, но и ментор для инженера)

В своем исследовании авторы опираются на следующие факты
- Накопленный опыт использования GitHub Copilot и аналогов в индустрии, включая выявленные проблемы взаимодействия человека с AI
- Предыдущие попытки автоматизировать разработку с помощью мультиагентных систем (ChatDev, MetaGPT, Devin и др.)
- Проверенные временем методологии разработки (TDD, парное программирование)
- Фундаментальные теории из образования (эффект наставничества по Блуму) и психологии (Theory of Mind) для обоснования социально-обучающего аспекта ИИ

Статья была опубликована как препринт на arXiv в апреле 2024 года и сразу привлекла внимание в сообществе. Google Scholar индексирует эту работу; уже в 2024–2025 годах появились ссылки на нее в ряде новых исследований. Стоит отметить, что сами авторы продолжили развивать эту тему: в октябре 2024 они выпустили расширенный препринт “Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap”, фактически развивающий идеи этой статьи. В нем они ввели терминологию “Software Engineering 3.0” и более подробно описали план исследований на ближайшие годы.

Если вам нравится эта тема и интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.

#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign

AI agents in 2025: Expectations vs. reality (Рубрика #AI)

Когда изучал информацию про успехи AI Agents наткнулся на статью полугодовой давности от IBM. В марте 2025 года IBM собрали четверых экспертов, чтобы обсудить с ними насколько реальна революция AI агентов. Среди экспертов были
- Maryam Ashoori, PhD: Director of Product Management, IBM® watsonx.ai™ 
- Marina Danilevsky: Senior Research Scientist, Language Technologies 
- Vyoma Gajjar: AI Technical Solutions Architect 
- Chris Hay: Distinguished Engineer 

Их позиции в этой статье выглядели примерно так
1. Ашоори: Сегодняшние «агенты» - это LLM с базовым планированием и function calling. Настоящий агент должен автономно рассуждать и планировать.
2. Данилевски (самая скептичная): «Я до сих пор не понимаю, чем это отличается от обычной оркестрации. Вы просто переименовали оркестрацию в агенты, потому что это модное слово». Данилевски опирается на опыт программирования - оркестрация существует давно. Ашоори разделяет текущие возможности и теоретический потенциал.
3. Хэй (самый оптимистичный): Технологический фундамент уже готов:
-- Лучшие, быстрые, компактные модели
-- Chain-of-thought training
-- Расширенные контекстные окна
-- Function calling
На чем основано: Хэй анализирует техническое развитие моделей за 12-18 месяцев и видит качественный скачок в возможностях.
4. Гаджар: «Мы видим ранние проблески, но для сложных решений нужны прорывы в контекстном мышлении и edge cases».

Среди экспертов разгорелись споры по следующим темам
1. Оркестрация vs единый агент
Хэй: Будет маятниковое движение - сначала multi-agent системы с оркестратором, потом переход к «богоподобным» единым агентам, затем снова к коллаборации.
- Ашоори: Это архитектурное решение, зависит от use case. Не всегда нужен мета-оркестратор.
2. Enterprise readiness
- Хэй: «Большинство организаций не готовы к агентам. Интересная работа будет в экспозиции API ваших enterprise-систем». На чем основано: Понимание текущего состояния enterprise-архитектур и требований интеграции.
3. Проблемы безопасности
- Ашоори: «Что, если агент подключится к датасету и удалит кучу чувствительных записей?»
- Данилевски: «Технология не думает. Она не может быть ответственной. Масштаб риска выше - технология может сделать больше за меньшее время незаметно».
- Гаджар предлагает в качестве решений: строгое тестирование в sandbox, механизмы rollback, audit logs.
4. Human-in-the-loop vs замещение
- Данилевски: Агенты будут аугментировать людей - «человек должен постоянно присутствовать и принимать финальные решения».
- Хэй: «Есть реальный риск, что при неправильной реализации люди будут дополнять AI, а не наоборот».

На чем основаны прогнозы экспертов
- Технический анализ: Хэй смотрит на прогресс в модельных capabilities
- Практический опыт: Данилевски основывается на опыте с текущими системами
- Enterprise research: Ашоори опирается на исследования поведения разработчиков
- Архитектурное понимание: Гаджар анализирует требования к production-системам

Выводы для инженеров
- Текущие «агенты» - это upgraded LLM с function calling. До настоящей автономии еще далеко, но базовые кейсы уже работают.
- Ценность будет у тех, кто организует свои данные для агентных workflow. Проблема не в моделях, а в enterprise-readiness.
- Transparency, traceability, rollback mechanisms - это не опция, а must-have. Один неконтролируемый агент может удалить критические данные.
- «Не становитесь молотком в поисках гвоздей» - сначала определите ROI, потом внедряйте агенты.

Главное предсказание авторов в том, что 2025 действительно станет годом экспериментов с агентами, но революцию стоит ожидать позже. Готовьте почву сейчас, но держите ожидания реалистичными. Пока кажется, что он сбывается:)

#AI #Software #Architecture #Agents #Leadership #ML #SystemDesign

[2/2] How tech companies measure the impact of AI on software development (Рубрика #AI)

Продолжая пост про измерение влияние AI на разработку хочется поделиться примером из Dropbox, где ~90% инженеров регулярно пользуются AI-помощниками (по индустрии ~50%). Там измеряют активных пользователей, CSAT, экономию времени и расходы на ИИ, а затем накладывают эти данные на core-метрики: change fail percentage (CFR), throughput и др. (заметим, что CFR и throughput - это контр-балансирующие метрики). В итоге AI-пользователи доставляют на ~20% больше кода в неделю, при этом качество не падает (сбоев даже меньше). Это признак того, что массовое внедрение ИИ реально повышает эффективность, а не просто активность.

Компании также сравнивают показатели у тех, кто пользуется ИИ, и тех, кто нет, и наблюдают изменения со временем. Такой анализ возможен только при наличии базовых данных до внедрения ИИ, но он ценен: так можно проверять гипотезы о влиянии ИИ на реальных цифрах. Важно не упирать только на скорость, забивая на качество - важно, чтобы рост частоты релизов/PR не сопровождался увеличением багов или откатов. Для выявления скрытого негативного эффекта (ухудшение maintainability, недовольство команды) проводите регулярные опросы Developer Experience.

Из размышлений авторов вытекают практические рекомендации:
1.Сформулируйте ключевые метрики продуктивности (качество и скорость) и зафиксируйте базовый уровень до внедрения ИИ. Без этого непонятно, улучшает ли ИИ то, что нужно.
2. Отслеживайте использование ИИ, но не путайте активность с результатом. Важно не количество сгенерированного кода, а влияние на качество, скорость и комфорт работы
3. Балансируйте скорость и надёжность. Ускорение работы не должно приводить к росту брака - следите сразу за метриками скорости и качества
4. Учитывайте опыт команды. Наряду с логами и другими системными метриками регулярно собирайте обратную связь разработчиков (опросы DevEx, CSAT) - так вы не пропустите проблемы, незаметные в одних только цифрах.
5. Не карайте метриками. Донесите, что показатели ИИ нужны для улучшения процессов, а не для оценки персонала. Иначе подорвёте доверие и получите искажённые данные.
6. Культивируйте эксперименты. Пробуйте разные инструменты на небольших проектах, сравнивайте, где эффект максимален. Поощряйте обмен знаниями – обсуждайте удачные и провальные кейсы, делитесь находками и предупреждайте об ограничениях инструментов
7. Держите в фокусе ROI и риски. Отслеживайте, где ИИ даёт наибольший эффект и оправдывает вложения. Ограничьте применение ИИ в критичных зонах (данные пользователей, безопасность) до появления уверенности и нужных контролей

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops