От story points до tokenmaxxing: почему инженерия измеряет не то, что важно

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

Количество важнее качества: неверный способ измерения каждый раз

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

Затем в 2000-х появление Agile принесло нам story points, абстрактный способ оценивать сложность задачи, трудозатраты и риск относительно другой работы. Вместо ответа на вопрос «Сколько это займёт времени?» story points должны были отвечать на вопрос «Насколько это велико по сравнению с тем, что мы уже делали?». На бумаге это звучит хорошо, но на практике некоторые команды научились обходить систему: завышали оценки, переусложняли решения, чтобы выглядеть более продуктивными, и теряли из виду, создаёт ли их работа вообще ценность. Снова метрика становилась целью, а настоящая цель — поставлять результаты, важные для бизнеса, — уходила на второй план.

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

Количество в эпоху ИИ

Сегодня tokenmaxxing — тренд, при котором разработчики и команды оптимизируют потребление как можно большего числа токенов AI-модели, — трактует сырое потребление как эквивалент результата. На мой взгляд, это последняя ошибочная метрика продуктивности, пробравшаяся в мир разработки ПО. Tokenmaxxing — не более чем ещё одна vanity metric и столь же бесполезен, как использование «строк кода» или раздутых story points в качестве ориентира.

Tokenmaxxing — это результат нескольких разных моделей поведения, включая:

• Prompt flooding: запихивание огромных кодовых баз, документации и контекста в каждый prompt, тратя токены на контекст, который модели на самом деле не нужен.
• Agent swarms: запуск нескольких AI-агентов параллельно, чтобы максимизировать выпуск кода, независимо от того, согласована ли работа и насколько она связна.
• Background loops: непрерывное удержание AI-сессий или агентов в фоне, накапливая расходы на токены без ясного понимания, что именно производится — и зачем.

Не секрет, что AI меняет то, как разрабатывается программное обеспечение, и именно этим изменением объясняются такие практики. Передавать AI кодовые базы, запускать несколько агентов одновременно и даже полагаться на coding assistants — всё это может быть полезно. Но когда мы теряем контроль над тем, какие изменения вносим и зачем, мы снова сталкиваемся с той же старой проблемой в новой форме: измеряем продуктивность инженерии неправильными метриками.

Более полезный вопрос — не «Сколько токенов мы потратили?», а «Какую проблему мы действительно решили и для кого?»

Расход ресурсов без цели

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

Как CTO, я только за эксперименты с AI. Я хочу использовать его, чтобы делать наши программы лучше, сильнее и более готовыми к будущему. Чего я не хочу — так это чтобы он подталкивал нас к избыточности, оставляя при этом слишком мало видимого результата.

Тест, к которому я постоянно возвращаюсь, прост: помогает ли этот AI-сгенерированный результат выпустить что-то действительно важное? Снижает ли он трение для пользователя, закрывает ли пробел в workflow или повышает надёжность для клиента? Если ответ неочевиден, значит, мы тратим ресурсы — и человеческие, и вычислительные — без определённой цели. А это не инженерия. Это активность.

Spec-driven development: где определяется ценность

Пора внедрять более новые подходы, такие как spec-driven development — метод, в котором инженеры сначала пишут подробные спецификации, а затем AI генерирует код под них. Вместо того чтобы полагаться на prompt flooding и agent swarms и надеяться, что AI выдаст лучший результат, нам нужно сместиться к определению требований, ревью AI-generated output и управлению системами с намерением.

Но spec-driven development — это не просто методология. Это место, где одновременно определяется инженерное намерение и бизнес-ценность. Именно в спецификации вы отвечаете на вопрос: «Почему это важно и какую проблему мы решаем?» — ещё до того, как будет потрачен хотя бы один токен.

Разработчики давно гордятся умением писать элегантный код, и мне не хотелось бы, чтобы AI удешевлял эту гордость вместо того, чтобы усиливать её. В мире AI-first ремесло не должно исчезать; оно просто должно сместиться вверх по цепочке. Теперь элегантность живёт в спецификации, и она заслуживает того же внимания к деталям, которое раньше мы оставляли коду.

По сути, разработка ПО — это определение, анализ и решение технических задач. Если мы добровольно отдадим всё это AI, мы потеряем целостность дисциплины и способность доказывать свою ценность. Использовать максимум токенов, чтобы получить код, — не впечатляет. А вот использовать хорошо продуманный, осмысленный prompt для решения конкретной проблемы? Вот это работа, которую стоит отмечать.

Перестаньте изображать продуктивность и начните поставлять её

Мы находимся в точке перелома. Многие организации по умолчанию переходят к activity-based metrics, измеряя, сколько именно используется AI, а не то, улучшает ли он delivery, качество продукта или бизнес-результаты.

Вопрос, который действительно стоит задавать, — не «Сколько AI мы использовали в этом sprint?», а «Какую ценность мы принесли нашим пользователям, команде или бизнесу?» Это была возможность быстрее устранить критический баг? Сократить cycle time для высокоценной функции? Сделать customer workflow, который теперь занимает минуты вместо часов? Это и есть результаты. Именно их и стоит измерять.

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

—

New Tech Forum предоставляет площадку для технологических лидеров — включая вендоров и других внешних авторов — чтобы подробно изучать и обсуждать новые корпоративные технологии с беспрецедентной глубиной и широтой. Отбор субъективен и основан на нашем выборе технологий, которые, как мы считаем, важны и наиболее интересны читателям InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь присланный контент. Все запросы направляйте на doug_dineley@foundryco.com.

Материал — перевод статьи с английского.

Оригинал: From story points to tokenmaxxing: Why engineering keeps measuring the wrong things