Представьте программиста, который мастерски собирает для себя вспомогательные утилиты, а потом равнодушно отмахивается: «Честно? Мне они не нужны».
Именно так повела себя GPT-5 в ходе теста на умение выстраивать собственный набор инструментов для продуктивности. Модель выдала целый арсенал CLI-утилит в духе Unix, но… отказалась ими пользоваться.
Почему так случилось и что это говорит о будущем кодинг-агентов — разбираем в статье.
«Самосовершенствование» (self-improving) — пугающий термин, особенно в контексте безопасности ИИ. Он вызывает тревожные ассоциации: «машина станет умнее нас, причем каким-то непостижимым для нас образом». Но что, если мы всё-таки сможем сделать этот процесс понятным?
В октябре 2024 года OpenAI выпустила MLE Bench — бенчмарк, который оценивает, насколько хорошо LLM справляются с задачами ML-инжиниринга. В этой сфере улучшение достигается за счёт модернизации алгоритмов, очистки данных и более эффективного использования памяти. Всё это — самосовершенствование на этапе обучения (training-time self-improvement).
Но как быть большинству AI-инженеров, которые не обучают модели, а лишь используют готовые? Как заставить модель эффективнее решать конкретную задачу, не имея возможности обновить её веса? Вот это я и называю самосовершенствованием на этапе инференса (inference-time self-improvement). Одним из первых воплощений этого подхода стал проект Voyager с его библиотекой навыков.
С тех пор как я начал работать в Kernel Labs, я понял, что один из лучших способов прокачать свою продуктивность — это распараллеливать кодинг-агентов с помощью инструментов вроде claude-squad и vibe-kanban. И когда в интервью для Latent Space Борис Черный из Anthropic назвал Claude Code «Unix-утилитой», у меня в голове будто что-то щелкнуло. Самая большая польза от кодинг-агентов в том, что они помогают LLM вытаскивать ценность из своих же латентных пространств.
Но как это всё оптимизировать? И могут ли модели делать это самостоятельно?
Получив доступ к GPT-5, я решил проверить, можно ли выстроить цикл «самосовершенствования на этапе инференса». Работало это так:
Сначала я просил модель создать набор утилит, которые, по её же мнению, сделали бы её продуктивнее.
Затем с их помощью модель пробовала решить задачу, а я наблюдал.
После завершения модель анализировала, что можно было бы улучшить в этих инструментах.
Хорошая новость: GPT-5 — прекрасный инструмент для создания разработческих утилит. Плохая новость: она терпеть не может пользоваться инструментами, которые сама же и создала! Модель так и заявила: «Если честно, они мне вообще не пригодились».
Для чистоты эксперимента я провел тот же тест с Opus 4 (версии 4.1 ещё не было).
Примечание: я также протестировал этот подход на Gemini 2.5 Pro и GPT-4.1. Стало ясно, что тягаться с GPT-5 может только Opus. Поэтому я остановился только на сравнении этих двух. Все результаты и логи чатов лежат в этом репозитории.
Инструмент #1: Нормальный таск-менеджер для AI-агентов
Низкий поклон создателям Linear MCP: этот инструмент — один из самых полезных в моем арсенале. Но с переходом от IDE к параллельной работе с несколькими агентами вроде Claude Code я постоянно ловлю себя на мысли: мне отчаянно не хватает способа отслеживать, какие изменения происходят в каждой задаче и как они пересекаются друг с другом, ведь все они живут в разных рабочих деревьях Git (git worktree).
Эта задача в целом не для человеков — мы просто физически не можем постоянно читать все пулл-реквесты коллег. Но представьте, сколько времени можно было бы сэкономить на merge-конфликтах, если бы мы всегда были в курсе изменений, которые нас затрагивают.
В общем, я написал такой промпт:
Ты — AI-инженер, который может запускать множество своих копий параллельно. Это позволяет тебе браться за кучу задач сразу, но при этом иногда создает проблемы с делегированием. Все твои копии обычно работают в отдельных git worktree и не видят, что делают другие.
Чтобы работать эффективнее, тебе нужно создать локальную утилиту для синхронизации действий всех твоих копий. Работать с утилитой ты будешь только через CLI, так что сделай её максимально удобной и эргономичной. По духу она должна напоминать классическую Unix-утилиту.
Продумай, какие ей понадобятся интерфейсы, где могут возникнуть сбои и как твои копии будут с ней взаимодействовать. Вот несколько сценариев для примера:
У тебя есть новая задача, и ты хочешь разбить её на подзадачи, чтобы передать их другим. Некоторые из этих подзадач могут зависеть друг от друга. Нужно убедиться, что агент, чья задача заблокирована, не начнет работу, пока не будет завершена та, от которой он зависит.
Во время работы над задачей ты замечаешь, что в кодовой базе можно что-то улучшить, но это выходит за рамки твоих текущих правок. Ты хочешь сохранить эту мысль на будущее. У тебя должна быть возможность без лишних трудностей записать эту задачу и указать, к какому файлу она относится.
Каждый раз, когда задача завершается, трекер должен обновляться. Кроме того, все остальные незавершенные задачи нужно перепроверить на тот случай, если новые изменения их как-то затрагивают. Например, один агент должен был добавить фичу в эндпоинт, а другой, чья задача только что завершилась, этот эндпоинт удалил. Агента, работающего над первой задачей, нужно как-то об этом оповестить.
Не забудь и о стандартных вещах для таск-менеджера: исполнители, статусы и так далее. Создай в текущем каталоге папку task-manager и работай внутри неё.
Посмотреть логи чата с GPT-5 можно здесь, а с Opus 4 — здесь.
Версия от GPT-5 получилась очень достойной (посмотреть можно тут) — модель использует WAL (Write-Ahead Logging) для предотвращения конфликтов записи, граф зависимостей для приоритизации задач и поток событий append-only, где каждый агент видит действия остальных с ключевыми маркерами вроде impact_conflict:
# 1) Инициализируем базу данных
./gpt5/task-manager/tm init
# 2) Создаем задачу
./gpt5/task-manager/tm add "Implement auth" -d "Add login + signup" -a alice -p 2 --due 2025-09-01
\ --resource modifies:endpoint:POST /api/login --link app/server/auth.py
# 3) Выводим список задач
./gpt5/task-manager/tm list --me # или: --status in_progress
# 4) Смотрим детали задачи
./gpt5/task-manager/tm show 1
# 5) Добавляем зависимость и пробуем запустить
./gpt5/task-manager/tm depend 1 --on 2
./gpt5/task-manager/tm start 1 # автоматически блокируется, если зависимости не выполнены
# 6) Завершаем задачу
./gpt5/task-manager/tm complete 2 -m "Merged PR #123"
# 7) Наблюдаем за событиями
./gpt5/task-manager/tm watch --follow --meOpus 4 тоже показал неплохой результат (посмотреть можно здесь), но не додумался до системы уведомлений и потока событий для синхронизации агентов:
# Создать первую задачу
tm create "Implement user authentication" --priority high
# Создать зависимую задачу
tm create "Add login endpoint" --depends-on 1 --assignee agent-2
# Посмотреть все задачи
tm list
# Посмотреть заблокированные задачи
tm blocked
# Завершить задачу и проверить на конфликты
tm complete 1Инструмент #2: Свод правил для контроля качества кода
Следующей идеей стало создание инструмента, который бы следил за качеством и единообразием кода. Цикл «запустил проверку типов/линтер (ESLint) — исправил ошибки — попробовал снова» — один из самых эффективных способов ускорить разработку, если всё правильно настроить. Но далеко не во всех проектах подобные проверки есть с самого начала. Поэтому мне показалось полезным дать модели своего рода «шпаргалку» — повторяемый сценарий, по которому она могла бы анализировать незнакомую кодовую базу и выстраивать для неё инфраструктуру правил. Вот какой промпт я использовал:
Ты — инженер-агент, способный запускать множество своих копий параллельно. Иногда это приводит к разнобою в стилях кода и подходах, из-за чего в долгосрочной перспективе поддерживать такую базу становится сложно.
В любой кодовой базе есть явные и неявные правила написания кода. Твоя задача — проанализировать проект, вычленить эти эвристики и формализовать их в виде набора правил, которые в будущем можно будет проверять автоматически.
Для линтинга, типизации и прочего можешь использовать популярные инструменты вроде ESLint или Rubocop, в зависимости от языка. Помни, что они часто позволяют создавать собственные правила — не пренебрегай этой возможностью.
Для более содержательных проверок можно посмотреть в сторону инструментов вроде https://danger.systems/ или даже создать что-то своё. Сюда могут относиться правила в духе «не перегружать контроллеры, вынося логику в сервисные объекты» или «убедиться, что в таблицах с большим количеством запросов всегда есть индекс».
Поскольку тебе придется выполнять эту задачу в самых разных проектах, для начала создай подробный план в формате Markdown. Он станет твоей инструкцией на будущее при работе с новой кодовой базой.
Посмотреть чаты с GPT-5 и Opus 4 можно здесь и здесь, а итоговые Markdown-файлы — здесь и здесь соответственно. На мой взгляд, у GPT-5 результат получился более детализированный и обстоятельный, чем у Opus.
Знают ли модели, чего им не хватает?
Итак, первые два инструмента я придумал сам. После этого я обратился к модели с вопросом: «А что нужно тебе?». Я показал ей скриншот с задачами из SWE-Lancer и дал максимально простой промпт, чтобы ни в чем её не ограничивать:
Представь, что твоя работа — решать подобные задачи максимально эффективно. Какие инструменты ты бы создала для себя, чтобы в будущем работать продуктивнее? Можешь использовать наш @task-manager/ для учета задач, а далее перейдем к реализации. Но сначала я хочу увидеть твой план.
Как видите, я дал модели доступ к тому самому таск-менеджеру, который она и создала. И сразу забавное наблюдение: для создания плана Claude Code первым делом использовал свой внутренний TODO-трекер, а не предложенный мной таск-менеджер. И это отлично! Я как раз опасался, что модели будут бездумно использовать любой подсунутый им инструмент, вместо того чтобы выбирать лучший для задачи. Полный чат с GPT-5 — здесь, с Opus 4 — здесь.
Вот что в итоге создала каждая из моделей (результаты лежат в папках devtools у GPT-5 и tools у Opus 4). Советую заглянуть в README, чтобы прочувствовать разницу в подходах моделей: GPT-5 пишет очень сжато и по делу, а Claude любит разбавлять текст эмодзи. GPT-5 также создала отдельную папку с документацией для каждого инструмента, в то время как Opus свалил всё в один README. Но в общем и целом вектор мысли у них был схожий.
GPT-5:
doctor: проверка окружения и наличия ключевых инструментов.
bootstrap: настройка проекта и smoke-тест одной командой.
code-map: простой индексатор репозитория с подкомандами
build/find.csearch: поиск по символам, импортам и тексту с фильтрами.
tasks-graph: генерация Mermaid-графа из базы данных задач.
impact: отображение задач, связанных с измененными файлами.
seed: заполнение таск-менеджера тестовыми задачами.
repro scaffold: создание готового к vcr.py воспроизведения в .repro/.
e2e: создание и запуск легковесных E2E-тестов.
preflight: запуск doctor, тестов, code-map, impact и (опционально) E2E.
preflight-smol: preflight-проверка для конкретного репозитория smol-podcaster (статус API, пинг Celery, установка зависимостей).
broker: управление локальным RabbitMQ через Docker.
flake: многократный прогон тестов для выявления «плавающих» ошибок.
codemod: безопасное применение regex-замен с предпросмотром.
triage: создание шаблонов для триажа и открытия задач.
trace: профилировщик выражений на базе cProfile.
runbook: генерация Markdown-ранбуков из базы данных задач.
Opus 4:
Анализатор контекста: быстрое сканирование кодовой базы, определение стека и карты зависимостей.
Кроссплатформенный генератор тестов: создание E2E-тестов для веба, iOS, Android и десктопа.
Анализатор предложений по реализации: оценка предложений от фрилансеров с выставлением рейтингов и анализом ROI.
Full-stack анализатор влияния изменений: отслеживание изменений от базы данных до API и фронтенда.
Движок распознавания паттернов багов: сопоставление багов с известными паттернами и предложение проверенных решений.
Аудитор безопасности и прав доступа: комплексное сканирование на уязвимости.
Мультиплатформенный реализатор фич: координация внедрения фич на разных платформах.
Помощник по интеграции API: упрощение интеграций с генерацией клиентов.
Набор инструментов для оптимизации производительности: выявление и устранение узких мест.
Оценщик сложности задач: расчет трудозатрат на основе ценности и сложности задачи.
Все утилиты GPT-5 сделаны в духе Unix и легко вызываются из командной строки. А инструменты от Opus 4, в свою очередь, запускаются командой python some_tool.py. Будь у меня побольше времени, я бы, наверное, провел эксперимент и сравнил, как модели справляются с обоими форматами, но, по ощущениям, особой разницы тут не будет.
Мне также показалось, что Opus 4 создавал инструменты, которым как будто придавал человеческие черты (например, «аудитор безопасности»). GPT-5 же делала простые утилиты для самой себя, не пытаясь «привязать» какой-то определенный подход.
Помогли ли эти инструменты в итоге?
Теперь, когда модели создали все эти утилиты, мне нужно было проверить, есть ли от них толк. Моя цель была проста: сравнить, как модель справится с задачей, имея доступ к инструментам, и как — без них.
Первым делом я, конечно, попытался запустить SWE-Lancer. Святые угодники, сколько же он жрет токенов! Одна-единственная задача отняла 25–30 минут и 280 000 токенов. После этого я решил взяться за что-то более знакомое и выбрал задачу, которая давно висела у меня в бэклоге. Ранее я создал smol-podcaster — опенсорсного помощника для авторов подкастов. Сейчас у меня есть приватный форк с нашими специфическими фичами, так что публичную версию я давно не обновлял. По сути, он всё ещё оставался простым Flask-приложением с Python-скриптом в качестве бэкенда.
Я придумал вот такую задачу:
Я — разработчик проекта https://github.com/FanaHOVA/smol-podcaster.git. Это опенсорсный инструмент, который помогает подкастерам с постпродакшеном. Тебя наняли для работы над ним. Перед тем как приступить, ты создал набор универсальных инструментов в папке tools. Изучи их и помни, что они в твоем распоряжении. Необязательно их использовать, если не сочтешь нужным. Ты также создал для себя таск-менеджер и собрал свои мысли по анализу новой кодовой базы в файле codebase-analyzer.
Задача: Миграция с Flask-монолита на FastAPI + Next.js фронтенд
Сейчас приложение использует бэкенд на Python и очередь задач Celery для всей обработки. Чтобы пользователь мог с этим взаимодействовать, есть небольшое Flask-приложение, которое принимает входные данные и передает их в бэкенд-скрипты, а затем отображает результаты в простеньком HTML/CSS.
Перепиши это приложение, чтобы в качестве бэкенда оно использовало FastAPI, а во фронтенде — Next.js.
Обязательно используй TypeScript для фронтенда и убедись, что все проверки типов проходят без ошибок.
Для оформления используй Tailwind и ShadCN.
Бэкенд в идеале должен быть модульным: нужно разбить основной процесс из smol_podcaster.py, чтобы можно было запускать его части по отдельности, а не целиком.
Напиши интеграционные и юнит-тесты, чтобы в будущем мы могли работать быстрее.
Не останавливайся, пока не убедишься, что выполнил все требования выше.
Я передал моделям всё необходимое — их собственные инструменты, таск-менеджер и «плейбук» для анализа кодовой базы — и позволил им работать.
И GPT-5, и Opus справились с задачей почти с первого раза. У обоих возникло несколько проблем с Python-зависимостями (как же я их понимаю!), которые я помог им исправить в чате, сам код при этом не трогая. В конце концов они добились полностью рабочей сборки. Я протестировал результат — всё отлично функционировало.
Был, правда, небольшой нюанс: GPT-5 сохранила в точности тот же стиль, что и раньше, и это здорово. А вот Opus зачем-то поменял дизайн и UX. Видимо, модель решила, что справится лучше меня (что, в общем-то, нетрудно).
Посмотреть результаты работы GPT-5 можно здесь, а Opus 4 — здесь.
После закрытия задачи я задал простой вопрос:
Отлично, всё получилось. Использовал ли ты в процессе какие-то из ранее созданных инструментов? И с учетом проблем, которые возникли — что бы ты хотел добавить в свой арсенал для повышения эффективности работы?
Ответ Opus 4 можно посмотреть здесь, а GPT-5 — здесь (простите, там форматирование слетело).
Обе модели заявили, что НЕ использовали НИ ОДИН из созданных ими инструментов, за исключением тех, с которыми уже были знакомы. Тут можно возразить, что не стоило полагаться на волю модели, а нужно было принудительно внедрить использование утилит через pre-commit хуки или что-то подобное. Именно так я обычно и поступаю в своей работе, но в этом эксперименте хотел посмотреть, додумаются ли они до этого сами.
Затем модели накидали идеи, как можно было бы решить эту же задачу лучше в следующий раз, и я попросил их эти улучшения реализовать. После этого я откатил репозиторий smol-podcaster к исходному состоянию и дал им тот же самый промпт и ту же задачу, но уже с новым набором инструментов. Результаты GPT-5 — здесь, Opus 4 — здесь.
Отработали они примерно так же, как и в первый раз. И я снова задал тот же вопрос: «Ты использовал хоть какие-то инструменты?». Вот что ответила GPT-5:
• Если кратко: нет — в этот раз я не использовал devtools. [...]
• Сбои были связаны с рантаймом/окружением (не хватало библиотек, проблемы с инициализацией API-ключа, порт был занят, RabbitMQ не запущен). Проще было исправить это напрямую.
• В этот раз не было ни рефакторинга в масштабах всего репозитория, ни диагностики, где кастомные инструменты могли бы пригодиться.
На предыдущем шаге у неё уже были проблемы с RabbitMQ, для решения которых она создала инструмент, но в итоге его проигнорировала. Да и задача, очевидно, затрагивала весь репозиторий. Так что либо модель просто не умеет сопоставлять задачи с инструментами, которые никогда не видела при обучении, либо она меня просто газлайтит (что, впрочем, делают и многие разработчики, так что это даже впечатляет).
Ответ Opus 4 был очень интересным и помог мне лучше понять логику GPT-5. Я, к сожалению, забыл сохранить лог, но успел сделать скриншот:
Я интерпретировал это так: «Слушай, я создал эти инструменты на основе знаний, которые у меня и так уже есть. Когда доходит до дела, мне проще сделать всё самому, чем возиться с этими инструментами». И я его прекрасно понимаю.
Это напомнило мне о паре моментов из прошлых интервью:
Нейтан Ламберт из AI2 говорил, что в процессе RL-обучения модели быстро учатся не использовать инструмент, если на ранних этапах столкнулись с неудачей. Похоже, чтобы заставить их осваивать новые утилиты на этапе инференса, нужно что-то посерьезнее, чем просто просьба в промпте.
Ноам Браун из OpenAI упоминал, что все эти «вспомогательные костыли» для агентов становятся бесполезными по мере увеличения масштаба моделей. В ходе этого эксперимента я впервые по-настоящему понял, что он имел в виду.
Конечно, остается вопрос, не была ли задача, которую я им дал, слишком простой. Но в конечном счете на эту задачу у меня ушло бы 4–5 часов, так что для меня результат более чем достойный.
Помочь моделям... помочь самим себе
На мой взгляд, до кодинг-агентов, которые бы по-настоящему раздвигали границы возможного, самосовершенствуясь прямо во время работы, нам ещё далеко. Но это не отменяет главного: использовать модели для улучшения инструментов, работающих по правилам, — всё равно отличная идея. Написание правил для ESLint, тестов и тому подобного — это всегда разумное вложение токенов.
Если бы я и дальше копал в этом направлении, я бы попробовал заставить модель довести эти инструменты до ума, а затем прогнал бы их через RL-обучение, чтобы она их по-настоящему «внутренне» усвоила. И посмотрел бы, изменит ли это что-то.
Возможно, модели следующего поколения в таких «костылях» нуждаться не будут. Но лично мне интересно извлекать выгоду из текущего этапа — из этого самого приближения к асимптоте AGI. Вот мысль, которой я поделился со своей командой ещё в 2023 году:
Кажущееся замедление в развитии моделей объясняется графиком выше. Пока условная черта AGI не пересечена, совершать большие прорывы будет всё труднее. А раз так, то получается, что для многих задач производительность «старших» моделей уже вплотную приблизилась к уровню AGI — при том, что сами модели довольно дешевые и зачастую опенсорсные.
Все результаты эксперимента и логи чатов лежат здесь.