Comments 6
Где-то в недрах мэрии Москвы проводят интенсив по перекладыванию плитки. Хвастаются, что за прошлый месяц переложили 1000 квадратных километров плитки, а за первые 12 дней этого месяца - уже 800. Причем благодаря выстроенной архитектуре Råspeel результат можно даже не проверять! Бригады работают автономно, а ты только подписываешь сметы! Автор доклада признаётся, что работает в условиях неограниченных бюджетов на благоустройство.
Спасибо за перевод. Тема довольно интересная жаль только, что сам вопрос доверия — то ради чего статья существует вообще не раскрыт.
Риторика Лорен полна подменой понятий, противоречий и не подкрепленных утверждений поэтому не могу просто пройти мимо. Сюжетная канва вообще очень странно устроена. С одной стороны выдвигается тезис, что основная проблема в доверии, но в то же время на протяжении всего спича проблемой является отсутствие у агентов умения решать конкретные задачи без участия человека.
Дальше тезисно
Когда вы не доверяете агенту, вы вынуждены постоянно вовлекаться в процесс и проверять каждое действие. Это сильно ограничивает вашу продуктивность, вы не можете распараллелить работу и запустить сразу много агентов, потому что не верите ни одному из них.
Можем, просто результат придется проверять в конце. Мне не нравится, что количество строк кода и набор закрытых PR выдается за валидную метрику продуктивности. В каком году мы живем? Не думал, что мемы про индусский код и разработку через количество станут новой веткой реальности.
Лорен показала кривую, на которой по вертикали отложен уровень доверия, а по горизонтали — время
А рядом на заборе нарисовала граффити. Что доказывает кривая? В каких единицах измерения доверие отмечено? Корреляция с количеством агентов и доверием кем измерена?
Верификация означает способность агента самостоятельно запускать код, снимать CPU‑трассировки, открывать симулятор iOS или иным способом проверять свою работу в реальной среде
Верификация означает не это. Она означает, что у нас есть механизмы проверки кода на соответствие спецификации. Написанной людьми между прочим. Это могут быть как статические инструменты, так и человек в виде принимающего лица. Здесь проводится попытка провернуть слушателя на половом органе поскольку с одной стороны мы хотим доверять LLM через средства проверки и в то же время считаем, что LLM сама способна выступить в его роли. Нет тут гарантий никаких.
Верификация не гарантирует, что код будет хорошим в смысле архитектуры, но она гарантирует, что код будет корректным. А это уже огромный шаг вперёд к доверию.
То есть тупо проверили, что код компилится, проходит линтеры и проставили галочку "проверено". Нужен кто-то или что-то, что проверяет правильность того, что мы сделали и LLM здесь не подойдет поскольку она и есть источник кода. Так понимаю здесь речь идет о TypeScript, а если у нас не Rust/Go/Java, а что-то динамическое? Получается и этих механизмов нет, остается только доверять автотестам от той же LLM.
Лорен проводит параллель с управлением людьми. Если вы менеджер и не доверяете своей команде, вы начинаете микроменеджерить, тратить время на проверку каждого коммита. Точно так же с агентами.
За подобную софистику надо помидорами закидывать. Здесь попытка наделить LLM человеческими качествами через проведение аналогии. Нет их, агент это просто программа работающая на базе языковой модели. Да, иногда хорошо работает, а иногда и нет. Проверка как раз об этом.
В CI реализованы проверки на уровне графа зависимостей, чтобы код из рендерер‑процесса не импортировал тяжеловесные модули, которые должны работать только в главном процессе Electron. Запрещены все паттерны, которые плохо обрабатываются агентами: например, useEffect в React, потому что это частая причина проблем с производительностью и агенты часто используют его неправильно.
Ну опять же, это все про то как код выглядит, а не то как он работает. Самое важное понять что код выдает результат, что нам нужен.
Статья имеет нулевую ценность. Описан абсолютно тривиальный путь разработчика работающего с агентами. Сначала просто пробуешь работать с агентом, пишешь вручную весь контекст в диалоговом режиме. Через какое-то время понимаешь, что можно улучшить процесс через написание скилов и спецификации проекта. Потом осознаешь, что контекст не резиновый и начинаешь более качественно писать скилы и управлять им. Затем в помощь приходят готовые инструменты лучше встраивающие информацию о кодовой базе в контекст и т.д.
Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста. Это утверждение никак не доказано и все механизмы нацеленные на подсовывание машине нужных инструкций это костыльные попытки заставить гомункула делать то, что нам надо. Сегодня одна модель, завтра другая. Новые веса, новый вендор, обучение на новом датасете и можем перестать уметь выполнять задачи которые раньше хорошо решались. Проблема тут в том, что LLM это статистическая модель работающая с вероятностями, а система проверки должна работать детерминировано.
Все время пишем скилы, спеку и инструменты, чтобы система работала автономно... где же тут автоматизация? :)
Автоматизация в том, что у коллег уже ai-native разработка и код руками они не пишут, не ревювят, и не тестируют, и результат - 800 PR как раз в том, что все скиллы и инструменты уже настроены.
Вы, видимо, не поняли, что Лорен все рассказала по тезису - основная проблема в доверии и как они ее решают, чтобы один человек мог управлять тысячами агентов.
Агенты умеют решать конкретные задачи без участия человека, поэтому у нее сейчас и 800 PR, и сотрудник в Курсоре вовлекается на уровне evals и governance.
Ну и вот это ваше высказывание "Описанный подход опирается на предположение, что LLM достаточно умна, чтобы сделать все правильно при наличии поданного контекста" - вообще не в тему ) Всю статью она рассказывает, как они выстроили тулзы контроля, чтобы LLM все сделала правильно )
Так, а где контроль то, что LLM сделала все правильно? Нет примера из разряда — вот у нас есть задача по которой есть спека, наш агент её выполнил так-то и так-то, затем рой агентов + некие утилиты доказали, что решение соответствует спеке. В этой точке в статье должно появиться описание инструментов и то как они гарантируют проверку логики. Некий способ доказать изоморфность постановки задачи к её решению. Метрики, цифры и так далее, описание дрифта с целевым решением на разных конфигурациях инструментов и LLM моделей. Без всего этого тезисы голословные и ничем не подкреплены.
Я тоже могу включить в yolo моде агента, заставить его писать код и настроить проверки в CI. Не бог весть какая задача, Claude такое за пару вечеров сварганит вот только доверия к этому подходу ровно столько насколько я уверен в промптах, инструкциях и возможностях модели.
Автоматизация в том, что у коллег уже ai-native разработка и код руками они не пишут, не ревювят, и не тестируют, и результат - 800 PR как раз в том, что все скиллы и инструменты уже настроены.
Количество не аргумент, можно и большие цифры выдавать хоть со скилами хоть без. Особенно при неограниченных ресурсах. Если код никто не ревьюит, и не тестирует, то как же так выходит, что мы думаем, что он соответствует логике? То, что принято сейчас называть автоматизацией не то, чтобы действительной ей является. Решение все равно создаю я. Описываю спецификацию, проектирую архитектуру и придумываю процессы. Написание кода агентом это финальная часть решения, которая не является боттлнеком сама по себе. Это ускорение клавиатуры. Нужна метрика подтверждающая, что описание достаточно точной задачи, которую агент сможет реализовать без уточнений будет эффективнее, чем написание самому с нуля иначе автоматизация иллюзорна.
Тейк про то, что скилы написаны и инструменты настроены я не принимаю. По Станиславскому «Не верю!». Пока продукт является конструктором из готовых компонент такой подход ещё с пивом покатит, однако достаточно сменить язык проекта, домен или вкорячить новую фичу на базе технологий под которую нет скилов и начинается новая итерация prompt engineering. Да и под каждую фичу все равно надо описать задачу. При этом если домен сложный, то без профильных знаний никуда, например разработка ОС или работа с медицинским оборудованием.
сотрудник в Курсоре вовлекается на уровне evals и governance
В статье этого нет, а стадии довольно интересные.
Лорен все рассказала по тезису - основная проблема в доверии и как они ее решают
Для Лорен сам факт наличия инструментов намеренных повысить качество кода повышает уровень доверия. Оно и понятно, степень ошибки в домене в котором она работает не столь высока. Насколько я могу догадываться речь идет ещё и о фронтенде за счет чего мы получаем быструю петлю обратной связи потому что можем увидеть проблему глазами.
Спасибо, очень интересная статья
Спасибо, всегда интересен чужой практический опыт, даже если он и не применим полностью
Кейс Cursor: 800+ PR в месяц или как выстроить доверие к ИИ‑агентам в разработке