Why the Best AI Tech Stack Is from 1995 (HTML, CSS, JS, SQL)
I wrote my first line of web code in the late 90s using the <marquee> tag in Netscape Navigator on a CRT monitor. Around the same time, I was writing database applications on Windows 3.11 using FoxPro. Thirty years later, building production software with AI coding assistants (Gemini, Claude, Antigravity) has led me to an unexpected realization: the most effective tech stack for modern AI development is not a new AI-native framework, but the exact web primitives we started with in 1995.
When an AI coding model outputs an interface, renders a dashboard, or formats data, its native language is standard HTML, semantic CSS, and direct SQL. Yet over the last fifteen years, frontend engineering convinced itself that building a web page requires a dozen build tools, multi-gigabyte node_modules folders, client-server hydration boundaries, and fragile compilation pipelines.
In the AI era, for a one-person development team, that modern framework complexity is an active liability. The fastest way to build software with AI is to strip away the build steps and return to fundamentals.
The Big Tech Illusion: Who Were Frameworks Built For?
To understand why modern web development feels so heavy, look at why today's dominant frameworks were created in the first place.
React, Next.js, Webpack, microservices, complex ORMs, and CSS-in-JS were not designed to make individual developers build faster. They were invented to solve human coordination problems inside 500-person Big Tech organizations. They exist so large engineering departments at Google or Meta can isolate hundreds of junior developers into strict component silos so nobody accidentally breaks the main branch.
For a team of 500 engineers, the coordination overhead of strict typing boundaries, abstract configuration layers, and rigid compilation checks makes sense. But when you are a one-person dev team working with AI agents, that exact same framework architecture becomes quicksand.
Every layer of framework abstraction introduces three catastrophic penalties for AI workflows:
- Context Window Tax: Heavy frameworks consume precious LLM attention tokens on boilerplate, routing conventions, server/client boundary directives, and obscure configuration files before the model even writes a single line of business logic.
- The Hallucination Surface: Meta-frameworks churn their APIs constantly. An AI model trying to write Next.js or React Server Components frequently mixes up patterns between version 13, 14, and 15, getting trapped in recursive debugging loops over hydration mismatches and cache invalidation bugs.
- Fragile Feedback Loops: When an AI agent generates code with complex bundlers and build tools, a single missing peer dependency or webpack error stops execution cold. The agent spends more time troubleshooting the build environment than implementing features.
The 30-Year Training Moat: Why LLMs Master 1995 Primitives
LLMs are statistical pattern engines trained on the entire history of public code. They have digested thirty years of raw HTML, semantic CSS, vanilla JavaScript, POSIX shell commands, and ANSI SQL.
The Lindy Effect applies directly to AI training data: technologies that have survived for thirty years have accumulated orders of magnitude more high-quality reference material than a framework invented three years ago.
- HTML & CSS: An LLM's statistical confidence when generating semantic HTML markup and CSS variables is virtually 100%. The model understands layout, accessibility, and visual styling without needing a compiler.
- SQL: Given a clean relational schema with explicit constraints and foreign keys, an AI agent writes joins, aggregations, and CTEs reliably on the first attempt. Heavy ORMs and abstraction layers only insert friction between the model and the database engine.
- TypeScript on Bun: Standard typed JavaScript executed directly in Bun provides the strict type safety AI models need without the baggage of Babel or Webpack.
When you ask an AI assistant to build a feature using native web primitives, it outputs working code on shot number one. When you ask it to navigate a complex framework wrapper, it spends half its energy fighting the framework's internal abstractions.
The RAG Illusion: Why the File Format is the Memory
The AI industry is currently repeating the exact same architectural mistake with memory that frontend engineering made with JavaScript frameworks: creating elaborate pipelines to solve simple data problems.
To give AI agents persistent memory, modern tutorials insist on deploying complex Retrieval-Augmented Generation (RAG) stacks: pgvector, Pinecone, embedding chunkers, re-ranking layers, and graph databases. These systems shred coherent documents into isolated 200-word snippets, stripping away the surrounding narrative context and frequently confusing the models they are meant to assist.
As software engineer Cal Paterson observed in his analysis of agent memory as a file format, memory should be a simple data structure, not an intricate multi-stage process. Quoting Fred Brooks from The Mythical Man-Month: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
In our 1995-inspired architecture, we run no Vector DB and maintain no RAG pipeline. The file on disk is the memory:
- The Output is the Memory: When an AI agent finishes drafting a blog post, documenting an architecture decision (ADR), or indexing a legal docket, it writes a clean Markdown or semantic HTML file to the repository. That output immediately becomes the ground-truth memory for the next agent.
- Prose Over Chunks: Frontier models with 1M to 2M token context windows digest entire articles and codebases in a single pass. Preserving intact prose keeps all narrative logic, chronology, and nuance intact, eliminating the context fragmentation caused by naive vector chunking.
- More Model, Less Mechanism: LLMs are already exceptionally proficient at standard POSIX tools (
grep,find,cat), raw Markdown, and SQLite queries. Relying on simple files on local disk gives agents the freedom to inspect and search data directly without fighting proprietary vector APIs.
When you treat memory as plain text files in a Git repository, your system scales automatically as models improve, without requiring a rewrite of your retrieval infrastructure.
This exact philosophy is codified in my open-source agent orchestration harness, Konductor (konductor-workflow). Instead of orchestrating multi-agent systems with heavy message brokers, Redis caches, and vector databases, Konductor runs entirely on plain Markdown files inside your repository:
KONDUCTOR.mddefines the agent's operating contract and architectural guardrails.CHECK_IN.mdtracks active-cycle state and atomic handoffs between coding sessions.docs/ADR-*.mdstores immutable architectural decisions that agents reference directly on demand.
There are no embeddings to synchronize, no vector databases to corrupt, and zero platform lock-in. The Git repository itself is the memory bus, the state machine, and the orchestration harness.
The FoxPro Paradox: 1995 on Windows 3.11 vs. Today
My programming journey started on Windows 3.11 in my early teens writing FoxPro. FoxPro was fast and purpose-built for working with structured data before Microsoft acquired and eventually sunsetted it.
The superpower of FoxPro was simplicity. While enterprise databases required dedicated mainframe servers running Oracle or DB2, FoxPro stored data in .dbf files directly on local disk. A single machine could run full SQL queries without a database daemon, network configuration, or dedicated system administrator. A teenager on a 486 PC could build, test, and ship a complete inventory management system without external dependencies.
Over the subsequent twenty-five years, the industry moved in the opposite direction. We added layers of network latency, cloud database clusters, distributed microservices, and client-side state hydration to solve problems that most applications never had.
Today, SQLite paired with modern runtimes has brought us right back to that original FoxPro advantage: local disk storage, direct queries, zero network hops, and instant execution.
The 2026 One-Person Stack: 1995 Fundamentals on Modern Steroids
Stripping away framework bloat does not mean writing ugly or archaic software. It means picking tools that amplify AI velocity rather than fighting it.
Here is the exact production architecture I use across client and personal software:
| Layer | The Framework Way | The AI Primitive Stack | Why AI Agents Excel Here |
|---|---|---|---|
| Frontend Layout | Tailwind utility soup / CSS-in-JS | BulmaCSS / Semantic CSS | Clean semantic class names that models parse and modify without token bloat. |
| Interactivity | Complex React / Next.js SPA | Alpine.js / Vanilla JS | Reactivity declared directly in HTML (x-data, x-show) with zero build step. |
| Backend & API | Node.js + Webpack + Docker | Bun + Hono (TypeScript) | Instant cold starts, native TypeScript execution, and single-file clarity. |
| Database | Cloud RDS / Managed NoSQL | SQLite / Embedded SQL | Zero network latency, single local file, backups via simple file copy. |
| Agent Memory | Pinecone / Vector DB / RAG Pipelines | Plain Markdown & HTML | Zero chunking or embedding drift. The output file on disk is the memory itself. |
With this setup, a single .sqlite file on disk comfortably handles thousands of queries per second with sub-millisecond response times. There are no Docker containers to maintain, no cloud database bills, and no network latency between the app and the database.
For static content, this entire blog uses no database at all. It is plain HTML, CSS, and client-side JavaScript served directly to the browser with zero build step.
Real-World Production Velocity
Dropping framework overhead is not theoretical. Over the past two years, adopting this lean architecture transformed what I can ship as a solo engineer pairing with AI assistants:
- Full LMS Platforms: Architected, built, and deployed to production in days.
- Interactive Content Portals: Designed and launched in under 48 hours.
- Custom ERP Systems: Delivered from schema to working production software in two to three weeks.
When you remove the compilation layer, you remove the primary barrier between your AI assistant and working software. The agent writes HTML, styles it with CSS, wires reactivity with Alpine, and queries SQLite directly. The entire loop executes instantly in the browser.
The 2056 Test: Building Software That Lasts
Every time you add a framework dependency to your project, you start a countdown clock. How long until that package is abandoned? How long until a major version upgrade breaks your build configuration?
Web applications built with standard HTML, vanilla CSS, and direct SQL do not suffer from bitrot. An HTML file written in 1995 still opens and renders perfectly in every browser today. An HTML file written in 2026 will render just as reliably in 2056.
If you want to build software with AI that is fast to create today and still maintainable thirty years from now, stop adding layers. Bet on the primitives that have already survived three decades.