The Software Library That Contains No Code

On January 8, 2026, a developer released whenwords, a relative time formatting library with a peculiar twist: it contains absolutely no code. Instead, the repository holds specifications and tests that AI coding agents use to generate implementations across languages. The library provides five functions for converting timestamps into human-readable strings like "3 hours ago" and works across Ruby, Python, Rust, Elixir, Swift, PHP, and Bash.

The installation process reveals the core concept: users paste a simple prompt into Claude, Codex, Cursor, or similar AI tools. The prompt instructs the agent to read the specification document, parse the test cases, implement the five required functions, and run tests until all pass. The entire library is defined in three files: SPEC.md (detailed behavior requirements), tests.yaml (language-agnostic input/output pairs), and INSTALL.md (the build instructions).

This isn't just a novelty act. The author notes that recent coding models, particularly Opus 4.5 with Claude Code, have crossed a threshold where they can reliably implement tightly specified code in a single attempt. Every language tested succeeded on the first try. The experiment forces a question that cuts to the heart of modern software engineering: what happens when the cost of writing code approaches zero?

The immediate implication challenges our entire dependency ecosystem. For simple utility libraries like time formatting, why maintain dozens of language-specific implementations when one perfect specification could generate whatever you need on demand? The whenwords repository lists implementations for seven languages, but the author notes it could work in any language. The spec is only about 500 lines. The tests are explicit. The result is deterministic.

But the model starts breaking down as complexity increases. The author identifies five critical scenarios where traditional code libraries remain essential:

Performance Optimization A spec-only browser implementation would follow HTML, JavaScript, and CSS specifications perfectly, but performance matters. Real browsers require memory leak fixes, rendering optimizations, and battle-tested handling of malformed websites. These improvements emerge from real-world usage and expert optimization, not specifications alone. SQLite's 51,445 tests versus whenwords' 125 tests show the scale difference.

Testing Complexity When a bug appears in one language implementation, fixing the specification might break others. The author asks whether we'd need CI/CD pipelines that test specs against multiple coding agents across dozens of languages. For complex systems, the surface area grows exponentially. The probabilistic nature of AI models means implementations can diverge in subtle ways, making comprehensive testing increasingly difficult.

Support and Debugging Spec-only libraries create a nightmare for support. If a customer encounters a bug in their generated codebase, replicating the issue becomes nearly impossible. The exact same spec might produce slightly different code in different environments. Traditional libraries provide a stable reference point that support teams can analyze and debug.

Continuous Updates Critical libraries like LiteLLM, nginx, Rails, and Postgres require ongoing security patches and feature updates. These dependencies need maintainers who respond to issues and push fixes. Spec-only libraries work best for implement-and-forget utilities, not foundational components that require continuous attention.

Community and Interoperability The open source model thrives on community. More users find more bugs. More contributors fix more issues. Comprehensive testing enables faster pull request acceptance. Community support keeps code current. A specification alone doesn't create this ecosystem. The code we rely on represents not just a spec, but the crystallized product of people working toward a shared goal.

The whenwords experiment suggests a potential bifurcation in the software dependency market. On one side, simple, well-specified utilities might migrate toward spec-only models. On the other, complex frameworks and foundational libraries will likely remain code-based, supported by active communities.

This raises deeper questions about the nature of software engineering itself. If code generation becomes essentially free, the value shifts from implementation to specification. Writing precise requirements, understanding edge cases, and defining comprehensive tests becomes the core skill. The engineer's role evolves from crafting code to architecting specifications that AI agents can reliably implement.

The model also creates new failure modes. Traditional libraries fail predictably - you can read the source code and understand exactly what went wrong. Spec-only libraries might fail differently depending on which agent generated the code, which version of the model was used, or even subtle differences in how the specification was interpreted. The determinism we rely on in software becomes probabilistic.

Yet the potential benefits are substantial. Imagine never worrying about whether a library supports your language. No more dependency conflicts. No more waiting for maintainers to merge pull requests for new platforms. Just a perfect specification and an AI agent that builds exactly what you need.

The whenwords repository serves as a tangible thought experiment, but it points toward a fundamental shift in how we think about software dependencies. As coding agents become more capable, the question isn't whether spec-only libraries will exist, but which problems they solve well and which require the traditional model of shared, compiled code maintained by active communities.

The author acknowledges their thinking isn't fully baked and invites discussion. As models improve and agents become more capable, the line between specification and implementation will continue to blur. The software engineering community needs to grapple with what we actually need from our dependencies when the cost of writing code itself becomes negligible.