Someone Who Can't Code Just Shipped a Feature
Something started happening at AutoUncle a few months ago. Colleagues who have never touched a code editor, people in customer success, sales, marketing, and finance, began shipping code. Real code, into real production systems. And it was sanctioned by me, on purpose. Somewhere in the building, a senior engineer felt a sudden chill.
A few years ago that would have been a horror story, the kind you tell junior engineers around a campfire. Today I think it is one of the most important shifts happening in software organisations, and almost nobody is ready for it. So why would I actively encourage it, and how do you do it without your production systems quietly catching fire? That is what this post is about: why this is coming to your company whether you plan for it or not, why it is worth wanting, and the part everyone politely skips, which is how much friction it creates and how to live with it.
Why This Is Happening Now
The bottleneck in software was never the supply of good ideas. The people who answer support tickets, sit in sales calls, or run operations have always known exactly what was broken and what was missing. What they lacked was the ability to translate that knowledge into working features fitting the product. That translation layer - among many other things - required a developer, and developers are finite, expensive, and busy. So a lot of that insight quietly died in a backlog.
Agents collapse the translation layer. The interesting part is no longer that an agent can write code. It is that the agent can sit where a non-technical person already works and meet them in plain language. Claude, for example, can now live directly inside Slack, where you mention it and it acts. That is the ready-made end of the spectrum: a finished product you just switch on. At the other end, a fast-growing set of open, build-your-own agent frameworks has appeared (with names like the "nano" agents and the OpenClaw variants, which all sound like rejected energy drinks, stay with me). Instead of adopting someone else's finished tool, you take one of these as a starting point and wrap your own company's context, rules, and guardrails around the model, so the agent actually understands how your business works and what it is allowed to touch.
The moment it really clicked for me was an inspiration session earlier this year with Chris from Landfolk. (And btw. you can now get that inspiration too from here, in danish though). He walked me through Pax, an internal agent he had built on top of Pi, that let his own non-developers describe what they needed and get it safely shipped. It was not a demo of a product. It was a company quietly rewiring how work gets done, with the people closest to the problem doing the building. That session genuinely changed how I think about this, and it is the direct reason we are now building our own version at AutoUncle, an agent we call UncleClaw, because apparently every internal agent now needs a name that sounds faintly feral.
The point is not the specific tools. They will change again by autumn. The point is that the interface to building software is becoming a conversation, and conversations are something everyone can have.
A practical aside, since I just spent a paragraph romanticising the build-your-own route: for most companies, most of the time, you are probably better off betting on one of the big proprietary providers, a Claude in Slack, a Cursor cloud agent, and so on. They already sit on top of your vital company context, and they are far less work to stand up than rolling your own. Building your own is real and worth understanding, but it is not the default choice. And this part of the market is about to get crowded: expect a wave of the same idea over the next couple of months from Gemini with its Personal Intelligence work, from OpenAI's Codex, and from more or less everyone else with a model and a sales team.
Why You Should Want This
It would be easy to read all of this as a threat to contain. I think that is the wrong instinct, and a costly one.
The value is not that you save developer hours. That framing is a trap. The value is that the distance between noticing a problem and solving it collapses for the people who notice the most problems. The person on the front line who understands a customer's frustration in their bones can act on it directly, instead of compressing it into a sentence in a ticket that loses ninety percent of its meaning on the way to an engineer. That is an enormous amount of latent value most companies are currently leaving on the floor. If your competitors unlock it and you do not, you will feel it.
There is a second reason, and it has crept up on a lot of teams without them naming it. AI did not raise every role equally (yet). It initially made engineers dramatically more productive and left much of the rest of the organisation roughly where it was (that is changing too). One engineer with a capable agent now ships what used to take a small team. Anthropic itself reportedly told its growth team to hire more product managers, because its engineering org had quietly started shipping at something like three times its headcount, and the bottleneck moved with it.
When you triple how fast you can build but not how fast you can decide what is worth building, the constraint simply relocates. It moves from typing to judgement: what matters, for which customer, and why. The already-strained ratio of one product person to eight engineers starts behaving more like one to twenty. As a recent VentureBeat piece put it, the bottleneck is no longer typing. It is deciding what to type.
I made more or less this prediction on an episode of my podcast a while back: the balance of a classic software team is shot to pieces. The scarce resource is no longer the person who can write the code. It is the person who carries the product judgement, the taste, and the customer understanding to point all that production capacity at the right thing.
Which reframes the whole question. When someone in support, sales, or operations wants to contribute, they are not just extra hands. They are carrying exactly the thing that has become scarce: direct, unfiltered insight into a real customer and a real problem. We are short on product thinking, not on the ability to produce.
Let me not overclaim here, though, because this is where the bold version of the argument falls over. A support agent with a good idea does not replace a product manager. Deciding what a coherent version of the whole product should look like, the taste, the prioritisation, the saying no to good ideas that do not fit, is still real expertise, and it does not transfer just because the tooling got easier. What opens up is the long tail: the smaller features, the obvious fixes, the papercuts a product owner would never get around to anyway. Letting the people closest to those problems resolve them directly is not a substitute for product judgement. It is relief for an overloaded product function, and a way to rebalance a team that AI has tipped heavily toward raw production. Handled well, it is reinforcement, not a threat.
Triple how fast you can build without tripling how fast you can decide what to build, and the bottleneck just moves to judgement.
Now the Uncomfortable Part
Here is the thing the optimistic version of this story skips. Opening the doors creates real friction, and it lands hardest on your developers. I think a lot of engineering leaders are about to feel this, so it is worth being honest about it.
Someone still owns production. When a non-developer ships a change, the tech lead whose name is on the system's stability still carries that responsibility. Their job description did not change. So from where they sit, you have just invited a stream of changes they did not write, cannot fully anticipate, and are still accountable for. That is genuinely uncomfortable, and dismissing the discomfort is how you lose your best engineers' trust.
The natural reaction is to gate harder: review every change, scrutinise every diff, make sure nothing slips through. And that reaction, completely understandable as it is, is exactly the thing that breaks. It does not scale. It turns your most experienced people into a queue. It makes them the bottleneck for the very thing you are trying to open up, and it quietly tells everyone that the new contributors are not really trusted. The friction is real. Gatekeeping harder is the wrong way to resolve it.
How We Are Actually Doing It
The way through, at least the way we are taking at AutoUncle, has two halves: build trust at the front, not at the end, and change what "quality control" even means.
At the front, the agent a non-developer talks to cannot be a blank prompt box, and the one we are building is designed so it never is. It carries the organisation's context: our products, our architecture, what is safe and what is sensitive. Its job is to triage. A small, well-scoped fix can flow straight through to the automated pipeline. Anything large, performance-sensitive, or touching a fragile part of the system gets routed to a conversation with a developer or even a PM about the plan, before any code is written. The goal is simple, even if building it is not: nobody self-ships a gigantic change into a fragile area just because it happened to pass. This is the same logic I argued for in It's All About Trust: you do not get safety by inspecting every output after the fact, you get it by designing the perimeter up front. The gate moves earlier, to the plan, where it is cheap and where a developer's judgement actually compounds.
Which Brings Us to the Code Review Heresy
Ahh, code reviews. The steel gates of quality so many of us have stood guard at for decades. It feels almost sacrilegious to say what comes next, so I will just say it: you cannot open the doors to non-developers and simultaneously keep human code review as your quality gate. The two are incompatible. If every change still needs an engineer to read it and click approve, you have not opened anything. You have just added a longer queue.
So we let go of it. Early this year I stood up in front of my engineering team and announced something that sounded reckless: by summer, none of us would write code by hand, and none of us would read or review it either. I have a habit of making pronouncements like this in meetings, the kind that leave the most senior people studying the ceiling tiles with great concentration. This was one of them. I wrote about the emotional weight of saying that in It Wasn't Wrong, and about the day-to-day practice of getting there in Shifting Gears. It is summer now. We are here. Months ago we removed the branch protection rule that required a human to approve a merge, and I posted about that moment publicly on LinkedIn.
So how did the goal actually land? Better than I expected, and not quite all the way. The part about not writing code by hand was the easy sell. The part about not reading it took longer, but it has largely happened. In our most recent tech strategy meeting the common refrain around the table was a slightly surprised "honestly, I don't really read the code anymore." For code that developers and their agents produce, we are essentially there. The frontier now, the genuinely uncomfortable next stage, is extending that same trust to code that did not come from a developer at all. That is the harder half, and it is most of what the rest of this post is about.
And there are hard numbers behind the feeling. I pulled the git history of our fifteen largest repositories and compared the four most recent months to the same months a year earlier, on a like-for-like set of our longest-running repos so that newer projects do not flatter the figures. In a typical month a year ago we added around 41,000 lines of real, non-generated code across those repositories. This spring it is around 137,000, more than three times as much. Commits, the steadier measure, went from roughly 370 a month to roughly 660, close to double. And here is the part that matters most: we did it with no more developers. If anything we have fewer actual developers than a year ago. The count of distinct people committing has crept up by maybe forty percent, but that rise is increasingly contributors who are not developers at all. So the same, slightly smaller core team is now producing two to three times the output. Per developer, throughput has at least doubled, and in most months tripled, in twelve months. (Lines of code is a noisy, AI-inflated metric, which is why I lead with commits and stripped generated and data files out before counting. The shape holds across every measure.)
Three times the code, twelve months later, with fewer developers, not more. The leverage was never the headcount.
The part that gets misread every time: this is not less review. It is more. We run more automated checks, more linters, more specs, and AI review on every single pull request than we ever did with humans. The review got more thorough. It just stopped requiring a person to sit and read the diff. The pull request is still useful, as a way to decide when something goes live and to package a change everyone can see, but it is a coordination tool now, not a human quality gate. If you want the deeper argument for replacing human judgement with deterministic enforcement, that is the whole of Don't Just Tell It. Enforce It.
There is a bigger idea lurking underneath all of this, and I have been chewing on it for a while. If the specs and the automated checks are the real source of truth, then the code itself starts to look less like a precious artifact you lovingly maintain, and more like something you regenerate when the world changes. The New Stack has a sharp piece on this spec-driven, regenerative view of code, and I find myself increasingly leaning that way. I am not claiming we are fully there, and a few of my own engineers would push back hard on it, but the direction is unmistakable. It is also the same direction that makes someone like John contributing feel a lot less reckless than it sounds.
And if you catch a developer sitting and reading a diff to feel safe, that is the signal to move their energy somewhere better. Every hunch they have, the quiet "this feels slow" or "this looks off", should not be spent as a one-off comment. It should become a rule, a spec, a check, so the system catches it forever instead of a person catching it once.
Ownership Moves, It Does Not Disappear
Letting non-developers ship does not mean the person who described a change now owns its production behaviour. Of course it does not. John is not going to get paged at 2am because his button misbehaved. We do not have "someone else's code" at AutoUncle. We have systems, and people responsible for them. If you own a system in production, you own what goes into it, wherever it came from, and whoever, or whatever, typed it.
What changes is where a developer's ownership lives. It moves up, from writing and guarding lines of code to owning outcomes and the system that produces them. Your job is no longer to be the gate. It is to build the harness so good that the gate is not needed, and to own the result in production. That is a more senior job, not a smaller one. It is also a harder identity shift than any tooling change, which is why it deserves to be named out loud rather than glossed over.
The Objections Are Real, and the Answer Is Still the Harness
The strongest pushback I get is not abstract, and it is fair. It comes from engineers who know their domain better than I do. The hardest cases are not really bugs at all. Nothing crashes, nothing throws an exception, the code is perfectly valid. But some small detail in how a page is structured or rendered quietly hurts you over time. The classic example is a long-term SEO ranking problem caused by a technical blunder in how content gets generated: not an error, just a structural choice that slowly erodes your organic traffic. No test fails. No alert fires. It simply costs you, months later.
Here is the honest version of that problem. If you have neither tests nor good production monitoring for that class of issue, you are left relying on a human to catch it by judgement and feel. That can work. But it does not scale, and, importantly, it never did. This was the weak link long before AI existed, so it is not some new danger that agents introduced. What is genuinely new is the opportunity on the other side: for the first time, you have a realistic chance to automate the monitoring of exactly these complex, consequential problems, the ones that take real reasoning to notice. That was close to impossible with deterministic testing frameworks alone. An agent watching production can reason about whether the page structure still looks right for search the way a careful human would, at a consistency and scale no human ever could.
So the move is not to put the human back at the gate. It is to feed the pain into the system:
- Specs, unit and integration, that encode the intent you keep relearning the hard way.
- Better tooling, so agents can reproduce production accurately in local and CI environments and get real feedback instead of guessing.
- Real automated production testing, including AI-driven browser automation that clicks through the actual experience on throttled devices.
- Production signals piped back to the agents: error tracking, performance monitoring, logs, even search and SEO data, through MCPs and CLIs, so the loop closes on reality.
- Async audit agents that watch for exactly these regressions and catch them early.
This depends entirely on having the foundations in place, which is the argument I made in Still True: monitoring, observability, infrastructure as code. With those, the economics flip. Damage from a bug has always been a multiplier of time, and agents crushed the time term. When something breaks, an agent reads the logs, the errors, and the recent deploys and proposes a fix in minutes. Lower damage per incident, and honestly fewer incidents than before. The risk of opening the doors is smaller than it feels, as long as you do the unglamorous work.
How to Deal With the Pain
If you lead engineering, this is coming for you, so here is what I would actually do about it.
Name the discomfort instead of pretending it away. Your senior engineers are not being difficult; they are being responsible, and their fear of owning code they did not write is legitimate. Then redirect that exact energy: the time they used to spend guarding the gate is the time you need them to spend building the harness that makes the gate unnecessary. Set the direction clearly and own it, including the risk. When someone on my team said "I want to go there but I cannot fully trust it yet," my answer was that they do not have to believe in it first. I am setting the direction as the person responsible, and if it goes sideways, that is on me. That is the arrangement, really: I get to make the grand pronouncements in meetings, and I also get to be the name at the top of the incident report. You earn the belief by doing the work, not the other way around.
And accept that the ground is moving. The thing that is a painful stretch this month becomes routine in three, because the models and the agent infrastructure are improving faster than our processes can settle. You can keep postponing on the grounds that it is not quite good enough yet, forever, or you can ride the wave while it is still a little bumpy and be standing where it breaks first.
The doors are opening either way. The people closest to your customers are going to start producing. The only real choice is whether you treat that as a threat to manage or the most valuable thing to happen to your product in a decade. I know which one I am betting on. And John from marketing, for what it is worth, is not waiting for either of us to make up our minds.