Four HTTP clients in one repo, and I approved every one of them
Went looking for why a service got slow and found four ways of making an HTTP request in it. A fetch wrapper, axios, and two hand rolled retry loops. Nobody added them in one sitting. Each one arrived in a different session, in a diff that was correct on its own, and I approved all four.
That's the failure mode I didn't see coming with agents. They're good at the task in front of them and they have no opinion about what the repo already does, so every session starts from a blank slate even when the codebase doesn't. Bad code you catch in review. A second correct implementation of something you already have reads fine in a diff, and it only shows up later when a change has to be made in four places.
What's helped is a 40 line conventions file at the root saying what we already use for HTTP, dates, queues and logging, pasted in at the start of anything structural. New duplicates mostly stopped. It does nothing about the ones already in there.
Has anyone found a way to detect these after the fact? Grepping imports catches libraries, it doesn't catch four different retry loops somebody wrote by hand.
Replies
Same failure mode across a few of my repos before I started pinning conventions. What worked was less a conventions file and more a rule that any new dependency needs a one line reason why the existing one in the repo does not cover it, written in the PR description before merge. Cheap to enforce, and it surfaces the duplication at review time instead of three months later when someone is debugging why a service is slow. Detecting the ones already in there is harder, I have not found anything better than grepping for the obvious client libraries then manually checking anything that looks like a hand rolled retry loop, which your fetch wrapper example is exactly the kind that hides from that search.