AI Dev Podcast #2: архитектура в эпоху ИИ

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

Андрей не выдерживает и спорит: есть Lovable, и человек, худо-бедно владеющий любым языком, собирает прототип за минуты, тогда как раньше он платил за техническое задание, искал исполнителей по референсам и месяцами тянул до прототипа. Инженерной культуры и платформы для этого не нужно — разработка демократизировалась и стоит небольших денег. Александр принимает пример: внутри Т-Банка он отвечает за собственный аналог такой платформы, и в Lovable действительно собирается не только прототип, но и работающий продукт с интеграциями вроде Stripe и Shopify, аутентификацией и базой данных. Только в какой-то момент вы уже не добавляете фичи, а багфиксите: чините одну часть — разваливается другая. Он связал получившийся продукт с репозиторием на GitHub, скачал код и увидел, что внутри нет ни файла с правилами для агентов, ни скилов, ни гайдрейлов, ни тестовой обвязки. Песочный замок: без инженера, который поставит распорку и укрепит фундамент, выше метра его не построить.

Сергей разделяет два ортогональных процесса: создание нового и развитие существующего. Прототип живёт сам по себе и никого не трогает, и сейчас многие меняют внешние SaaS-сервисы на свои — условную CRM или планировщик за неделю можно написать промптами: продавать это нельзя, но задачи оно закрывает. Сложности начинаются на продуктовых решениях, и первый вопрос — экономика. Развернули в трёх местах: где-то маржинальность 10–20%, а где-то из-за трафика и расхода памяти она уже отрицательная, и объяснить модели «трать меньше моих денег» довольно тяжело. Отсюда его тезис про джунов: модель априори знает то, что человек учит пять лет в университете и десять-двадцать на работе, но говорить с ней нужно на языке предметной области. Попросите «построй архитектуру маркетплейса» — получите одно; сформулируйте ту же задачу в терминах книги по архитектурным практикам — ответ будет уже, формальнее и с меньшим числом галлюцинаций, а модель начнёт мыслить архитектурными тактиками, которые вам остаётся приземлить на свой контекст.

Александр рассказывает про роль архитектора. Каноническая иерархия энтерпрайза — корпоративные архитекторы, solution-архитекторы, софт-архитекторы и инженеры внизу пищевой цепочки — ему не нравится; в Т-Банке архитектуру делали ролью, которую исполняют инженеры высокого грейда, «меньше поговорить, больше поделать», а корпоративный слой приземляли в зону ответственности технических директоров по доменам. Сверху вниз языковые модели пока работают ассистентски: собрать ландшафт, сгенерировать документацию. Зато plan mode в ассистентах вроде Claude Code или Codex — это фактически архитектор уровня фичи внутри репозитория: он исследует код и спрашивает, что для вас важно. С таким ассистентом Александр проектировал мультитенантность: раньше документ писался день, продавался неделю и месяц ждал реализации, а на greenfield это умещается в день интерактивного сопроектирования. Дальше он хочет подтягивать контекст четырёх уровней: правила компании, домена, репозитория и конкретной задачи. Сергей осаживает: сделанное за день не живёт в вакууме, и упираемся мы уже не в скорость кода, а в поставку и готовность инфраструктуры.

Другой ограничитель, по Сергею, — данные. База знаний, удобная людям, для модели должна ещё соответствовать онтологии и не содержать дублей, иначе корпоративные правила от сегодняшнего дня и от прошлых лет заставят её спорить самой с собой; а часть контекста — предпочтения, политические причины решений — вообще не закодирована и всегда отстаёт от реальности. Александр описывает переход от Software Engineering 1.0 с ролями и передачей ответственности между аналитиком, разработчиком, тестировщиком и саппортом к версии 2.0, где люди и агенты работают в одной системе. Делегировать агентам часть ответственности можно только при понятном интенте, зафиксированных ограничениях, автоматизированном код-ревью и выстроенных эвалах, а собрать это способен лишь человек в контексте домена. Сергей добавляет цифры: в прошлом году компании отчитывались об увольнении 10% персонала и десятков тысяч человек, а в этом квартальный отчёт Gartner фиксирует, что людей снова нанимают, — для работы с агентами понадобились сильные специалисты.

Почему фундамент не обесценится, Сергей объясняет через метауровень: тактики живут над кодом, и ни в таблицах, ни в схемах нет метаданных о модульности. Его пример — два сервиса под одним бизнес-инвариантом, где нельзя списать больше десяти тысяч при условии из соседнего сервиса: две команды договорятся, а агентам нужен надсистемный контекст. К тому же модель приходит к валидному ответу невалидными рассуждениями — она может уйти в архитектуру домов и городов и выдать формально корректное, но нерабочее решение. Меняется и экономика: переиспользуемый компонент всегда стоил дороже и окупался, если его брали две-пять систем, а теперь стоит столько, сколько на него потрачено токенов. Александр смещает ценность с имплементации на контракты и правила, а техдолг, годами висевший в бэклоге, предлагает отдавать Claude Code, Codex или Cursor. Общий риск — вендорлок на внешней модели, которая сегодня субсидирует токены, а завтра поднимет ценник; ответ — слой с квотами и каноническим API и внутренняя модель для переключения. В финале Андрей называет контекст главным дифференциатором, Александр напоминает: на третий год экспериментов спрашивают уже за финансовый эффект, а Сергей советует поднять локальную модель дома.