Скорость написания кода никогда не была проблемой

Мираж оптимизации или Голдратт уже все сказал

Как сказал создатель теории ограничений - Элияху Голдратт

“Час, сэкономленный не на «бутылочном горлышке» — это мираж”

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

Другими словами - когда вы оптимизируете этап, который не является узким местом, вы не получите более быструю систему. Вы получите более неэффективную систему.

Сколько времени инженеры тратят на код?

Различные исследования по анализу работы инженеров приводят показатели затрат времени на написание кода относительно других стадий работы: от ~10-16% до ~50-65% в небольших проектах на ранних стадиях. В исследовании Microsoft Research — “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era” инженеры делятся оценкой в 11%. При этом в “идеальной неделе” они хотели бы тратить на написание кода - 20% и на технический дизайн - 15%.

Отчет Global Code Time Report от 2022 приводит медианную цифру - 52 минуты в день.

Проблемы по серьезнее

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

Теперь мы пишем больше кода, но создаем меньше качественного функционала.

Реальное узкое место

Качество гипотез и идей в наших беклогах! Вот то, что должно быть максимально оптимизировано - то что лежит далеко за началом процесса разработки. Часто мы слишком уверенны в необходимости этих задач без должных исследований, проверки гипотез и их достаточного описания перед передачей в разработку.

Если мы гарантировано будем знать - что и как “строить” и каждая фича будет приносить значительную ценность клиенту, а значит и для нас как для команды или компании.

Инструменты построенные для AI-First разработки построенные инженерами следуют четкому принципу:

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

Как это выглядит на при разработке с ИИ? Вы тратите несколько часов на описание с агентом,и если выдержали - с высокой долей вероятности получаете качественный, ожидаемый результат за 10 минут потраченные на генерацию кода.

Так или иначе об этом говорится и в романах Тома Демарко, и в профессиональной литературе по управлению проектами вроде руководства Джозефа Хигни.

Что делать?

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