Мы используем языковые модели в ежедневной работе больше года. За это время сложилась довольно чёткая картина: на одних задачах выигрыш измеряется часами, на других — отрицательный. Делимся без восторгов и без скепсиса.
Где выигрыш очевиден
Разбор чужого кода
Клиент приносит сайт, который делали три подрядчика подряд. Раньше на понимание структуры уходил день. Сейчас модель за полчаса даёт карту проекта: где логика заказа, откуда берутся цены, какие места опасно трогать. Проверять всё равно приходится, но стартовая точка гораздо лучше.
Типовая обвязка
Формы, валидация, обработчики ошибок, миграции, тесты на очевидные случаи. Всё, что пишется по образцу, модель делает быстрее человека и с меньшим числом опечаток.
Тексты для интерфейса и мета-описания
Заголовки страниц, описания карточек, подписи к формам, alt-тексты. Черновик от модели редактируется быстрее, чем пишется с нуля.
Где мы перестали её применять
Архитектурные решения
Модель уверенно предлагает решение, которое выглядит разумно и разваливается на третьем требовании. Она не знает, что через полгода на этот сайт придёт обмен с 1С, а через год — мультиязычность. Такие вещи держит в голове человек, который говорил с клиентом.
Работа с деньгами и правами доступа
Расчёт скидок, проверка прав, всё, что связано с оплатой. Здесь цена ошибки слишком высока, а ошибки бывают тихими: код работает, но считает неправильно в редком случае.
Оптимизация производительности
Советы обычно правильные в общем виде и бесполезные в конкретной ситуации. Профилировщик даёт ответ за десять минут, обсуждение с моделью — за час и без гарантии.
Правило студии
Код от модели проходит те же ревью, что и код разработчика. Если человек не может объяснить, почему написано именно так, — переписываем. «Так предложила модель» не аргумент на ревью.
Как это влияет на сроки и смету
Мы не стали делать сайты в два раза быстрее. Сократилось время на рутину — примерно на 15–20% от общего объёма работ. Освободившееся время ушло не в скидку, а в то, что раньше делалось по остаточному принципу: тесты, документация, разбор пограничных случаев.
Модель ускоряет набор кода. Она не ускоряет понимание задачи — а именно на это уходит большая часть времени в проекте.
Что это значит для заказчика
- Скорость разработки выросла заметно, но не кратно — обещания «сайт за три дня» по-прежнему означают шаблон.
- Качество кода зависит от команды, а не от инструмента: плохой разработчик с моделью пишет плохой код быстрее.
- Спрашивайте подрядчика, как он проверяет результат. Если ответа нет — это риск.
Где выигрыш измерим, а где кажущийся
Заметнее всего ускоряется работа, где результат легко проверить: типовые компоненты, тесты, преобразование данных, разбор чужого кода. Проверка занимает секунды, ошибка видна сразу, и время действительно экономится.
Обратная ситуация — архитектурные решения и работа в незнакомой предметной области. Ответ выглядит уверенно, а проверить его дорого: чтобы понять, что схема данных неверна, нужно дойти до середины проекта. Здесь скорость обманчива, а цена ошибки высокая.
Отдельная категория — код, который работает, но никто в команде не понимает почему. Он проходит проверку сегодня и становится проблемой через полгода, когда его нужно менять. Мы ввели простое правило: в проект попадает только то, что разработчик может объяснить построчно.
Какие долги мы за собой заметили
Первый — размывание стиля. Сгенерированный код бывает написан в другой манере, чем остальной проект, и через сотню правок кодовая база выглядит собранной из кусков. Лечится ревью, но ревью стало занимать больше времени, чем раньше.
Второй — устаревшие подходы. Модель охотно предлагает решения, которые были нормой несколько лет назад: старые API, лишние зависимости, приёмы, вытесненные возможностями самого языка. Это не ошибка, и тесты проходят — но проект получает груз, который потом кто-то будет разгребать.
- Скорость первой версии выросла заметно, скорость доведения до сдачи — почти нет
- Больше всего экономии в тестах и разборе чужого кода
- Меньше всего — там, где нужно решить, как устроить систему
Частые вопросы
Влияет ли использование ИИ на цену проекта?
Напрямую — нет. Экономия на наборе кода невелика в масштабе проекта: основное время уходит на проектирование, согласование и доведение до работоспособности. Обещание «дешевле, потому что ИИ» обычно означает экономию на проверке.
Пишете ли вы тексты сайта нейросетью?
Черновики и варианты формулировок — да. В публикацию такой текст не идёт: он гладкий и пустой, без цифр, ограничений и случаев из практики. Фактуру даёт человек, который делал работу.
Инструмент полезный и уже неотделим от работы. Но он усиливает существующие процессы, а не заменяет их. Там, где процессов не было, ИИ просто ускоряет накопление технического долга.
