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

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

Именно поэтому Thoughtworks Technology Radar Vol. 34 важен не как очередная карта трендов, а как признак сдвига в инженерной оптике. Этот выпуск не сводится к тезису «ИИ всё меняет». Он показывает, что software engineering уже смещается от разговора о возможностях модели к проектированию среды, в которой люди, агенты, инструменты и контуры контроля совместно изменяют систему.

У Radar по-прежнему привычная структура: квадранты, кольца зрелости, разделение на techniques, tools, platforms, languages and frameworks. Но в 34 выпуске важнее не сама схема, а четыре темы, вокруг которых собран весь выпуск. Thoughtworks прямо выделяет усложнение оценки технологий в agentic world, возврат к базовым инженерным принципам, риски permission-hungry agents и необходимость жёстче ограничивать coding agents.

Почему этот выпуск важен

У Technology Radar всегда был свой сильная сторона - он не пытается угадать будущее, а даёт язык для оценки технологических изменений. В 34-м выпуске этот подход становится особенно важным, потому что ломаться начинает не только технологический ландшафт, но и сами критерии его оценки.

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

Это ломает привычный цикл Radar. Если ждать зрелости, рекомендации быстро устаревают. Если реагировать слишком рано, в картину попадает временный шум, а не устойчивый сигнал.

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

Четыре сигнала

1. Оценивать технологии стало сложнее

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

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

В такой среде всё меньше смысла спорить о новизне и всё больше — о свойствах эксплуатации. Реально важны сопровождаемость, модель безопасности, устойчивость, наличие сообщества и подтверждение того, что практика работает за пределами нескольких показательных сценариев. Это и есть одна из причин, почему в Radar усиливается зона Caution.

2. Старые инженерные принципы стали ценнее

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

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

3. Permission-hungry agents — уже задача архитектуры безопасности

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

При этом защитные механизмы не успевают за амбициями. Prompt injection остаётся нерешённой проблемой, поведение модели остаётся непоследовательным, а успешное выполнение задачи один раз не гарантирует повторяемости ни во второй, ни в сотый. Thoughtworks отдельно подчёркивает, что агенты могут находить неожиданные пути эксфильтрации данных, менять то, к чему не должны иметь доступа, и размывать привычные approve/deny chokepoints даже без злого умысла.

Отсюда следует довольно практичный вывод. Безопасная агентная система, по мысли Thoughtworks, должна строиться не вокруг одного «умного» монолита, а вокруг контура из более ограниченных агентов, с принципом наименьших привилегий, эшелонированная защита, сильный мониторинг и жёсткий контроль, архитектура нулевого доверия как базовая норма. Не случайно архитектура нулевого доверия (zero trust architecture) в этом выпуске стоит в Adopt.

4. Coding agents нужно включать в управляющий контур

Четвёртая тема, пожалуй, самая полезная для повседневной инженерной практики. Thoughtworks пишет, что по мере роста качества coding agents команды всё чаще пытаются вывести человека из рабочего контура, и именно поэтому начинают инвестировать в управляющие контуры.

Логика здесь простая. До генерации кода нужны feedforward controls, которые повышают вероятность корректного первого шага. После генерации нужны feedback controls, которые позволяют агенту исправиться до human review.

