ПостВышел свежий Gartner Hype Cycle по software engineering за 2026. Формально это отчёт про разработку, но по факту не толь…

Вышел свежий Gartner Hype Cycle по software engineering за 2026. Формально это отчёт про разработку, но по факту не только… Там есть допущение: к 2028 году 60% инженерных инициатив будут опираться на полностью автономное агентное кодирование, и разработка сместится к спецификационно-ориентированным процессам. Дальше обычно начинается спор о том, заменит ли AI разработчиков. Мне этот спор не интересен. Интересно другое. Мы двадцать лет защищали надёжность замедлением. Релизные окна, ручное ревью, «в пятницу не деплоим»… Все эти контроли работают за счёт того, что поток изменений упирается в количество квалифицированных рук — и мы этой узостью пользуемся как естественным предохранителем. Так вот, предохранителя больше нет. Когда генерация кода дешевеет на порядок, любой контроль, живущий за счёт торможения, получает два исхода: его обходят или он становится главным тормозом бизнеса. Третьего не будет. Но самое неприятное в отчёте не это. Gartner в разделе про spec-driven development говорит о том, что нужны guardrails, чтобы не полагаться на предположения агента, заполняющие пробелы в контексте. Вот это и есть новая корневая причина инцидентов, к которой мы не готовы. Агент не оставляет незаданное требование невыполненным. Он его домысливает. Не указали таймаут — будет какой-то таймаут. Не описали поведение при недоступности смежной системы — будет какое-то поведение. Не сказали про идемпотентность платёжной операции — получите какую-то семантику повтора. Причём код пройдёт ревью, тесты будут зелёные, пайплайн отработает. Отказ, который выглядит успехом. Gartner в разделе про dark factories называет это прямо: silent failures плюс дефицит навыка аудировать вывод агента на сбои, которые кажутся корректными. У нас нефункциональные требования живут в головах, в вики, которую последний раз правили в позапрошлом году, и в архитектурном ревью, где сеньор говорит «здесь нужен circuit breaker». Человеку этого хватало — он додумывал из опыта. Агент додумывает из статистики обучающей выборки. Это разные источники. Отсюда практический вывод: спецификация в регулируемой среде должна нести не столько функциональные требования, а больше нефункциональные. SLO и бюджет ошибок. Таймауты, ретраи, лимиты — в цифрах, а не «должно быть устойчиво». Требования к наблюдаемости. Всё, что мы раньше передавали устно и через код-ревью, теперь нужно сделать машиночитаемым — просто потому что читатель сменился. Ещё один риск, которого в отчёте нет, но он очевиден: мы всегда считали отказы независимыми. Агент размножает одно и то же отклонение по десяткам сервисов за вечер. Резервирование от неё не спасает. @Simple_Reliability