AI-инструменты могут ускорять разработку, но вместе со скоростью команды теряют главное: понимание, почему система устроена именно так. В статье про контекстное хранилище авторы InfoQ напоминают о неприятной цифре: в одном из ранних исследований Microsoft Research разработчики с GitHub Copilot справлялись с задачей на 55,8% быстрее, но уже более свежие данные показывают, что в больших реальных кодовых базах эффект может оказаться обратным. Для русскоязычных команд это сигнал простой: проблема уже не в генерации кода, а в том, как не утонуть в последствиях этой скорости.
Как пишет InfoQ, текст подготовили участники программы InfoQ Certified Architect Program: Stella Berhe, Stephan Bragner, Vikram Maran и Anand Jayaraman. Их тезис звучит жестко, но знакомо любому техлиду: AI отлично закрывает первые 80% задачи, когда нужно быстро собрать каркас, написать проходящий код и показать демо. Но последние 20% — интеграция со старой логикой, граничные сценарии, странные тестовые стенды, старые компромиссы по производительности и безопасности — никуда не исчезают. Наоборот, именно там живет архитектура, и именно там ускорение внезапно превращается в долг, который команда замечает слишком поздно.
Авторы подкрепляют это не только ощущениями. Они напоминают про исследование Microsoft Research 2023 года, где использование GitHub Copilot дало ускорение на 55,8% в контролируемой задаче. Но через два года некоммерческая организация METR провела рандомизированное исследование уже на опытных разработчиках, работавших в собственных крупных репозиториях. Ожидания были оптимистичными: экономисты прогнозировали прирост производительности на 39%, эксперты по машинному обучению — на 38%. По факту разработчики с AI-инструментами потратили на задачу на 19% больше времени. И это не самая неприятная часть: после эксперимента те же участники оценили, что AI якобы сделал их на 20% быстрее. Разрыв между ощущением и результатом составил 39 процентных пунктов. Для менеджмента и CTO это особенно токсичная ситуация: команда уверена, что летит, а система уже начинает терять устойчивость.
Дальше InfoQ поднимает разговор на уровень инцидентов и метрик. В качестве примера на уровне команды приводятся мартовские сбои витрины Amazon в 2026 году: причиной стали изменения, подготовленные с помощью AI и смерженные без должной проверки. После этого компании пришлось ужесточать правила и вводить обязательное одобрение со стороны senior-инженера для AI-assisted кода. На уровне руководства картина похожая: в отчете Google DORA за 2025 год внедрение AI продолжало коррелировать с ростом нестабильности поставки софта, даже если throughput рос. Иначе говоря, коммиты идут быстрее, а тестирование, контроль версий и контуры обратной связи не успевают за этим темпом. Пока все работает, это выглядит как успех. Когда начинается инцидент или уходит человек, державший в голове причинно-следственные связи, выясняется, что организация уже не может ответить на базовый вопрос: почему этот кусок системы вообще устроен именно так.
На этом фоне авторы предлагают не новую магию, а довольно приземленный инженерный механизм — контекстное хранилище. Речь не о памяти LLM и не о еще одном корпоративном вики-разделе, который никто не обновляет. Под этим термином они понимают версионируемую, привязанную к репозиторию запись проектного замысла, проверяемого поведения и архитектурного соответствия. Туда должны входить артефакты, на которые могут опираться и люди, и AI-агенты: спецификация фичи рядом с кодом, тесты, которые сначала падают, а уже потом разрешают принять сгенерированный результат, и автоматические fitness functions, блокирующие CI при нарушении ключевых свойств системы. В статье предлагается хотя бы минимальный набор для каждой важной функции: один зафиксированный спецификацией сценарий, один заведомо красный тест до генерации кода и три CI-блокирующие проверки для самых рискованных архитектурных характеристик.
По сути, InfoQ переупаковывает давно известные практики — specification-driven development, TDD и эволюционную архитектуру — под новый режим работы, где код появляется быстрее, чем успевает сформироваться его ментальная модель. В этом есть важная мысль для рынка: AI не отменяет архитектурную дисциплину, а повышает цену ее отсутствия. Когда написание кода становится дешевым, дорогим ресурсом становится понимание домена, границ ответственности, контрактов между компонентами и причин, по которым команда когда-то выбрала именно такие ограничения. Не случайно в статье вспоминают выступление Phillip Mortimer на QCon London 2026: сложность программных систем уже растет быстрее, чем человеческая способность их целиком понимать. AI эту проблему не создал, но сделал ее заметной даже там, где раньше она годами пряталась под ковром.
Для разработчиков вывод вполне прикладной. Если в репозитории нет живых спецификаций, намеренно написанных негативных тестов и автоматических архитектурных ограничителей, AI-инструмент будет масштабировать не качество, а хаос. Для бизнеса вывод еще неприятнее: метрики скорости без метрик понимания становятся ловушкой. Если организация смотрит только на количество доставленных изменений, она почти гарантированно пропустит момент, когда архитектурная память команды уже вынесена за скобки. И тогда каждый следующий релиз будет выглядеть дешевым только до первого серьезного инцидента, найма нового владельца сервиса или попытки переписать критичный контур без людей, которые помнят его историю.
Главный вопрос теперь не в том, ускоряет ли AI разработку вообще. Он уже ускоряет отдельные участки работы и будет делать это дальше. Вопрос в другом: успеют ли команды превратить контекстное хранилище и архитектурные проверки в обязательную часть CI/CD до того, как генерация кода окончательно обгонит способность компании объяснять собственную систему. Для индустрии это выглядит как следующий зрелый этап AI-разработки: выигрывать будут не те, кто быстрее всех включил ассистента, а те, кто первым научился хранить и проверять смысл вместе с кодом.