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

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

В феврале 2026 года мероприятие The future of software development retreat, организованное Martin Fowler и Thoughtworks в том же месте, собрало небольшую группу практиков, исследователей и руководителей из технологических компаний, чтобы задаться вопросом: как выглядит эффективная разработка в эпоху AI. Ретрит не привел к единому видению будущего, но вместо этого дал нечто более полезное: карту линий разлома, где текущие практики разрушаются и формируются новые.

Ниже представлена таблица и подробный отчет о выводах и инсайтах из состоявшихся разговоров:

1. Куда уходит инженерная дисциплина?

Самый важный вопрос ретрита. Он всплывал практически на каждой сессии.

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

Группа выявила пять направлений, куда дисциплина уже перемещается:

1. Вверх по процессу - в ревью спецификаций;
2. В наборы тестов как артефакты первого класса;
3. В системы типов и ограничения;
4. В карту рисков;
5. В непрерывное понимание системы.

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

Это имеет практические последствия. Организации, экспериментирующие с разработкой на основе спецификаций (Spec-driven development), сообщают, что сами спецификации требуют новых форматов. Традиционные пользовательские истории (User stories) слишком размыты. Некоторые команды переходят на структурированные подходы, такие как EARS (Easy Approach to Requirements Syntax), конечные автоматы (State machines) и таблицы решений (Decision tables). Это не новые техники, но они переоткрываются заново, поскольку дают агентам AI достаточную точность для создания корректных реализаций.

В наборы тестов как артефакты первого класса
Один из наиболее цитируемых инсайтов ретрита состоит в том, что разработка через тестирование (Test-driven development, TDD) дает значительно лучшие результаты при работе с AI агентами. Механизм конкретен: TDD предотвращает сценарий сбоя, при котором агенты пишут тесты, подтверждающие некорректное поведение. Когда тесты существуют до кода, агенты не могут схитрить, написав тест, который просто подтверждает любую некорректную реализацию, которую они произвели.

Это переосмысливает TDD как форму проектирования промптов (Prompt engineering). Тесты становятся детерминированной валидацией для недетерминированной генерации. Ряд экспертов описали полное смещение усилий по ревью в сторону набора тестов, рассматривая сгенерированный код как расходный материал. Если тесты корректны и код их проходит, код приемлем вне зависимости от того, как он выглядит.

Инсайт эксперта:

В системы типов и ограничения
Ретрит выявил значительный интерес к использованию возможностей языков программирования для ограничения AI-генерируемого кода. Вместо ревью кода после генерации эксперты исследуют способы сделать невозможным само существование некорректного кода. Это опирается на идеи из формальных методов (Formal methods) и строгих систем типов (Strong type systems), применяемых не как академические упражнения, а как практические ограждения для вывода агентов.

Ключевым инсайтом стало разделение спецификаций и ограничений. Спецификации описывают, что должно измениться, а ограничения определяют ограниченные контексты (Bounded contexts), в рамках которых изменения допустимы, включая то, что не должно затрагиваться. Эти ограничения уменьшают радиус поражения (Blast radius) и позволяют агентам безопасно работать на границах доменов. Когда ограничение необходимо нарушить, это сигнализирует о новой системной границе и инициирует рефакторинг.

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

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

В непрерывное понимание системы
Если код меняется быстрее, чем люди успевают его ревьюить, традиционная модель формирования ментальных моделей через ревью кода перестает работать. На ретрите обсуждались альтернативы: еженедельные архитектурные ретроспективы, ансамблевое программирование (Ensemble programming), при котором несколько инженеров одновременно работают над одним и тем же кодом, и инструменты понимания кода на базе AI, генерирующие обзоры системы по запросу.

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

Инсайт эксперта:

2. Средний цикл (The middle loop): новая категория работы

Самая перспективная концепция ретрита. Индустрия еще не дала ей название.

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

• Внутренний цикл (Inner loop). Это персональный цикл разработчика: написание, тестирование и отладка кода;
• Внешний цикл (Outer loop). Это более широкий цикл поставки: CI/CD, развертывание и эксплуатация.

Ретрит выявил третий: средний цикл инженерной работы (Supervisory Engineering), располагающийся между ними. Этот средний цикл включает направление, оценку и исправление вывода агентов AI. Он требует иного набора навыков, чем написание кода. Он предполагает способность декомпозировать задачи на рабочие пакеты в пределах контекста агента, калибровать доверие к выводу агентов, распознавать, когда агенты производят правдоподобно выглядящие, но некорректные результаты, и поддерживать архитектурную целостность в условиях множества параллельных потоков работы, генерируемой агентами.

