Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Звучит заманчиво, но у меня не получается так, чтобы я дал задачу абстрактно и получил результат. В проекте просто нет и не может быть всех данных для решения проблемы. И конвенции не спасают. А делаю бэкенды, если что.
Фиксануть какой-то мелкий баг - обычно без проблем (хотя иногда с проблемами). А вот сделать новую фичу - уже так просто не получается. Приходится писать дизайн-документ, который кроме "что мы хотим" содержит кучу технических решений. Иначе модель нафигачит "как она видит" при том по разному от запуску к запуску. Документ уточняется по мере реализации.
Я пытался собирать в кучу места, где модель косячит и столкнулся с тем, что процесс походу бесконечный. Правил становится всё больше и конца не видать. А ещё чем больше правил, тем модели сложнее: она пытается учесть все правила, даже самые неважные и уходит в сложные рассуждения.
Гейты штука хорошая, но они не закрывают проблем в случае, если модель сделала не то или какую-то фигню. При этом гейты молчат, валидация другой моделью тоже.
В общем кодогнератор и ревьюер полезный, но как ему доверить разработку и не смотреть в код - я хз
Тут есть, что сказать. Модель нафигачит “как она видит”, причём по-разному от запуска к запуску - значит она видит что-то противоречивое. В коде, в правилах, в документах. Некоторый разброс генерации есть всегда, но это не всегда плохо. При непротиворечивом контексте от запуска к запуску может меняться реализация, а трактовка задачи - нет. Если меняется трактовка - модель каждый раз заново выбирает, какой из противоречащих источников считать правдой.
“Правил всё больше и конца не видать” - тот же корень. Каждое правило-заплатка становится ещё одной версией правды и источником следующего конфликта. Отсюда и “модель уходит в сложные рассуждения”: она разрешает противоречия между правилами, а не решает вашу задачу.
Попробую дать пару советов, как бы я сам делал. Всё, что проверяется машиной - в гейт. Правила, которые ничем не проверяются - кандидаты на удаление, а не на пополнение. По дизайн-документу попробуйте сценарии, которые прогоняются - тогда “сделал не то” краснеет сразу. И попробуйте приём из статьи: агент в режиме максимального думания ищет противоречия в вашем контексте.
- значит она видит что-то противоречивое.
Не значит. Это только одна из причин. А другая - вероятностная суть моделей. Самое просто: разные имена ендпоинтов от запуска к запуску. Или разное поведение внутри обработчика, потому что какие-то граничные случаи не были описаны. Т.е. код не эквивалентный по поведению.
Правила, которые ничем не проверяются - кандидаты на удаление, а не на пополнение
А такие бывают? их можно проверять другой моделью
По дизайн-документу попробуйте сценарии, которые прогоняются - тогда “сделал не то” краснеет сразу.
У меня полно авто-тестирования, но мы не знаем того, чего не знаем. Из последнего: из дева приехали изменения, которые влияют на текущую задачу, а ИИ просто переписывает эти изменения под сценарии, которые сделал человек. Поняли на странном коде на ревью.
агент в режиме максимального думания ищет противоречия в вашем контексте.
Делаю такое, происходит бесконечное уточнение спецификации :) Тут важно вовремя остановиться и начать писать код, т.к. код тоже спецификация сама по себе.
P.s. "тот же корень" - нейронка писала или просто много общался ЛЛМ?
Если по примерам Вашим судить:
1 - Разные эндпоинты. Насколько я понимаю - имя эндпоинта это контракт, его лучше фиксировать в отдельной задаче и давать как часть контекста в задачу по реализации. Но тут настаивать не буду, не зная Вашего проекта.
2 - Сценарии. Вы описали типичный пример двух версий правды. Конечно агент запутается. Если ему сказано - что сценарии главнее, то он будет переписывать код. Если бы сценарии выполнялись на CI - код с dev бы не вмержился. Если бы код с дева пришел вместе с соответствующим тестом или сценарием - то “ИИ просто переписывает эти изменения под сценарии” сломало бы эти тесты.
3 - Бесконечное уточнение спецификации это опять-таки пример, когда вместо поиска и удаления противоречий ставятся заплатки. Я не видел Вашу спеку, но такие симптомы наблюдал. Чат бы тоже было интересно посмотреть, возможно это симптом recency bias. В этом случае бесполезно писать код, пока противоречия не сняты. Агент будет путаться, а Вы - злиться на него на code review.
переписывает эти изменения под сценарии” сломало бы эти тесты.
А он и тесты переписал. И только глазки человека позволили это заметить :D
имя эндпоинта это контракт, его лучше фиксировать в отдельной задаче
Верно. И тут мы развиваем интуицию, что можно давать агенту выбирать, а что нужно фиксировать. Но бывают вещи, про которые ты не подумал, а агент не сказал и там может быть что угодно.
Бесконечное уточнение спецификации это опять-таки пример, когда вместо поиска и удаления противоречий ставятся заплатки.
Неправда. Мы тут топим каждый за своё. Ты за противоречия, типа пиши без противоречий. А я за полноту. Агент не путается и не делает заплатки, он уточняет понимание до бесконечности пока спецификация не станет похожей на код. Поэтому и я сказал, что процесс нужно когда-то остановить.
У меня уже сформировалась "чуйка", что агент может сделать, а что нет, какого уровня задачи ему можно давать и какая должна быть детализация постановки. Моя метрика - это усилия. Если понимаю, что проще руками - делаю руками, если быстрее через ИИ - то через ИИ.
А где-то там есть прекрасный мир где "оно само", но я пока смотрю на со скепсисом, т.к. не чувствую, что нейронка может выдать результат нужного качества, сколько её не промтируй.
я понимаю твой путь. Он как раз описан в разделе статьи “Сколько на самом деле стоит “автоматизация””. Это допустимый путь, но это не совсем агентская разработка, на мой взгляд. Если что-то делать вместо агента, когда он делает неправильно. Я призываю сместить фокус на контекст и детерминированную верификацию. Потому что верификации должно быть в несколько раз больше, чем оно было необходимо для человеческой разработки раньше. В том числе простая проверка, что код изменился вместе с тестами. Такой сигнал может призвать человека к review. У меня тоже постоянно встречаются ситуации, когда руками было бы проще. Но я не делаю руками, я начинаю копать, почему с ИИ сложнее, почему он не сделал, что мне надо. И всегда раскапываю.
Ну просто надо не забывать о своей роли кожаного, но умного мешка и строить процесс так, чтобы не вывалиться из лупа, а найти в нем свое место. Модели сейчас реально умные, если им что-то непонятно, они задают правильные вопросы, просто не нужно отдавать им на откуп весь процесс. Сам с этим столкнулся и сделал DCS (см. в статьях, если интересно), вся разработка теперь только так.
Agent Comfort - свойство среды: насколько агенту удобно ориентироваться в контексте, применять доступные инструменты и проверять свою работу. Измеряется оно метрикой First-Prompt Success Rate:
Меня этот кусок зацепил. Делается неявное предположение, что если агенту будет удобно ориентироваться в проекте (т.е. комфортно), то метрика будет 100%. Т.е. агент всегда может справиться с задачей. Но это вообще-то отдельно доказывать надо.
А самое прикольное, что человек тоже обучается и со временем начинает давать задачи с которыми агент справляется и метрика идёт к 100% чисто на чуйке пользователя.
Это в некотром роде переворот моей идеи. Я не говорю, что в комфортной среде метрика будет 100%. Наоборот: высокий FPSR - признак того, что среда комфортна. В обратную сторону это не работает. Зависит также от модели и класса задач, а не только от среды. Про чуйку согласен, что с любым инструментом надо научиться работать. Разница в том, что чуйка живёт в голове у одного человека. Ее нельзя отдать новому члену команды, положить в репозиторий и проверить на CI. Поэтому я вкладываюсь в среду, а не в собственный навык подбирать задачи под агента. В конце концов мы теперь можем разрабатывать в алкогольном опьянении. И в комфортной среде норм получается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш агент не тупой — ему просто неудобно