The AI-Ready Stack: Why Most Frameworks Are Built for Humans, Not Agents
20

The AI-Ready Stack: Why Most Frameworks Are Built for Humans, Not Agents

A solo developer's perspective on choosing the right framework stack for AI-assisted development. What works, what's overkill, and where the industry is heading.

The AI-Ready Stack: Why Most Frameworks Are Built for Humans, Not Agents

By Batyr Akmuradov, CEO of BridgeCore SYSTEMS — building ERP and EdTech platforms in Turkmenistan with AI-assisted development.

How I Got Here

I didn't choose my stack because some article told me to.

I started with Django and Django Template Language (DTL). It worked. But something always felt heavy — too much magic, too many files, too much ceremony just to add a simple endpoint.

So I searched for something lighter. Somehow I stumbled upon Elysia.js. A friend recommended Vue.js. I evolved to Nuxt 3. And without realizing it, I ended up with exactly the right stack for the AI era.

Today I run two production applications — an ERP system for industrial enterprises and a language school platform — as a solo developer, using Claude Code as my primary development engine.

This post is what I learned.

The Core Insight: Frameworks Were Built for Human Teams

Think about why GitHub, Slack, Jira, and heavy frameworks like NestJS or Spring exist. They exist to solve one problem: coordinating humans.

  • GitHub prevents 10 developers from overwriting each other's code.
  • Slack lets a distributed team communicate asynchronously.
  • Jira helps a manager track who is doing what.
  • NestJS enforces structure so a team of 5 doesn't create chaos.

An AI agent doesn't have these problems. It doesn't need to coordinate via Slack or track tasks in Jira. It doesn't need a 5-file module structure to avoid stepping on a colleague's work.

What an AI agent needs is completely different:

  • Files — to read and write.
  • Terminal access — to execute commands.
  • Context — to understand what we're building and why.
  • Memory — to remember decisions between sessions.

Framework Comparison: AI-Readiness in 2026

Backend Frameworks

❌ NestJS — Overengineered for AI

To create a single endpoint, an agent needs to modify:

  1. users.controller.ts (routing)
  2. users.service.ts (logic)
  3. users.module.ts (DI)
  4. users.dto.ts (validation)
  5. users.entity.ts (model)

More files = more tokens = slower, more expensive, more error-prone. Verdict: Overkill for AI. Built for human teams of 10+.

❌ Spring (Java) — Maximum Pain

The verbosity alone makes it hostile. Java's boilerplate and Spring's magic annotations create a context window nightmare. Verdict: Avoid entirely for AI-assisted development.

⚠️ Django — Powerful but Heavy

  • ORM magic is hard to reason about.
  • Many implicit behaviors ("magic") confuse agents.
  • File structure is spread across apps. Verdict: Works, but inefficient. You'll spend tokens explaining conventions instead of solving problems.

⚠️ Express.js — Simple but Structureless

Verdict: Acceptable, but needs strong CLAUDE.md conventions to prevent the agent from inventing inconsistent structures.

✅ Elysia.js + Bun — The Best Choice Today

This is what I use in production.

  • Minimal surface area: A complete API route with validation in a few lines.
  • TypeScript-first: The agent sees types and catches errors at compile time.
  • Eden Treaty: End-to-end type safety between backend and frontend. Verdict: Best choice for AI-assisted development today.

Frontend Frameworks

⚠️ Next.js — Popular but Complex

  • Pros: Enormous training data (Claude knows it deeply).
  • Cons: App Router vs Pages Router, complex caching, large configuration surface. Verdict: Works well due to training data, but complexity adds friction.

✅ Nuxt 3 — Structured and Predictable

Nuxt’s file-based routing and clear separation make it highly predictable.

  • Pages in /pages, components in /components, API in /server/api.
  • Zero ambiguity. Verdict: Excellent for AI-assisted development.

What the Ideal AI-Ready Stack Looks Like

Feature AI-Friendly Approach
Files Minimum files per feature
Language TypeScript throughout (agents love types)
Structure Predictable, conventional, no hidden magic
Patterns Avoid decorator-heavy or XML/YAML configs

My current production stack:

  • Runtime: Bun
  • Backend: Elysia.js
  • ORM: Drizzle ORM
  • Frontend: Nuxt 3
  • API client: Eden Treaty
  • AI memory: CLAUDE.md + .md notes

The Memory Problem — And How .md Files Solve It

AI agents have no memory between sessions. Every time you start a new Claude Code session, it starts fresh.

Plain text files are the memory layer of AI development. I maintain:

  • CLAUDE.md — Project overview, stack decisions, conventions.
  • docs/architecture.md — System design reasoning.
  • docs/decisions.md — Architecture Decision Records (ADRs).

When I start a session, the agent reads these first. Suddenly, it has months of context in seconds.

Where We're Going: The Next 3 Years

  • 2026 — Now: AI agents work with existing frameworks. Developers choose minimal, type-safe stacks.
  • 2027 — Near future: Persistent AI agents on servers running continuously — monitoring, fixing bugs, and deploying.
  • 2028+ — The shift: New frameworks emerge designed specifically for agents.

The stack of the future won't be chosen for developer experience (DX). It will be chosen for agent experience (AX).

The Practical Takeaway

  1. Choose minimal frameworks (Elysia, Hono, Nuxt).
  2. Go TypeScript everywhere — types are free documentation for your agent.
  3. Write CLAUDE.md first — context before code.
  4. Keep features in few files — one feature, one file.
  5. Skip coordination tools — you don't need Jira if you're solo with an agent.

Batyr Akmuradov is the CEO and founder of BridgeCore SYSTEMS, building ERP and EdTech platforms in Turkmenistan. Follow the journey on Twitter/X and explore the projects at bridgecore.tech.

← Back to Blog