LLM говнокодит не хуже людей.
### 🤖 LLM говнокодит не хуже людей. Только быстрее
Полгода назад я решил попробовать писать свой проект с помощью LLM-агентов. Первое время это было похоже на волшебство: фичи появлялись со скоростью света, и я за неделю делал больше, чем раньше небольшая команда. Но вскоре начались проблемы. Каждое новое изменение начинало ломать старые функции, и я проводил больше времени, разгребая последствия, чем создавая что-то новое.
Оказалось, что LLM, как и люди, не работает с плохой архитектурой. Все классические принципы, такие как SOLID и чистая архитектура, стали ещё важнее. Без них LLM теряется в коде, как новичок в команде, и начинает делать всё на ощупь. В итоге, скорость работы LLM падает, и весь проект превращается в болото, но не за три года, а за три месяца. Это происходит потому, что LLM обучен на коде из GitHub, где хорошего кода меньше, чем хотелось бы.
> «LLM обучен на человеческом коде с GitHub — включая весь говнокод, которого там статистически больше, чем хорошего кода.»
LLM может легко справляться с задачами, если код хорошо структурирован и изменения локальны. Классические принципы разработки снова в моде: они делают код понятным не только для будущих поколений разработчиков, но и для LLM.
◾️ Проект: сервис AI-обработки изображений
◾️ Бэкэнд: Symfony
◾️ Фронтенд: Next.js
Так что, если вы хотите, чтобы ваш LLM-код не стал очередным легаси, не забывайте о старых добрых принципах. А у вас был опыт работы с LLM, который закончился в болоте?
Подписаться на «Нейро Пульс»
Первоисточник ↗
Полгода назад я решил попробовать писать свой проект с помощью LLM-агентов. Первое время это было похоже на волшебство: фичи появлялись со скоростью света, и я за неделю делал больше, чем раньше небольшая команда. Но вскоре начались проблемы. Каждое новое изменение начинало ломать старые функции, и я проводил больше времени, разгребая последствия, чем создавая что-то новое.
Оказалось, что LLM, как и люди, не работает с плохой архитектурой. Все классические принципы, такие как SOLID и чистая архитектура, стали ещё важнее. Без них LLM теряется в коде, как новичок в команде, и начинает делать всё на ощупь. В итоге, скорость работы LLM падает, и весь проект превращается в болото, но не за три года, а за три месяца. Это происходит потому, что LLM обучен на коде из GitHub, где хорошего кода меньше, чем хотелось бы.
> «LLM обучен на человеческом коде с GitHub — включая весь говнокод, которого там статистически больше, чем хорошего кода.»
LLM может легко справляться с задачами, если код хорошо структурирован и изменения локальны. Классические принципы разработки снова в моде: они делают код понятным не только для будущих поколений разработчиков, но и для LLM.
◾️ Проект: сервис AI-обработки изображений
◾️ Бэкэнд: Symfony
◾️ Фронтенд: Next.js
Так что, если вы хотите, чтобы ваш LLM-код не стал очередным легаси, не забывайте о старых добрых принципах. А у вас был опыт работы с LLM, который закончился в болоте?
Пока нет комментариев — будьте первым.