Проектирование софта AI-first с нуля: руководство для практика

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

Вот вопрос, который большинство инженерных команд ещё не произнесли вслух: если модель может писать код, в чём именно мы теперь должны быть хороши?

Ответы, которые я слышу, в основном защитные. Промпт-инжиниринг. Проверка вывода ИИ. Знание, за какой инструмент взяться. Всё это реальные навыки, все они ниже по течению от настоящего сдвига, и ни один не объясняет то, что я вижу на практике снова и снова: команды, внедрившие одни и те же инструменты, в одном и том же квартале, с одними и теми же моделями, оказываются в совершенно разных местах. Одна группа выпускает быстрее, и софт держится. Другая выпускает быстрее и проводит следующий квартал, выясняя, что сломала.

Одни инструменты. Противоположные результаты. Эта разница не про модель.

Усилитель, которого никто не учёл

Отчёт DORA «State of AI-assisted Software Development» за 2025 год поставил этому цифры. 90% специалистов в технологиях теперь используют ИИ на работе, и более 80% верят, что он повысил их продуктивность. И то и другое неудивительно. Значим третий вывод: более высокое внедрение ИИ связано с ростом пропускной способности поставки софта и с ростом нестабильности поставки софта одновременно.

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

Формулировка DORA в том, что ИИ — усилитель: он увеличивает любую практику, на которую попадает. Сильные системы становятся сильнее. Слабые системы становятся быстрее в своей слабости.

А значит, интересным вопросом никогда не было «как нам внедрить ИИ». Он был «что ИИ в нас усиливает». И чтобы на него ответить, нужно вернуться дальше, чем любое решение об инструменте.

Исходите из задачи, а не из инструмента

Мышление с нуля — одна из тех фраз, которые повторяли до потери смысла, так что позвольте уточнить, что я имею в виду, а что нет.

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

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

Сделайте это честно, и обнаружите, что ИИ изменил ровно одну вещь — и не ту, которую продавала категория.

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

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

Первое: модель данных — это продукт

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

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

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

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

Второе: отложенное решение всё равно принимается

Вот что практики недооценивают.

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

Что пользователь с отменённой подпиской всё ещё может видеть? Что происходит, когда два человека правят одну запись? Уникален ли адрес электронной почты и уникален в пределах чего? Никто не задавал этих вопросов в промпте, поэтому никто на них не ответил — а у приложения теперь есть ответ на все три, выбранный по выводу и обнаруживаемый только натыканием на него в продакшене.

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

У практики, которая это исправляет, теперь есть имя: разработка по спецификации. Запишите требования, ограничения и критерии успеха первыми. Относитесь к этому документу как к источнику истины. Дайте агенту строить против него. GitHub выпустил Spec Kit, AWS выпустил Kiro, и такое схождение не случайно.

Третье: когда генерация бесплатна, ограничения должны быть записаны

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

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

Это практическое ядро проектирования AI-first, и оно лишено всякого блеска. Опускайте инварианты вниз, в слой, который может их обеспечить. Not-null и unique в базе данных, а не в обработчике формы. Типы на границах, а не в комментарии к коду. Авторизация как политика, которую система вычисляет, а не как условие, которое кто-то не забыл вписать в эндпоинт.

Каждое ограничение, которое вы вынесли наружу, — это решение, в котором модель больше не может ошибиться.

Четвёртое: теперь вы строите для двух потребителей

Последнее — самое новое и то, которое большинство команд вообще не усвоило.

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

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

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

Как выглядит пропуск этого в данных

GitClear проанализировал 623 миллиона изменений кода с 2023 по 2026 год, и картина по поддерживаемости согласуется со всем сказанным выше.

Относительно базы 2023 года дублированных блоков кода больше на 81%. Копипаста внутри коммита выросла с 9,4% в 2022 году до 15,7% в первой половине 2026 года. Конструкций, маскирующих ошибки, больше на 47%. При этом межфайловые вызовы функций — самый ясный доступный сигнал переиспользования кода — снизились на 35%, а активность рефакторинга обрушилась с 21% изменений в 2022 году до 3,8% пока что в 2026-м.

