Oбзор отчета The Future of Software Engineering

Часть 1: Сквозные темы
Ключевые выводы дают картину основных проблем, поднятых на ретрите. Эта картина отражает лишь часть: обсуждения были насыщенными и разнообразными, поэтому имеет смысл подробнее рассмотреть отдельные темы, чтобы понять, как они возникли и какие последствия участники группы видят для индустрии разработки программного обеспечения в целом.

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

1. Формируется новый словарь тестирования. На конференции были представлены и продемонстрированы вживую такие понятия, как тесты ограничений (Constraint tests, единичные тесты входных и выходных данных, ограничивающие то, что агенту разрешено генерировать), сценарные тесты (Scenario tests) и логи хороших и плохих сценариев (Good/Bad logs), полученные из реальных инцидентов. Специально разработанные системы приемочного тестирования (Approval-testing rigs), созданные за несколько часов, демонстрируют более высокую эффективность по сравнению с типовыми фреймворками BDD. Это частично объясняется тем, что такие системы сохраняют простоту, доступной для проверки человеком, и затрудняют манипуляции со стороны агента;
2. Для миграционных проектов с высокими рисками формируется многоуровневый стек верификации доверия. Он выглядит следующим образом: характеризационные тесты (Characterization tests) → символьное исполнение (Symbolic execution), основанное на строгих математических принципах → обратное тестирование на Production (Production back tests) по реальным потокам данных. Это новая техническая методология;
3. Смешанная детерминированная и недетерминированная оценка представляет собой решение проблемы ненадежности подхода LLM-as-judge. Обсуждался опыт одной из команд, объединившей линтеры (Linters) и сопоставление шаблонов (Pattern-matching) с советом судей (Council of judges) из трех моделей, что позволило повысить долю успешного прохождения проверки с первого раза примерно с 60% до 80%;
4. Многолетняя уверенность в эффективности ручного ревью кода подвергается открытому сомнению. Несколько практиков отметили, что ни один из присутствующих не смог привести данные о том, сколько дефектов ручное ревью клда фактически выявляет — это иллюзия статус-кво (Status quo illusion), которую необходимо подвергнуть проверке фактическими данными.

Harness Engineering формируется как отдельная дисциплина с четко определяемым владением
По мере того как модели становятся коммодити, несколько сессий независимо друг от друга пришли к общему выводу: инфраструктура вокруг модели (управление контекстом (Context management), детерминированные защитные механизмы (Deterministic guardrails), навыки (Skills), самоулучшающиеся циклы обратной связи (Self-improving feedback loops)) представляет собой фактор, определяющий разницу между качественной Agentic Engineering и некачественной:

1. Существуют конкретные измеримые результаты. Одна организация сообщила, что применение эффективной инфраструктуры (Harness) сократило использование токенов как минимум в 4 раза и существенно повысило детерминированность результата. Эксперимент по рефакторингу показал, что использование обычного линтера улучшило устранение Code smells до уровня менее 50%, тогда как перевод вывода линтера в конкретные детерминированные пошаговые инструкции по рефакторингу (Habit hooks) обеспечил показатель устранения на уровне около 90%. Также сообщалось, что модель меньшего размера с качественной инфраструктурой превосходит по результатам более крупную модель со слабой инфраструктурой;
2. Наиболее результативные команды не создают Harness вручную. Они позволяют агентам совершать ошибки, применяют навык обучения, который анализирует каждую сессию и предлагает изменения в инфраструктуре, а роль человека сводится к периодической очистке и упрощению, а не к непосредственному созданию;
3. Управление общими харнесом и навыками остается нерешенной организационной проблемой. Навыки и общие артефакты контекста деградируют по тому же принципу, что и код без определенного владельца (Unowned code), если не установлено четкое владение (Ownership). Централизация в рамках выделенной Harness команды несет риск воспроизведения устаревшего антипаттерна отдельной команды эксплуатации (Ops team).

Дизайн команд становится компактнее, узкое место смещается в сторону принятия решений
Обсуждения топологий команд (Team Topologies) повторялись как минимум в пяти сессиях и сходились к общей модели: небольшие Nucleus teams (2-3 инженера) осуществляют контроль над крупными флотами агентов (Fleets of agents), при этом сохраняется социальный порог сплоченности на уровне примерно 10 человек, необходимый для организационной устойчивости:

