Оценка проектов ИИ против арифметики: 300 часов оказались втрое ниже минимума ISBSG

---

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

Русскоязычный разработчик опубликовал подробный разбор спора с заказчиком, которому показалась завышенной оценка в 300 часов на доработку внутренней учётной системы. Автор, который строит учётные системы на low-code-платформе (платформе, позволяющей собирать приложения с минимумом ручного кода), применил три признанных в отрасли способа подсчёта трудозатрат и получил результат, неудобный для обеих сторон.

Три метода дали одну картину: 300 часов слишком мало

Проект включал 8 предметных сущностей, 13 таблиц данных, 40 экранов, 77 точек обращения к серверу (API-эндпоинтов) и около 90 пользовательских действий. Сюда же входили интеграции с Google Sheets, корпоративным таск-трекером, облачным хранилищем S3 и сервисом распознавания голоса, а также работа в офлайне и сборки для двух мобильных магазинов.

Автор подсчитал объём тремя способами:

• Снизу вверх, по действиям. Каждое из 90 действий раскладывается на полный цикл: основной сценарий, обработка ошибок, права доступа, тесты. Распределение по шкале 1 / 4 / 16 часов дало 306 часов.
• Функциональные точки и база ISBSG. Объём составил 412 функциональных точек (функциональная точка, единица измерения «полезного размера» софта, не привязанная к языку программирования). По репозиторию ISBSG (International Software Benchmarking Standards Group, крупнейшая в мире база данных по реальным IT-проектам) даже лучший результат low-code-проектов на 90-м процентиле составляет около 990 часов. Медиана Java-проектов в той же базе даёт около 3 600 часов.
• COCOMO II. Модель COCOMO II (Constructive Cost Model, формула оценки трудозатрат по размеру кода, разработанная в USC) при номинальных параметрах показала около 12 400 часов.

Авторская оценка 300 часов соответствует 0,73 часа на функциональную точку. Это ниже минимума всей low-code-выборки ISBSG.

Почему «ИИ сделает за вечер» не работает для учётных систем?

Заказчик возражал именно так: зачем 300 часов, если с ИИ всё собирается за вечер. Автор разобрал этот аргумент с опорой на три независимых источника.

Эдди Османи из команды Google Chrome DX в декабре 2024 года описал «проблему 70 %»: первые 70 % решения появляются быстро, а оставшиеся 30 % (крайние случаи, безопасность, интеграция с реальной инфраструктурой) остаются такими же трудоёмкими, как и раньше.

Систематический обзор практического опыта (arXiv:2510.00328, принят на конференцию ICSE-SEIP 2026, 101 источник, 518 наблюдений из первых рук) зафиксировал устойчивую закономерность: практики получают быстрый результат, но сами описывают его как «быстро, но с изъянами», а проверку качества систематически пропускают или поручают тому же инструменту, который написал код.

Эксперимент Anthropic (arXiv:2601.20245, 52 участника) показал, что люди, решавшие задачу с помощью ИИ, продемонстрировали на 17 % худшее понимание полученного кода. Лучше удерживали материал те, кто задавал уточняющие вопросы, а не принимал результат как есть.

Отдельный факт о цене «быстрой сборки»: в мае 2025 года публичное раскрытие уязвимости CVE-2025-48757 описало более 170 рабочих приложений, собранных на популярной ИИ-платформе, где базу данных мог читать и менять любой анонимный запрос. Сгенерированная схема приходила без правил разграничения доступа.

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

Что ломает любую оценку?

Автор отдельно перечислил зоны, где все три метода перестают работать:

• Миграция данных. В техническом задании её обычно нет, а на практике это десятки часов: старые справочники, дубликаты, записи без обязательных полей.
• Чужие API. Оценка «интеграция за 16 часов» верна для документированного интерфейса и разваливается на лимитах запросов, недокументированных полях и обновлениях на стороне поставщика.
• Офлайн-режим. Это не отдельная функция, а свойство архитектуры: очередь сообщений, разрешение конфликтов, гарантия повторной отправки. Дописать потом дороже, чем заложить сразу.
• Приёмка. Заказчик впервые видит систему на своих данных и обнаруживает, что термин «мастер» в его компании означает не то, что в модели данных.

Что это значит для вас?

Авторам Дзена и копирайтерам. Когда вы описываете ИИ-инструменты, честно предупреждайте читателей: «собрать за вечер» относится к прототипу, а не к рабочей системе. Оценка проектов с помощью ИИ требует тех же вопросов, что и без него: что именно входит в объём, кто проверяет результат, сколько стоит исправление ошибок.

Маркетологам. Если вы заказываете внутреннюю CRM или учётную систему и подрядчик обещает «всё за 40 часов с ИИ», попросите его назвать количество экранов, действий и интеграций. Сверьте с отраслевыми нормами ISBSG: даже для low-code лучший показатель начинается от 2,4 часа на функциональную точку, а не от 0,73.

Предпринимателям в РФ и СНГ. Методики ISBSG и COCOMO II открыты и не зависят от санкционных ограничений. Их можно использовать при оценке проектов с помощью ИИ на любой платформе, будь то «1С», российские low-code-решения или зарубежные инструменты.

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