"Чему AI-агенты могут научиться у C++ Мы недавно поняли, что давая агенту слишком много инструкций, мы его ""тупим"": буквально ограничиваем, а не помогаем. И недавно Jeff Dean, Chief Scientist в Гугле, запостил их гайд по оптимизации C++ и там несколько забавных параллелей c AI агентами (в том числе на тему ""делать тупее""): 1) Оптимизации, потерявшие актуальность В C++ оптимизации под старое железо начинают вредить на новом. Inline assembly из 2008 года сегодня медленнее нативного кода, потому что компилятор стал умнее. В агентах имхо похожее. К примеру, системный промпт Codex сократился на 66% при переходе с o3 на GPT-5: убрали инструкции как планировать, как работать с гитом, как валидировать, поскольку модель уже это знает. В ту же тему Anthropic в гайде по eval-ам пишет, что лучше оценивать, достиг ли агент цели, а не конкретный путь, которым он шёл. Цели > пошаговые инструкции. Кстати, сегодня выложили классный скилл по эвалам - рекомендую! 2) Односторонние ~~двери~~ решения Безос разделяет решения на обратимые и необратимые (""односторонние двери""). Jeff Dean упоминает эту же идею в контексте разработки. В уже упомянутом гайде от Anthropic выделяется 2 типа эвалов: - pass@k (хотя бы одна из k попыток успешна —> как генерация кода пока тесты не пройдут) - pass^k (каждая из k попыток должна быть успешной —> как отправка писем клиентам). Пример: агент шлёт 5 холодных сообщений, каждое с 90% шансом быть адекватным. Вероятность, что ВСЕ 5 ок: 0.9⁵ = 59%, то есть надёжность падает экспоненциально. Отсюда правило: необратимое действие (email, перевод денег) должно проверяться или человеком (human-in-the-loop) или детерминистически. Обратимое (черновик, анализ) - можно особо не париться, пусть фейлит тесты, пока не справится. 3) Агент ""падает"" до уровня своего harness-а Помните James Clear: ""Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем."" В C++ совет звучит так: не полагайтесь на чеклисты, закодируйте проверки в автоматизацию. Проверки до запуска (compile-time) > проверки после (runtime). По аналогии, агент не поднимается до уровня своего системного промпта, он падает до уровня своих ""подпорок"" (harness-а). В условном Claude Code можно настроить хуки - детерминистические проверки до и после каждого tool call: ```pre_tool_call: if tool == ""send_email"" and not draft_mode: reject(""Requires human approval"")``` Это compile-time проверки для агентов, которые не зависят от их ""настроения"" сегодня. 4) Numbers Every AI Engineer Should Know Jeff Dean когда-то составил таблицу временных затрат ""Numbers Every Programmer Should Know"". Я подумал, что прикольно будет ее адаптировать для AI агентов, что-то в стиле: ```Локальная БД: ~10 мс Чтение файла: ~50 мс Поиск по коду (grep): ~100 мс Vector/embedding поиск: ~100 мс Облачная БД: ~100 мс LLM (Haiku/Flash): ~1 с / ~$0.001 LLM (Sonnet 4.6 / GPT-5.2): ~3 с / ~$0.005 Web search API: ~2 с / ~$0.005 Web page fetch: ~3 с / ~$0.01 LLM (Opus 4.6): ~4 с / ~$0.01 LLM (Sonnet 4.6 + reasoning): ~15-30 с / ~$0.03 LLM (Opus 4.6 + extended thinking): ~30-60 с / ~$0.10 Мульти-агент (10 turns, Sonnet 4.6): ~3 мин / ~$0.50 Ревью человеком: минуты-часы / $$``` Диапазон: от 10мс до часов ~6 порядков. И тот же вывод, что у Dean-а: знай, где твоё узкое место: если агент делает 10 вызовов Opus, когда хватило бы 1 Opus + 9 Haiku — ты переплачиваешь 10x и по времени, и по деньгам. Особенно, если ретрай допустим (см. pass@k пункт выше) === Итого: - С каждым апгрейдом модели - (потенциально) подчищаем промпты - Выделяем действия агента на обратимые vs необратимые, ставим human in the loop в последних - Добавляем детерминистические проверки, чтобы не дать агенту делать ненужные ошибки - В голове и на бумажке прикидываем стоимость операций - не используем ли мы условный Opus там, где хватит Haiku? Кстати, надо сделать skill на эту тему наверное, м?"