1. Проблема двух часов (Two clocks problem) представляет собой наиболее острый новый диагностический критерий. Команды отслеживают одновременно темп создания кода и темп ожидания принятия решений. Пропускная способность разработчиков (Developer throughput) значительно выросла, при этом общее время цикла (Cycle time) осталось на прежнем уровне: ограничивающим фактором стали процесс принятия решений и четкость спецификаций;
2. В нескольких сессиях повторялся один и тот же кейс, иллюстрирующий здоровую и нездоровую модель работы команды. В первом случае продуктовый менеджер и дизайнер превратились в Superpowers, самостоятельно создающих функциональность с помощью агентов, а роль инженера свелась к устранению последствий (Cleanup). Во втором случае команда совместно работала над спецификациями, тестами и замыслом дизайна, в то время как флот агентов сходился к готовым решениям. Первая модель показала высокую продуктивность, при этом руководство оценило ее как формирующуюся катастрофу, поскольку она разрушала культуру парной работы и организационную сплоченность;
3. Платформенным командам требуется повышение уровня доверия к их компетенциям. Традиционные платформенные команды, ориентированные на инфраструктуру, зачастую не обладают достаточным уровнем компетенций в разрабтке для управления инструментарием класса Harness или Dark factory. В качестве решения неоднократно предлагалось, чтобы платформенные команды использовали те же Agentic инструменты, которые они рекомендуют использовать продуктовым командам, и переходили к более определенной модели работы, предоставляя Paved roads;
4. Domain-driven design переосмысливается как наиболее релевантная из существующих дисциплин для согласования границ модулей и команд. Значимость этой дисциплины определяется прежде всего тем, что она остается единственной устоявшейся дисциплиной, обеспечивающей непрерывное согласование и определение границ в масштабах крупной организации, а не тем, что она формирует единый комплексный дизайн.

Кризис наставничества и передачи навыков
Независимо друг от друга, как минимум в шести различных сессиях, старшие специалисты поднимали одно и то же опасение: если младшие специалисты (Juniors) лишены возможности самостоятельно работать с реальным кодом, реальными инцидентами и реальными компромиссами в проектировании (Trade-offs), поскольку эту работу выполняют агенты (либо старшие инженеры, работающие в паре исключительно с агентами), индустрия утратит важнейший механизм формирования следующего поколения инженеров с развитым суждением и вкусом:

1. Были предложены конкретные меры противодействия, часть из которых уже проходит пилотное тестирование. Кворум по дизайну (Design quorum) или моб-программирования (Mob-programming), при котором старший специалист ведет обсуждение дизайна, а младшие специалисты непосредственно формулируют промпты. Отдельные учебные упражнения без использования AI с публичной отчетностью и новые учебные программы, включающие оркестрацию и контроль над агентами для специалистов на раннем этапе карьеры;
2. Специалисты с опытом от 7 до 10 лет были определены как группа, испытывающая наиболее острое давление. Инвестировав десятилетие в освоение навыков, которые модели теперь зачастую превосходят, эти специалисты сталкиваются с реальным эмоциональным давлением и кризисом профессиональной идентичности;
3. Смежное исследование подтверждает данную обеспокоенность. У студентов университетов, писавших эссе с интенсивным использованием LLM, было зафиксировано измеримое снижение способности к критическому мышлению в течение трех месяцев наблюдения, в том числе по сравнению с их собственным исходным уровнем без использования LLM.

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

1. В разных сессиях повторялись общие принципы дисциплины миграции: "Не добавляй ничего, не меняй ничего, удаляй все, что возможно" в процессе переноса системы; изменение одного аспекта за раз; намеренное сохранение известных ошибок как решения, согласованного с клиентом, вместо того чтобы позволять AI исправлять элементы, от которых может зависеть нижестоящая система;
2. Стали технически достижимыми ранее недоступные методы. Среди примеров: полноценный кастомный компилятор из TypeScript в .NET CLR, созданный с помощью AI за четыре дня; COBOL компилятор, прошедший тестовый набор NIST, созданный за три дня при затратах на токены около 5000 долларов; реверс-инжиниринг недокументированного зашифрованного формата бинарного файла мейнфрейма 1994 года с помощью модели, выявляющей закономерности на уровне байтов. Задачи, ранее экономически нецелесообразные для решения в принципе, включая создание специализированных компиляторов, транслитераторов и средств формальной верификации, теперь находятся в пределах возможностей рядовой команды;
3. Формулировка, находящая отклик у советов директоров. Прямая увязка инвестиций в AI с бюджетом на модернизацию и поддержку систем (составляющим 30-50% совокупных ИТ расходов крупных предприятий) переводит абстрактный технологический запрос в конкретное, понятное для совета директоров решение о распределении капитала. В одном из реальных примеров расплывчатый запрос на сумму свыше 100 млн долларов был преобразован в конкретное предложение объемом 8 млн долларов, охватывающее 20% систем, с привязкой к измеримой ценности.

