Обучение · Агенты и вайб-кодинг

Глава 9. Выбор модели, уровень усилий и оценка сроков

Перед каждой задачей принимаются два решения, о которых обычно вообще не думают: какой моделью и на каком уровне усилий. Оба стоят денег, оба влияют на результат, и оба принимаются за секунду, если есть критерий.

Третья тема главы, оценка сроков, стоит рядом, потому что вопрос сколько это займёт задают ровно в тот же момент.

Модель выбирается по типу неопределённости Формула, которая ходила в разговорах в разных вариантах, но всегда про одно.

Что ты знаешь о задаче Какая модель

Путь известен, проверка сильная, риск низкий Самая дешёвая

Цель ясна, а как решать, надо придумать Средняя

Непонятно даже, в чём именно задача Старшая

Другая формулировка того же, ещё короче: задачу можно поручить даже школьнику, бери младшую модель. Понимаешь, как решить, и нужна просто пара рук, бери среднюю. Тебе самому хуй проссышь, что делать, бери старшую.

ГЛАВНОЕ ПРО ВЫБОР МОДЕЛИ Ты платишь не за ум, а за неопределённость. Старшая модель нужна там, где надо придумать, а не там, где надо сделать. Отсюда самая частая ошибка новичка: берёт лучшую модель на всё подряд и потом хватается за сердце от счёта. И самая частая ошибка опытного: берёт дешёвую на задачу, где надо придумать, и полдня с результатом бодается.

Уровень усилий это бюджет, а не шкала ума Второе решение путают чаще первого. Многие уверены, что уровень повыше означает модель поумнее. Хуй там: модель та же самая, ей просто разрешают потратить больше на обдумывание.

Отсюда следует, что уровень подбирают под размер задачи, а не под её важность.

Выбор модели, уровень усилий и оценка сроков

ЧТО ПРОИСХОДИТ ПРИ НЕВЕРНОМ УРОВНЕ

Уровень усилий не совпал с задачей

Слишком высокий Слишком низкий

доёбывается до запятых, гоняет одну мысль по кругу срезает углы, выдаёт недоделанное

Признак завышенного уровня видно сразу: вчитайся в рассуждения, и станет заметно, что одна и та же мысль ходит по кругу. Люди, которые читают рассуждения, замечают это первыми и спускаются на ступень ниже.

Признак заниженного тоже узнаваемый: работа сделана, но по краям. Ровно то, что просили буквально, и ни хуя вокруг.

Отдельно стоит знать, что одинаковые настройки в разных инструментах дают разное. У одного человека субагенты запускаются только на максимальном уровне, у другого приходится специально запрещать, иначе плодятся как тараканы. Переносить чужие настройки бессмысленно, подбирай у себя.

Разделение ролей между моделями Практика, устоявшаяся у людей, которые работают с этим каждый день: разные этапы отдают разным моделям.

Спецификацию пишет одна. Реализацию по готовой спецификации другая, попроще. Поиск ошибок и ревью третья.

Причины называют конкретные. Одна модель пишет честный рабочий код, но в проектировании агентов и написании инструкций хуёвая. Другая работает очень долго и её приходится ловить за руку, зато копает глубже. Третья лучше всех находит корневые причины.

СТОИТ ЛИ ГОРОДИТЬ ТАКУЮ СХЕМУ За. Экономия. Схема, где сильная модель планирует и принимает, а дешёвая исполняет, замедляет работу примерно втрое и кратно снижает расход лимитов. Против. Сложность. Переключения, разные форматы, разное поведение. На одном проекте терпимо, на пяти превращается в отдельную работу. Обязательное условие для обеих позиций. Ревью самого плана. Слепые зоны есть всегда, и если план не проверен, вся экономия улетает в переделки.

Отдельная тонкость, замеченная практиками: сильная модель работает хорошо, когда контекст ей собрали, и хуёво, когда собирать его она должна сама. Ещё один аргумент за разделение: сборка контекста и принятие решений это разные умения.

Выбор модели, уровень усилий и оценка сроков

Оценка сроков Вопрос, который задают руководители и на который у модели честного ответа нет.

Причина фундаментальная: модели нечем измерять время. Она не устаёт, не спит и не умрёт. Всё, что она скажет о сроках, это пересказ того, как подобные задачи оценивали люди в её обучающих данных.

Отсюда две позиции.

Радикальная. Любое упоминание сроков от модели считать пиздежом и попыткой заболтать. Позиция честная, но бесполезная, если начальству нужна цифра.

Рабочая. Использовать модель как калькулятор, а точку отсчёта задавать самому.

КАК ПОЛУЧИТЬ ОЦЕНКУ, КОТОРОЙ МОЖНО ПОЛЬЗОВАТЬСЯ 1. Разбей работу на этапы до нужной детализации. 2. Обязательно включи в разбивку хотя бы один этап, длительность которого ты знаешь из опыта. 3. Попроси оценить этапы, предупредив: исполнителем будет один инженер с агентом, и в компании принят такой-то коэффициент ускорения относительно обычной разработки. 4. Посмотри на контрольный этап. Модель дала четыре дня там, где ты точно знаешь, что три, скажи об этом и попроси пересчитать все остальные пункты с тем же коэффициентом. 5. Полученную цифру считай оценкой порядка, а не обещанием.

Контрольный этап это вся суть приёма. Он превращает выдумку в масштабируемый коэффициент.

И напоминание, которое стоит держать в голове при любых оценках: работа заполняет отпущенное на неё время. Дашь две недели, задача займёт две недели независимо от того, сколько она реально требовала.

Честная картина Как это выглядит в жизни: чаще всего вопрос звучит не сколько это займёт, а как уместить в две недели то, что туда заведомо не лезет. Модель тут не помощник, она помощник в другом: разложить работу так, чтобы стало видно, что именно придётся выбросить нахуй.

Это, кстати, лучший способ применения оценки. Не назвать срок, а показать состав.

Что запомнить Модель выбирается по типу неопределённости: сделать, придумать как, понять что.

Уровень усилий это бюджет в токенах. Завышенный даёт придирки и хождение по кругу, заниженный срезанные углы.

Чужие настройки не переносятся. Проверяй у себя, особенно поведение субагентов.

Выбор модели, уровень усилий и оценка сроков

Разделение ролей между моделями окупается расходом, а не качеством, и требует ревью плана.

Модели нечем измерять время. Дай ей контрольный этап, длительность которого знаешь сам, и пересчитай остальное по коэффициенту.

Модуль 3. Обвязка Пять глав про инструкции, скиллы, хуки и инструменты.

Сначала о том, что писать в файл правил и как писать, чтобы правило реально исполнялось, а не висело мёртвым грузом. Потом о скиллах: как они устроены, как протухают и во что обходятся. Потом о хуках, единственном способе гарантировать шаг. И в конце глава о том, когда всю эту конструкцию пора расхуячить нахуй.

Последняя глава модуля важнее первых четырёх.

← Диалог, который превращается в план · оглавление · Файл правил →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.