Comments 4
Нейросеть налила слишком много воды.
Что тут основная мысль, сжато?
И ещё: статья сплошное прожектерство: статья про новый процесс, который нигде в реальности не используется. Что из этого опробовано в реальности?
Собственно, основная мысль размещена в самом начале
Основная идея. Чтобы получить код, соответствующий требованиям, не нужно изобретать новую методологию. Управление требованиями и их изменением, независимая верификация, контроль кода, статистический контроль процесса — всё это давно разработано, формализовано в стандартах и опробовано на людях; в своих принципах эта дисциплина переносится на агентов целиком. Систему агентской разработки следует строить из тех же контуров. Но агент как исполнитель обладает свойствами, отличными от свойств человека-исполнителя, и эти свойства смещают акценты внутри знакомых контуров: значительная часть того, что в человеческой разработке получалась «сама собой» — за счёт памяти исполнителей, их вопросов, неловкости перед коллегами, выученных привычек, — для агента не существует, и соответствующая функция должна исполняться системой явно, как механически закреплённый элемент.
Вы видите в этом всем много воды - я то, с чем сталкиваюсь каждый день, отлаживая процесс производства.
Процесс, который описан - он ни разу не новый. В общем виде это стандартный процесс разработки ПО.
А вот новой реализацией данного процесса для управления агенткой разработкой мы сейчас занимаемся. Готовим к выпуску продукт, который будет реализовывать комплексный процесс разработки программного обеспечения. Первую версию планируем выпусть через 1-2 месяца.
объяснённое один раз не закрепляется и на следующей задаче само не применяется
Это разве легко не решается на уровне системного промпта, к которому или к его части, можно заставить систему обращаться во всех релевантных случаях? И потом это, думаю, сильно зависит от используемой модели. И ещё есть дообучение, если надо чтобы "само". Но это же очень рискованно с кодом, потому лучше сохранять ручной контроль.
В описанной системе независимость проверяющего — необходимое условие, но, кажется, есть ещё один риск: исполнитель и проверяющий могут быть независимыми процессами, но использовать один и тот же ошибочный oracle. Тогда трассировка будет полной, все проверки зелёными, а исходное заблуждение просто пройдёт через весь конвейер. Я бы добавил проверку самих критериев: негативные примеры, mutation probes и явную версию oracle, на основании которой был вынесен вердикт. Тогда можно различить «требование связано с тестом» и «тест действительно способен поймать правдоподобное нарушение требования».
Особенности агентской разработки ПО, обеспечивающей соответствие замыслу и требованиям