Атомарные навыки
как улучшить агентов для программирования на 18.7%

Авторы статьи предлагают перестать тренировать ИИ-агентов только на комплексных задачах и вместо этого учить их атомарным навыкам — небольшим, проверяемым строительным блокам разработки.

Когда агентов для программирования учат не «чинить баги», а мыслить последовательно

У ИИ-агентов для программирования: модели неплохо приспобаливаются к бенчмаркам, но стоит чуть изменить постановку задачи — и ничего не работает. Агент умеет закрывать задачи в стиле SWE-bench, но теряется на рефакторинге. Хорошо пишет патчи, но слабо воспроизводит баги. Уверенно проходит тесты, но не умеет толком ревьюить чужой PR.

Авторы статьи Scaling Coding Agents via Atomic Skills предлагают на удивление здравую идею: перестать тренировать агентов только на «больших» комплексных задачах и вместо этого учить их атомарным навыкам — небольшим, проверяемым, многократно используемым строительным блокам разработки. Не «почини баг», а «найди нужные файлы», «внеси точечную правку», «сгенерируй хорошие unit-тесты», «воспроизведи issue», «сделай code review».

На бумаге это звучит почти очевидно. Но в реальности это довольно радикальный сдвиг в том, как мы вообще масштабируем coding agents. И, судя по результатам, сдвиг полезный.

В чем проблема с нынешним подходом

Большая часть современных LLM-агентов для программирования тренируется на составных задачах: исправление багов, терминальная разработка, ML-инжениринг и безопасность Это удобно: есть понятный конечная форма успеха — тесты прошли или нет, задача решена или нет.

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

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

Если ИИ-агенты действительно должны работать в реальных репозиториях, а не только на вылизанных бенчмарках, им нужна обобщаемость. В реальной разработке задачи бесконечно разнообразны, а собирать для каждой новую конфигурацию обучения с подкреплением с внятной функцией вознаграждения — дорого и часто практически невозможно.

Пять атомарных навыков как базис разработки

Вместо обучения на «монолитных» задачах авторы выделяют пять фундаментальных навыков:

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

Редактирование кода — внести нужную правку в код.

Генерация юнит-тестов — написать тесты, которые реально ловят ошибки.

Воспроизведение багоа — воспроизвести баг минимальным скриптом или последовательностью команд.

Ревью кода — оценить, действительно ли PR решает заявленную проблему.

Идея в том, что это не просто список «всего понемногу», а именно базисные векторы инженерной работы. Из них можно собрать более сложные сценарии. Например, исправление багов — это почти всегда комбинация локализации, воспроизведения, редактирования и проверки. Рефакторинг задействует редактирование и код-ревью Безопасность может требовать воспроизведения и тестирования.

Авторы задают для каждого навыка очень важные требования: он должен быть минимальным, четко специфицируемым и независимо проверяемым. Это ключевой момент. Если навык нельзя надежно оценить автоматически, RL быстро превращается в хаос.

Как они это обучают

Сначала модель слегка дообучают в supervised-режиме на данных только по атомарным навыкам — без составных задач. Это стартовая точка. Дальше запускается joint reinforcement learning: один агент, одна общая политика, один смешанный буфер задач, в котором перемешаны эпизоды по всем пяти навыкам.

Это не пять отдельных моделей и не пять skill-specific heads. В этом и суть: авторы хотят, чтобы внутри модели возникли общие представления для понимания кода, работы с репозиторием, запуска инструментов, интерпретации результатов и принятия решений.

Технически агент работает в песочнице, может вызывать bash и редактировать файлы через простой инструмент вроде str_replace. Ограниченный набор действий здесь не минус, а плюс: меньше шума в action space, легче стабилизировать RL.

Для оптимизации используется GRPO — Group-based Relative Policy Optimization. Вместо того чтобы полагаться на абсолютные значения награды, модель сравнивает несколько сэмплов между собой внутри группы. Это полезно, потому что разные навыки имеют разные reward-скейлы и разную степень шума. Относительное сравнение снижает хрупкость обучения.

Как устроены награды — и почему это, пожалуй, сильная часть работы

Самое интересное в статье то, что авторы довольно аккуратно продумали execution-grounded rewards.

Для локализации кода награда дается, если модель точно угадала набор файлов, которые в реальности меняли разработчики. Критерий строгий: либо полное совпадение, либо нет. Спорно, но понятно — такой reward не размывается частичными попаданиями.

Для редактирования кода всё еще прямолинейнее: патч считается правильным, если проходят юнит- и регрессионные тесты

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

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

Для код-ревью агент получает PR и должен вынести бинарный вердикт — решает он проблему или нет. Награда зависит от совпадения с разметкой корректности.

