The Citizen SDLC: Six Governed Stages From AI Prototype to Production

One of our clients is a private equity firm. A member of their portfolio operations team, someone who has never written a line of code, built the dashboard her whole team now uses every day. It tracks value-creation work across roughly two dozen portfolio companies. She built it by prompting Claude, iterating over about two months. Every single line was written by AI.

And it’s good. The views are right, the workflow fits how the team actually operates, and adoption was instant. She sketched the correct product before any engineer was involved.

That is not luck. For decades, the person who understood a business problem was almost never the person who could build the software to fix it. Closing that gap was a herculean effort: a product manager to turn her problem into a spec, engineers to translate the spec into code, and a spot in line behind everything else on the roadmap. Months passed between the idea and the tool, and what finally shipped was someone else’s interpretation of what she meant.

That gap just collapsed. The power to build has moved to the people who actually understand the process, know what the data means, and live in the workflow every day. She built the right thing on the first try because she was the source. Nobody stood in the middle to translate her, or to get it slightly wrong. That is the promise of citizen development — non-engineering employees building real software for their own teams, with an AI agent doing the coding, where the domain expert becomes the builder and no engineer writes the code — and she delivered on it.

Then we looked under the hood.

The entire application was one HTML file. 540 KB. Around 5,300 lines. The master dataset lived inside it as an 80 KB blob of data on a single line. When the file needed updating, the AI had bolted on patch functions that rewrote values every time the app loaded. Saving your work meant the app rewrote its own HTML, downloaded itself to your laptop, and you re-uploaded it to a shared drive as a new version. If two people edited at once, last save wins, and the other person’s edits vanish.

One day, a save function went looking for a marker in the file, didn’t find it, and wrote back what it had anyway. The entire 540 KB application truncated to 7 bytes. In a single silent write, the dashboard her team ran on every day ceased to exist, and nothing in the way it was built was designed to catch it, stop it, or bring it back.

Most leaders hear that story and conclude citizen development is a liability to be shut down. We think that’s the wrong lesson, and the companies that act on it are going to lose. The right lesson: she did her job brilliantly. Nobody had built the road for the software to ship on.

Why has the bottleneck moved from building software to governing it?

For decades, building software was the expensive part. It was slow, scarce, and costly, and the entire software development lifecycle grew up to protect it. Specs, tickets, sprints, code review: every ceremony in the traditional SDLC exists because writing the code was the bottleneck.

AI collapsed that stage to near zero, and the bottleneck moved. When anyone can build a working app in an afternoon, the expensive work is no longer the building. It is what comes after: making sure what got built is sound and secure, and keeping a growing fleet of these apps governed once they are live.

The data on professional engineering teams already shows the squeeze, and they had process to begin with. LinearB’s 2026 benchmarks, drawn from more than 8.1 million pull requests across 4,800-plus organizations, found that AI-assisted pull requests wait 4.6× longer before a reviewer picks them up, and that AI-assisted PRs merge at roughly half the rate of human-written code — 32.7% versus 84.4%. Agentic PRs sit idle 5.3× longer. Generation got faster; the human review capacity behind it did not move at all.

Operating model

The org is changing shape.

How the operating model transforms with AI.

Old Model AI-Native

Old model

EngineerPR submitted

EngineerPR submitted

EngineerPR submitted

EngineerPR submitted

↓

PR queueevery change waits on a human

↓4–7 days

Tech lead1 reviewer per 6–8 engineers Bottleneck

↓

Main branchthroughput bounded by the reviewer’s calendar

4–7 daysavg review cycle

1reviewer per 6–8 engineers

4.6×longer wait before a reviewer picks up an AI-assisted PR, LinearB 2026

AI-native

Engineercode committed

Engineercode committed

Engineercode committed

Engineercode committed

↓

Pre-commit reviewinstant · shift-left

↓

AI reviewbugs · security · edge cases ~80% auto-merge if pass

Peer reviewarchitecture · product taste · ~20%, complex PRs only

↓

Main branch10–100× throughput

Under 4 hrsavg review cycle

~80%of PRs auto-merged once checks pass

