В AI Builders сейчас 29 открытых глав из 58 запланированных, разложенных на десять частей. Читать подряд можно, но обычно не нужно: у вас уже есть конкретная фича в конкретном состоянии, и полезны главы про следующий шаг, а не про предыдущие.
В учебнике для этого есть шкала зрелости. Она сформулирована вопросами о системе, а не о человеке: уровень определяет не ваш стаж, а то, что сейчас лежит в репозитории.
Уровень 1. Умеет ли система вызвать модель и получить текст
Признаки: ключ провайдера в переменных окружения, один запрос, ответ печатается в лог или прилетает в чат. Работает на ноутбуке, показывали коллегам.
Здесь важно понять одну вещь, и она есть в первых главах: вызов API — это ещё не интеграция. У вас пока нет фичи, у вас есть доказательство, что провайдер отвечает.
Дальше идут части про уместность модели: где задача решается регуляркой и справочником, а где действительно нужна LLM. Пропустить их дороже всего — именно отсюда растут проекты, которые потом не доезжают до прода.
Уровень 2. Переживает ли вызов ошибку и отдаёт ли ответ потребителю
Признаки: код уехал в сервис, есть ручка или задача в очереди, кто-то в компании уже этим пользуется. И первый инцидент: провайдер ответил пятисоткой, задача упала, пользователь увидел спиннер до бесконечности.
Ваш блок — протокол и контракты. Что именно вы ждёте от модели, как это описано схемой, что делает система, когда пришёл валидный JSON с бессмысленным содержимым. Ретраи и таймауты: чем отличается ретрай, который спасает, от ретрая, который утраивает счёт. Фон и очередь: почему синхронный вызов модели в HTTP-ручке — это отложенная авария.
Здесь же появляется бюджет. Не «сколько стоит тысяча токенов», а сколько стоит одно обращение вашего пользователя и что происходит с системой, когда месячный лимит кончился двадцатого числа. Отдельно про это — разбор счёта по пяти статьям.
Уровень 3. Где в этой фиче модель не нужна, а вы её всё равно ставите
Признаки: фича работает, ей пользуются, но качество плавает, а стоимость растёт быстрее пользы. Появляется вопрос, на который в компании нет ответа: а стало ли лучше?
Это самый неудобный уровень, потому что чинить надо не код, а решение. Части про сокращение зоны модели: выносим детерминированное в код, оставляем модели только то, что действительно требует языка. Каждый вынесенный кусок — минус деньги, минус задержка, минус источник галлюцинаций.
Дальше — тестирование недетерминированной системы. Обычные тесты тут не работают: два одинаковых запуска дают разный результат. Нужны evals, набор размеченных случаев и порог, ниже которого версия не выкатывается. И метрика, записанная до начала работы, а не подобранная потом под удобный результат.
Уровень 4. Может ли команда показать контракт, evals, fallback, бюджет, правила безопасности и логи одной версии
Признаки: на этот вопрос у вас есть ответ, и он занимает меньше пяти минут.
Если каждый пункт лежит у другого человека и собирается неделю — вы не на четвёртом уровне, каким бы зрелым ни выглядел проект снаружи. Это нормальное состояние большинства команд.
Здесь части про эксплуатацию: версионирование промптов и моделей как обычного кода, поведение при смене версии у провайдера, разбор инцидента с ответом «почему система решила так», правила безопасности и границы того, что уходит наружу — с оглядкой на 152-ФЗ.
Как это использовать
Откройте ai.potapov.me, прочитайте четыре вопроса и честно ответьте на них про свою фичу. Не про ту, что в планах на квартал, а про ту, что в репозитории.
Первый вопрос, на который ответ «нет», и есть ваша точка входа. Оттуда и читайте.
Если по дороге найдёте главу, которая противоречит вашему опыту, — напишите об этом в канал сообщества @ai_builders_ru. Замечания попадают в текст: он для того и открыт.
