04 — Tech Stack and Coding — Popularity Is a Feature

My instinct to pick interesting tools kept costing me in errors, and the fix was the opposite of what felt right. Writing it down forced the idea into focus: when the AI is the one writing the code, popularity is a feature, not a compromise. The model has seen exponentially more React than some niche framework, so its React is sharper, its errors are rarer, and the answers it gives are more likely to match reality. The roadmap states it flatly: _AI works better with a widely-used, well-documented stack_ — and choosing novelty is choosing to fight the tool.

The framing that clicked: the AI's accuracy is a function of how much training data it has on the path I chose. The well-trodden path has the most data. That's the whole argument.

Why popularity matters more with AI than without

Without AI, picking a niche stack is a personal trade-off — I'm betting the tool's elegance is worth a smaller community. With AI, the trade-off gets worse, because the AI is not a neutral participant. It is a statistical model, and statistics favors the common case [2][3].

• More training data → fewer hallucinated APIs. On React + Next.js, the model knows the current hooks, the App Router conventions, the common gotchas. On a niche framework, it confidently invents APIs that don't exist, because the real ones appeared rarely in its training.
• More Stack Overflow / GitHub history → better debugging. When I paste an error, the model has probably seen that exact error before for the popular stack. For the niche one, it guesses.
• More package churn absorbed. Popular stacks have many people flagging when an API changed between versions. The model's prior on "this is the v3 way, not the v2 way" is much stronger.

This isn't a taste argument. The GitHub Octoverse data is consistent with the roadmap's claim: TypeScript and Python sit at the top of language activity, and the rise of AI-assisted development is reinforcing the concentration around a few stacks [3]. The loop is self-reinforcing — more code in a stack means more training data, which means better AI for that stack, which means more code in that stack.

State your preferences before the first prompt

The second discipline the roadmap names, and I had to learn the hard way: write down your coding preferences and give them to the AI before you start, otherwise it will make its own choices [1]. Left to itself, the AI reaches for the statistically most common pattern — which may not be mine. It will pick a styling approach, a state-management library, a folder structure, an error-handling style, all without asking. By the time I notice, those decisions are woven through the codebase.

The fix is a short preferences document — a paragraph or a small file — handed to the AI at the start of every session:

Preferences for this project:
- Next.js App Router, TypeScript strict, Tailwind for styling
- Server Components by default; 'use client' only when needed
- Prefer named exports; no default exports for components
- Error states handled with Result-style returns, not thrown exceptions
- Files small and modular — one component per file

That paragraph is the difference between a codebase that looks like mine and one that looks like the model's average of a million repos. It's also the cheapest version of consistency — stated once, applied everywhere.

Keep it small and modular — then refactor on a schedule

The roadmap's third point is the one I keep relearning: always tell the AI to keep code small and modular. It will try to put everything in one file if you let it [1]. The model's default is to solve the immediate request in the most self-contained way — which means a 600-line file with everything inline. That's fine for a prototype and a disaster for a codebase.

The discipline comes in two parts:

• Per-prompt: ask for modularity. Every build prompt includes "keep functions small, one responsibility per file, extract reusable pieces." Stating it once at the start of a project is not enough; the model drifts back toward monolithic files within a session.
• On a schedule: refactor sessions. _Do refactoring sessions regularly, ask AI to review the codebase, and clean up the mess. If you skip this, things get out of control fast_ [1]. The honest version: AI-generated codebases accumulate duplication faster than hand-written ones, because each prompt is solved fresh without memory of the last. A weekly pass where I ask the AI to review the codebase for duplication, dead code, and inconsistency is the only thing that keeps the slope from becoming vertical.

The way of thinking I keep: an AI codebase is a garden, not a building. It grows fast in every direction. Without regular weeding — refactor sessions — it becomes impassable, and the AI's own output gets worse because it's working inside its own mess.

How I use this

Three habits, in order. First, default to the popular stack on any new AI-assisted project — React/Next.js/TypeScript on the front, Python or Node on the back, Tailwind for styling — and treat the choice to use something niche as a deliberate bet I'll pay for in error rate. Second, write a one-paragraph preferences doc and paste it into every session before any code. Third, schedule a weekly refactor pass where the AI reviews its own output for duplication and mess, because nothing else keeps an AI codebase maintainable.

References

[1] roadmap.sh, "Tech Stack and Coding," 2026. [Online]. Available: https://roadmap.sh/vibe-coding/tech-stack-and-coding

[2] DEV Community, "Web Frameworks 2026: Future-Proofing Enterprise Tech Stack," 2026. [Online]. Available: https://dev.to/devin-rosario/web-frameworks-2026-future-proofing-enterprise-tech-stack-4l03

[3] GitHub, "TypeScript, Python, and the AI Feedback Loop Changing Software Development," The Octoverse, 2025. [Online]. Available: https://github.blog/news-insights/octoverse/typescript-python-and-the-ai-feedback-loop-changing-software-development/