Автор материала, инженер с многолетним опытом работы с десятком языков программирования, включая Clojure, и глубоким интересом к поддерживаемому коду, делится наблюдениями за последние полтора года ежедневной работы с агентами. Она подчеркивает, что ни одна строчка статьи не была написана языковой моделью: агенты использовались только для поиска информации, проверки ошибок и генерации текстовых графиков, а рифмы подбирались через генераторы. Основной посыл обращения к разработчикам заключается в том, что неважно, как читатель относится к агентной разработке, — важно задуматься о новых подходах и пересмотреть привычные практики. Свой опыт автор описывает через личную историю: в 2017 году она устроилась в Яндекс и впервые в жизни столкнулась с легаси, испытав столько боли, что стремление писать понятный код отпечаталось в её психике. С тех пор она изучала редкие языки вроде Clojure, читала SICP и разбирала кодовые базы в open-source — всё ради того, чтобы понять, как минимизировать долгосрочное страдание от поддержки систем. Этот бэкграунд объясняет, почему тема поддерживаемости остаётся для неё центральной и почему она рассматривает агентную разработку не как модный инструмент, а как вызов привычным инженерным ценностям.

Ключевая идея строится на различии между легкостью и простотой, которое автор заимствует у Рича Хикки. Легко — это субъективно, то, что рядом и привычно, как русский язык для носителя. Просто и сложно — объективные категории, связанные со связыванием независимых аспектов системы. Вайбкодинг, по мнению автора, делает генерацию кода легкой, но порождает сложные системы. Агенты радикально удешевляют написание кода, однако ответственность за поддержку и надежность остается на разработчике. Чем сложнее код, тем труднее его понять, а значит, тем меньше оснований считать систему надежной. Автор специально оговаривает, что сложность — это объективное свойство, в отличие от трудности, но определить её в коде непросто. Code smells вроде нарушения DRY не всегда означают рост сложности, а иногда дублирование, наоборот, упрощает систему. Для понимания сложности нужен опыт, чтение кода и книг, доклады, дискуссии, рефакторинги и, наконец, боль при работе с последствиями — коротких путей здесь нет.

Техническая сторона вопроса упирается в необходимость различать случайную и внутреннюю сложность. Автор напоминает, что архитектура нужна для сокращения времени выхода на рынок и соблюдения соглашений об уровне обслуживания. Оба эти критерия напрямую зависят от того, насколько сложную систему приходится поддерживать. При этом сложность в коде трудно определить формально: code smells вроде нарушения DRY не всегда означают рост сложности, а иногда дублирование, наоборот, упрощает систему. Для понимания сложности нужен опыт, чтение кода, доклады, дискуссии и рефакторинги, а не короткие пути. В статье автор отдельно останавливается на вопросах автономии и контроля: понимает ли LLM сложность, как найти баланс между свободой агента и ответственностью разработчика. Она предлагает смотреть на проблему сверху — от целей разработчика и ценностей, а не снизу, от конкретных правил и промптов. Именно поэтому в структуре материала появляются разделы про цели, про легкость, порождающую сложность, и про то, зачем вообще избегать сложности.

Контекст статьи вписывается в более широкую дискуссию о роли ИИ в разработке. Автор ссылается на свои предыдущие публикации о качестве кода, архитектуре и выгорании, подчеркивая, что тема поддерживаемости систем остается центральной. В отличие от многих материалов, предлагающих конкретные подходы к работе с агентами, здесь акцент сделан на ценностях и смыслах. Это перекликается с общим трендом на рынке, где ИИ-бум перерос в борьбу за вычислительные мощности, а компании вроде Microsoft выпускают специализированные модели для выбора вариантов без разговорного интерфейса. Автор упоминает и собственные более ранние тексты — про заговор разработчиков против корпораций, про архитектуру и принципы, про выгоревшего сеньора и двух джунов, про распараллеливание тестов, про Clojure Flutter, про декларативный коллапсирующий тулбар и про Delegate Adapter. Все они так или иначе касаются качества кода и поддерживаемости, и новая статья продолжает эту линию, но уже в контексте агентной разработки.

Для российского рынка разработки тема особенно актуальна, поскольку многие команды уже активно экспериментируют с агентами, но сталкиваются с проблемой накопления легаси. Автор описывает собственную травму от работы с легаси в Яндексе в 2017 году, которая сформировала её стремление писать понятный код. Этот опыт перекликается с сообществом, где боль от поддержки запутанных систем знакома многим. Реакция отрасли пока неоднородна: одни видят в агентах панацею, другие указывают на риски роста сложности и снижения контроля. В российских реалиях к этому добавляется фактор доступности инструментов и моделей, а также давление сроков и требований к SLA, из-за которого соблазн ускорить генерацию кода особенно велик. Автор не даёт готовых рецептов, но предупреждает: без понимания терминов легкости, трудности, простоты и сложности любые практические рекомендации не будут иметь смысла. Именно поэтому она предлагает сначала разобраться в ценностях и смыслах, а уже потом переходить к инструментам — и этот призыв звучит особенно уместно для команд, которые уже накопили первый слой сгенерированного кода и начинают ощущать его последствия.

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

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