Эксперты, достигающие высоких результатов в этой новой работе, как правило, обладают рядом общих характеристик:

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

Это навыки, которыми опытные инженеры нередко обладают, однако они редко целенаправленно развиваются или признаются в карьерных лестницах.

Ретрит провел параллель с историей компьютерной графики. В 1992 году инженеры вручную писали алгоритмы рендеринга полигонов. Два года спустя эта работа была перенесена в аппаратное обеспечение, и работа стала заключаться в анимации и освещении. Сегодня это кастомная физика и игровые миры. Каждый раз, когда уровень абстракции поднимался, инженеры, настаивавшие на том, что их наняли для рендеринга полигонов, оставались позади. Та же динамика разворачивается сейчас с производством кода.

Сторона продуктового менеджмента в этом уравнении в равной мере остается неустоявшейся. Если разработчики теперь больше думают о том, что строить и зачем, они выполняют работу, которая раньше принадлежала продуктовым менеджерам. Одна крупная технологическая компания активно исследует, нуждается ли роль PM в новом названии. Другая обучает всех продуктовых менеджеров работать в Markdown внутри инструментов разработчика. Конвергенция реальна, даже если никто не сходится во мнении относительно того, к чему она приведет.

3. Топологии агентов и корпоративная архитектура

Закон Конвея не устарел. Он стал сложнее.

Ретрит ввел концепцию "Топологий агентов" (Agent Topologies) как расширение фреймворка Team Topologies. Предпосылка: если организации проектируют системы, отражающие их коммуникационные структуры, что происходит, когда агенты становятся полноправными участниками этих структур?

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

1. Несоответствие скоростей. Агенты сжигают бэклоги настолько быстро, что сталкиваются с медленными организационными зависимостями. Один из участников описал этот опыт: вы даете команде инструменты AI, они разбирают бэклог за несколько дней, а затем упираются в стену межкомандных зависимостей, архитектурных ревью и принятия решений в человеческом темпе. Результатом является не более быстрая поставка. Это та же скорость с большим разочарованием, потому что узкое место сместилось с инженерной мощности на все остальное;
2. Дрейф агентов (Agent drift). Агенты, обучающиеся на своем контексте, будут расходиться со временем. Агент по базам данных, работающий над e-commerce бэкендом, накапливает иные паттерны и предпочтения, чем тот, что работает над ERP системой, даже если они начали с идентичных конфигураций. Это зеркалит человеческую проблему командно-специфичных норм, но в ускоренном темпе. На ретрите обсуждался вопрос: следует ли управлять этим дрейфом (по аналогии с усилиями по стандартизации в человеческих командах) или принять его (по аналогии с предоставлением командам возможности локальной оптимизации);
3. Усталость от решений как новое узкое место. Если агенты могут производить работу быстрее, чем руководители успевают ее ревьюить и одобрять, ограничение смещается с производственной мощности на мощность принятия решений. Мидл-менеджеры, ранее служившие точками координации, теперь становятся узкими местами одобрения. Ряд экспертов сообщили, что это уже происходит в их организациях: агенты генерируют описания вакансий, исправления кода и реализации функций быстрее, чем кто-либо успевает дать согласие.

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

Инсайт эксперта:

4. Самовосстанавливающиеся и самосовершенствующиеся системы 

Амбиция реальна. Предпосылки далеки от выполнения.

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

• Самовосстановление (Self-healing). Возврат системы в известное исправное состояние;
• Самосовершенствование (Self-improving). Активное развитие нефункциональных качеств системы, таких как производительность и надежность.

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

• Четкий реестр каждого изменения, позволяющий агентам понять, что произошло;
• Операционная система для агентов с контролем идентичности и границами разрешений;
• Надежные универсальные возможности митигации (Rollback, Feature flags), работающие без изменений кода;
• Фитнес-функции (Fitness functions), определяющие, что означает "здоровое состояние" в терминах, доступных для оценки агентами.

Ретрит был прямолинеен: изменения кода должны быть последним средством при устранении инцидентов. Путь к самовосстановлению пролегает через лучший Rollback, лучшие Feature flags и лучшую Observability прежде, чем через переписывание агентами производственного кода.

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

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

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

5. Человеческая сторона: роли, навыки и опыт

