AI-разработка как совместно эволюционирующий стек

Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы?

В пятницу, 7 августа, в 27-м выпуске "Research Insights Made Simple" разберу AI-разработку как совместно эволюционирующую производственную систему. В этот раз без гостя: хочу собрать в одну картину выводы из последних исследований и инженерных разборов — от hardware-software co-design до agent harness, MCP, evals и production traces.

Главная идея выпуска: преимущество всё реже живёт в одном компоненте. Сильная модель становится продуктом только внутри конкретной среды - с контекстом, примитивами действий, identity, policy и доказательствами результата. А сбой превращается в улучшение, только если команда умеет воспроизвести его, изменить нужный слой и заново пройти проверку.

Поговорим о том:

- Почему не каждый сбой требует новой модели и чем быстрый цикл настройки tools и harness отличается от медленного цикла model и hardware;
- Почему API-совместимость и MCP ещё не дают поведенческой совместимости, корректных полномочий и безопасного эффекта;
- Чем telemetry отличается от evals и training data — и почему production traces не улучшают модель автоматически;
- Где провести границу между арендой, адаптацией и созданием своего: что разумно арендовать у провайдера, что адаптировать, а чем компания должна владеть сама;
- Когда собственная обвязка действительно оправдана, а когда она превращается в дорогую попытку повторить общий агентный цикл.

Для меня главный вывод такой: возможности компании не в модели и не количество MCP-серверов, а скорость доказанного изменения. Увидеть реальный сбой, сохранить эпизод, воспроизвести его, поправить один слой, пройти release gate и безопасно вернуть улучшение в production.

Материалы выпуска и полный разбор:
https://polomodov.tech/2026-08-07-ai-development-stack-codesign/

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering