Make everyone a developer

Four parts ago I showed you an SDLC run by agents with humans holding two gates. Everything since — the learning loops, the reaction ladder, the security model — has been machinery. This part is the payoff, and it's the one that changes your org chart rather than your toolchain:

Once the gates hold, it stops mattering whether the person behind the agent is an engineer.

The marketer who needs the campaign page fixed. The VP Product with a small, well-scoped feature. The ops lead who wants one more column in the report. Every one of them can now direct an agent that writes real code against your real repo — and the only question that matters is whether your process judges the work or the worker.

This is already happening — at scale

This isn't a prediction I'm asking you to trust. Block built Goose, an open-source agent framework, for its engineers — and within months roughly 5,000 people, about 60% of the company, were using it weekly. Developers and non-developers. Their conclusion, near verbatim: Goose isn't a developer tool. The abstraction that made it spread was the recipe — a workflow file a non-engineer can author, share and run.

Anthropic's own legal, marketing and finance teams run Claude Code — a member of the legal team shipped a working bot without knowing how to code, and the growth team cut ad production from thirty minutes to thirty seconds. And the cultural permission structure arrived back in 2025, when Shopify's CEO made "reflexive AI usage" a baseline expectation for every employee — a memo half the industry copied within a month.

So "everyone's a developer" isn't the contrarian claim. Here's the contrarian claim: most orgs that open the repo to everyone will regret it within a quarter — and the data on why is already in.

The naïve version fails, measurably

Open the funnel without changing the gates, and the bottleneck doesn't disappear. It relocates — onto your most senior people.

Faros AI's telemetry across 10,000+ developers found high-AI-adoption teams merging 98% more pull requests — with review time up 91%. LinearB's 2026 benchmarks put the pickup delay on agent-authored PRs at 5.3× longer than human ones. GitHub reported in May that more than one in five code reviews on its platform now involves an agent, and that agent PRs are multiplying faster than human review capacity. And open source is the canary: the Jazzband Python collective shut down and curl killed its bug bounty, both citing the flood of AI-generated submissions burning out the humans who review them.

Read those numbers again as an org design problem. The bottleneck has moved from writing code to deciding whether code is safe to merge — and most orgs' entire safety model for that decision is a tired senior engineer reading diffs at 4pm. Hand those orgs a hundred new code authors and you haven't democratised development. You've democratised the queue.

Why the gates change the answer

Now run the same maths against the machinery from Part 1. Every PR at Herita — mine included — faces adversarial design review when it's structural, a mandatory bug-hunt that fails the build on unanswered findings, and a QA agent that opens a real browser on a real staging environment and uses the product before merge. None of those reviewers gets tired at 4pm. None of them has a queue that grows resentful.

That machinery was built to absorb agent volume. But look at what it actually checks: the work, never the worker. The QA gate cannot tell whether the PR it's clicking through came from me or from the office manager — and that indifference is the whole point:

Seniority used to be the permission system. The gates are better at the job.

A marketer's PR that passes design review, survives the bug-hunt and gets a green verdict from an agent that used the feature is — by construction — held to exactly the standard mine is. The honest inversion: it's held to a higher standard than most human-reviewed code at most companies, because nothing at most companies drives every change to a terminal state before merge.

And they can check their own work the same way. Part 1's rule that every branch gets its own staging environment means the person who asked for the change can open it and click through themselves — manual QA by the requester, on top of the agentic kind, at zero cost to anyone else.

The contributor tier

None of this means handing the office manager merge rights. Part 4's ladder — developer, production, root, each named for what it may do to production — extends downward more naturally than it extends up:

A contributor can direct an agent, open PRs, and drive their branch's staging environment. They cannot merge, and nothing they hold unlocks production — not because we distrust them, but because the tier means the question never has to come up. Merge rights stay with the developer tier and above; the two human gates from Part 1 don't move at all.

The requester-authority rule from Part 3 slots straight in: who is asking determines what may happen automatically. Marton's well-scoped feature can schedule itself into the sprint; a contributor's first PR waits for a developer-tier merge like everyone else's. Guardrails as code, not as trust — the same sentence I've written in four articles now, because it keeps being the answer.

Give them cloud agents, not laptops

Here's the part where I argue against myself, and it's the test of whether Part 4 was reasoning or reciting.

For engineers, I argued the device is today's most secure host — the laptop already carries a managed security posture, short-lived credentials, a human physically present. For a contributor, every one of those premises fails. Their laptop has no development setup worth trusting, their credentials shouldn't exist at all, and asking them to maintain a local toolchain is how the whole idea dies in the first week.

So contributors get cloud agents: a sandboxed machine in the cloud with the repo on it, an agent that works in it, a live preview in the browser, and a full audit trail — spun up per task, disposable afterwards. Same principle as Part 4 — blast radius over trust — opposite conclusion, because the blast radius lives somewhere else. The sandbox holds contributor-tier credentials and nothing more; the worst possible outcome is a bad PR, and bad PRs are precisely what the gates exist to catch.

What to open first — and what not to

Two boundaries keep this from becoming the citizen-development horror story your security team is imagining:

• Internal tools before product. The prototype-to-production gap is where these programmes die. A reporting script, an internal dashboard, a content page — high value, low blast radius, and failure teaches cheaply. The product repo opens later, one well-scoped ticket at a time.
• The trifecta rules still apply. More contributors means more untrusted text flowing toward agents — Part 4's ticket-tracker argument, multiplied. Contributor-triggered agents run with the fewest legs of the lethal trifecta of anyone in the org: sandboxed, no secrets, no external comms. That's not a restriction on the people. It's a restriction on what their words can set in motion.

Where are we on this at Herita? Honestly: mid-rung. Everyone already ships through tickets — Part 1's feedback loop means the person who files a ticket never needs to know which kind of worker fixed it, and that's been true for months. Opening the repo itself — contributor tier, cloud seats, first non-engineer PRs — is the rung we're building now, and I'll write about what breaks when it does.

The question this series ends on

Five parts, one arc: agents run the SDLC, the org improves itself, it reacts while you sleep, the whole thing is arranged so trust barely matters — and once all that holds, the boundary around who builds becomes a choice rather than a fact of nature.

Which means you're going to have to make it. My challenge from Part 1 was that every execution step in your SDLC can now be agent-run. The challenge this time is one org-chart question further:

When the gates judge the work instead of the worker, what exactly is your justification for the repo being members-only?

Some of your best product thinking is currently locked inside people who've never been allowed to ship it. The org that fixes that first doesn't just move faster. It finds out what everyone else's engineers were for.

This completes the series: Part 1 — Agents run your SDLC · Part 2 — Your agentic org self-improves · Part 3 — Your agents react · Part 4 — Securing the agentic org · or start at the hub: The Agentic CTO.