Архитектура — последняя территория человека

За последние два года я постепенно перестал спорить с очевидным. AI пишет код. Не в смысле демонстрационных роликов и не в смысле «однажды сможет», а буквально в смысле моего рабочего дня в мае 2026 года. Агент держит контекст репозитория, видит соседние модули, понимает принятые в проекте соглашения и довольно уверенно генерирует функции, эндпоинты, хуки, тесты, миграции. Тактический слой разработки фактически закрыт. То, что три года назад я делал руками и считал основной частью профессии, теперь чаще всего выполняется быстрее и аккуратнее, чем сделал бы я сам в конце тяжёлого дня.

Но чем дольше я работаю в этом режиме, тем отчётливее вижу странную асимметрию. Внутри заданной структуры модель сильна. Как только структуру нужно выбрать, она начинает плыть. Она с удовольствием реализует слой, но не умеет ответить на вопрос, нужен ли этот слой вообще. Она блестяще заполняет форму, но не она решает, какой должна быть форма. И это не временный дефект, который закроется следующим релизом. Это структурное свойство того, как устроены эти инструменты и откуда они берут уверенность.

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

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

Почему модель сильна внутри структуры и слаба при её выборе

Стоит разобраться, откуда берётся эта асимметрия, иначе разговор скатится в мистику про «душу инженера». Никакой души тут нет, есть устройство задачи. Когда структура уже задана — есть слой сервисов, понятный контракт API, принятый стиль работы с состоянием, — задача написать новый кусок кода становится локальной. У неё есть ближайший контекст, есть образцы рядом, есть понятная форма результата. Это ровно та ситуация, в которой языковая модель работает лучше всего: продолжить устойчивый паттерн по множеству похожих примеров.

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

Из-за этого AI при выборе структуры ведёт себя предсказуемо: он усредняет. Он предлагает то, что чаще всего встречалось в обучении для похоже звучащей задачи. А «чаще всего встречалось» — это, как правило, переусложнённый каркас крупного проекта, потому что именно такие проекты обильно представлены в публичном коде, статьях и обсуждениях. Спросите агента, как организовать обработку заказа, и он бодро предложит слой доменных сущностей, репозитории, мапперы, стратегии расчёта, отдельные use case и пару интерфейсов «на вырост». Технически всё корректно. Но это не решение вашей задачи. Это статистически популярный ответ на абстрактную задачу.

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

Архитектура — это компромисс, а компромисс требует контекста

Любое настоящее архитектурное решение — это выбор того, чем мы готовы пожертвовать. Гибкость против простоты. Скорость разработки против скорости выполнения. Связность ради удобства против изоляции ради независимости слоёв. Дублирование кода против дублирования смысла. Не существует архитектуры, которая выигрывает по всем осям сразу, и именно поэтому это работа стратегическая, а не тактическая. Хорошее решение здесь — не самое красивое и не самое общее, а то, которое лучше всего подходит под конкретный набор ограничений данного проекта.

Чтобы выбрать компромисс осмысленно, нужно знать, что для этого продукта дорого, а что дёшево. Для банковского ядра дорога ошибка в расчётах, и там избыточная строгость окупается. Для маркетингового лендинга, который перепишут через два месяца под новую кампанию, дорога медленная разработка, и любая лишняя абстракция — чистый убыток. Один и тот же код будет правильным в первом случае и грубой ошибкой во втором. Модель не различает эти ситуации, потому что различие лежит не в коде, а в бизнес-контексте, которого у неё нет.

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

Модель умеет предсказать следующий токен, но не следующий квартал вашей дорожной карты

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

AI работает в настоящем времени. Он видит задачу здесь и сейчас и оптимизирует ответ под неё. У него нет модели будущего этого конкретного проекта, потому что это будущее не записано нигде — оно ещё не случилось и зависит от решений людей, которые ещё не приняты. Когда я выбираю между двумя структурами, я по сути делаю ставку на то, как изменится продукт. Это вероятностное суждение о ненаписанном будущем конкретной команды. Модель умеет предсказывать следующий токен, но не следующий квартал вашей дорожной карты.

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

Как у меня в мае 2026-го реально проходит граница между мной и агентом

