Smol Developer: The Whole-Codebase AI That Generates Complete Apps From Prompts

Hook

Most AI coding tools complete your function. Smol developer writes your entire application—routes, database models, utilities, tests, and all. It's ambitious, opinionated, and deliberately designed to hand control back to you when it inevitably gets stuck.

Context

The first wave of AI coding assistants focused on autocomplete: GitHub Copilot suggests the next few lines, ChatGPT helps you debug a function, and IDE extensions fill in boilerplate. They're glorified snippet generators—helpful, but fundamentally reactive. You write code; they help you write it faster.

Smol developer inverts this relationship. Instead of assisting with code you're already writing, it generates entire codebases from natural language specifications. Need a Flask API with authentication? A React dashboard with charts? Describe it in plain English, and smol developer scaffolds the complete project: directory structure, dependency files, route handlers, database schemas, utility functions. It's "whole program synthesis" rather than incremental assistance, positioning itself as a prototyping tool that gets you from idea to working code in minutes rather than hours. The trade-off? You're supervising a junior developer who works fast but needs oversight, not a senior engineer who ships production-ready code.

Technical Insight

Smol developer's architecture follows a three-stage pipeline that mirrors how human developers approach greenfield projects: plan the shared context, decide what files you need, then implement each file. This progressive disclosure pattern isn't just pedagogically sound—it's practically necessary when working with LLMs that have context limits and variable output quality.

Stage one generates a "shared dependencies" document: a specification of libraries, data schemas, function signatures, and architectural conventions that every file will reference. This acts as a shared contract, reducing the chance that generated files will have incompatible assumptions. Stage two uses OpenAI's Function Calling API to produce a structured JSON list of file paths. By forcing the LLM to return valid JSON rather than free-form text, smol developer eliminates an entire class of parsing errors that plague text-based code generators. Stage three iterates through these paths, generating code for each file with the shared dependencies and other file paths as context.

Here's what invoking the embedded library looks like:

from smol_dev.main import generate_codebase

prompt = """
Create a FastAPI web service that:
- Accepts webhook events from Stripe
- Validates signatures
- Stores events in PostgreSQL
- Exposes a /events endpoint with pagination
"""

generate_codebase(
    prompt=prompt,
    model="gpt-4",
    output_dir="./stripe-webhook-service"
)

The function call above generates a complete project: main.py with FastAPI routes, models.py with SQLAlchemy schemas, auth.py for signature validation, requirements.txt with dependencies, even a basic README.md. The key insight is that smol developer doesn't try to generate perfect code—it generates debuggable code. Files are small and focused. Dependencies are explicit. The structure is conventional enough that an experienced developer can immediately orient themselves and start making changes.

The asynchronous generation mode deserves special attention. Since each file generation is an independent API call to OpenAI, smol developer can parallelize them:

generate_codebase(
    prompt=prompt,
    model="gpt-4",
    output_dir="./my-app",
    async_mode=True  # Generates files concurrently
)

This can reduce generation time by 60-80% for projects with many files, though it comes at the cost of higher API rate limit exposure and slightly less consistent cross-file coherence (since files don't "see" each other during generation).

The tool also functions as an Agent Protocol server, implementing the emerging standard for AI agent communication. This means you can run smol developer as a service and interact with it via standardized HTTP endpoints, making it composable with other AI agent systems:

python -m smol_dev.server
# Exposes POST /tasks, GET /tasks/{id}, etc.

What makes smol developer philosophically interesting is its embrace of human handoff. Unlike tools that try to iterate indefinitely or maintain long-running "agentic" loops, smol developer generates code, then gets out of your way. It has a /debug mode that lets you paste error messages and get fixes, but the assumption is that you'll quickly reach a point where manually editing code is faster than prompting. This "AI as scaffolding" mindset contrasts sharply with the "AI as pair programmer" framing of tools like Cursor or Aider, and it works well for its target use case: getting from zero to something that runs.

Gotcha

The OpenAI dependency is absolute and non-negotiable. There's no adapter layer for Anthropic's Claude, no local model support via Ollama or llama.cpp, no Azure OpenAI option. If OpenAI's API goes down, your development pipeline stops. If GPT-4 costs spike, your prototyping budget evaporates. This makes smol developer fundamentally unsuitable for environments with compliance requirements around data locality or organizations trying to reduce vendor lock-in.

More fundamentally, smol developer inherits all the limitations of GPT-4's code generation capabilities, which are considerable. It struggles with domain-specific libraries, generates outdated patterns for fast-moving frameworks, and has no awareness of your organization's code standards. The generated code often contains subtle bugs: off-by-one errors, missing edge case handling, incorrect async/await usage, and database queries that work for small datasets but don't scale. You're not getting a working application—you're getting a first draft that compiles. Budget significant time for testing and refinement, especially around security-critical code like authentication, input validation, and database queries. The tool positions itself as a "junior developer," and that's accurate: you wouldn't ship a junior's first-pass code without review, and you shouldn't ship smol developer's output without scrutiny either.

Verdict

Use if: You're an experienced developer who needs to rapidly prototype greenfield projects, explore unfamiliar tech stacks without reading documentation, or generate boilerplate for side projects where initial velocity matters more than code quality. It's particularly valuable for MVPs, proof-of-concepts, hackathon projects, or learning exercises where the goal is to see something working quickly and you have the skills to debug and refactor afterward. Skip if: You need production-grade code, work in regulated industries where OpenAI's API is non-compliant, have a limited API budget, or are a junior developer who can't effectively validate generated code. Also skip if your project involves complex state management, real-time systems, or architectural decisions beyond straightforward CRUD applications—smol developer excels at conventional web apps but flounders when the problem space gets weird.