Этот текст — своего рода дополнение / побочный квест к недавней серии. Он не вписался аккуратно в основную статью, поэтому я публикую его отдельно. На него кратко ссылаются в части 2 статьи Почему софтверные фабрики терпят неудачу: Снова включаем свет.
Поиск рычага
Ещё до появления ИИ только 25–50% времени на выпуск фичи уходило на написание самого кода. Остальное — согласование/планирование, ревью кода/доработка и тестирование/верификация решения.
Если вы используете ИИ только для написания кода, то вы сокращаете 2–4 часа написания кода до 10–20 минут, но всё остальное не ускоряется.
Но если вы используете ИИ для планирования и согласования, то на самом деле вы получаете ускорение примерно в 2–3 раза.
Правило 80/20 в рычаге ИИ для кодинга
Допустим, если вы наобум кидаете двухстрочный промпт в свою фабрику, вероятность получить полностью сливаемый результат составляет ~50%, а вероятность того, что придётся переделывать — 50%.
Теперь представим, что вы — ведущий инженер с 10-летним опытом. Вы загрузили всю кодовую базу из 100 репозиториев себе в голову. Поэтому вы тратите полдня на написание вручную идеально детализированной спецификации. Теперь ваши шансы лучше, но всё равно остаётся около 10% вероятности, что придётся переделывать \*что-то* существенное.
А на другом конце спектра: пишете каждую строчку сами. Агенту нечего испортить, так что вероятность переделки стремится к нулю.
\\примечание\\ В этом примере я буду смазывать
«вероятность того, что придётся что-то менять» с учётом «насколько болезненным будет изменение»
в единый процент, но, очевидно, это две разные переменные. Если модель с вероятностью 50% неправильно выберет стиль кнопки, но исправление — это один дешёвый промпт, то наша совокупная «ожидаемая боль» невелика.
ожидаемая боль = P(придётся менять) × насколько больно это изменение
Если это изобразить, то между затраченными upfront усилиями и ожидаемой болью существует обратная зависимость.
Чего не стоит делать — тратить 6 часов на планирование задачи, когда 80% ожидаемой боли можно было устранить за первые 10 минут.
Нужно делать это без чрезмерного упора на вопросы, на которые нельзя ответить, не спустившись на уровень ниже. Например, если вы уже поработали на уровне «Продукта» и ещё не ответили на все открытые вопросы, возможно, придётся остановиться на этом месте и спуститься на уровень технических деталей, чтобы понять, что вообще реализуемо. Идеального процесса для этого нет.
Именно это мы имеем в виду под рычагом — и для этого требуется прагматизм. Если вы проводите несколько этапов планирования, приближаясь с высоты 50 000 футов до 10 000 футов, на каждом этапе нужно немного корректировать курс, чтобы устранять как можно больше ожидаемой боли.
Удачи.
