Как мы разрабатываем с AI: архитектура и гибкость вместо набора кода

Коротко. Мы используем AI для написания большой части нашего кода, и это осознанный выбор, а не способ срезать угол. Причина проста: агент быстро производит код и плохо владеет системой целиком. Поэтому набор кода мы отдаём ему, а инженеров поднимаем выше по стеку — к архитектуре, к гибкости, к системным решениям, от которых зависит, будет ли кодовую базу всё так же приятно менять через год. В 2026 году индустрия пришла к тому же: 84% разработчиков теперь используют AI каждый день, а выигрышный паттерн звучит как «генерируй агрессивно, проверяй строго». Загвоздка в том, что AI оптимизирует каждый файл локально, а кодовую базу глобально не оптимизирует никто — именно поэтому кодовые базы, которые мы проверяем, ломаются одними и теми же шестью способами. Наш ответ: оставить человека на той части, которую AI не видит, — на архитектуре. Вот как мы работаем и почему.

Работа изменилась, и мы изменились вместе с ней

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

Это узкое место исчезло. Как описывает обзор мира разработки за июнь 2026 года, AI-инструменты прошли путь от диковинки до базовой нормы: 84% разработчиков обращаются к ним ежедневно, TypeScript обогнал Python как самый используемый язык отчасти потому, что типизированный код держит AI в рамках, а самые продуктивные инженеры больше не пишут руками больше кода — они оркестрируют агентов, которые это делают. «10x-инженер» превратился в управляющего машинами.

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

База 2026 года в четырёх цифрах:

• 84% используют AI ежедневно. AI-инструменты теперь норма, а не опциональное дополнение.
• 46% не доверяют, 3% доверяют полностью. Разработчиков, не доверяющих выводу AI, гораздо больше, чем доверяющих, — поэтому проверка обязательна.
• Мультиагентность стала нормой. Самые продуктивные инженеры направляют флоты агентов, а не пишут больше кода руками.
• TypeScript — №1. Типизированные языки обогнали Python отчасти потому, что держат сгенерированный код в рамках.

Что мы отдаём AI, а что оставляем себе

Понятнее всего описать наш процесс, разделив работу надвое: то, что мы делегируем машинам, и то, что отказываемся отдавать.

AI мы отдаём набор кода. Бойлерплейт, CRUD-эндпоинты, десятая вариация формы, склейка для перекладывания данных, черновики тестов, миграции, нудные механические преобразования, которые раньше съедали полдня, — агенты по-настоящему хороши во всём этом. Модель напишет правдоподобную реализацию быстрее, чем человек успеет её описать. Так пусть и пишет. В 2026 году нет никакой доблести в том, чтобы вручную набивать постраничный список.

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

Это разделение не компромисс. Это наиболее эффективное использование обеих сторон. Машина делает то, в чём быстра; люди делают то, что пока хорошо умеют только люди. Гуляющая по индустрии формулировка — «Codex для нажатий клавиш, Claude Code для коммитов» — на самом деле про высоту: чем ближе вы к решению, от которого зависит вся система, тем больше человек нужен в контуре.

Почему архитектура должна оставаться за человеком

Вот неудобная правда, которую мы видим каждую неделю, и она — двигатель всего, о чём мы только что говорили.

Мы проводим аудиты кода для постоянного потока приложений, собранных на AI. Кодовые базы дико разные, а вот находки — почти никогда: нет тестов, один и тот же хелпер продублирован четыре раза с небольшими расхождениями, два экрана в одном проекте написаны как двумя разными командами, сложное состояние свалилось в callback hell, код предполагает одну машину и портит сам себя, как только запускается на двух, секреты закоммичены прямо в репозиторий. Шесть проблем, снова и снова.

Каждая из них — системное свойство. Ни одна не может появиться из одного хорошего промпта, потому что ни один промпт не видит систему целиком. У модели, генерирующей код, узкое окно контекста и нет памяти о решении, принятом три файла назад. Она каждый раз делает локально оптимальный выбор — а сумма локально оптимальных выборов это кодовая база, которая работает сегодня и сопротивляется любому изменению завтра. Дрейф — не баг конкретной генерации; это неизбежная форма генерации без глобального владельца.

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

Vibe and verify: как мы держим AI-код безопасным

В данных есть реальный разрыв доверия, и мы относимся к нему серьёзно: по индустрии 46% разработчиков активно не доверяют выводу AI и лишь 3% доверяют ему полностью. Зрелая реакция — не перестать использовать AI, а относиться ко всему, что он производит, как к недоверенному стороннему коду, пока не доказано обратное. Генерируй агрессивно; проверяй строго. «Vibe and verify».

На практике это значит, что каждая написанная агентом строка проходит тот же контроль, что и пул-реквест от подрядчика:

• Её читает человек, а не пробегает глазами. Ловушка доверия к AI-коду в том, что он выглядит законченным, поэтому те 20%, которые не закончены, незаметны. Мы читаем на предмет того, в чём модели стабильно ошибаются, — отсутствующая авторизация за экраном логина, ввод, подставленный прямо в запрос, эндпоинт, возвращающий весь объект пользователя, когда интерфейсу нужно было имя.
• Ей пишут тесты, целенаправленно. Сгенерировать фичу и сгенерировать к ней тесты — два разных запроса, и второй сам по себе случается редко. Мы добиваемся, чтобы он случился: smoke-тест на то, что приложение поднимается, реальное покрытие вокруг денег и авторизации и регрессионный тест на каждый исправленный баг.
• Её меряют по архитектуре, а не только по «запускается ли». Фичу, которая работает, но изобретает собственный паттерн состояния, или дублирует существующий хелпер, или тянется через границу, о которой не должна знать, отправляют на доработку — даже если её счастливый путь проходит.

Это та же дисциплина, которую мы описали для основателей, выводящих AI-прототипы в продакшен, — что ломается между демо и продакшеном. Короткая формула, к которой мы постоянно возвращаемся: AI проходит 80% пути за 5% времени — а последние 20% и есть весь продукт. Эти 80% мы отдаём AI. А 20% оставляем себе.

Оркестрировать агентов, а не писать больше кода

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

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

Гибкость — это и есть вся суть

Если описать одним словом то, что мы оптимизируем, это не скорость — скорость теперь дёшева. Это гибкость: способность вобрать изменение требований без переписывания.

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

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

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

Частые вопросы

Делайте быстро, оставайтесь гибкими

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

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