124
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 18 Sep 2026
124 points (97.0% liked)
Programming
28522 readers
1572 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
I read a retrospective from another team yesterday. They were preparing a demo for leadership and apparently it didn't go so well. There were many reasons like last minute changes in requirements but one line was interesting for this discussion: The use of the LLM agents caused confusion about who is fixing which bug and taking on which tasks. The agents act like they're alone in the codebase and keep adding and changing code broadly whenever they see an opportunity for improvement. And that often without specifically being prompted to do so. Now if you have multiple team members collaborating on a project with each their agents, chaos ensues because the agents are not coordinating and the diffs/commits become insane and the team doesn't fully understand them.
This actually results in a necessity to test more and longer because nobody knows which bugs have really been fixed now and rapidly preparing for a release or a demo becomes more difficult than before.
In my opinion an LLM can be very useful to rapidly prototype something. Especially with an API or language you're not familiar with. But for Production it's still a huge risk to push code you don't understand.
Those engineers are bad