AI-асистенти для написання коду дуже балакучі. Іноді це корисно: вони пояснюють, що і чому змінили, які файли зачепили та які припущення зробили. Але часом це просто купа зайвих слів навколо дрібної правки. Нещодавно я натрапив на скіл під назвою «Caveman».
Ідея проста: змусити асистента спілкуватися короткими «печерними» реченнями. Менше пояснень, жодних довгих абзаців чи ввічливих відступів. Теоретично це має економити токени, адже ШІ витрачає менше часу на опис своїх дій.
Це виглядає приблизно так:
Me inspect files.
Me change request.
Me run tests.
Tests pass.
Замість цілого полотна тексту про план імплементації та потенційні ризики.
Менше слів, більше коду?
Коли працюєш з AI-асистентами весь день, помічаєш, скільки токенів іде на «спілкування» навколо коду. Часто це потрібно — наприклад, щоб зрозуміти, чому тест впав. Але іноді це втомлює. Особливо, коли ти добре знаєш свій codebase, чітко розумієш задачу і просто хочеш, щоб асистент виконав роботу.
Я вирішив перевірити, чи зробить Caveman мого агента (останнім часом я частіше використовую Codex замість Claude, оскільки вважаю його «темною конячкою» з кращим ROI) дешевшим або ефективнішим у реальній роботі.
Чи вдалося зекономити токени?
Так, але не так суттєво, як я очікував.
Причина проста: коли ви використовуєте Claude для кодингу, більшість токенів витрачається не на пояснення. Основний обсяг іде на читання файлів, аналіз контексту, генерацію коду, застосування diffs та перевірку результатів.
Навіть якщо асистент замість розлогого речення напише:
Me fix bug.
Йому все одно потрібно написати сам код. Файли все одно мають бути прочитані. Відповідь все одно містить назви функцій, namespaces, imports та тести. Тобто Caveman скорочує «балачки», але кодинг — це не лише розмови. Документація Caveman обіцяє економію до 65% токенів, і в певних сценаріях це можливо. Проте в моїх завданнях реальна економія склала від 5% до 20% залежно від складності таска.
Чи було це корисно?
Думаю, так. Мені не потрібні розлогі пояснення кожного кроку асистента. Я все одно перевірятиму код, тому стислий звіт допомагає швидше перейти до рев'ю.
Me update DTO.
Me add missing nullable field.
Me run Pint.
All good.
Крім того, переглядати такий вивід просто весело. Є щось кумедне в тому, як асистент описує Laravel refactor так, ніби він щойно винайшов вогонь.
Де це працює гірше
Для складних завдань і стратегічного планування я все ж віддаю перевагу нормальним поясненням (тут я щиро рекомендую skill «grill-me» від Matt Pocock).
Якщо правки зачіпають кілька частин системи, змінюють логіку поведінки або мають компромісні рішення — я хочу бачити аргументацію. Стиль печерної людини — це смішно, але його замало, коли треба зрозуміти складний архітектурний вибір.
Важливо розрізняти відсікання зайвих слів та втрату корисного контексту. Іноді саме «зайві» пояснення допомагають вчасно помітити хибне припущення асистента.
Чого я навчився
Скіл Caveman — чудовий приклад того, як мінімальні зміни в стилі комунікації впливають на досвід роботи з ШІ. Він робить дрібні завдання «легшими», а процес рев'ю — значно веселішим.
Це доводить, що скіли не обов'язково мають бути складними автоматизаціями. Іноді достатньо просто змінити манеру поведінки асистента, щоб це стало корисним інструментом.
Чи залишу я його для швидких тасків? Однозначно.
Me like skill. Skill good.