Эта конструкция важна потому, что показывает: авторы не просто сказали «давайте дробить задачи», а действительно построили масштабируемую RL-инфраструктуру для такого дробления.

Что получилось на практике

Главный результат статьи звучит очень неплохо: joint RL по атомарным навыкам улучшает и сами навыки, и перенос на невиданные составные задачи. Средний прирост по 5 атомарным навыкам и 5 составным задачам — 18,7%.

Если смотреть на таблицы, картина выглядит последовательно. После RL модель улучшается на всех пяти атомарных навыках. Например:

— локализация: 0.665 → 0.712

— редактирование: 0.458 → 0.611

— воспроизведение задач: 0.542 → 0.605

— генерация юнит-тестов: 0.359 → 0.472

— код-ревью: 0.563 → 0.622

Но важнее, что рост переносится на OOD-бенчмарки, которые не использовались как RL-цели: SWE-bench Verified, мультиязычное исправление багов, Terminal-Bench, рефакторинг, безопасность

Это и есть главный аргумент статьи. Если бы улучшения оставались только внутри training distribution, работа была бы просто еще одной вариацией на multi-task RL. Но здесь авторы показывают, что обучение на «кирпичиках» действительно помогает на новых, более сложных задачах

Почему совместное обучение лучше специализации

Отдельный блок статьи — сравнение joint RL с более узкими вариантами: RL только на задачах редактирования кода или только на SWE-bench Verified.

Интуитивно можно было ожидать, что single-task RL даст более резкий прирост хотя бы по своей цели, а joint training начнет страдать от интерференции. Но авторы утверждают обратное: явных trade-off’ов не видно. Все пять атомарных навыков растут вместе, а перенос на составные задачи в joint-режиме лучше и стабильнее.

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

Конечно, специализация все еще полезна. Авторы честно пишут, что RL прямо на конкретном бенчмарке может дать сравнимый результат. Но если цель — не один лидерборд, а более универсальный агент, joint atomic training выглядит сильнее.

Динамика обучения: редкий случай, когда графики действительно что-то объясняют

В работе есть полезные графики обучения. Они показывают, что атомарные навыки в среднем улучшаются монотонно по мере обучения с подкреплением. И вместе с ними растут показатели на составных OOD-задачах.

Это важно, потому value=потому что в RL по агентным сценариям часто бывает иначе: что-то резко взлетает, потом деградирует, одна способность растет за счет другой. Здесь же авторы видят относительно устойчивое совместное улучшение.

Отдельно они анализируют число шагов во взаимодействии со средой. Для части навыков оно растет вместе с качеством. Это похоже на то, что агент начинает не «угадывать», а активнее исследовать репозиторий и осмысленнее пользоваться инструментами.

Почему эта работа шире, чем только агенты для программирования

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

У агентов для программирования это особенно видно, потому что разработка естественным образом раскладывается на повторяемые операции. Но идея может оказаться шире. Любая сложная агентная деятельность — ресерч, аналитика, работа с GUI, enterprise-автоматизация — тоже, скорее всего, состоит из набора атомарных навыков, которые лучше поддаются верифицируемому RL, чем «большая задача целиком».

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

Но есть и ограничения

При всех плюсах, работу не стоит воспринимать как окончательный ответ.

Во-первых, набор из пяти навыков все же довольно авторский. Он выглядит разумно, но не исчерпывает всей инженерной практики: тут нет, например, архитектурного проектирования, работы с зависимостями, миграций, performance tuning, планирование многошаговых задач.

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

В-третьих, все это работает на большой модели и серьезной инфраструктуре: десятки тысяч песочниц, предустановленные Docker-образы, Kubernetes-кластер. Для лабораторий и крупных компаний это реалистично, для большинства команд — пока нет.

Но даже с этими оговорками сама идея не теряет силы.

Вывод

Scaling Coding Agents via Atomic Skills — это одна из тех работ, где главный вклад не в новой архитектуре, а в смене парадигмы Авторы предлагают смотреть на агента для программирования не как на машину для прохождения очередного комплексного бенчмарка, а как на систему, которую надо учить навыкам, из которых собирается вся инженерная работа.

И результаты поддерживают этот взгляд: совместный RL по пяти атомарным умениям повышает качество не только на самих этих умениях, но и на более сложных, ранее невиданных задачах — от фикса багов до секьюрити и рефакторинга

Главный вывод звучит просто: если хотите универсального агента для программирования, возможно, не стоит «дрессировать» его только на починки багов. Лучше научить его сначала хорошо находить, воспроизводить, проверять, редактировать и оценивать код.

Для ИИ-разработки это, пожалуй, одна из самых практичных мыслей последнего времени.