You Don't Need a Dev Team Anymore

Twenty-five years in insurance. I know documents — policies, endorsements, adjuster reports, tables of authority, reinsurance treaties. I know what's in them, what should be in them, and exactly what happens when a claim is processed against the wrong version of one.

What I didn't know was how to build software. That gap always meant the same thing: describe the problem to a developer, wait, review something that almost worked, describe it again, wait some more.

That gap is gone.

Over ten sessions with Claude Code — Anthropic's AI coding tool — I built Lumen. A full-stack prompt engineering workbench. Production-grade. React and TypeScript on the front. FastAPI on the back. Supabase with vector search. PDF processing, Word and Excel ingestion, versioned prompts, batch runs, accuracy scoring, and side-by-side source correlation with click-to-highlight. The kind of system that, two years ago, I would have taken to a CTO.

No CTO. No developer. No hand-coded lines. Just domain depth, a well-structured methodology, and an AI that knows how to build.

The barrier was never technical capability. It was always the assumption that technical capability was required.

What Lumen Actually Does

Lumen is a workbench for extracting structured data from documents using AI — but doing it rigorously. Not a chatbot. Not "ask questions about your PDF." Something more specific.

A prompt engineer — or someone who thinks like one — comes in with a business problem: "I need to extract these twelve fields from every policy document we receive, and I need to know how accurate the extraction is before I put it in production." Lumen handles the full cycle.

You can see it live at lumen.prototypes.design — the LLM API key is switched off in the public version, but the interface, the schema builder, the prompt versioning system, and the run history are all visible.

For insurance, this matters enormously. A coverage decision made against the wrong policy version is a liability. A cross-reference that misses a subrogation clause is a recoverable amount written off. Lumen doesn't just extract — it shows its work, scores itself, and makes the iteration process systematic rather than a series of hunches.

The Build Methodology

This is the part that matters most — not what was built, but how.

Ten sessions. Each one had a defined scope, explicit inputs, and a verification checklist before anything was marked done. The sessions didn't bleed into each other because of memory — they stayed coherent because of a document called CLAUDE.md.

Each session ended with a verification checklist — does the feature work end-to-end, does it match the spec, are the edge cases handled? The discipline isn't in the coding. It's in the process. The AI handles the coding. The human handles the process.

The Stack

For anyone who wants to assess what "production-grade" means in this context:

Two external API dependencies. One managed database service. No proprietary UI. No developer on payroll. The complexity is real — this is not a no-code wrapper. But the person who built it has never written a for loop in a terminal.

Three Groups, One Shift

There are three groups of people watching what's happening right now, and they're having very different reactions.

I am Group Two. Twenty-five years of domain depth — understanding exactly what insurance documents contain, what matters, what creates liability, where the process breaks down — converted directly into software. No translation layer. No specification document passed to someone who doesn't understand the domain. No three months of requirements meetings.

The insight is simple and it's not about coding: domain depth is the scarce input now. The technical execution layer has been automated. What you know about the problem — not the code — is what determines what you can build.

The new software developer is the person who understands the problem most deeply. The AI writes the code. The domain expert makes the decisions.

What "Git for Prompts" Actually Means

The phrase I've been using to describe Lumen is "git for prompts." It's not quite right — Lumen is more than that — but the instinct behind it is correct and worth unpacking.

When software developers collaborate on code, they use version control. Every change is logged. Every version can be compared. Every rollback is clean. Nothing is lost, nothing is overwritten without a record.

Prompts — the instructions you give AI models — have none of that infrastructure yet. Most teams are copying prompts into a notes doc, or worse, rebuilding them from scratch when something breaks. There's no audit trail. No accuracy benchmark across versions. No systematic iteration.

Lumen applies software development discipline to prompt development. Every prompt is versioned. Every run is logged against a specific version. Accuracy is scored at the field level. You can compare v3 against v7 on the same documents and see exactly which fields improved and which regressed. You can annotate why a version changed. You can roll back.

This matters because prompts in production environments are not static. They evolve as edge cases emerge, as document formats change, as regulatory requirements shift. Without version control, that evolution is unmanageable. With it, it's just engineering.

The Broader Implication

I started this article by telling you I built a full-stack application. What I actually built is evidence of something larger.

Across every industry, there are people who have spent ten, twenty, thirty years accumulating domain knowledge. Knowledge about how claims are processed. How supply chains break. How regulatory filings work. How financial reconciliation fails. How customer onboarding stalls. How compliance reports get produced manually every month by someone who has better things to do.

That knowledge has always had a conversion problem. You couldn't turn it into software without a developer. You couldn't turn it into automation without an IT team. You couldn't turn it into a system without a budget and a project plan and six months.

The conversion problem is solved.

The person who understands the problem best can now build the solution directly. Not perfectly — the methodology matters, the process discipline matters, understanding what you're asking for matters. But the technical barrier that separated domain expertise from software capability is no longer the controlling constraint.

That's what Lumen represents. Not just a useful tool for prompt engineers — an existence proof that the citizen developer era is not coming. It's here.