Михаил Эрик, который ведет курс The Modern Software Developer в Стэнфорде и руководит направлением ИИ в Monaco, перестроил программу после того, как выяснилось, что все опрошенные студенты второго и третьего курсов уже пишут код с помощью агента. Первый запуск CS146S включал девять заданий и итоговый проект, однако многие упражнения вскоре стали выполняться с одной попытки, поэтому теперь в домашнюю работу входит вклад в проект с открытым кодом. Эта история важна, поскольку показывает, что считать мастерством инженера, когда генерация кода перестает быть ограничением.
Как изменились курс Стэнфорда и практика Monaco
Десятинедельная программа CS146S теперь направляет студентов к внешним мейнтейнерам, которые проверяют их патчи и решают, нужна ли функция проекту. Студент может попросить агента внедрить изменение за один день, но все равно должен разобраться, как устроен код, нужен ли патч мейнтейнеру и что еще он может сломать. В выпуске такой обмен назван подготовкой младших инженеров, которые учатся у старших коллег через ревью. Приложенные материалы включают программу, задания и партнеров open source, что позволяет сравнить курс с прошлым годом.
В Monaco коллеги применяют coding agents для выпуска программ и разбора сбоев, а команда протестировала коммерческие инструменты и выбрала смешанный подход. Среди продуктов для ревью кода после оценки сохранили Devin, а с workspaces для агентов пошли обратным путем. Фоновому агенту нужно место, где можно запустить продукт, воспроизвести сбой и проверить патч, причем детали зависят от устройства облака Monaco. Поэтому команда собрала собственные workspaces, следуя правилу Эрика, которое пересказано как покупай, чтобы учиться, и строй, чтобы сохранить.
К контексту относится навык explain-diff от Джеффри Литта, который превращает изменение в наглядный разбор, а затем проверяет читателя вопросами. Предложенное упражнение — применить его к патчу, написанному агентом, и заметить, какой вопрос заставляет заново открыть код. Другой ориентир — Authority Map от Basis, где указано, в каких местах агенту искать текущее поведение, прежние решения и замысел. В выпуске также приведен пример Stripe Minions как рабочего способа дать фоновым агентам среду и путь к pull request с проверкой инженером.
Что это меняет для компаний с coding agents
Для компаний практический сдвиг состоит в переходе от написания кода к проверке, тестированию и объяснению результата работы агента. Пример Hal из Monaco показывает схему: инженер может попросить систему расследовать сбой и открыть pull request, а продавец — объяснить, как работает продукт. В одном случае итогом становится изменение для ревью, в другом — объяснение для клиента. Небольшие фирмы получают более быстрый путь к патчам и ответам, а крупным организациям нужны workspaces, права доступа и ресурсы ревью, чтобы фоновые агенты работали безопасно.
Ограничения связаны с нагрузкой на ревью и утраченной историей решений. В упомянутом исследовании Faros команды с высоким внедрением ИИ сливали на 98 процентов больше pull request, а время их ревью оказалось на 91 процент дольше. Агент видит текущий код, но не знает, почему похожее изменение отклонили полгода назад, поэтому записи решений и оценка мейнтейнера становятся ценнее. Перед выбором инструментов компаниям следует проверить, где запускаются агенты, как настроены зависимости и разрешения и кто утверждает финальное слияние.
Признаком подтверждения тренда станет то, превратятся ли репозитории open source в готовые для агентов фабрики программ с зафиксированным замыслом и историей решений, как прогнозирует Эрик. Если мейнтейнеры опубликуют более ясные правила вклада и больше студенческих патчей пройдет ревью, стэнфордская модель распространяется. Если очереди ревью продолжат расти без ускорения решений, именно ревью кода останется узким местом.
