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

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

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

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

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

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

Различные исследования по анализу работы инженеров приводят показатели затрат времени на написание кода относительно других стадий работы: от ~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 минут потраченные на генерацию кода.

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

Что делать?

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

Ландшафт разработки программного обеспечения меняется стремительно, прямо сейчас.

Я более 15 лет занимаюсь инженерной работой в ИТ. Я ежедневно и активно использую ИИ-инструменты в работе: для разработки внутренних инструментов, автоматизации, аналитики и управления инфраструктурой.

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

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

Изменение состава и когнитивной сложности работы

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

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

Петля обратной связи

Думаю, многие, кто серьезно увлекался решением задач с помощью ИИ, сталкивались с такой ситуацией: вот еще чуть-чуть, еще пара исправлений, еще один вопрос, еще один ответ — и оно точно заработает как надо. Хотя, казалось бы, уже и так почти работает. Но еще совсем немного… и вот уже два часа ночи.

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

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

Командная и личная эффективность

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

Преимущества одиночной разработки с ИИ сложно перенести и на командную разработку.

Оценка результатов

Оценка в ИТ — тема для отдельной библиотеки. Но как теперь вообще понимать, что долго, что сложно и почему?

Теперь нам приходится формировать новую систему координат и заново переосмысливать сложность.

Заключение

Мы уже живем в таком будущем мире разработки программного обеспечения.

Эти изменения уже здесь.

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