What It Does
smol developer is a Python library that generates an entire codebase from a single natural-language prompt. Given a product specification written in plain text, it runs a three-stage pipeline: first it asks an LLM to produce a shared_dependencies.md document enumerating all shared variables, data schemas, and interfaces; then it asks the LLM to enumerate the file paths needed using function calling for structured JSON output; finally it generates each file in parallel, prepending the shared-dependency manifest to each file’s prompt to prevent cross-file hallucination inconsistencies.
The tool operates in three modes: a standalone CLI for local use, a pip-installable library for embedding into existing Python applications, and an API mode via the Agent Protocol standard for remote invocation. The parallel file generation uses Modal Labs for task scheduling and execution, though the core library can run locally without Modal.
Key Features
- Three-stage generation pipeline: shared-dependency manifest → file enumeration → parallel file generation
shared_dependencies.mdconcept prevents cross-file hallucination and inconsistency- Function calling API ensures structured JSON output for file path enumeration
- Three operational modes: CLI, pip library (embeddable), and Agent Protocol API
- Modal Labs integration for parallelized file generation (reduces 2-4 min generation time)
- Multiple LLM support: OpenAI GPT-4/GPT-3.5-turbo as primary, Anthropic Claude as alternative
- Human-in-the-loop design: error messages are pasted back into prompts for iterative refinement
- Community-contributed ports in JavaScript/TypeScript, C#/.NET, and Go
- MIT-licensed with no vendor lock-in on the framework itself (only on LLM API choice)
Use Cases
- Rapid prototyping: generating a working skeleton for Chrome extensions, CLI tools, or single-page apps from a spec in 2-4 minutes
- MVP scaffolding: creating an initial project structure before human developers refine it
- Embedded code generation: teams wanting to bake a prompt-to-scaffold capability into their own developer tooling or SaaS products
- Educational use: understanding how multi-file LLM code generation works at a minimal implementation level
- Historical reference: understanding the shared-dependency manifest pattern before adopting it in custom pipelines
Adoption Level Analysis
Small teams (<20 engineers): Best fit at this level, with caveats. Works well for prototyping and rapid scaffolding. The generated output requires significant human review and debugging — expect it to be a starting point, not production-ready code. For teams already using frontier LLM APIs, the incremental cost of smol developer is low.
Medium orgs (20-200 engineers): Poor fit in 2026. More capable tools (Claude Code, OpenHands, Codex) with better benchmark performance and richer tooling exist. smol developer does not provide the observability, audit logging, or team-level features medium orgs need.
Enterprise (200+ engineers): Not suitable. No enterprise features, minimal maintenance activity, no sandboxing, no secrets management, and no governance controls.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| Claude Code | Autonomous end-to-end coding agent, 80.9% SWE-bench Verified | You want state-of-the-art autonomous coding with full repo context |
| OpenHands | Open-source platform with Docker sandboxing, multi-model support, SDK | You need an embeddable, model-agnostic coding agent with team features |
| Codex (OpenAI) | Async task delegation, fire-and-forget model, OpenAI ecosystem | You want async agent tasks within the OpenAI ecosystem |
| Direct LLM API (structured output) | No framework dependency, simpler, more flexible | You want to build a custom code generation pipeline without adding a dependency |
| gpt-engineer | Similar philosophy, more active maintenance post-2023, broader feature set | You want a similar whole-program generator with ongoing development |
Evidence & Sources
- smol developer GitHub repository — source code, README, and issue tracker
- Andrej Karpathy endorsement (Twitter, May 2023) — notable ML figure endorsement that drove initial viral adoption
- Latent Space blog post by swyx on smol developer philosophy — author’s design rationale
- Agent Protocol specification — standard used for smol developer’s API mode
Notes & Caveats
- Maintenance status: The repository has 124 commits and 69 open issues as of April 2026. The last significant update was in late 2023. Treat this as effectively archived/unmaintained for production use.
- Superseded by context window growth: The core architectural innovation (shared_dependencies.md to prevent cross-file hallucination) was designed for GPT-4’s 8k context window. Modern frontier models (Claude 3.5 Sonnet, GPT-4o, Gemini 2.5 Pro) have 128k-1M token windows, making the manifest approach largely unnecessary.
- No sandboxing: Generated code is not executed in a sandboxed environment. There is no safety mechanism for running untrusted LLM-generated code.
- LLM API cost dependency: Every run requires GPT-4 API calls for each file in the codebase. For projects generating 20+ files, API costs accumulate quickly. No cost estimation or cap mechanism is provided.
- Anthropic underperforms: The README itself notes that “Anthropic as coding layer underperforms compared to OpenAI” — an unusual candor but worth noting if you’re considering using it with Claude models.
- Historical significance: Despite its current maintenance status, smol developer was widely cited as the reference implementation of the “whole-program coherence” and “shared-dependency manifest” patterns. These concepts were absorbed by subsequent tools, making smol developer worth reading as a case study in designing minimal AI coding agents.
- Fork ecosystem: The repository has 1.1k forks, many of which are active experiments and adaptations. If you need a maintained version, forking and adapting the ~300-line core is practical.