Why AI coding tools overengineer everything, and how to stop it
Developers are like kids. Show them something new and shiny, and they want it. Show them what Google or Facebook is building with, and they want it even more.
That's not a criticism. Curiosity is what makes good engineers. But it creates a pattern: a large company releases a framework, the community adopts it, tutorials multiply, GitHub fills with examples, and within two years it's the default answer to every frontend question, regardless of whether it fits.
React is the obvious case. Facebook built it to manage a genuinely complex, stateful interface at massive scale. Then everyone else decided they needed it too. Small agencies, solo developers, internal dashboards for 12 users. Some teams rewrote perfectly working applications in React not because the old version had problems, but because the old stack wasn't fashionable anymore.
Why this became an AI problem
LLMs learn from code. The models powering tools like Copilot, Cursor, and Claude were trained on GitHub, Stack Overflow, and millions of tutorials. Lots of that code uses React. Lots of those tutorials default to Next.js. The training data reflects the industry's collective habit of reaching for complex stacks, not the range of what's actually appropriate.
So when you ask an AI coding tool to "build a frontend," it reaches for React. Not because it evaluated your requirements. Because that's what most of the code it learned from used.
The result is predictable. A simple one-page marketing site gets scaffolded with React, Vite, a component library, and a package.json with 40 dependencies. A contact form becomes an SPA. An internal tool that three people will use gets a full Next.js setup with SSR, hydration decisions, and a separate deployment pipeline.
What this actually costs
More code means more tokens. More tokens means slower responses, higher API costs, and longer context windows that push the relevant parts of your prompt further from the model's attention.
The build step adds CI/CD complexity that didn't need to exist. You now have a separate frontend deployment, a bundler to configure, and a local dev environment that requires Node, a build command, and occasionally a ritual to get running on a new machine.
The implement-build-test cycle gets longer. What could have been a single file deployable with one command is now a multi-stage pipeline with type checks, linting, bundle analysis, and a staging environment.
None of this was necessary.
The fix is simple
Tell the AI what stack to use. Every time. Before anything else.
AI coding tools comply when you give them constraints. "Build this as a single TypeScript file using Bun and Hono, server-rendered HTML, Alpine.js for interactivity" will produce exactly that. Without the constraint, you get React.
The broader discipline is deciding your stack before starting a project and sticking to it. Some of these choices involve genuine trade-offs, and some are personal preference. If you're not sure what fits your project, ask someone with experience rather than letting a trending GitHub repo or an AI default decide for you.
What we use at RightTech
These are the choices we made for ourselves, after working out what actually fits.
For databases: PostgreSQL or SQLite. For back-end: Python with FastAPI, Bottle, or Litestar, or TypeScript with Bun and Hono. For web front-ends: HTMX, Alpine.js, and Flyonui or Syncfusion. For desktop: C#. For mobile: Flutter.
Each piece was chosen because it fits the work, deploys simply, and doesn't introduce complexity that wasn't asked for. When we use AI coding tools, we specify this stack upfront. The output is leaner, the build is simpler, and the result doesn't look like a framework demo.
That's the whole point.