Драбина виконавців: спершу дешево, підвищувати рівень лише з причиною

🪜 Ідея

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

У нас чотири рівня. Нульовий рівень — жодної моделі: лінтер, скрипт, запит до бази даних. Перший рівень — дешева модель для обсягу роботи. Другий рівень — модель середнього рівня для складніших одиничних завдань. Третій рівень — старший арбітр для рідкісного рішення.

🔑 Ескалація потребує причини

Крок вище за вхідний рівень дозволений лише з одним із п'яти кодів причини: не пройшла детермінована перевірка, два молодші прогони розійшлися в результатах, завдання є архітектурним рішенням, завдання торкається грошового шляху або оператор попросив. Будь-яку іншу причину відхиляють. «Про всяк випадок» у переліку немає, бо саме так дорогий виконавець і починає робити все.

Важливі дві деталі. Якщо завдання — це чиста перевірка, то невдала перевірка є фактом, а не приводом кликати старшого: скрипт сказав «ні», отже виправляйте причину. (Робота молодшого, яка не пройшла детерміновану перевірку, — це інший випадок, і він є однією з п'яти перелічених причин.) І причина потрапляє в трасування виклику, тож журнал може сказати не лише скільки коштувала ескалація, а й чому вона сталася.

📏 Стелі з вимірювань

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

🔬 Що показує журнал

Наш транспорт із обліком записує рівень і причину ескалації кожного виклику. На 3 листопада 2026, 21:53 UTC у ньому було 10 062 рядки першого рівня із загальною вартістю $15,76 і 32 рядки третього рівня вартістю $0,38. Другий рівень мав 0 рядків. 54 рядки не мають рівня; усі вони припадають на три хвилини 22 вересня 2026. Лише 18 рядків мають причину ескалації, усі — «запит оператора», і всі вони серед рядків першого рівня. Жоден із 32 рядків третього рівня не має причини.

Це прогалина в нашій власній практиці, знайдена під час написання цієї сторінки. Правило вимагає кодованої причини для старшого виклику, а журнал показує старші виклики без неї. Ми ще не простежили, чи ці виклики обійшли маршрутизатор, чи були записані до того, як поле почали перевіряти, і тут вгадувати не будемо. Урок: звіряйте власний журнал із власним правилом.

📉 Правило припинення

Ми заздалегідь визначили, що покладе край драбині. Ми рахуємо частку викликів другого й третього рівнів, які змінили результат. Якщо вона тримається нижче двадцяти відсотків протягом шістдесяти днів, драбина згортається до двох рівнів. Тоді старші виклики не окупають себе. Ми ще не зібрали достатньо ескалацій, щоб застосувати правило, і кажемо про це прямо.

🛠️ Практика: побудуйте власну драбину

1. Перелічіть свої класи завдань, наприклад перевірити файл, підсумувати тікет, відрецензувати дизайн.
2. Для кожного класу виберіть вхідний рівень і рівень стелі. Ставте нульовий рівень першим усюди, де рішення може ухвалити скрипт.
3. Запишіть закритий перелік причин ескалації. Тримайте його коротшим за шість пунктів.
4. Зробіть так, щоб маршрутизатор відхиляв будь-яку ескалацію без причини з переліку, і записував причину в трасування виклику.
5. Встановіть стелі вартості на виклик з найвищої вартості, яку ви справді бачили.
6. Виберіть правило припинення і дату до того, як почнете.

✅ Перевірте себе

• Попросіть старший виклик без причини. Маршрутизатор відмовить.
• Ви можете перелічити ескалації минулого тижня і причину кожної. Якщо старший виклик не має причини, ви знаєте чому.
• Невдалий прогін лінтера не запускає виклик моделі.
• Ви можете назвати частку старших викликів, які змінили результат, або сказати, що поки не можете.

🚧 Коли це не працює

• Занадто мало ескалацій. Правило про «частку, що змінила результат» потребує вибірки. Із таким малим числом записаних причин це лише тенденція.
• Причини, що стають звичкою. Якщо кожен виклик каже «архітектурне рішення», перелік стає прикрасою. Переглядайте причини щомісяця.
• Складні завдання, які складні з самого початку. Деякі класи мають входити на високому рівні. Пропишіть це в конфігурації.
• Дешевий рівень завдає шкоди. Дешева модель на завданні, що потребує судження, заощаджує мало, а коштує довіри.
• Драбина без журналу. Якщо ви не записуєте рівень і причину, ви нічого з неї не навчитеся.

📊 Докази

➡️ Далі

Порахуйте вартість рівнів у Витрати, бюджети та ліміти і подивіться, що змінює керування маршрутизацією, у Моделі та маршрутизація.

Джерела

• Витрати, бюджети та ліміти: бюджети на завдання.
• Моделі та маршрутизація: що змінює маршрутизація.
• Розподіл роботи між агентами, і коли цього робити не варто: рої агентів.
• Оцінювання AI: чому «воно каже, що готово» не є прийманням: приймання через перевірки.