10–100×throughput, human judgment reserved for what matters

Same people. Fundamentally different throughput. And the building is not slowing down, which creates two problems that have to be solved:

• Quality under the hood. An agent prompted from a blank page by a non-engineer converges on hacky software that works today and is unmaintainable forever. The 540 KB file is not an outlier; it is the default output of building without rails.
• Sprawl. Every team wants its own app, and no central IT group can hand-build and operate dozens of them. Without guardrails, each one gets built on whatever stack the builder or the model reached for: a different database, a different auth scheme, secrets stashed wherever they landed. Block the requests instead and they don’t stop, they just move off the books. Either way you inherit not just a fleet of apps but the tangled mess of infrastructure underneath them, and none of it something IT can reasonably secure, support, or explain.

So the real question every company is about to face: how do you let non-technical staff ship real internal software without inheriting that fleet?

Why do the three obvious answers all fail?

1) Lock it down. Requests queue, patience runs out, and the shadow apps get built anyway. Now you can’t see any of it. You can’t govern what you can’t see. This is the same failure mode as banning AI tools outright — the ban reflex manufactures the exact risk it was written to prevent, as we argue in what AI governance you need for safe employee use.

2) Let it rip. Point non-engineers at AI tools with no structure and celebrate the demos. This is how you get the 540 KB file. And you cannot review your way out of it after the fact. By the time a monolith shows up in code review, it’s already a monolith. It has to be prevented at the starting point.

3) Review everything. Put a human approval on every change. Your IT team is lean, build volume is exploding, and now every deployment waits on a reviewer’s calendar. Reviews either kill adoption or get rubber-stamped. Both outcomes defeat the purpose.

So the answer is not another policy document but a lifecycle: a real SDLC, designed for people who will never call themselves developers, with guardrails built into the platform instead of written into a memo. A road that carries a build from the first plain-language idea all the way to governed production without ever asking the builder to become an engineer. The person supplies the intent; the platform provides the discipline.

What is the Citizen SDLC?

Six governed stages that turn AI-built employee prototypes into internal software the company can rely on. One principle runs through every stage of it:

AI does the labor, deterministic code sets the guardrails, and humans handle the exceptions.

AI drafts, classifies, and writes. Code decides what is allowed. People are spent only where judgment is actually required. Hold onto that division; it is what makes the whole thing scale.

Tenex Framework

The Citizen SDLC

Six governed stages that turn AI-built employee prototypes into internal software the company can rely on.

The Operating Model The builder supplies intent; the platform supplies discipline at every stage.

Stage 1

The Idea

Question

What should exist, who uses it, and what data will it touch?

Input

Plain-language memo, AI-assisted brief, owner, users, data sources.

Governance

No code, access, or infra yet. Form an opinion before the app exists.

Output

A durable brief that downstream checks and decisions can reference.

Stage 2

The Front Door

Question

Can the company see, route, and find every software request?

Input

The brief becomes the request, IT ticket, and permanent record.

Governance

One structured intake. No hallway asks, favors, or shadow pipeline.

Output

Every app enters triage on the record before any build work begins.

Stage 3

The Triage

Question

Is this safe to approve, a duplicate to reuse, or an exception to escalate?

Input

App shape, blast radius (reach, reversibility, exposure, data sensitivity), overlap with existing apps.

Governance

AI advises. Code decides. IT-owned deterministic policy makes the call.

Output

Approved, reused, or escalated with full request context and a named shape.

Stage 4

Provisioning

Question

Can the app be born inside secure defaults instead of reviewed later?

Input

One approval, the paved road for the app’s shape, app metadata and owner.

Governance

Elevated power runs once. Repo, sign-in, deploy identity, private env, database.

Output

An isolated app shell with auditability and constraints from day zero.

Stage 5

The Build

Question

Can a non-engineer build without inheriting laptop secrets or fragile patterns?

Input

Controlled cloud workspace, AI coding agent, generated contracts and test data.

Governance

Guardrails in template, merge checks, runtime rules, and platform boundaries.

Output

Routine changes move at CI speed. Consequential exceptions reach people.

Stage 6

Run & Change

Question

