На этот пост в почтовой рассылке Golang Nuts уже немало народу обратило внимание, и про него (в том числе) я рассказывал на подкасте у Эдгара Сипки (скоро в эфире).
Если коротко: у LLM нет прав, значит нет ответственности. Если вы приносите код в Open Source проекты, то вы отвечаете за него, вне зависимости от того с помощью каких инструментов он был сделан. Под этим подразумевается что а) вы старались над корректностью-читаемостью-производительностью кода б) вы понимаете, что он делает с) вы понимаете как отвечать на вопросы по этому коду. Все эти пункты критичны, тк именно код, а не ваши спецификации для Opus/Codex/Gemini, будут поддерживать в дальнейшем.
Нет спора о том, что LLM хороши для прототипирования и one-off проектов, где понятие «долгосрочная поддержка» не существует и/или не имеет смысла. Но если вы хотите «навайбкодить то самое изменение» в большой и сложный Open Source проект, но не готовы разбираться и прикладывать усилий для понимания его проблематики, то лучше воздержитесь от этой идеи. Сэкономите и своё время и время тех кто ведёт сий проект и его код.
П.С. Проблематикой обучения LLM на устаревших данных озаботилась и команда Golang, о чём напишу в следующем посте.
Post #119
3.72K
Код и Капуста AI или не AI Весьма интересное обсуждение - стоит ли использовать AI для разработки Go? Рас Кокс очень обстоятельно отвечает всем интересующимся: засуньте уже себе в ...! На саммо деле, нет конечно, все очень прилично, но суть примерно как я описал выше.…Telegram Эдгар Сипки Про AI, DevTools и разработку: как строить продукты и инженерные workflow. Связь: @zergsLaw Сайт: https://sipki.online/
- 👍 17
- ❤ 1