Разработчики теперь примерно в пять раз чаще копируют и вставляют, чем рефакторят. В 2022 году это соотношение работало в обратную сторону.

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

Как работать так, начиная с этой недели

Ничто из этого не требует реорганизации. Требуется изменить порядок четырёх-пяти привычек.

1. Напишите модель данных до первого экрана. Сущности, связи, кардинальность, что делает строку уникальной, что каскадится при удалении. Час здесь — час с наибольшим рычагом во всём проекте, и именно его инструменты активно предлагают вам пропустить.
2. Сделайте спецификацию тем артефактом, который вы рецензируете, а не диффом. Если спецификация верна, а генерация ей верна, рецензировать тысячи строк сгенерированного кода — театр. Рецензируйте документ, который их произвёл. Спорьте о спецификации, пока спор ещё дёшев.
3. Вынесите наружу каждое ограничение, которое можете назвать. Перед генерацией перечислите правила, которые нельзя нарушать, и поместите каждое туда, где система его обеспечивает. Всё, что останется в разговоре, в итоге будет нарушено чем-то, что к разговору не присоединялось.
4. Проектируйте API как продуктовую поверхность. Затем относитесь к человеческому интерфейсу как к одному из её потребителей. Это скорее вопрос последовательности, чем инженерии, и именно поздняя постановка в очередь делает это дорогим.
5. Измеряйте нестабильность, а не только пропускную способность. Вывод DORA в том, что скорость и хрупкость выросли вместе, так что измерение только скорости покажет вам хорошую половину собственного тренда. Частота отказов при изменениях и время восстановления — те числа, которые говорят, работает ли усилитель на вас.

Чего это стоит

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

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

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

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

Часть, которая никогда не поддавалась автоматизации

Некоторые роли, построенные вокруг производства кода, сократятся. Некоторые исчезнут. Делать вид, что нет, никому не помогает подготовиться, и люди, говорящие вам, что любая инженерная работа в безопасности, вам не одолжение делают.

Но посмотрите, что асимметрия на самом деле сделала. Она автоматизировала выражение решений и оставила сами решения совершенно нетронутыми. Что строить. Чего не строить. Какие инварианты держатся. Чего система никогда не должна делать. Где лежат границы и кому позволено их пересекать.

Эта работа всегда была сложной частью. Просто она была скрыта под трудом набора текста, который был достаточно дорог, чтобы выглядеть работой.

Набор текста никогда не был работой.

Что почитать дальше

Практика в деталях: разработка по спецификации. Если вы выбираете инструмент: лучшие ИИ-конструкторы приложений в 2026 году.

Часто задаваемые вопросы

Что означает «проектирование софта AI-first»? Проектирование приложения исходя из допущения, что большая часть кода будет сгенерирована, а не написана вручную, и что часть потребителей будут агентами, а не людьми. Практически это значит, что модель данных, ограничения и контракт API определяются явно заранее, потому что это те решения, которые генерация не может принять за вас.

Чем проектирование AI-first отличается от простого использования ИИ-инструментов для кодирования? Использование ИИ-инструментов добавляет возможность в неизменный рабочий процесс. Проектирование AI-first меняет порядок операций процесса: модель и контракт до интерфейса, спецификация как рецензируемый артефакт, ограничения, опущенные в слои, где они обеспечиваются. Исследование DORA за 2025 год обнаружило, что внедрение ИИ подняло пропускную способность и нестабильность вместе, — а это то, что происходит, когда инструмент меняется, а практика нет.

Каковы первые принципы проектирования софта в эпоху ИИ? Держатся четыре: модель данных — это продукт, а экран — её представление; любое решение, не принятое явно, принимается неявно генератором; ограничения должны жить там, где они машинно обеспечиваются, а не в чьей-то голове; и ваше приложение теперь обслуживает и человеческий интерфейс, и API для агентов, которым нужен паритет.

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

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

Когда всё это можно нормально пропустить? Прототипы, демо, внутренние одноразовые вещи и всё, что вы планируете выбросить. Накладные расходы стоит нести только для софта, который должен пережить реальных пользователей, реальные данные и изменения со временем.