Comment by skeledrew
1 day ago
Sounds like better guidance needed. You have to always keep in mind that the agent doesn't understand the repo from the "business" perspective, only from the functional. You have to give it the why, and ensure a shared understanding. Whenever I plan epics with an agent I always check on acceptance criteria before the tickets hit the tracker, so I know it gets the business aspect. Tends to lead to far better code.
Yes, I understand that. And yet I keep opening up repos written by other people that have insane tests. And sometimes I even come across people who managed to notice it but thought it was a good thing because "moar tests == moar good"
Just because *you* can avoid it doesn't mean it's not an issue with the tooling.
Nah that's not a tooling issue (although - more - mitigation tools can always be built). That's a people issue. And it still may not be their fault per se, like an accountant might have read in a random programming blog that tests are good, so when they decide to "vibe code an award-winning accounting tool", they're going to stick a "ensure there are lots of tests" into that prompt.