В марте–апреле 2026 разговор об AI-агентах резко перестал быть разговором только о новых интерфейсах и демо. На уровне инструментов произошел синхронный сдвиг: Cursor 3 переехал в agent-first интерфейс, OpenAI и Anthropic перестроили SDK вокруг агентных паттернов, а Claude Computer Use из «прикольной фичи» превратился в рабочий инструмент для длинных сценариев взаимодействия с компьютером. На этом фоне идеи Karpathy перестали выглядеть как частные наблюдения одного инженера и начали работать как язык, через который индустрия объясняет происходящее.

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

Апрель 2026 как точка перелома

Если собрать сигналы последних недель в одну линию, для dev-инструментов вырисовывается довольно цельная картина. Anysphere выпускает Cursor 3 с интерфейсом, который «сдвигает основной способ работы с файла к управлению параллельными агентами, локальными и облачными». Anthropic выводит Claude Computer Use в десктопный Cowork/Claude Code: теперь агент легально кликает мышью, печатает, открывает IDE и браузер и может проходить по нескольким шагам задач без ручного микроменеджмента.

На уровне нарратива все это уже формализовано как переход к «третьей эре разработки», где разработчик все меньше пишет код напрямую и все больше оркестрирует агентов, которые этот код пишут и проверяют. Факты под это есть: в Cursor 3 основная поверхность, окно агентов, в Claude Computer Use, длинные сценарии по работе в браузере и десктопных приложениях, у Veai (рабочая среда для агентной инженерии» для российских команд)

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

Конкурировать начинает не только качество модели, но и качество исследовательского конвейера, насколько быстро вы можете формулировать, проверять и отбраковывать гипотезы при заданном compute-бюджете.

Именно в этот момент рамка Karpathy оказывается особенно удобной. Он не просто показал новый инструмент, а дал объяснение происходящему: разработчик и исследователь все меньше выступают как прямые исполнители и все больше как оркестраторы систем агентов. Для ML это де-факто новая операционная модель R&D.

Что Karpathy называет agentic engineering

В своей статье о AutoResearch Karpathy описывает agentic engineering как следующий этап после vibe coding: инженер большую часть времени не пишет код вручную, а оркестрирует LLM-агентов, выступая уровнем oversight и control loop поверх них. В AutoResearch это выражено буквально: человек задает research-spec в program.md, а агент сам читает репозиторий, модифицирует train.py, запускает эксперименты и по метрике решает, какие изменения сохранять.

Для ML-ресерчера это сдвиг роли от «оператора экспериментального стенда» к research advisor / experiment designer. Он формализует исследовательский вопрос, определяет compute-бюджет, задает допустимое пространство изменений (model architecture, optimizer, scheduler, regularization), проектирует evaluation harness и следит за тем, чтобы loop не ломал валидность экспериментов. Работа смещается на уровень design of experiments и search space definition, а не ручного «twiddle the hyperparameters».

В этом контексте агент выступает как «цифровой junior-исследователь»: он реализует непрерывный propose–modify–train–evaluate цикл, перебирает варианты внутри заданного search space и поддерживает git-историю валидных улучшений, но не берет на себя формулировку задач и выбор долгосрочного научного направления. Для зрелых ML-команд agentic engineering выглядит не как угроза замены ресерчеров, а как нормализация давно назревшего паттерна: люди проектируют исследовательский конвейер и критерии качества, а агенты закрывают объемный, но формализуемый перебор.

AutoResearch: как выглядит агентный ресерч на практике

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

В репозитории архитектура сведена к трем файлам: фиксированный prepare.py, в котором живут данные и утилиты, изменяемый train.py с моделью и тренировочным циклом и описание исследовательского направления в markdown-файле. Агент имеет право править только train.py: архитектуру, гиперпараметры, оптимизаторы, batch size и другие элементы цикла. Дальше запускается «ratchet loop»: если изменение улучшило целевую метрику, оно остается, если нет, откатывается.

Широкую огласку AutoResearch получил после кейса, в котором за несколько десятков часов агент провел сотни экспериментов (в открытых обзорах фигурируют числа порядка 100+ прогонов на одну GPU-машину за ночь) и нашел заметное количество нетривиальных оптимизаций поверх уже довольно аккуратного baseline. В ряде материалов эту динамику окрестили «Karpathy Loop», ночной агентный цикл, который сам улучшает то, что вы ему отдали.datasciencedojo+3

Отсюда следует ключевой организационный вывод. Агентный ресерч отличается от обычной автоматизации тем, что человек перестает быть диспетчером каждого запуска. Ночью работает цифровой junior researcher, днем lead или scientist смотрит на агрегированную картину, историю изменений и карту гипотез и решает, куда копать дальше.

Почему это не просто AutoML

Скептическая реакция на такие кейсы выглядит ожидаемо: «hyperparameter search и AutoML уже давно существуют, что нового?». В классических системах оптимизации (Bayesian search, grid/random search, Optuna, Ray Tune) поиск идет в заранее заданном пространстве параметров: мы описываем search space, алгоритм выбирает точки, а код пайплайна остается неизменным.

Agentic research-цикл работает шире. AutoResearch из коробки дает агенту право менять не только численные параметры, но и структуру самого тренировочного кода: переписывать конфиг, пробовать другой loss, менять архитектуру, включать и выключать вспомогательные проверки. По сути, это совмещение трех способностей в одном loop: генерация кода, запуск эксперимента и интерпретация результатов.

Именно поэтому AutoResearch интереснее, чем еще один Bayesian optimization layer. В аналитике по AutoResearch его описывают как «исследовательскую лабораторию, которая работает, пока вы спите», а не как тюнер гиперпараметров. Для ML-ресерчеров это ключевой момент: у агента появляется шанс участвовать не только в выборе точки внутри плана, но и в пересборке самого плана.

