Неделю назад генеральный директор Cursor Майкл Трюэлл отметил событие, которое прозвучало как нечто выдающееся.
«Мы создали браузер с GPT-5.2 в Cursor», — заявил он в посте в социальной сети. «Он работал непрерывно в течение недели».
По его словам, этот браузер состоял из трёх миллионов строк кода в тысячах файлов. «Механизм рендеринга написан с нуля на Rust, включая HTML-парсер, CSS-каскад, компоновку, формирование текста, отрисовку и собственную виртуальную машину JavaScript».
Уровень сбоев в работе — 88 процентов — говорит о кодовой базе, которая не функционирует
«Он *вроде бы* работает! У него всё ещё есть проблемы, и он, конечно, очень далёк от паритета с WebKit/Chromium, но мы были поражены тем, что простые веб-сайты отображаются быстро и в целом корректно», — добавил он.
Некоторым разработчикам удалось скомпилировать код после устранения некоторых ошибок. Другие сообщили об успехе после изменений в инструкциях по сборке.
Однако в целом разработчики не убеждены, что Cursor совершил прорыв.
Джейсон Горман, управляющий директор Codemanship, британской консалтинговой компании по разработке программного обеспечения, утверждает, что это доказательство того, что агентный ИИ масштабируется для создания неисправного программного обеспечения.
Оливер Медхерст, инженер-программист и бывший сотрудник Mozilla, участвующий в работе группы по стандартам TC39 организации Ecma International, согласен. На вопрос, есть ли в этом нечто большее, чем демонстрация того, что ИИ-агенты могут создавать крупные проекты не самого высокого качества кода, он ответил, что это хорошее обобщение проекта.
«Впечатляет то, что это *кое-как* работает и что он может (неумело) управлять кодовой базой такого размера, но я бы сказал, что впечатляет именно это», — сообщил Медхерст изданию The Register по электронной почте. «Cursor заявил, что это всего лишь демонстрация, и я считаю справедливым называть это именно так, но это определённо не хороший движок для браузера, объективно. Ещё один момент заключается в том, что он невероятно раздут. Ladybird и Servo делают гораздо больше при гораздо меньшем количестве строк кода (репозитории Ladybird и Servo оба содержат около 1 миллиона строк)».
Непростая задача
Написание веб-браузера — одно из самых сложных универсальных приложений, за которые может взяться программист. Chromium, основа открытого исходного кода для Google Chrome, содержит более 37 миллионов строк кода.
Cursor не зашёл так далеко: по словам Трюэлла, его браузер под названием FastRender состоит примерно из трёх миллионов строк кода.
Разработчик программного обеспечения Джошуа Мариначчи ещё в 2022 году писал о том, насколько усложнился веб, до такой степени, что «только несколько компаний могут реализовать браузер с нуля».
Тот факт, что Microsoft прекратила разработку собственного движка для браузера и перевела Edge на Chromium, подтверждает огромные инженерные ресурсы, необходимые для разработки и поддержки браузера и лежащей в его основе технологии рендеринга.
Инженер-программист Cursor Уилсон Лин, работавший над кодом браузера, опубликовал статью в блоге с подробным изложением целей проекта: «понять, как далеко мы можем продвинуть границы агентного кодирования для проектов, на которые обычно у человеческих команд уходят месяцы».
The Register обратилась за комментариями к Cursor и Лину, но ответа не последовало.
В своей статье Мариначчи, несмотря на предупреждения о сложности браузеров, тем не менее призвал разработчиков попробовать свои силы в разработке браузеров. Один из способов сделать это — использовать существующие компоненты.
Критики обвинили Cursor в том, что он в значительной степени опирается на Servo — движок рендеринга с открытым исходным кодом на базе Rust, разработанный Mozilla.
Однако Лин в онлайн-дискуссии отверг утверждение о том, что FastRender был собран из готовых библиотек и фреймворков. «Я бы поспорил с идеей о том, что всё, что сделали агенты, — это соединили зависимости — виртуальная машина JS, DOM, системы отрисовки, интерфейс, конвейер обработки текста — всё это разрабатывается в рамках данного проекта, и там создаются действительно сложные системы для достижения цели движка браузера, даже если они ещё не готовы», — написал он.
Горман из Codemanship остаётся не впечатлённым. В своей статье он указывает на то, что метрики производительности действий на странице «Insights» репозитория FastRender демонстрируют нестабильность базового кода.
«Уровень сбоев в работе — 88 процентов — это очень много», — написал он. «Это в некотором роде говорит о кодовой базе, которая не работает».
Когда мы спросили Гормана об отчётах об успешных сборках, он выразил скептицизм, отметив, что сборка CI по-прежнему завершается с ошибкой.
Разработка ИИ: «Та же игра, другие кости»
Хотя мы отмечали случаи, когда опытные разработчики сообщали об успешном использовании инструментов кодирования на базе ИИ, Горман остаётся невозмутимым перед такими рассказами.
«Когда мы смотрим на доступные непредвзятые данные (например, последний отчёт DORA о состоянии разработки ПО с помощью ИИ или исследование METR, которое показало, что разработчики сообщают о значительном росте производительности, но при этом в среднем они работают на 19 процентов медленнее), становится очевидна тенденция: разработчики сильно недооценивают влияние на собственную производительность, а на результатах, таких как время выполнения задач и надёжность релизов, негативно сказывается большинство команд», — пояснил он.
«Меньшинство, которое видит скромный прирост, уже устранило узкие места в своих процессах разработки программного обеспечения, таких как тестирование, код-ревью и интеграция. Большинство команд никогда не устранят эти узкие места, в основном потому, что они на самом деле не смотрят на конечные результаты».
Горман заявил, что многие из наиболее сенсационных заявлений об успехе кодирования с помощью ИИ исходят от разработчиков, работающих над небольшими задачами в одиночку, без заказчика, пользователей или зависимостей, связанных с другими командами.
«Они разогнали машину до 200 миль в час на прямой дороге без других машин вокруг и пришли к выводу, что более быстрые машины означают более быстрый трафик», — сказал он. «А затем они возвращаются в офис и требуют такого же ускорения от своих команд, которые, по сути, едут в час пик».
Когда измерением является выходной результат — строки кода, коммиты, Pull Requests — Горман говорит, что увеличение определённо есть.
«Но просто потому, что вы подключили к своей сантехнике пожарный шланг, генерирующий код, это не значит, что вы получите сильный душ», — сказал он. «Многие команды измеряют давление воды, выходящее из пожарного шланга, а не из душа. Вот что показывают доказательства».
Далее он указал на отсутствие доказательств того, что инструменты ИИ приводят к созданию большего количества программного обеспечения, измеряемого количеством продуктов, доступных в магазинах приложений, и на отсутствие дохода, приписываемого этим инструментам.
«Где всё это программное обеспечение, сгенерированное ИИ?» — спросил он. «Я три года это изучаю. Иногда я чувствую себя Джеймсом Рэнди на съезде по сгибанию ложек».
Горман считает, что технология ИИ очень впечатляет, но часто ошибочна. «Думаю ли я, что она бесполезна?» — спросил он. «Совершенно нет. Я использую её каждый день. Как тренер и наставник, я чувствую, что должен убедиться, что хорошо разбираюсь в том, как её использовать и что работает лучше всего.
«Считаю ли я, что это меняет правила игры? Нет. Принципы и практики, которые делали команды разработчиков высокоэффективными до появления “ИИ”, — это те же самые принципы и практики, которые делают их эффективными и с ним — небольшие шаги, замкнутые циклы обратной связи, непрерывное тестирование, код-ревью и интеграция, а также высокомодульные архитектуры. Та же игра, другие кости».
Он добавил: «Если бы ИИ-агенты действительно *могли* создать работающий продукт из 3 миллионов строк кода за неделю, когда в этом процессе проектирования происходит обратная связь от пользователя/клиента? Именно там открывается настоящая ценность».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Thomas Claburn