Разрыв в восприятии между руководством и инженерами представляет собой более серьезный риск, чем любые ограничения моделей
Повторяющейся, практически повсеместной жалобой стало то, что советы директоров и CEO зачастую полагают, что "продуктовый менеджер загружает PRD в волшебную машину и на выходе получается идеально работающее программное обеспечение". Это представление отчасти объясняется тем, что собственный практический опыт руководителей в области AI ограничен инструментами для написания отчетов и суммаризации текста, которые демонстрируют высокую эффективность, но представляют собой слабый ориентир для оценки разработки программного обеспечения:

1. Устранение этого разрыва не связано напрямую с улучшением моделей. Оно достигается за счет ярких, конкретных примеров, привязанных к влиянию на финансовые показатели организации. Также требуется строгая работа с данными: проверка заявлений поставщиков о 10x росте продуктивности на основе реальных сравнительных показателей (Benchmarks), а также структурированные упражнения, позволяющие руководителям самостоятельно попробовать создать что-либо и столкнуться с реальными ограничениями;
2. Конкретный актуальный тревожный сигнал. В одной из организаций количество внутренних инцидентов безопасности выросло примерно в 20 раз за шесть месяцев, при этом бюджеты на токены исчерпывают годовые лимиты за три месяца вместо двенадцати. Подобный бюджетный шок в настоящее время привлекает внимание совета директоров быстрее, чем заявления о росте продуктивности;
3. Реалистичные ожидания в отношении роста продуктивности следует активно корректировать в сторону снижения относительно заявлений поставщиков. По оценке одного из практиков, учитывающей полный цикл разработки программного обеспечения (SDLC), а не только генерацию кода, реалистичный рост продуктивности в краткосрочной перспективе составляет примерно 2-3x, а не 10x, как заявляется в маркетинговых материалах. По его прогнозу, разрыв между ожиданиями и этой реальностью может привести к схлопыванию пузыря в течение 12-18 месяцев.

Governance не успевает за развитием Citizen development и автономией агентов
Сессии, посвященные Citizen development и безопасности, объединил ряд последовательных и конкретных реальных инцидентов:

• приложение, созданное бухгалтером с помощью Copilot, случайно раскрыло данные клиентов в открытый доступ через туннель Cloudflare, предложенный AI;
• маркетинговая команда предоставила AI ассистенту широкий доступ к G-Suite через каскадные права доступа OAuth, которые компания не смогла даже полностью перечислить при попытке отключить этот доступ;
• агент, столкнувшись с нехваткой места на диске, удалил резервные копии для освобождения пространства и при этом выразил удовлетворение результатом.

1. Повторяющийся и практически применимый паттерн управления. Модель уровней риска по принципу green/amber/red (личное использование/использование в команде с обязательным обучением/использование в масштабах всей компании с привлечением инженеров), в сочетании с приоритетом обнаружения над предотвращением, то есть непрерывным сканированием логов диалогов агентов на предмет опасных паттернов вместо опоры на первоначальное обучение, которое не успевает за еженедельными релизами моделей, может рассматриваться как ключевая тактика управления;
2. Новый вектор атаки на цепочку поставок. Злоумышленники способны прогнозировать названия несуществующих библиотек, которые с высокой вероятностью будут галлюцинированы LLM, и публиковать под этими именами реальные вредоносные пакеты. Изолированное выполнение кода в песочнице (Sandboxing) не решает эту проблему полностью, поскольку вредоносная зависимость все равно способна попасть в production;
3. Существуют и распространяются практические частичные меры снижения риска:

• выдерживание паузы примерно в 14 дней перед использованием новых версий библиотек (большинство скомпрометированных пакетов выявляется именно в этот период);
• использование проверенных внутренних реестров;
• изоляция на уровне микро-виртуальных машин (Micro-VM sandboxing);
• отношение к коду, сгенерированному агентом, как к недоверенному даже внутри собственной сети компании, с применением принципов Zero-trust не только на периметре, но и внутри инфраструктуры.

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

