AI ускоряет разработку. Почему программа всё равно может делаться месяцами?

Однажды Claude написал мне программу прогнозирования за день. В конце он уверенно сообщил, что всё сделал.

Файлы действительно были. Код запускался. Можно было открыть результат и подумать: вот она, разработка будущего — утром поставили задачу, вечером получили программу.

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

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

За день появляется код, а не готовая программа

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

Рабочая программа должна доказать намного больше:

• она считает правильно на обычных и странных данных;
• пользователь понимает, куда нажимать;
• два человека не портят данные друг друга;
• ошибку можно заметить и расследовать;
• доступы ограничены;
• после обновления старые данные не исчезают;
• результат соответствует настоящему процессу, а не его первому пересказу.

Самая дорогая часть часто начинается после демонстрации.

Первый месяц: мы выясняем, что задача была описана не полностью

Заказчик знает свой бизнес, но не держит в голове формальное описание каждой развилки. Он может сказать: «Спрогнозируй продажи по истории». Только в работе выяснится:

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

AI быстро воплощает формулировку. Он не может заранее получить правила, о которых никто не вспомнил.

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

Второй месяц: правильная формула оказывается неправильной для части данных

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

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

Поэтому нужны эталонные примеры, сверка со специалистом, тесты на границах и объяснение результата. AI помогает писать проверки, но человек должен знать, что считать правильным.

Третий месяц: программа встречает пользователя

В первой версии прогнозирования Claude вообще забыл интерфейс. Для модели задача могла выглядеть завершённой: функция принимает данные и возвращает ответ. Для сотрудника программы ещё не существовало.

Интерфейс — не украшение. Он должен объяснить:

• какие данные загрузить;
• что система сейчас делает;
• почему строка не рассчиталась;
• где исправить ошибку;
• можно ли отменить действие;
• какой результат уже сохранён;
• что передать следующему сотруднику.

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

«Матчер»: шесть месяцев до запуска и развитие после него

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

Разработка заняла около полугода. Я работаю в системе уже три месяца и до сих пор её дописываю: где-то нужны новые функции, где-то в реальных заказах проявляются ошибки.

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

Ошибкой было бы объявить финалом первую версию алгоритма, которая красиво сопоставила десять строк.

Исследования дают противоречивые результаты — и это нормально

В рандомизированном исследовании METR 16 опытных разработчиков решали 246 задач в знакомых открытых проектах. С инструментами начала 2025 года они в среднем потратили на 19% больше времени, хотя сами ожидали ускорения и после работы считали, что стали быстрее. Исследование узкое: опытные авторы, зрелые репозитории и старые по меркам 2026 года модели. Его нельзя превращать в вывод «AI всегда замедляет».

Другой препринт 2026 года изучил 802 разработчиков и 196 212 запросов на изменение кода в одной компании. Производительность на человека со временем дошла до 2,09 от исходного уровня после обязательного внедрения AI. Но это наблюдение одной организации, а число изменений кода не равно качеству продукта.

SWE-WebDevBench проверил шесть платформ, создающих приложения по заданию. Ни одна не достигла 60% по инженерному качеству и 65% по безопасности при целевом уровне 90%.

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

Куда на самом деле уходит время

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

Как честно планировать AI-разработку

Называть первую версию прототипом

Она отвечает на вопрос «можно ли сделать», а не «можно ли завтра перевести на неё отдел».

Сразу выбрать контрольные примеры

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

Запускать на узком участке

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

Планировать время специалиста бизнеса

Разработчик и AI не определят самостоятельно, почему возврат надо учитывать именно так. Нужен человек, который принимает результат и объясняет исключения.

Отдельно определить готовность

Например: расчёты совпадают с 200 эталонами; ошибки видны в журнале; есть интерфейс; роли настроены; данные восстанавливаются; два сотрудника прошли сценарий без помощи разработчика.

AI всё-таки сокращает срок?

Да. Он помогает мне быстрее пробовать подходы, писать типовой код, искать причины ошибок и переделывать систему. Без него оба проекта, вероятно, заняли бы больше времени.

Но ускорение не превращает неизвестную задачу в известную. Программа прогнозирования была «написана» за день и остаётся в разработке третий месяц. «Матчер» создавался полгода и развивается после запуска.

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

Источники и ограничения

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — рандомизированный эксперимент, но всего 16 опытных разработчиков и инструменты начала 2025 года.
• AI Writes Faster Than Humans Can Review, 2026 — большое продольное наблюдение внутри одной организации; препринт и корпоративный контекст ограничивают обобщение.
• SWE-WebDevBench, 2026 — сравнение шести AI-платформ на ограниченном наборе задач.
• «Матчер» и программа прогнозирования — авторский опыт Алисы Пилат; сроки относятся к этим проектам и не являются нормативом для любой разработки.