Как я использую AI в разработке и где он не помогает

Общая экономия времени на проекте от AI у меня получается 20-25%, и это честная цифра. Не в десять раз, не вдвое. Она складывается неравномерно: на вёрстке и типовом коде экономия доходит до 35-40%, на черновиках текста около 40%, на архитектуре, безопасности и отладке редких багов она равна нулю, а иногда отрицательная. Ниже разбираю по этапам, где именно и почему.

Считаю по своим проектам за последний год: сайты на Astro, гибридные мобильные приложения на Capacitor, личные кабинеты, миграции. Все цифры - мои замеры, а не бенчмарки из статей.

Разработка сайта под ключот 250 000 до 600 000 ₽сроки: 4-8 недель

Где экономия реальная

Типовой код и разметка. Сетка карточек, таблица с сортировкой, форма с валидацией, модальное окно, скелетоны загрузки. Всё это написано в мире миллион раз, и модель воспроизводит его уверенно. Я описываю поведение и структуру данных, получаю каркас, дальше правлю руками. На типовой посадочной странице это экономит два-три часа из восьми.

Черновики текстов. Заголовки, описания блоков, микрокопия кнопок и сообщений об ошибках, наброски FAQ. Публиковать без переписывания нельзя ничего, но пустой лист закрывается за минуту. Это примерно 40% времени на копирайтинге.

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

Рутинные миграции. Когда я переносил 500+ файлов на Vue 3, механическая часть - смена синтаксиса опций на композицию, замена импортов, правка типов - отлично делается пачками. Модель обработала примерно 70% файлов без вмешательства. Оставшиеся 30% - те, где была нетривиальная реактивность, и там она ломала логику молча, без ошибок сборки. Именно поэтому миграция шла с тестами, а не «на глаз».

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

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

Сколько это в долях проекта

Структура цены

Доли времени по этапам и где AI экономит

Разбивка по типовому проекту сайта на 12 посадочных страниц. Проценты в примечаниях - сколько времени этапа снимает генерация.

01 02 03 04 05 06

100%

01 Семантика и карта страниц Экономия близка к нулю: данные из Wordstat, решения по структуре мои

12%

02 Прототип и тексты Экономия около 40%: черновики генерирую, переписываю всё

14%

03 Дизайн Экономия 10-15%: помогает на вариантах, не помогает на решении

22%

04 Вёрстка и типовой код Главная экономия: 35-40% времени этапа

26%

05 Интеграции и аналитика Типовое ускоряется, недокументированное API - нет

12%

06 Отладка, безопасность, приёмка Экономии нет, на редких багах бывает минус

14%

Итог: типовой сайт под ключ, 4-8 недель

Если перемножить доли на экономию по каждой, выходят те самые 20-25% по проекту. Дальше цифра не растёт, потому что этапы, которые ускоряются лучше всего, занимают меньше половины времени.

Где AI не помогает вообще

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

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

Безопасность. Здесь я не принимаю сгенерированный код в принципе, только читаю его целиком. Типовые находки: проверка прав на клиенте вместо сервера, секреты в коде фронтенда, эндпоинт, который отдаёт данные любого пользователя по подставленному идентификатору, отсутствие ограничения частоты запросов на форме. Всё это выглядит рабочим и проходит ручное тестирование. Роли и доступы в личных кабинетах я пишу руками и проверяю отдельно, потому что цена ошибки тут не «некрасиво», а утечка.

Недокументированные и редкие API. Самый дорогой случай. Когда я делал нативные плагины на Swift и Kotlin, модель регулярно предлагала методы, которых в API не существует. Выглядит правдоподобно, компилируется в голове, падает на сборке. Полчаса уходит на то, чтобы понять, что метода нет вообще. То же самое с малоизвестными библиотеками и со свежими версиями, которых модель не видела.

Чужой легаси. Проект на десять лет, где половина решений принята по причинам, которых больше нет. Модель предложит переписать по учебнику, не зная, что вон тот странный костыль держит интеграцию с бухгалтерией. В чужом коде я пользуюсь генерацией только для объяснений, не для правок.

Редкие баги. Тот класс, где симптом не совпадает с причиной: гонка при загрузке, утечка памяти на длинных сессиях, разное поведение на iOS и Android. Модель дважды предложит очевидное, вы это проверите, потеряете час, и вернётесь к тому, что работает: логи, бинарный поиск по коммитам, замеры. В терминале на 25 000 трейдеров все интересные баги были такими, и ни один из них не разбирался генерацией.

Где он не просто не помогает, а стоит времени

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

Уверенное неправильное направление. Модель никогда не говорит «не знаю». Она выдаёт версию, вы её проверяете, версия неверна. Два-три таких круга - и потеряно больше времени, чем сэкономлено на всём остальном за день. Правило, которое я себе поставил: если после двух попыток проблема не сдвинулась, закрываю чат и разбираюсь руками.

Код, который работает, но не тот. Хуже прямой ошибки. Функция делает похожее на нужное, тесты проходят, а расхождение вылезает через месяц на реальных данных. Ловится только чтением кода, поэтому я читаю всё, что принял.

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

Правила, по которым я пускаю AI в проект

Сформулированы после года практики и держатся довольно жёстко.

Решения принимаю до генерации, а не спрашиваю у неё. Структура, схема данных, границы модулей - это письменный документ, и он появляется раньше первой строки кода.

Читаю всё, что принял. Не бывает так, что кусок «просто работает» и его можно не смотреть. Это и есть основная работа: генерация переносит время из написания в чтение, а не убирает его.

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

Держу тесты на всём, что генерировалось пачками. Миграция 500 файлов без тестов - это не ускорение, а лотерея.

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

Что это значит для заказчика

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

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

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

Как устроен процесс, какие артефакты вы получаете до начала вёрстки и по каким числовым критериям я сдаю работу - на странице разработки сайтов. На первой консультации разбираю задачу и говорю, какая её часть реально ускоряется, а какая нет.