1. Эффективность затрат варьируется в диапазоне до 1400 раз в зависимости не только от выбора модели, но и от архитектуры доступа к корпоративным данным. Неэффективный обмен данными по протоколу MCP между моделью и корпоративными системами представляет собой недооцененный фактор затрат. Это порождает реальное противоречие между оптимизацией затрат, требующей приближения данных к модели, и требованиями безопасности, ограничивающими степень раскрытия данных;
2. Полноценный хостинг в крупном масштабе представляет собой узкоспециализированную и дефицитную компетенцию. Performance Engineering с точки зрения пропускной способности на доллар фиксированной инфраструктуры GPU, вплоть до физической топологии серверных стоек, в значительной степени сосредотачивается в руках гиперскейлеров и специализированных облачных провайдеров. Организациям следует учитывать этот разрыв в компетенциях и планировать деятельность с его учетом, не полагая самостоятельный хостинг простой в реализации задачей;
3. Для задач, связанных с разработкой кода, был предложен реализуемый промежуточный вариант: использование менее масштабного специализированного оборудования для инференса или специализированных провайдеров хостинга моделей, что снимает необходимость решения задачи самостоятельного хостинга.

Open Source сталкивается с переломным моментом
На мероприятии развернулась острая дискуссия: усугубляет ли AI кризис устойчивости Open Source, обостряя такие проблемы, как выгорание мейнтейнеров и неоплачиваемый труд, извлекаемый компаниями с миллиардной капитализацией, или же он порождает принципиально новую динамику, включая мегапроекты, создаваемые одним человеком и достигающие огромного масштаба за считаные месяцы, а также потоки AI pull requests, которые мейнтейнеры физически не успевают оценивать.

1. Был предложен конструктивный паттерн работы с изменениями сгенерированными AI : реверс-инжиниринг намерения, заложенного в Pull request, с формулировкой его на понятном языке; оценка этого намерения; последующая реализация этой идеи с нуля собственным AI инструментом мейнтейнера перед слиянием изменений. Такой подход позволяет отметить вклад автора изменений, избежать слепого доверия к предложенному коду и обеспечить низкие затраты времени мейнтейнера;
2. Был обозначен гипотетический, но правдоподобный сдвиг: распространение практики Open Source может сместиться с уровня кода на уровень спецификаций и идей, поскольку реализация становится дешевой для повторной генерации под каждого конкретного потребителя. При этом существует реальный риск: в случае полного вытеснения агентами модели Shared library dependency, инженеры, не имеющие доступа к AI и соответствующей вычислительной инфраструктуре, утратят преимущества.

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

1. Существуют исторические аналогии, подтверждающие, что подобная позиция не является ностальгией. Импрессионизм возник именно потому, что фотокамера обеспечила возможность точного воспроизведения реальности, сместив ценность человеческого труда в сторону интерпретации. Барабанщики с появлением драм-машин не утратили востребованность: их мастерство, напротив, усложнилось и развилось. Сильнейшим игроком в шахматы в мире начиная с 1997 года можно обоснованно считать не отдельно взятый движок, а команду в формате "человек плюс движок";
2. Данная позиция не носит характер отрицания технологий. Она сосуществует с общим энтузиазмом участников конференции в отношении Agentic инструментов. Наиболее четкая формулировка заключалась в необходимости сохранения цикла, в котором суждение вносится осознанно и заметно человеком, даже по мере того как цикл создания продукта становится в высокой степени автоматизированным.

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

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

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

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

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

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

Планирование с учетом сжатого цикла хайпа
Несколько участников, обладающих непосредственным опытом работы с рынком и оценкой стоимости компаний, ожидают, что текущий инвестиционный цикл в области AI сожмется быстрее, чем предыдущие технологические циклы. В частности, был обозначен реалистичный горизонт в 12-18 месяцев, по истечении которого ожидания рынка скорректируются относительно фактически поставляемой ценности, составляющей примерно 2-3x, а не 10x. Руководству следует планировать горизонты инвестиций и коммуникационную стратегию соответствующим образом: формировать устойчивые компетенции (Harness engineering, Verification discipline, Governance) сохраняющие ценность независимо от дальнейшей динамики цикла хайпа, вместо построения стратегии на предположении о сохранении наиболее оптимистичных из сегодняшних заявлений о росте продуктивности.

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

Для достижения успеха инженерным организациям необходимо перейти от восприятия продуктивности как метрики объема к восприятию ее как дисциплины доверия и управления. Дальнейший путь развития требует рассматривать Harness engineering в качестве ключевой компетенции и проактивно противодействовать кризису наставничества: необходимо обеспечить следующему поколению инженеров возможность развивать суждение и вкус, которые модели и агенты AI воспроизвести не способны.

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

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