Это хорошо перекликается со свежей статьёй [Биргитты Бёкелер о harness engineering](Harness engineering for coding agent users](https://martinfowler.com/articles/harness-engineering.html), где такой контур описан как сочетание опережающего направления и обратной связи: направляющие механизмы повышают вероятность корректного первого действия, а датчики помогают агенту самостоятельно исправиться ещё до проверки человеком.

В Radar эта логика проявляется очень последовательно: Agent Skills позволяют модульно оформлять инструкции и соглашения и подгружать их по мере необходимости; OpenSpec и другие подходы, опирающиеся на спецификацию, структурируют рабочий процесс ещё до генерации кода; feedback sensors for coding agents встраивают компиляторы, линтеры, проверки типов, тесты и другие детерминированные барьеры качества прямо в цикл работы агента; а подходы к снижению архитектурного дрейфа показывают, что поверх формальных правил можно добавлять и смысловые проверки.

Именно здесь виден важный сдвиг 2026 года. Мы обсуждаем уже не только способность модели писать код, а условия, при которых агенту вообще можно доверить это действие.

Что брать в работу

Из 34 выпуска уже можно уверенно брать в практику несколько направлений.

Во-первых, context engineering. Thoughtworks переводит его из разряда optimisation tactic в разряд foundational architectural concern для современных ИИ-систем. Контекст здесь понимается не как «текст рядом с запросом», а как спроектированная информационная среда агента. Вместо одного большого промпта предлагается progressive context disclosure: сначала лёгкий индекс доступного знания, затем подгрузка только того, что реально нужно по ходу работы.

Во-вторых, curated shared instructions for software teams. Thoughtworks называет анти-паттерном ситуацию, в которой каждый разработчик заново пишет свои промпты с нуля. Инструкции должны становиться общим инженерным активом команды и встраиваться в шаблоны сервисов, репозитории и reference applications через файлы вроде AGENTS.md, CLAUDE.md или project-specific rules. Это важный организационный сдвиг: полезные настройки работы с ИИ перестают жить в личных заметках и входят в базовую поставку проекта.

В-третьих, structured output from LLMs. Thoughtworks уже считает это sensible default для сценариев, где ответы модели обрабатываются программно. Ценность здесь не в любви к JSON как таковому, а в снижении неоднозначности и в возможности строить поверх ответа машинно-проверяемые контракты. Когда к этому добавляются deterministic quality gates, получается рабочий контур, в котором агенту можно быстро и формально показать, где он вышел за границы допустимого.

В-четвёртых, zero trust architecture - это уже не факультативная практика из мира security, а базовый инженерный ответ на автономные системы с широкими полномочиями. Чем выше автономия агента, тем опаснее доверие по умолчанию. Поэтому identity-based control, least privilege, continuous verification и наблюдаемость должны закладываться как обязательные свойства системы, а не как поздняя доработка.

Что пробовать осторожно

Категории Trial и Assess в этом выпуске особенно интересны. Они звучат не как «ещё рано», а как «уже полезно, но только при правильно спроектированном инженерном контуре».

Сюда попадают Agent Skills, feedback sensors for coding agents, progressive context disclosure, sandboxed execution for coding agents и semantic layer. В Assess Thoughtworks относит architecture drift reduction with LLMs, context graph, measuring collaboration quality with coding agents, MITRE ATLAS, role-based contextual isolation in RAG, skills as executable onboarding documentation, team of coding agents и LLM evaluation using semantic entropy.

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

Что держать в caution

Зона Caution в Vol. 34 едва ли не важнее зоны Adopt. Именно здесь Thoughtworks возвращает разговор об ИИ с уровня рыночного возбуждения на уровень инженерной трезвости.

В Caution попали agent instruction bloat, AI-accelerated shadow IT, codebase cognitive debt, coding agent swarms, coding throughput as a measure of productivity, ignoring durability in agent workflows и MCP by default. Уже сам список говорит о многом. Речь не о том, что агентные системы не нужны, а о том, что без дисциплины они очень быстро увеличивают операционную и архитектурную нагрузку быстрее, чем команда успевает её осмыслить.

Особенно показателен пункт про MCP by default. Мысль здесь зрелая и полезная: протоколы и формальные интерфейсы имеют смысл там, где действительно нужны жёсткие контракты, управляемые границы доступа и воспроизводимая интеграция. Но превращать их в универсальный ответ на любую связку систем — значит без необходимости увеличивать абстракционный налог.

Каким становится ремесло

Теперь software engineering выглядит чуть менее как ремесло написания кода и чуть больше как ремесло проектирования среды изменений. Это сдвиг, который уже можно описать вполне практично.

Во-первых, инженер проектирует не только код, но и среду вокруг кода: контекст, правила доступа, quality gates, контуры обратной связи и режимы эскалации.

Во-вторых, появляются новые инженерные артефакты: context architecture, shared instructions, agent access model, eval catalog, harness templates и audit trail по использованию инструментов. Эти артефакты прямо следуют из набора практик и техник, которые Thoughtworks выделяет в Adopt, Trial и Assess.

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

В-четвёртых, ускорение больше нельзя оценивать только объёмом произведённого кода. Thoughtworks прямо предупреждает против coding throughput as a measure of productivity и одновременно выносит DORA metrics в Adopt. Это означает довольно жёсткий управленческий вывод: если ИИ действительно улучшает разработку, это должно проявляться в lead time, deployment frequency, MTTR, change failure rate и rework rate, а не в красивой статистике generated LOC.

Что нужно делать в ближайшие дни

Если переводить отчет в практику, список приоритетов выглядит так:

1. Ввести общие инструкции (shared instructions) как командный актив.

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

   • task contract (контракт задачи),

   • allowed context (разрешённый контекст),

   • allowed actions (разрешённые действия),

   • quality gates (барьеры качества),

   • stop conditions (условия остановки),

   • audit trail (журнал аудита).

3. Перейти от prompt-first (мышления, начинающегося с промпта) к context-first (мышлению, начинающемуся с контекста).

4. Вынести agent access model (модель доступа агента) в отдельный инженерный артефакт.

5. Добавить feedback sensors (датчики обратной связи) в change lifecycle (жизненный цикл изменения).

6. Перестать мерить успех ИИ количеством generated LOC (сгенерированных строк кода).

7. Для безопасности использовать zero trust (архитектуру нулевого доверия) и ATLAS-style threat lens (модель угроз в логике ATLAS), а не только optimistic sandbox (излишне оптимистичную изоляцию выполнения).

Вывод

Thoughtworks Technology Radar 34 важен не потому, что перечисляет модные пункты, а потому, что фиксирует взросление инженерного разговора вокруг ИИ.

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

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

Искусственный интеллект действительно ускорил разработку. Но главный тезис Vol. 34 в другом: теперь нужно ускорять не только выпуск изменений, но и зрелость инженерной практики.