Does the app stay governed after launch, ownership changes, and usage shifts?

Input

Production usage, change requests, audit events, ownership and access data.

Governance

Firm sign-in, per-app access, append-only audit trail, usage-driven lifecycle.

Output

Promote what people use, archive what they do not, send changes back to Stage 1.

Why This Works Human attention handles exceptions. Automated structure handles the routine path.

TENEX

This is not an exotic structure. NIST’s AI Risk Management Framework asks for the same things its Govern function names — defined roles and accountability, enforced policy, and monitoring across the lifecycle. The Citizen SDLC is what those requirements look like when you install them as running systems instead of writing them down.

Stage 1 — The idea: what should exist, and who owns it?

A person describes the app in plain language, with AI’s help: what it does, who uses it, what data it touches, who owns it. Takes minutes and reads like a memo. It doubles as the brief everything downstream runs on. This is the operating model’s first move: AI does the labor of turning a ramble into a structured artifact.

Here’s what that looks like in practice. Someone in fund finance types: “I want a tracker for capital call notices. Right now it’s a spreadsheet I update by hand and email around every Friday.” The AI asks what an intake analyst would ask:

Stage 1, Live

From ramble to brief

The conversation

I

Who else needs to see it?

12 people across fund finance & IR.

Where does the data live today?

A spreadsheet in Box. Read-only is fine.

Who owns it when you’re out?

My manager.

The brief

· · ·

What it does · · ·

Who uses it · · ·

Data it touches · · ·

Access · · ·

Owner · · ·

Shape · · ·

✓ Brief complete · routed to the front door

The ramble has become a brief: purpose, users, data source, access level, owner, even a first guess at the app’s shape. A PRD — the short spec normally written before software gets built — in effect, written by someone who has never heard the term.

Nothing exists yet. No code, no access, no infrastructure. That’s deliberate: the firm forms an opinion about the app before the app exists, instead of six months after it’s load-bearing.

Stage 2 — The front door: can you see every request?

Every request goes through one structured front door, and the same motion that files it drops it straight into triage. The brief is the request, the ticket IT sees, the permanent record, and an entry in a catalog everyone can search, all at once. No hallway asks, no favors, no shadow pipeline. You can’t govern what you can’t see, and you can’t share what you can’t find. The front door makes both true from day one.

This is the stage that kills the shadow pipeline. A build that skips the front door can still exist as a prototype on a laptop, but that is where it stays. Everything that turns a prototype into software a team can rely on lives downstream of this stage: real storage, firm sign-in, a deploy pipeline, somewhere to actually run. None of it reaches a build that never came through. You can route around the front door; you just can’t get past prototype if you do.

Stage 3 — The triage: approve, reuse, or escalate?

AI classifies the request along two axes.

Shape: what kind of app is it? A reverse-audit of what employees actually build almost always collapses to a short list: artifact generators, workflow automations, CRUD apps, and interactive dashboards. Naming the shape tells you the architecture it needs, and it hands the next stage the paved road to stamp.

Blast radius: how much damage could this build do if it went sideways? We score that across four dimensions:

• Reach & capability: what can it touch, and can it write or only read?
• Reversibility & autonomy: is there a human in the loop, and can the action be undone?
• Exposure: who sees the output, and how far does it travel outside the company?
• Data sensitivity: how confidential is the data it interacts with?

But here’s the rule that makes this trustworthy: AI advises. Code decides. The model reads the brief and classifies it; then policy code IT wrote checks each classification against rules.

Watch it work on the capital call tracker. Shape: interactive dashboard. Blast radius: internal fund data, twelve internal users, read-only, human in the loop, no overlap with existing apps. Every dimension lands inside the approved thresholds, so it’s approved, and no human argued about it.

Now change one fact. Say the tracker also needs LP commitment data. The brief can be as persuasive as it wants; that single change spikes the data-sensitivity dimension past the threshold IT set, and the request goes to a person. No judgment call happened in between. A rule either matches or it doesn’t. Same pipeline, no persuasion layer.

Stage 3, Live

AI advises. Code decides.

Run 1 · the tracker, as briefed

