ИИ разрабатывает следующее поколение самого себя
Искусственный интеллект постепенно перестаёт быть только инструментом для создания программного кода и анализа данных. Он начинает участвовать в разработке новых моделей, фактически помогая проектировать собственных преемников. Компания Anthropic впервые подробно рассказала, насколько широко Claude уже применяется внутри её исследовательских и инженерных процессов.
По представленным данным, Claude участвует более чем в 90% задач, связанных с исследованиями и разработкой новых ИИ-моделей. При этом около 26% всей работы в направлении R&D система выполняет практически самостоятельно или с минимальным вмешательством сотрудников.
Внутри компании одновременно функционируют примерно 30 тысяч ИИ-агентов. Они пишут и проверяют программный код, анализируют результаты экспериментов, ищут ошибки в инфраструктуре, подготавливают документацию и распределяют отдельные поручения между собой. Один агент может поставить задачу другому, проверить его результат и передать итог следующему звену цепочки.
Такой подход уже сложно назвать обычным "вайбкодингом", когда разработчик описывает желаемый результат, а модель генерирует код. Речь идёт о своеобразном вайб-R&D: человек формулирует общую научную или инженерную цель, после чего группа агентов выполняет значительную часть рутинной и аналитической работы.
ИИ может предложить архитектуру эксперимента, написать необходимые скрипты, обработать полученные данные, сравнить несколько вариантов и обнаружить слабые места в текущей реализации. Это ускоряет цикл разработки и позволяет исследователям тратить больше времени на постановку задач, проверку гипотез и принятие стратегических решений.
Однако полной автономии пока нет. Ключевые решения по-прежнему остаются за людьми. Специалисты определяют направление исследований, оценивают достоверность выводов, контролируют безопасность и решают, можно ли использовать полученные результаты в следующей версии модели.
Особенно важен человеческий контроль там, где агенты начинают взаимодействовать друг с другом без постоянного участия инженера. Ошибка на одном этапе способна быстро распространиться по всей цепочке: неверный эксперимент породит неправильные данные, а некорректная интерпретация - ошибочную архитектурную гипотезу.
Тем не менее сама тенденция заметна: разработка ИИ всё чаще превращается в многоуровневую систему, где человек задаёт цели и ограничения, а агенты выполняют отдельные этапы работы. В перспективе это может существенно сократить сроки обучения и тестирования новых моделей.
Самая мощная модель не всегда оказывается лучшим выбором
Похожий вывод можно сделать и при использовании ИИ для программирования. На практике разработчику не всегда нужна наиболее интеллектуальная и дорогая модель. Гораздо важнее, насколько эффективно она решает конкретную задачу.
Для оценки применяют показатель Cost per Task - стоимость выполнения одной задачи. Он учитывает не только качество ответа, но и объём вычислений и количество потраченных токенов. Поэтому модель с более скромными результатами в абстрактных тестах может оказаться выгоднее при ежедневной работе.
В качестве примера приводится GPT-5.6 Luna в режиме max. По интеллектуальному индексу Artificial Analysis Intelligence Index она получает 38 баллов. Для сравнения, GPT-6 Astra в аналогичном режиме достигает 53 баллов. На первый взгляд преимущество Astra выглядит очевидным.
Но стоимость выполнения задачи различается гораздо сильнее: около 0,18 доллара у Luna против 3,26 доллара у Astra. Разница составляет почти двадцать раз. Если разработчик решает десятки задач в день, выбор более дешёвой модели напрямую влияет на итоговые расходы.
Причина заключается в том, что дорогая модель часто тратит больше ресурсов на рассуждения, дополнительные проверки и построение развернутого ответа. Это оправдано при сложной архитектурной работе, поиске неочевидных ошибок или анализе крупной кодовой базы, но избыточно для небольших изменений.
Как выбирать модель для программирования
Слабее не всегда означает хуже. Если задача сформулирована точно, модель среднего уровня способна быстро справиться с ней без лишних итераций. Например, для переименования функций, написания простого теста, преобразования формата данных или исправления очевидной ошибки переплачивать за наиболее мощную систему нет смысла.
При этом качество запроса становится критически важным. Чем подробнее описаны входные данные, ограничения, ожидаемый результат и критерии проверки, тем меньше модели приходится "догадываться". Хорошо составленное задание позволяет недорогой системе работать заметно эффективнее.
Практичный рабочий процесс может выглядеть так: простые операции поручаются быстрой модели, задачи средней сложности - универсальной, а наиболее рискованные изменения передаются флагманской системе. После этого код проверяется тестами и, при необходимости, анализируется человеком.
Полезно разделять стоимость генерации и стоимость ошибки. Если неправильный ответ способен привести к сбою production-сервиса, потере данных или уязвимости, экономия на модели может оказаться неоправданной. В таких случаях более дорогой анализ часто обходится дешевле последующего исправления.
Для команд разработки важен и другой показатель - время до готового результата. Быстрая модель, которая решает задачу с первой попытки, может быть выгоднее более интеллектуальной, но медленной системы, требующей нескольких уточнений и повторных запусков.
В будущем всё большее значение будут иметь не отдельные модели, а интеллектуальные маршрутизаторы. Они смогут автоматически определять сложность запроса и выбирать подходящий инструмент: экономичный агент для рутинной операции или мощную модель для нестандартной инженерной задачи.
Таким образом, ИИ постепенно участвует не только в создании программ, но и в разработке новых ИИ-систем. Однако главным преимуществом становится не максимальная "умность" модели, а грамотное распределение задач, контроль результатов и расчёт реальной стоимости работы.