AI не заменяет людей. Он перестраивает то, что люди делают, и то, как они к этому относятся.

Парадокс продуктивности и опыта
Developer experience традиционно определяется в трех измерениях:

• состояние потока (flow state);
• циклы обратной связи (feedback loops);
• когнитивная нагрузка (cognitive load).

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

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

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

Противоречие состоит в том, чего от Staff инженеров просят, и чем они должны заниматься. Многие тратят непропорционально много времени на координацию людей, а не на техническое руководство. Ретрит высказался за намеренный сдвиг: Staff инженеры должны стать устранителями трения (Friction killers), выявляя и убирая препятствия, замедляющие как работу людей, так и работу агентов. Их глубокое знание того, где зарыты скелеты, уникально позиционирует их для этой роли, однако многие испытали выученную беспомощность (Learned helplessness) после многих лет, когда им говорили, что бюджета на рекомендуемые ими улучшения нет.

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

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

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

Очевидно одно: AI обнажает существующие дисфункции в отношениях между PM и разработчиком, а не создает новые. Фрагментация знаний, культурные разрывы между дисциплинами и нечеткие границы ролей существовали до AI. AI просто делает их игнорирование более дорогостоящим. Ретрит подчеркнул роль инструментов как "граничных объектов" (Boundary objects), позволяющих разным ролям работать по-своему, сохраняя при этом общую видимость.

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

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

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

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

Семантические слои и графы знаний
Технологии, которым не удавалось получить широкое распространение на протяжении десятилетий, внезапно стали актуальными. Семантические слои, графы знаний и доменные онтологии (Domain ontologies) переоткрываются как слой заземления (Grounding layer) для агентов AI, которым необходимо понимать бизнес-домены. В ретрите участвовали эксперты, создающие эти системы в масштабе и сообщившие, что вся доменная онтология крупного телекоммуникационного оператора может быть охвачена примерно 286 концепциями. Это число сделало работу ощутимо достижимой, а не непосильно амбициозной.

Практическая ценность состоит в модернизации унаследованных систем (Legacy modernization). Выстраивая концептуальную модель данных на основе существующих систем и валидируя ее с экспертами в предметной области, организации могут создать слой спецификаций, необходимый агентам для уверенной модернизации. Одна из команд описала использование LLM моделей для автоматической идентификации команд, событий, агрегатов и политик из кода, фактически автогенерируя артефакты Event Storming. Эксперты затем валидируют и корректируют, сжимая недели воркшопов по исследованию в дни.

Агентная операционная система
Ретрит исследовал, что должна включать операционная система для агентов:

• Управление идентичностью и разрешениями агентов.
• Управление памятью и контекстным окном.
• Реестр работ, фиксирующий будущую, текущую и прошлую работу с атрибутами, такими как необходимые навыки, критерии приемки, SLO и ограничения по стоимости.
• Пути управления через граф возможностей агентов и требований соответствия.

Ключевым инсайтом стало то, что агент - это больше, чем его персона, цели или текущий контекст; он включает историю выполненной им работы. Хотя модели взаимозаменяемы внутри агента (одну LLM модель можно заменить другой), смена модели фундаментально меняет поведение агента и должна отслеживаться. Реестр работ выделился как базовый примитив этой новой операционной системы, по аналогии с финансовым блокчейном: поддающийся поиску, пригодный для аудита и позволяющий агентам обнаруживать работу и участвовать в ее распределении.

7. Безопасность, управление и будущее Agile

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

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

Выделились три приоритета:

• безопасность по умолчанию (Security by design) как неоспоримый базовый уровень;
• межотраслевые коалиции для создания совместимых стандартов безопасности агентов;
• защитные механизмы на базе AI, способные соответствовать скорости и сложности атак, осуществляемых с помощью AI.

Agile эволюционирует, а не умирает
Ретрит решительно отверг нарратив "Agile is dead". Происходящее более неоднозначно. Одни команды сжимают ритм спринтов до одной недели, используя AI для автоматизации церемоний, таких как демо, отчетность и сводки статусов. Другие переоткрывают практики XP (парное программирование, ансамблевая разработка, непрерывная интеграция), поскольку эти практики создают плотные циклы обратной связи и общее понимание, которых требует разработка с помощью агентов.