Shape: interactive dashboard Data: internal fund data Users: 12, all internal Overlap: none found

AI classified ↑ · policy code decides ↓

Blast radius inside every threshold

No overlap with existing apps

Brief complete · confidence high

Approved · provision it

Run 2 · same brief, one change

Shape: interactive dashboard Data: adds LP commitments Users: 12, all internal Overlap: none found

AI classified ↑ · policy code decides ↓

Data sensitivity crosses its threshold

Overlap check · not reached

Confidence check · not reached

Escalated · to IT & Security, brief attached

The model classifies, the rules decide, people get the exceptions.

Three routes out:

• Approved. Blast radius inside every threshold, complete brief, high confidence. At our client, about 9 in 10 requests resolve this way, automatically.
• Reuse. It overlaps an app that already exists, so the requester gets routed to that app’s owner instead of building a duplicate. Duplicates get merged, not multiplied.
• Escalated. A dimension crosses its threshold, or confidence is low. A human at IT and Security gets the full request as context.

The tenth request, the odd one out, still lands on a human’s desk with the full brief attached. The other nine never needed to.

Stage 4 — Provisioning: can an app be born inside secure defaults?

Here is the move that lets IT say yes at volume: provisioning is not IT losing control of what ships but IT’s control moving upstream. Instead of reviewing every app after the fact, IT authors the paved road once, and every app is born on it. One person approves, and the platform stamps the app from the road for its shape: a repo, firm sign-in, a deploy identity, a private environment, and its own database, all defined as infrastructure-as-code that IT owns and versions. Provisioned in minutes.

This is the only moment elevated power runs, and a human is in front of it. Every app is born isolated, governed, and audited: its own walled-off environment, no public address, no stored cloud secrets, an append-only audit trail from day zero. The security work happened once, in the road. No app has to repeat it.

Stage 4 · Under the hood

What one stamped app runs on

The only way in

A personon the firm network or VPN

→

Firm sign-inchecked at the door, before any app code runs

→

Private front doora private address; nothing faces the internet

One private environment per app

The appweb + API in one container

⇄

Its own databaseappend-only audit trail, written in the same transaction as each change

The app signs in to its database with a short-lived identity token, not a stored password. Telemetry & alerting watch both from day one.

The only way to deploy

Merge to mainevery check green

→

Build pipelinebuilds & tests the release

→

The running appdeployed with a narrow, short-lived identity; no stored keys

No public address No stored secrets No shared databases No deploys outside the pipeline

Because the road is authored per shape, the human approval is a default posture, not a permanent tax. Novel shapes and high-blast-radius builds keep the human gate for good. But once a shape’s road has proven itself over enough builds, low-blast-radius requests on that road can provision automatically. It is the same “save human judgment for the tail” logic applied one stage earlier: early on you route more to a person, and as the patterns hold, the line shifts toward automation.

And the road carries one more thing that matters as much as the infrastructure: the AI rulebook. The inherited repo hands the coding agent a set of instructions on every session, encoding the anti-patterns learned from real failures. Do not inline data blobs over 1 KB. Do not add functions that rewrite data when the app loads. This is how quality-under-the-hood gets solved without asking the builder to know a single best practice: the road makes the agent follow them. Every one of those rules is a scar with a story behind it — you’ve read one of them.

Stage 5 — The build: what carries the engineering discipline?

The builder prompts Claude Code inside a controlled cloud workspace, never on their own laptop. A terminal agent on a laptop inherits everything sitting there: mail, synced drives, browser cookies, cached credentials. In the workspace, the agent sees the project. Nothing else.

Everything an engineer would normally carry is carried by the rails instead. At our client, 35 guardrails in four layers that the builder cannot turn off.

The Rails

What the builder never has to get right

The template

10

what every app starts from

• AI rulebook read every session
• Guided skills for common asks
• Entity & field generators
• One typed API contract
• Generated front-end client
• Schema validation on every request
• Layer walls in the code
• Enforced lint & format
• Anti-pattern guards
• Synthetic test data only

The merge

9

every change gates on the way in

