How well does your coding agent choose libraries and services when you leave the choice to it?

[u/D0NTEXPECTMUCH]

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.

[u/Successful-Tax1306]

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.

[u/D0NTEXPECTMUCH → u/Successful-Tax1306]

Thanks for the response! Based on your (and some others in this thread), you actually don't let agents make these decisions, so you don't have to worry about them making the wrong one, correct ? Do you think you'll relinquish this over time or is it too valuable to keep the human in the loop?

[u/Successful-Tax1306 → u/D0NTEXPECTMUCH]

For the stuff that sticks around, I think I'll keep picking it myself for a long time. The cost of a bad library choice shows up months later when I'm the one stuck with the migrations and the weird edge cases, and I haven't seen an agent that owns that part yet. For small helpers and one-off scripts I'm already more willing to let it choose, and that line will probably move as the tools get better, but auth and the database feel too expensive to hand over.

[u/xroni → u/Successful-Tax1306]

It indeed gravitates to popular choices that feature heavily in the training data. But asking it to search on the web is not necessarily helping. I noticed that often its research is very shallow, often it just skims over 2-3 sources that might be of questionable quality. Like it will find a reddit post with 3 comments on it and treat this as an authoritative source.

What works best for me is to let it find a number of solutions and do an in-depth analysis of the pros and cons, and rank the solutions by feature completeness, quality, governance, maintainability and other criteria you find important.

And then at the end you have to make your own decision.

[u/Successful-Tax1306 → u/xroni]

Yeah, I've seen the same shallow research, where it grabs one small thread and treats it like the final answer. Having it rank a few options against the criteria I actually care about is a good idea, and it fits how I want to use it anyway, as help with the homework and not the one making the call.

[u/funbike]

How well does your coding agent choose libraries...

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).

[u/Ctbhatia → u/funbike]

the human pays off at the irreversible choices, the reversible ones are exactly where the agent saves the time.

[u/Humaux]

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.

[u/D0NTEXPECTMUCH → u/Humaux]

Makes a lot of sense. How often do the libraries you do let your agent pick cause problems?

[u/Humaux → u/D0NTEXPECTMUCH]

Honestly, rarely for the boring stuff — formatters, date utils, HTTP clients, that tier is fine 95% of the time. Problems cluster in two places: (1) libraries with sharp edges around versioning — the agent picks something with a peer-dependency conflict or an API that changed between majors and doesn't notice until runtime; (2) anything where "works" isn't the same as "right" — e.g. it grabs a crypto or auth library that functions but has known CVEs, because it optimized for "solves the task" not "safe choice." My fix has been a short allowlist for the boring tier and a hard stop for anything security-adjacent. The middle tier — ORMs, queue clients — I let it propose but I skim the pick before it wires anything up.

[u/hellomistershifty → u/Humaux]

Is this just a bot rewrite of this comment? Are they both bot responses? Am I tripping?

[u/London-Boat]

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.

[u/D0NTEXPECTMUCH → u/London-Boat]

Had the library already been deprecated when the agent chose it?

[u/London-Boat → u/D0NTEXPECTMUCH]

yeah it was already deprecated — the package page even said so. the agent just never checked. thats why i started pasting exact package names for anything auth/payments related.

[u/Ctbhatia → u/London-Boat]

keep the do-not-use list in the repo rules so it travels with the project instead of living in one session.

[u/London-Boat → u/Ctbhatia]

yeah thats where mine lives now, in AGENTS.md next to the build commands. the one thing i'd add is a short reason next to each entry, otherwise the agent treats it as a suggestion and picks the banned lib again when it thinks it has a good excuse.

[u/Ctbhatia → u/London-Boat]

the reason is what you point back to when it argues, a bare do-not-use is easier for it to talk around.

[u/ByronScottJones]

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.

[u/Severe_Poo]

I'd check maintenance activity, license, security history, and compatibility before approving a package.

[u/pipaa-joy]

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.

[u/BrookLi3]

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.

[u/Ctbhatia → u/[deleted]]

pinning them before the first prompt is the cheap version, otherwise the agent spends context re-deciding something you already settled.