Should an AI Coding Agent Choose Your Tech Stack?

Short answer: let an AI coding agent choose your tech stack for anything you could rip out in an afternoon, and decide the rest yourself. The split is not about how technical the choice is. It is about how expensive it is to reverse. Agents are good at picking a date library and bad at picking a database, and the reason has nothing to do with intelligence.

Why the reversibility line is the right one

An agent recommending a stack is doing something closer to recall than reasoning. It has read an enormous amount of code and writing about code, and it produces what the consensus looked like at its training cutoff, weighted by how often people wrote about it. That is a genuinely useful signal. Popular choices have documentation, answered questions, and fewer sharp edges, and an agent will write better code in a framework it has seen a million times than in your favourite obscure one.

What that signal does not contain is your situation. It does not know your team has three people who all know Postgres and none who know Kafka. It does not know your compliance officer will not sign off on that vendor. It does not know you are optimising for being acquirable in eighteen months. Those are the inputs that decide architecture, and none of them are in the training data.

So the useful question is not whether the agent is right. It is what happens if it is wrong.

The decision matrix

The rows near the top are where agents earn their keep. The rows near the bottom are one-way doors, and a one-way door deserves a human who will still be there in a year to live with it. The monolith question in particular has more to do with team size than technology, which is why monolith versus microservices for an AI built app is worth reading before an agent quietly answers it for you.

Three failure modes worth knowing by name

Frozen consensus. The agent recommends what was dominant when its training data was assembled. In a fast-moving ecosystem that can be two versions and one major migration ago. It is not lying, it is quoting a snapshot.

Popularity as proxy for fit. Volume of discussion is not suitability. The most written-about queueing system is a poor default for an app with two hundred users, and an agent has no way to feel that difference in scale.

Silent accretion. This is the one that actually hurts. Nobody asks the agent to choose a stack. It just adds a package here to solve a problem, another there, and by week four you have three overlapping ways to make an HTTP request and a state management library nobody chose. That drift is worth defending against explicitly, and stopping agents from adding dependencies covers the guardrails.

There is a fourth risk that is nobody's fault: vendors remove things. OpenAI's own deprecations page is a standing reminder that an API you build on can be given a shutdown date. That is an argument for putting your own thin interface in front of anything external, whoever chose it.

Use the agent as a research assistant instead

The highest-value way to use an agent on stack questions is not to ask what to pick. Ask it to argue. Three prompts that consistently produce something useful:

• Give me the three strongest arguments against the option you just recommended, assuming a two person team.

• What would have to be true about our traffic, team or budget for this to be the wrong choice?

• Describe the migration path off this in eighteen months. What is the hardest part?

That third one is the tell. If the agent cannot describe an exit, you are looking at a one-way door that was not labelled as one. Making the agent write its reasoning down before it writes code is the same discipline as reviewing an agent plan before it runs.

The check before you accept a recommendation

Four questions. If you cannot answer all four, the decision is not ready, whoever made it.

1. How long would removing this take in month six, with real users on it? Anything past a week is yours to decide.

2. Who on the team can debug it at 2am? If the honest answer is nobody, popularity did not help you.

3. Is the recommendation current? Check the release notes yourself. This is the single fastest way to catch frozen consensus.

4. Does it agree with what you already run? A second database because one library preferred it is a real cost that never appears in the recommendation.

Database choice earns its own version of that checklist, which is covered in how to choose a database for an AI built app. For everything else about working alongside these tools day to day, the AI coding tools pillar is the wider map.

The pattern that works in practice is unglamorous. You decide the handful of choices that are expensive to undo, write them down where the agent can read them, and let it move fast inside those walls. That is a smaller role than picking the stack, and it is the one where these tools are genuinely excellent.