Реальная угроза для Agile - это управление. Команды, принявшие AI инструменты и работающие быстрее, все равно сталкиваются с теми же процессами согласования, проверками соответствия и организационными зависимостями. Без реформирования управления наряду с практиками разработки более быстрые команды просто раньше упираются в те же стены. Ретрит подчеркнул необходимость привлечения функций внутреннего аудита и управления на раннем этапе при переосмыслении командных практик, а не отношения к ним как к препятствиям, которые нужно обходить позже.

Стабильность программного обеспечения также снижается по мере роста объема поставки (Batch size). Легкость создания больших наборов изменений с помощью AI инструментов подталкивает некоторые команды обратно к паттернам, напоминающим Waterfall, когда крупные нечастые релизы заменяют небольшие частые. Это прямая инверсия десятилетия исследований DORA, показывающих, что меньшие размеры батчей коррелируют с более высокой стабильностью. Ретрит обозначил это как активную регрессию, требующую внимания индустрии.

8. Рои агентов: за пределами последовательного мышления

Ретрит посвятил целенаправленное время роению агентов (Agent Swarming) и выявил инсайты, ставящие под сомнение общепринятые представления о том, как должна быть организована работа с помощью AI.

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

Для корпоративных сценариев использования ретрит выявил важный паттерн: идеальная точность отдельных агентов имеет меньшее значение, чем коллективная сходимость к цели. Рой индивидуально несовершенных агентов может производить ценные результаты, если архитектура системы направляет сходимость. Это принцип проектирования, заимствованный из распределенных систем и биологического роевого интеллекта (Swarm Intelligence), применяемый к оркестрации AI агентов.

Ретрит также отметил, что большинство корпоративных оркестраций агентов не будет выглядеть как роение вовсе. Более распространенный паттерн - "дежурные работники на циклах" (Patrol workers on loops): агенты, выполняющие четко определенные ETL преобразования, проверки качества данных и мониторы бизнес-процессов в непрерывных циклах. Иными словами, неприметная работа по обеспечению надежности и чистоты данных, постоянно выполняемая в фоновом режиме. Организации с надежными, хорошо спроектированными API значительно лучше позиционированы как для роения, так и для развертывания агентов в патрульном стиле, чем те, у которых их нет.

9. Открытые вопросы

Ретрит поставил больше вопросов, чем дал ответов. Вот те, которые не давали покоя участникам:

1. О работе и идентичности. Как помочь инженерам, любящим писать код, найти смысл и удовлетворение в надзорной инженерной работе? Какие пути профессионального развития ведут к среднему циклу (Middle loop)? Если роль продуктового менеджера и роль разработчика сближаются, как называется результирующая роль и кто ею владеет?
2. Об организационном дизайне. Если агенты делают узкие места мидл-менеджмента более заметными, предполагает ли организационный ответ меньшее количество менеджеров, менеджеров с иными навыками или принципиально иную модель координации? Как переспроектировать корпоративную архитектуру, когда агенты могут перемещаться через границы команд, а структуры управления - нет?
3. О доверии и верификации. Что должно быть верным, чтобы организации полностью перестали ревьюить код, сгенерированный AI? Существует ли мир, в котором наборы тестов и ограничения обеспечивают достаточную верификацию без человеческой проверки? Как выстраивать доверие к системам, которые фундаментально недетерминированы, где повторный запуск одних и тех же входных данных дает разные результаты?
4. О знаниях и понимании. Если код меняется быстрее, чем люди успевают его осмыслить, нужна ли нам новая модель поддержания институциональных знаний? Могут ли графы знаний и семантические слои по-настоящему заменить человеческую интуицию, приобретаемую годами работы в кодовой базе? Каков правильный уровень инвестиций в системы "подсознания агента" (Agent subconscious), которые большинство организаций пока не создает?
5. О скорости и стабильности. Находимся ли мы сейчас в регрессии, при которой прирост продуктивности, обеспечиваемый AI, нивелируется потерями стабильности из-за больших обьемов поставки? Придется ли разработке замедлиться, потому что объем решений превышает человеческую способность их оценивать? Как измерить реальную стоимость когнитивного долга (Cognitive debt) по мере его накопления?

Что дальше

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

Идеи, готовые к более широкому обсуждению в индустрии, включают:

• средний цикл инженерной работы (Supervisory engineering middle loop);
• классификацию по уровням риска как новую базовую инженерную дисциплину;
• TDD как наиболее сильную форму проектирования промптов;
• переосмысление Developer Experience через призму опыта агента для обоснования инвестиций.

Детальные исследования каждого из них последуют.

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

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