• Green or it does not merge
• Branch protection
• Security code scanning
• Dependency scanning
• Secret scanning
• Data-file blocking
• Contract drift check
• Reviewed migrations
• Destructive changes go to a person

The runtime

8

what the running app guarantees

• Firm sign-in on every request
• Per-app access groups
• MFA & device rules inherited
• Append-only audit trail
• Concurrency protection
• Gated, logged imports
• No database password
• Telemetry & alerting

The platform

8

the walls around it

• One private environment per app
• One database per app
• No public address
• Narrow deploy identity
• No stored cloud secrets
• Pipeline-only deploys
• Human-gated provisioning
• Infrastructure as code

The rails carry the engineering discipline, not the builder. The builder cannot turn any of these off.

The merge layer includes drift checks purpose-built for AI-generated code: file-size budgets, no oversized inline data, audit-log conformance. Green or it does not merge. When a check fails, the builder asks the agent to fix it and pushes again.

Humans do not review routine changes. The checks are the review. Routine changes move at the speed of CI, not at the speed of a reviewer’s calendar — which is exactly the 4.6× review queue that professional teams are drowning in. What reaches a human is the consequential tail, detected mechanically: destructive schema changes, new dependencies, changes to the agent’s own constraints, anything touching infrastructure. Those wait for a person. Nothing else does. And when something new escapes anyway, the fix is a new automated check, not more human review. The system gets stricter by encoding lessons, not by adding meetings.

Remember the dashboard from the opening. Two of those drift checks would have fired on it in the first week. The 80 KB single-line blob would have failed CI on its very first commit, months before any of the failure modes hardened.

Stage 6 — Run & change: does it stay governed after launch?

Six months later, the capital call tracker is still running, and this is where the lifecycle earns its keep. Someone in IR questions the wire deadline on the March notice. The audit trail answers in thirty seconds: who changed the field, when, and what it said before, recorded in the same transaction as the edit itself. Nobody reconstructs the truth from an email chain. When the builder switches teams, ownership transfers to a named successor instead of dissolving into a shrug. And if she leaves the firm entirely, her sign-in dies and every door it opened closes at once. The tracker included. Next quarter’s feature request walks the same rails as the first commit.

Governance runs on signal, not annual audits. The tracker’s usage metrics show two more teams leaning on it, so it gets promoted and invested in. The currency dashboard nobody has opened since April gets archived, not left to rot in a menu. Nobody mourns it. Ownership is assigned on day one, so nothing outlives its builder unowned. Documentation regenerates as the app evolves, so it never goes stale. An unused app is a failure, not a trophy. The goal was never app count: it’s a living catalog your people actually trust, instead of a graveyard of forgotten software.

As the catalog grows from ten apps to two hundred, a central team can no longer keep an eye on all of it, and oversight has to push outward to the teams that own the apps. When and how far to federate that is a judgment, and it shifts as the portfolio grows. Governance here is a posture you keep tuning, not a control you set once.

When does a prototype become software? The second-consumer rule

There’s one trigger we teach every client, because it answers 90% of the “does this need the full process?” questions: the second-consumer rule. It works because that’s the moment the risk profile changes.

Someone building analysis for themselves, on their own laptop, with bounded data access? Low blast radius, light governance. Charts, memos, and scripts they run for themselves don’t need a deployment pipeline. But the moment a second person wants to use the output directly, instead of asking the author for refreshes? The blast radius jumps: more reach, data traveling further, someone else trusting it to be right. It’s software now, and it graduates to the full lifecycle, deliberately, as an explicit event. Same data sources, same identity, new road.

That one rule is why the process doesn’t drown people. Most builds never cross the line. The ones that do are exactly the ones worth the ceremony.

What are we honest about?

No platform makes first-time builders write perfect code. We don’t claim to. The layers exist so that a mistake is an inconvenience inside one small boundary, not an incident across the firm. Each layer covers exactly what the one above it can’t.

Layer 01 · Identity — who gets in, and what they can touch. Firm sign-in gates every request before any app code runs, and role-based access runs through every layer beneath it: per-app groups, per-role permissions, scoped to the least each person needs. A departing employee loses every app at once. But sign-in says who someone is and what they may reach, not what a buggy app does once they’re inside.

