Перейти до основного вмісту

Частина 6: Контролюйте вартість

Типове питання про AI-розробку — «як швидко ми можемо випускати?» Краще питання — «скільки коштує це підтримувати?» Швидкість приховує реальну економіку. Чесна метрика — сукупна вартість володіння, і в AI-робочому процесі вона визначається одним: токенною економікою.

Прихований борг від швидкості​

Безсистемні промпти виглядають майже безкоштовно — підписка й кілька випадкових запитів, майже нульова початкова вартість. Рахунок приходить пізніше, і він накопичується:

  • Витрата токенів. Скидання величезних неструктурованих файлів у контекстне вікно й прохання моделі виправити власні неперевірені помилки створює дорогий цикл повторних спроб із низькою успішністю першого проходу. Кожна невдала спроба — витрачені токени ні за що.
  • Податок на підтримку. Неструктурований генерований код позбавлений узгодженості. Через шість місяців інженер витрачає дні на зворотне проєктування «спагеті», яке ніхто не проєктував.
  • Ліквідація вразливостей безпеки. Без харнесу оцінювання швидка генерація коду стає швидкою генерацією вразливостей. Виправлення дефекту в продакшні коштує набагато більше, ніж його виявлення на стадії проєктування.

Структурований підхід перевертає це: ви інвестуєте заздалегідь у схеми, тести й контекст, і гранична вартість випуску й підтримки кожної функціональності різко знижується. Вища вартість побудови, але значно нижча вартість володіння.

Важіль перший: успішність першого проходу​

Найдешевший токен — той, який ви не витрачаєте на повторну спробу. Щільний, насичений сигналом файл правил (частина 1) і добре керований контекст (частина 2) підвищують успішність першого проходу агента, що безпосередньо скорочує цикли «спроба-і-помилка», що спалюють гроші. Інженерія контексту — це не лише практика якості, а й практика контролю витрат. Той самий щільний CLAUDE.md, що покращує результат, також скорочує витрати.

Передавати цілий репозиторій на 100 000 токенів у кожен промпт фінансово нежиттєздатно у масштабі. Отримуйте релевантне; платіть за те, що використовуєте.

Важіль другий: маршрутизація за завданням​

У безсистемному робочому процесі ви використовуєте одну велику фронтирну модель для всього — платите преміальні ціни за виправлення друкарської помилки або генерацію шаблонного тесту. Спроєктований робочий процес маршрутизує за складністю завдання:

  • Архітектура, складний дизайн → Фронтирна модель — потрібне максимальне міркування
  • Початкова складна реалізація → Фронтирна модель — висока ставка, неоднозначність
  • Генерація тестів → Маленька/дешева модель — детермінована, чітко специфікована
  • Рев'ю коду (перший прохід) → Маленька/дешева модель — розпізнавання патернів
  • Перевірки CI/моніторинг → Маленька/дешева модель — повторювані, вузькі

Простий конфіг маршрутизації унаочнює це:

routing:
  default: small-fast
  rules:
    - match: ["architecture", "design", "migration plan"]
      model: frontier
    - match: ["write tests", "lint", "review diff", "ci check"]
      model: small-fast
    - match: ["implement feature"]
      model: frontier

Оркестрація мультимодельної суміші дозволяє підтримувати якість результату там, де це важливо, знижуючи вартість детермінованої більшості роботи.

Важіль третій: динамічний контекст і навички​

Повернімося до частини 2. Завантаження всього статично означає оплату при кожному виклику. Перенесення специфічних для завдань знань у навички, що завантажуються на вимогу, — і звернення до інструментів через виклики на вимогу, а не запікання всього в промпт, — тримає корисне навантаження кожного запиту невеликим. У масштабі різниця між «все завжди завантажено» і «лише необхідне» — це різниця між життєздатною структурою витрат і нежиттєздатною.

Опрацьована інтуїція​

Припустімо, успішність першого проходу зростає з 40% до 80% після інвестицій у файл правил і кілька навичок. Завдання, яким раніше потрібно було ~2,5 спроби, тепер потребують ~1,25. Це вдвічі менше токенів за той самий результат — ще до того, як ви направили хоч одне завдання на дешевшу модель. Додайте маршрутизацію (дешеві моделі обробляють генерацію тестів і рев'ю, що може становити половину ваших викликів) і крива операційних витрат різко згинається.

Налаштуйте власний робочий процес​

  • Перестаньте вимірювати лише швидкість; починайте відстежувати витрату токенів на випущену функціональність.
  • Удосконалюйте файл правил саме для підвищення успішності першого проходу й усунення циклів повторних спроб.
  • Налаштуйте маршрутизацію моделей: дешеві моделі для генерації тестів, рев'ю і CI; фронтирні для архітектури та складної реалізації.
  • Переносьте специфічний для завдань контекст у навички на вимогу, щоб не платити за нього при кожному виклику.
  • Порівнюйте вартість на функціональність до і після — початкові інвестиції мають проявлятися у зниженому поточному рахунку.