Конечно, это не делает агента научным руководителем. В тех же обзорах подчеркивается, что loop легко переоценивает случайные улучшения, может застрять в локальном оптимуме и производит правдоподобный, но бесполезный «slop», особенно если метрики и eval-контур описаны нестрого. Но именно сочетание сильных и слабых сторон делает его полезным: агент хорош в объеме и настойчивости, человек, в рамке, критике и выборе направления.aibyaakash+1

Как выглядит agentic workflow для ML-команды

Если убрать вокруг темы лишний футуризм, минимальный agentic workflow для ML-команды выглядит достаточно по-земному и легко встраивается в существующие пайплайны. На входе у нас есть:

• машинно-читаемый research-spec: что оптимизируем, какие метрики считаем ключевыми, какой compute-бюджет допустим, какие типы изменений агенту разрешены;

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

Дальше агент работает в цикле, который легко выразить псевдокодом:

pythonwhile budget_not_exhausted:
    state = read_experiment_history()
    goal = read_research_spec()
    hypothesis = agent.propose_next_step(goal, state)
    patch = agent.modify_code_or_config(hypothesis)
    run_id = launch_experiment(patch)
    metrics = collect_metrics(run_id)
    summary = agent.evaluate_result(hypothesis, metrics, state)
    save_summary(run_id, hypothesis, patch, metrics, summary)

while budget_not_exhausted: state = read_experiment_history() goal = read_research_spec() hypothesis = agent.propose_next_step(goal, state) patch = agent.modify_code_or_config(hypothesis) run_id = launch_experiment(patch) metrics = collect_metrics(run_id) summary = agent.evaluate_result(hypothesis, metrics, state) save_summary(run_id, hypothesis, patch, metrics, summary)

Ценность этого фрагмента не в синтаксисе, а в организационном принципе. Исследовательский процесс становится объектом проектирования: команда строит систему, которая умеет запускать, осмыслять и сужать поиск почти без постоянного ручного вмешательства.

Роль человека в такой системе становится понятнее и дороже. Исследователь нужен не для того, чтобы руками подставить очередной learning rate, а для того, чтобы определить полезную постановку, вовремя ограничить пространство поиска, отбраковать ложные сигналы и не дать агенту оптимизировать второстепенную метрику в ущерб главной цели. На уровне культуры это сдвиг от «я провел еще 20 запусков» к «мы спроектировали исследовательский конвейер, который за ночь провел 200 запусков и оставил 10 осмысленных веток».aibyaakash+1

Где здесь риски

Как и любой новый слой автоматизации, агентный ресерч опасен именно там, где кажется самым удобным. В обзорах по безопасности агентных систем prompt injection, data exfiltration и злоупотребление правами tools уже называются ключевыми угрозами. Если агент видит код, данные, запускалку задач и артефакты, он автоматически становится частью attack surface.

Есть и более приземленная, но ежедневная проблема, низкокачественная автономия. При слабом eval-контуре агент легко производит много формально корректной, но практически бесполезной работы: переусложняет пайплайн, фиксируется на локальном оптимуме, «улучшает» метрику ценой ухудшения воспроизводимости или просто засоряет репозиторий неубедительными изменениями. В документации по Claude Computer Use и похожим системам прямо рекомендуют ограничивать доступ и делать человека ревьюером, а не пассивным наблюдателем.

Отсюда вытекает прагматичное правило для ML-команд: автономия должна быть ограниченной, а оркестрация, детерминированной. Агенту можно разрешить менять конфиги, вспомогательный код и экспериментальные ветки, но нельзя давать бесконтрольный доступ к боевым системам, критическим данным и merge в основную ветку без ревью. Если относиться к агенту как к очень быстрому, но не всегда аккуратному junior-исполнителю, архитектурные решения становятся гораздо яснее.

Почему это особенно важно для России

Российским ML-командам эта история важна не потому, что нужно срочно копировать очередной западный хайп, а потому что agentic engineering хорошо ложится на существующие ограничения и сильные стороны.

В открытых обзорах по рынку ИИ и инфраструктуре для России стабильно всплывают три характеристики: сильный bias в сторону on-prem, локальные GPU-кластеры и повышенное внимание к размещению и контролю данных.

Это делает agentic research интересным не как еще одну SaaS-фичу, а как архитектурный подход, который можно реализовать полностью внутри периметра. У многих команд уже есть все необходимое в зачаточном виде: свои кластеры, локальные трекинговые системы, воспроизводимые тренинг-пайплайны, культура инженерной дисциплины и хроническая нехватка времени на системный перебор гипотез. В такой среде цифровой «ночной исследовательский отдел» особенно ценен: он не требует чудесной AGI, ему достаточно связать LLM, кодовую базу, запуск задач и хороший контур логирования в единую агентную петлю.

Если посмотреть трезво, у российских команд здесь есть шанс перепрыгнуть одну ступень. Не догонять бесконечно чужие IDE и ассистенты, а строить agent-first R&D-практики сразу вокруг собственных ограничений: on-prem, локальные модели, строгие права доступа, reproducible-пайплайны, sandbox по умолчанию.

Что можно сделать уже сейчас

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

• снижение времени тренировки без просадки по качеству;

• поиск более дешевой конфигурации inference при тех же SLA;

• подбор устойчивых preprocessing-вариантов для шумного датасета.

Дальше задача описывается в виде короткой research-spec (цели, метрики, бюджет, допустимые изменения), вокруг нее поднимается ограниченный sandbox, а агенту дается право в ночном окне крутить несколько десятков или сотен итераций. На уровне инструментария это может быть как AutoResearch в «чистом виде», так и ваш внутренний loop, собранный вокруг существующего трекинга, оркестрации и локальной LLM.

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