Почему ИИ не ускорит ваши процессы разработки – сосредоточьтесь на узких местах

Фредерик Ванбрабант критически рассматривает ажиотаж вокруг ИИ для оптимизации процессов, опираясь на классические труды, такие как «Путь Toyota» и «Цель». Его основная мысль: применение ИИ на этапе разработки не затрагивает настоящее узкое место — зачастую это неоднозначность требований на более ранних этапах.
Визуализация узкого места
В большинстве планов проектов блок разработки ПО занимает много времени. Инстинктивно хочется оптимизировать именно его, но Ванбрабант утверждает, что большая продолжительность не означает, что проблема кроется именно там. Используя диаграмму Ганта, он показывает типичный проект: определение рамок (10 дн.), определение бюджета (3 дн.), юридические вопросы (10 дн.), документирование (5 дн.), затем разработка (70 дн.). Очевидная цель — разработка, но настоящая проблема находится выше.
Проблемы на ранних этапах
Разработка ПО — это не просто быстрый набор текста; это понимание задачи. Расплывчатые запросы, такие как «отправить письмо пользователю после завершения продажи», требуют уточнений: что такое продажа? что делать в случае ошибки? какое содержание письма? Эта неопределенность замедляет разработчиков.
ИИ не решит эту проблему
Ванбрабант приводит типичное наивное предположение: ИИ сокращает разработку с 70 дн. до 3 дн. Но реальность такова, что ИИ все равно требует детальных спецификаций. Реальный график выглядит так: определение рамок (10 дн.) + юридические вопросы (10 дн.) + документирование (40 дн.) + разработка с ИИ (40 дн.). Этап документирования расширяется, потому что эксперты в предметной области должны описать каждую деталь, чтобы получить от ИИ корректный код. Он отмечает: «Если бы вы дали разработчикам-людям тот же объем документации по функциям и рамкам, вы бы тоже увидели резкий рост производительности».
Вывод
Статья оспаривает упрощенное представление о том, что ИИ автоматически ускоряет процессы. Вместо этого следует сосредоточиться на всем потоке создания ценности и устранить узкие места на ранних этапах — улучшить требования, наладить более тесное сотрудничество с экспертами в предметной области — прежде чем ожидать выгоды от ИИ. Для разработчиков, работающих с ИИ-агентами кодирования, это практическое напоминание о необходимости инвестировать в качество спецификаций.
📖 Источник: HN AI Agents
👀 Смотрите также

Самостоятельный хостинг против управляемого OpenClaw: 4-месячное сравнение разработчика
Разработчик перешёл с самостоятельного хостинга OpenClaw за 4 месяца на управляемый сервис RunLobster за $49/месяц. Самостоятельный хостинг требовал постоянного обслуживания, включая скрипты переподключения, отладку обновлений конфигурации и борьбу с неожиданными счетами за API.

OpenClaw на AWS Lightsail: Разбор затрат и уроки по настройке
Разработчик потратил $100 за неделю на запуск OpenClaw на AWS Lightsail с Claude Sonnet 4.6 через Bedrock, обнаружив, что настройки песочницы, управление токенами и размер промптов существенно влияют на функциональность и затраты.

Клод Оркестратор Пайплайна Код-Агентов: Очереди Задач, Запуск Агентов, Контрольные Ворота
В посте на Reddit в сообществе r/clawdbot подробно описывается, как агенты Claude Code управляют магазином, работающим на основе ИИ, занимаясь дизайном, маркетингом, контролем качества и операциями 30 раз в день. В нём есть ссылка на 9-й эпизод серии блогов, где объясняется конвейер оркестратора в производственной среде, включая проблемы, которые обычно не показывают в демонстрациях.

Многообразные применения OpenClaw: Обзор от сообщества Clawdbot
Узнайте о новаторских способах, которыми пользователи использовали OpenClaw, от личных проектов до амбициозных автоматизированных систем, о которых делится сообщество r/clawdbot.