I’ve been thinking about what a web framework purpose-built for AI would look like. Not just a framework that integrates with AI services, but one explicitly designed for AI to drive the development process from end to end. The core purpose: to create a system where AI is the implementer rather than just the implementer’s assistant, with humans providing direction rather than code.

What does “AI-driven” mean?

When I say “AI-driven,” I’m referring to a framework where users interact primarily with a chatbot to express what they want, and the AI delivers everything else:

  • Requirements gathering
  • System design
  • Implementation
  • Testing
  • Deployment
  • Maintenance

This goes beyond code generation or assisted programming—it’s about rethinking the entire development workflow.

The “Most Expensive Webserver in the World” Approach

One extreme approach would be having everything run through an LLM in real-time:

  • Every request to the website or API hits a prompt
  • Any persistent actions happen via tools
  • Responses are generated directly from LLM output

While technically feasible, this “most expensive webserver in the world” would be prohibitively costly at scale due to token costs, latency, and API fees for each request. Every page load or API call would incur LLM processing costs, making it economically impractical for all but the most specialized applications. The more practical approach is having AI write the code that runs your system, not be the system itself.

Drawing Inspiration from Cucumber

What interests me is the natural language specification aspect. I built a project using Cucumber (the natural language testing framework) in Ruby once, and despite some authentication and Selenium challenges, the experience of writing tests in plain language was surprisingly pleasant.

This got me thinking: what if we had a text-based specification format optimized for machine interpretation? A format that:

  1. Is easily understood by both humans and AIs
  2. Contains sufficient detail for implementation
  3. Can be validated objectively

JSON as the Foundation

JSON seems like a natural choice for this specification format:

  • AIs are already well-trained on JSON syntax
  • It’s hierarchical, allowing for nested structures
  • Files could be preprocessed to load only the necessary depth into context
  • It’s widely supported across programming languages

This approach goes far beyond existing API specification standards like OpenAPI/Swagger. While those focus on interfaces, our JSON specification would detail the entire implementation:

  • Database schema details (column size limits, foreign keys, etc.)
  • Caching strategies vs. database persistence decisions
  • Internal dependencies and service calls
  • Authorization rules that permeate throughout the system
  • Resource limits and performance expectations
  • Error handling strategies and fallback mechanisms

A structured JSON document would serve as this comprehensive specification, which an AI could then consume to create an implementation matching the inputs, outputs, and all the complex behavior in between.

Language and Technology Agnosticism

If properly specified, an AI could generate implementations in any programming language using any framework. The specification would define what the system does, not how it’s built.

This raises an interesting question about dependencies: for humans, adding and calling a package is much faster than reimplementing functionality. But for an LLM, ignoring token count limitations, maybe just implementing the library directly into your codebase is easier? (This applies only to open source, of course, and creates potential maintenance challenges.)

Tests as the Contract

Like a human implementer, the AI would produce tests to verify functionality. These tests would serve as an objective measure of whether an implementation meets the specification.

Once we have a comprehensive test suite, any implementation passing the tests would be considered valid—regardless of programming language, server, library, or database technology.

The Future of Software Engineering?

This approach would require vastly more detailed specifications than we typically write today, as illustrated by the implementation details mentioned above. But what if this becomes the norm for software engineering in 5 years?

Instead of writing code, most people might focus on being logical specification writers, driving AIs to create super-detailed specs that other AIs then implement. The human’s role shifts from implementation to direction and verification.

The specification could include everything:

  • Business logic
  • User flows
  • Error handling
  • Security requirements
  • Performance targets
  • Deployment configurations

UI work could flow from Figma or other design tools directly into the code—the design files themselves becoming the specification for the UI.

The User Experience

Let’s bring this back to the original thesis of chatbot interaction. Here’s what the development process might look like for a user:

  • The user interacts with a chatbot, describing what they want their program to do
  • As the conversation progresses, the chatbot transparently updates a JSON specification in real-time (perhaps displayed in a sidebar, similar to how Claude handles artifacts)
  • The user can edit the JSON spec directly at any point to refine details or correct misunderstandings
  • The output of this conversation is a complete, well-structured JSON specification
  • Next, another AI system takes this JSON spec and derives comprehensive tests from the specification requirements
  • These tests are verified (by either a human or another AI step) to ensure they accurately represent the specification
  • Finally, the implementation is written by AI, iteratively refined until all tests pass

Open Questions

This approach creates a fundamentally different software development workflow—one where the specification becomes the central artifact rather than the code itself. In this world, the human’s primary interaction is with the AI, directing and refining rather than implementing.

I’m still exploring this concept, but several questions come to mind:

  • How detailed would specifications need to be to ensure correct implementation?
  • How would we handle ambiguity and edge cases?
  • What tooling would help humans write these specifications efficiently?
  • How would versioning and updates work in this paradigm?
  • Would software built this way be more or less maintainable in the long run?
  • What skills would become most valuable for developers in this new paradigm?
  • How might we build trust in systems where humans may never directly review the implementation code?

The core idea here is asking what an AI-driven web framework might look like if designed explicitly for AI’s to drive and catering to their interface. The JSON specification approach is just one possibility for how it could be implemented.

Are you thinking about a first-principles approach to developing software in an AI-driven world? I’d love to hear your thoughts on how we might rethink software development from the ground up.