Layer 02 · Isolation — cut a leg off the attack. Isolation is built around the lethal trifecta of an AI agent: it can reach private data, it takes in untrusted content, and it has a path to send data back out. Remove any one leg and the attack collapses; isolation takes out the exfiltration leg. Each app runs in its own private environment, with its own identity and database and no public address, and the agent builds in a walled-off cloud workspace, never on a laptop full of live credentials. Stolen data has nowhere to go. But isolation bounds the damage; it doesn’t stop bad code shipping inside its own walls.

Layer 03 · Guardrails in code — what ships. The checks that block bad code live in the road and the merge gates, not in the builder’s head: failing checks block the merge, secrets and data files never enter the repo, and the codified rulebook steers the agent off the known anti-patterns before they’re written. A non-technical builder never has to know what any of these are. But checks catch what they were written to catch. Something will eventually get past.

Layer 04 · Audit — what happened. Every change writes who, what, before and after, and when, in the same transaction. It can never be rewritten. The job is to have the visibility you need before you need it, and that record only gets more valuable as an app ages and the questions get harder. Audit prevents nothing, but it makes every incident short, explainable, and attributable. That’s the difference between a bad afternoon and a bad quarter.

What is citizen development not for?

Citizen development is not meant to replace professional engineering. Systems of record in regulated processes, anything customer-facing or investor-facing, apps built for external users, anything where downtime carries a financial penalty: those still belong to engineering, and the front door routes them there on day one. That routing decision is the same one we walk through in buy AI tools or build agents — the answer depends on whether the thing is a differentiator or a commodity, and citizen builds live squarely in neither category.

What it replaces is the bottleneck. It democratizes the long tail of internal tools that were never worth a formal engineering project and ships them at a speed the roadmap queue could never offer. A framework with no boundaries is a slogan; this one knows what it is not for.

How would Tenex install this?

We work in four moves. The last one is leaving.

Embed. We reverse-audit what your people are already building — including the spreadsheets and single-file apps nobody put on a ticket. That produces the shape list and the blast-radius thresholds your policy code will enforce, grounded in your data classifications rather than a generic template.

Ship. The road goes in as working systems: the front door and triage, the paved road per shape as infrastructure-as-code your team owns, the template with its rulebook, and the merge gates. First production system by week four, median. The people doing this are the 0.16% — 50 builders hired from 32,100 applicants, every one through a paid build trial.

Train. Pairing inside real work, not a license count and a lunch-and-learn. Builders learn the road by shipping their own app on it, and IT learns to author the next road rather than review the next app.

Hand off. The policy code, the roads, the templates, the catalog — transferred to your team, with Tenex access revoked. Dependency is a design flaw. A lifecycle you rent is a lifecycle you lose at renewal.

Related questions land next door: who signs off on the thresholds is an ownership question, and what data is allowed to reach an agent at all is a data-controls question. The full engagement shape is on our AI transformation page, and the platform work underneath it is AI engineering.

What actually changes?

At the PE firm, the first app through the platform is the one that motivated it: the dashboard from the opening story, remade on the rails. Same screens. Same builder. Now with real storage, firm sign-in, and a history of every edit. It can never again truncate itself to 7 bytes, because the class of code that caused it can’t merge.

About 9 in 10 requests already resolve automatically, and that share only grows. Most of what non-technical builders make is low blast radius by nature: internal, read-mostly, small-audience tools. As each shape’s road proves itself, more of those builds become safe to provision and deploy with no human in the loop at all. Human attention keeps concentrating on the consequential tail and thinning out everywhere else.

Yes takes minutes today, and it trends toward instant, because no is built in.

Every company is about to have hundreds of builders. Most companies are still deciding whether to be scared of that or excited about it. The ones that win won’t be the ones with the most builders. They’ll be the ones with the best roads. We track what’s shifting that fast in ultrathink, our Tuesday newsletter, because the roads worth building get rewritten faster than any policy cycle.

If you want the road installed — front door, triage, paved roads, rails — tell us what you’re working with. We read every message. When it’s a fit, a partner reaches out within a couple of days.