Чтобы не остаться в области рассуждений, приземлю до конкретики, как у меня устроен рабочий день в мае 2026 года. Разделение получилось довольно чётким, и оно не про «AI помощник, а человек главный» — это разделение по природе задач.

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

Обратите внимание на последний пункт. Он не декоративный. AI закрыл написание кода, но не закрылнадзор за формой. Если я не держу простоту сознательно, агент незаметно нарастит структуру: добавит интерфейс, потому что «так чище», вынесет вспомогательную сущность, потому что «так переиспользуемо», разложит прямой сценарий на три абстрактных шага, потому что в обучающих данных так делали в больших проектах. Каждое такое решение по отдельности выглядит разумным. В сумме они дают ту самую переусложнённую систему, которую потом дорого читать, объяснять и менять.

У плохого решения раньше был тормоз — теперь его нет

Теперь стоит быть честным до конца, без этого статья была бы наполовину рекламой человеческой незаменимости. Главный риск 2026 года — не в том, что AI пишет плохой код. Код он пишет хороший. Риск в том, что соблазн делегировать ему ещё и выбор структуры огромен, и поддаться этому соблазну легко, потому что результат внешне выглядит профессионально.

Доверить AI структуру проекта — самая дорогая ошибка этой эпохи, потому что архитектурная ошибка, реализованная быстрым и аккуратным инструментом, успевает врасти в систему до того, как её заметят. Раньше у плохого решения был естественный тормоз: его долго писали руками, и в процессе кто-то успевал усомниться. Сейчас этого тормоза нет. Агент за час разворачивает по всей кодовой базе паттерн, который не подходит вашему продукту, и делает это настолько чисто, что на ревью придраться не к чему — синтаксически всё безупречно. Проблема не в строчках, проблема в том, что выбран не тот каркас. А это видно не на уровне диффа, а на уровне понимания, куда идёт продукт.

Через полгода такая система мстит ровно так же, как мстила всегда: любое изменение требует затронуть десять файлов, обойти три абстракции и не сломать контракт, придуманный под будущее, которое не наступило. Разница только в том, что теперь этот музей построен не за месяцы, а за недели, и ответственность за него размыта, потому что «так предложил агент». Но агент ничего не предлагал в смысле ответственности. Он усреднил. Выбор всё это время был на человеке — просто человек его не сделал.

Что это значит для самой профессии

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

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

Спросить мнение и делегировать выбор — это две разные вещи

Чтобы не свалиться в противоположную крайность, проговорю аккуратно. Я не утверждаю, что человек должен ревниво охранять архитектуру и не подпускать к ней AI. Наоборот, обсуждать структуру с агентом полезно: он быстро накидывает варианты, показывает типовые подходы, помогает увидеть, как похожие задачи решают в индустрии. Это хороший собеседник на этапе размышления. Опасна не помощь, опасна передача решения. Разница между «спросить мнение» и «делегировать выбор» здесь критическая, и она целиком на стороне человека, потому что только человек несёт последствия.

Точно так же я не утверждаю, что AI совсем не способен на разумные структурные подсказки. В простых, типовых ситуациях, где задача действительно близка к усреднённому образцу, его предложение часто будет нормальным. Граница проходит там, где задача специфична: где контекст бизнеса, история команды или горизонт планирования делают «популярный ответ» неподходящим. Чем уникальнее ситуация, тем меньше можно полагаться на усреднение и тем больше работы остаётся человеку. И, по моему опыту, по-настоящему важные архитектурные развилки почти всегда специфичны — иначе они не были бы важными.

Граница ответственности сместилась, но не исчезла

Если собрать всё сказанное в одну мысль, она будет не про то, что AI всё решил, и не про то, что он ничего не умеет. Она про то, что граница ответственности сместилась, но не исчезла. Тактика закрыта: код, тесты, рутинный рефакторинг, типовые реализации — всё это теперь дёшево и быстро, и держаться за него руками бессмысленно. А стратегия осталась там, где была всегда, — у человека, который знает свой бизнес, имеет право на компромисс и думает на полгода вперёд.

Архитектура оказалась последней территорией человека не из-за романтики профессии, а из-за устройства задачи. Выбор структуры требует контекста, которого нет в коде, суждения о ненаписанном будущем и готовности отвечать за компромисс. Модель не несёт последствий ваших решений — а значит, не может их принимать, как бы убедительно она их ни формулировала.

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