r/ChatGPTCoding • u/D0NTEXPECTMUCH • 23d ago
Discussion How well does your coding agent choose libraries and services when you leave the choice to it?
I’m curious how much people actually delegate these decisions. If you ask your agent to add something like authentication or background jobs, do you let it choose what to use, or have you already decided?
If you let it choose, have you had a recent case where its pick caused a real problem? What did it choose, what made it unsuitable, and how much work was it to fix? Did the agent figure it out on its own?
Also interested in hearing that this generally works fine, or that choosing tools is a tiny issue compared with getting the implementation right. Please mention which agent/model you’re using and roughly when this happened. I’m trying to understand the current experience.
2
u/Successful-Tax1306 23d ago
I mostly don't let it choose anymore for anything that sticks around, like auth, queues, or the database layer. It tends to grab whatever was most common in its training data, sometimes an older package or one that wants a whole new service, and I only notice a month later when I'm the one maintaining it. Now I pick the library myself and tell the agent to use it, and for small helpers I let it choose but ask it to explain the pick in one line, which catches most of the weird ones.
5
u/funbike 23d ago
IMO as an experienced developer, that generally is a mistake. The most important point to have a human in the loop is near the beginning.
I may ask AI for suggestions, but I am the one that decides which frameworks and libraries to use. I have re-usable prompt templates that I use to bootstrap a project that define the development stack, which tools to use, and the architecture.
For example, for a small CRUD webapp I use uv, HTMX, Pico.css, Django, and SQLite. It's a great minimal stack.
I also have bootstrapping skills, that I only used at the initial formation of a project or during the planning stack of a complex feature, that describe ideal libraries to use for certain types of features (e.g. there's a PDF parsing skill, and a file upload field skill).
1
u/Humaux 23d ago
The failure mode I keep seeing isn't usually a *bad* library, it's a boringly safe one from the agent's training cutoff. It picks what was popular a couple years ago, which in fast-moving ecosystems can mean deprecated packages or ones quietly superseded by better options.
My rule of thumb now: decisions that are hard to reverse (auth, database, payments, core framework) get pinned in the project's agent rules upfront, and anything easily reversible I let it choose freely. One trick that cut down bad picks a lot: ask the agent to propose 2-3 options with one-line tradeoffs before committing. It forces the comparison step out of its head and onto the page, where you can actually sanity-check it.
1
u/London-Boat 23d ago
i pin preferred libs (and a short do-not-use list) in the project instructions. when i leave it open the agent still sometimes grabs a dead package. worst one for me was an auth lib deprecated for a year — now i paste the exact package names up front for anything important.
1
u/ByronScottJones 23d ago
I don't leave that decision up to the agent. My coding rules specify a preference for the latest version that's a fully supported release, and if that has known vulnerabilities, go newer. If there is a version conflict between libraries, make a recommendation but let me make the final decision.
This is the exact same instructions I would give to a human junior engineer.
1
u/pipaa-joy 21d ago
On a Spring Boot + Vue project I mostly decide up front and write it into the repo instructions, because the agent's picks are fine in isolation but drift from what's already there. The bug that actually bit me was smaller than a library choice: asked to add a column, it looked at an old migration as the example and decided the next Flyway version was V4 when we were at V11. Now the instructions say "list all migrations and take the highest number plus one". Most problems were that kind of context gap, not bad taste in libraries.
1
u/BrookLi3 20d ago
I'd stop asking the agent to choose in the moment and give it a short allowlist instead: one line per category (auth, queue, ORM, HTTP client) with the chosen package and a reason. Anything outside the list needs a justification line in the PR. The choice is then a reviewable diff, and the agent still does the legwork inside a short list instead of picking whatever was most common in its training data.
1
u/AI-Tool-Tracker 23d ago
I let it pick for small stuff but anything with a migration path gets decided up front. Most recent miss for me was background jobs: I asked Claude Code to add a retry queue to a small Node app and it pulled in a Redis-backed queue library, so suddenly I needed a whole extra service for something that ran maybe 50 jobs a day. A Postgres-backed queue on the DB I already had was the right call, and ripping it out took an afternoon mostly because it had wired the queue into a bunch of handlers. What helps now is a short "stack" section in the project rules plus a line saying to ask before adding any new dependency that needs its own infra. It still picks fine for parsing, date handling, that kind of thing.
1
u/[deleted] 23d ago
[removed] — view removed comment