Your Sales Manager Can Write Code Now. That Is Not the Hard Part.

The pitch writes itself. Your business analyst knows exactly why the invoice screen is wrong. Your sales manager has explained the commission rule four times to three different developers. Your operations lead has a spreadsheet that is quietly running a department. All of them now have a tool that will write the code — so why are they still filing tickets and waiting two sprints?

I think the instinct behind that question is right, and I think most of the conclusions drawn from it are wrong. So this post is an attempt to separate the two, using numbers rather than adjectives.

Here is the short version. Something real did change, but it is narrower than “anyone can code now.” The cost of producing plausible code collapsed. The cost of knowing whether that code is right did not move at all, and the measured effect of everyone generating more code is that verification — not authoring — became the expensive part. That has a specific consequence for the idea in the first paragraph, and it is not the consequence the pitch implies.

First, an honest admission about the evidence

I went looking for the number that settles this: what share of people writing code at companies are not developers? It does not exist.

Every large survey people cite about AI coding samples people who already code. Stack Overflow's 2025 Developer Survey drew 49,009 responses across 177 countries — recruited through Stack Overflow. Google's 2025 DORA report surveyed 4,867 technology professionals. Sonar's 2026 developer survey states outright that all 1,149 respondents worked in a technology role, the vast majority in software engineering.

So when somebody tells you what percentage of business analysts are shipping code, they are guessing. That includes anyone making the optimistic case, and it includes me. What follows is built out of adjacent evidence, and I will say which is which.

The closest thing to a direct measurement is Anthropic's study of roughly 400,000 Claude Code sessions from about 235,000 users between October 2025 and April 2026. It confirms non-software occupations are present, and that management, sales, and legal are among the fastest-growing groups. It publishes no percentage share for any of them. And it says plainly that it “cannot measure real-world outcomes, like whether code written in a session is actually used or discarded thereafter.”

Sessions are not shipped software. Hold onto that.

The part of the thesis that is already old news

There is a version of this argument that says business users previously could not build anything. That is not true, and it has not been true for a long time.

Microsoft reports 56 million monthly active Power Platform users, with a stated ambition of reaching 500 million. Add Excel, Zapier, Airtable, Salesforce admin work, and every report someone built in a BI tool, and non-developers have been building working software at enormous scale for years.

What they were doing it inside was a vendor sandbox — a governed environment where the worst outcome is usually a bad form or a broken flow. The genuinely new thing is not that business people can build. It is that they can now get a checkout of the actual codebase: the web app, the mobile app, the system your business runs on. That is a different proposition with a different failure mode, and conflating the two is how this conversation goes wrong.

What the tools changed, and what they did not

The most useful finding I came across cuts both ways, and it is worth sitting with.

In Anthropic's data, occupation barely predicts whether a session succeeds. Software occupations reach verified success in about 30% of sessions; other professions about 26%. All ten of the largest occupational groups land within seven points of software engineers. Job title is not the barrier — which is a genuine point in favor of the original thesis.

Expertise predicts it heavily. Sessions rated novice succeed 15% of the time against 28–33% for intermediate and above. And 19% of novice sessions end in abandonment, against 5–7% for everyone else — roughly triple the give-up rate.

The behavioral signature underneath is the interesting bit. Novices issue about 5 actions per prompt and get roughly 600 words back. Experts issue about 12 and get 3,200. Experts keep going when the model is wrong. That persistence, not syntax, is the whole difference.

So the useful reframing is this: the question is not whether your sales manager can write code. It is whether that specific person can tell when the model is confidently wrong and recover from it. “The people with the most business knowledge” is the right instinct aimed at the wrong variable. Domain expertise in the business process tells you what to build. Domain expertise in the codebase is what error recovery requires — and that is precisely what the business user does not have.

The bill arrives at the review queue

This is the part that changed my mind about how to advise on it, and it is the part most posts on this subject leave out.

Faros AI analyzed telemetry from 22,000 developers across 4,000 teams over two years. Not a survey — actual review queues and production incidents. As teams crossed into high AI adoption:

Both columns are real. More work got done, and more of it broke. Faros's own explanation of why review got so much more expensive is the sharpest sentence in the whole literature: AI-generated code is “often superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase.” The failures are underneath. Their conclusion is that “the code arriving for review was never ready. This is an authoring problem, not a review problem.”

Sonar's survey lands in the same place from a different direction: 96% of developers do not fully trust that AI-generated code is functionally correct, but only 48% always check it before committing. 61% say AI “often produces code that looks correct but isn't reliable.” And when Sonar asked where AI helped, the split is stark — 89% report a positive impact on productivity and 70% on time to market, but only 39% on defect rates and 34% on vulnerability rates.

Speed up. Quality flat.

Now apply that to the original idea. If a business user authors a change, the code still has to be reviewed by somebody who can evaluate it — and it arrives less ready than a developer's would, from someone less able to answer questions about it. The middleman does not disappear. It relocates from planning to review. If your one engineer is already the bottleneck, this makes the bottleneck worse. That is the most common way these programs fail, and it is worth saying out loud because it is the exact opposite of the promised benefit.

A note on the numbers you will see quoted at you

Since this subject is drowning in statistics, three worth handling carefully — including one that cuts against my own argument.

The METR study. You will see “AI made developers 19% slower” everywhere. It comes from a genuine randomized trial: 16 experienced developers, 246 real tasks in their own repositories, who predicted a 24% speedup, believed afterwards they had been 20% faster, and were measurably 19% slower. The perception gap is the finding worth keeping. But METR walked the headline back in February 2026 — later data showed −18% and −4% with confidence intervals crossing zero, which METR itself calls “only very weak evidence,” adding that selection bias may mean their figures substantially understate real gains. Anyone still quoting the bare 19% is doing the thing they accuse vendors of.

GitHub's 55%. That figure came from a single standardized task — writing an HTTP server in JavaScript. GitHub's own later randomized trial with 202 developers and 1,293 blind expert reviews found code 53.2% more likely to pass all unit tests, but only 3.62% better on readability and 2.47% on maintainability.

DORA reversed itself, in the honest direction. DORA's 2024 report found that for every 25% increase in AI adoption, delivery throughput fell 1.5% and stability fell 7.2%. Its 2025 report says explicitly that “AI's relationship with software delivery throughput has turned from negative to positive.” The throughput objection is gone. The instability finding is not — higher AI adoption still predicts more delivery instability. Meanwhile Faros, working from telemetry rather than surveys, directly disputes DORA's framing that AI merely amplifies existing strengths, finding the degradation “appears regardless of baseline engineering maturity.” That disagreement is unresolved, and I would rather show it to you than pick a side.

So where does this actually work?

Here is the thing that surprised me. Every non-engineering example in Anthropic's own showcase of internal Claude Code use — a legal team prototyping a phone tree, marketing generating ad variations, finance describing workflows in plain text, data science building dashboards “without understanding the code themselves” — is an internal tool, a prototype, or a data workflow. None of them reach customers.

That is the company with the most to gain from a bolder claim, and its own examples stop at the same line. The instinct that internal tooling is the sweet spot is not just correct, it is the whole recommendation.

The organizing principle is blast radius. Not company size, not industry, not how clever the person is. What is the worst realistic outcome when this goes wrong?

Company size matters less than people expect, and mostly through a single variable: whether there is a named engineer with actual free hours to review the work. A ten-person company where the founder writes the code and will read every diff can do this well. A three-hundred-person company where the platform team is already underwater cannot, and the size of the org is not what makes the difference.

The one place size is decisive is regulation. If the system is in scope for HIPAA, PCI DSS, SOX IT general controls, GLBA, or FedRAMP — or a customer contract with change-control terms — stop. Those frameworks exist to produce an auditable chain of who changed what and who approved it. PCI DSS Requirement 6.5.1, for example, requires documented approval by authorized parties, documented security impact, and testing for every production change. Adding an unqualified author to that chain is a finding waiting to happen no matter how good the code turns out to be.

The test, before you try it

Work this top to bottom. One failed gate ends it. They are not weighted and this is not a score — the first two exist because no amount of training or good intentions changes the answer.

If you are going ahead: the setup

Roughly a week of engineering work, and it is the precondition for everything else.

Access and permissions

• A separate repository. Not a branch of the main codebase — its own repo, its own deployment. This is what keeps the blast-radius answer stable instead of re-litigated on every change.
• No production credentials on their machine. Masked or synthetic data. If the tool needs real data to be useful, that is a signal you are in the wrong tier.
• Branch protection and CODEOWNERS. The reviewer's name goes in the file before anyone writes a line. Required review, no self-merge, no exceptions for “small” changes — small changes are where this fails.
• Company SSO, never a personal account. Sonar found 52% of developers using ChatGPT reach it through personal accounts, against 17% for Copilot. Ungoverned accounts feeding company data to public models is the shadow-AI risk in one statistic.
• Secrets are the sharpest edge. An agent reading a directory reads whatever credentials are in it. Keep them out of the working tree, scope any token to the one thing it needs, and assume anything readable will be read.

Training that is worth the time

Not a syntax course. The failure mode is not that they cannot write a loop — the tool writes the loop. Teach the four things that actually gate outcomes:

• How to tell when the model is wrong. Reading output critically is the entire skill. Anthropic's expertise gap is a persistence gap.
• How to recover. What to do at the point where a novice abandons and an expert keeps going.
• Version control as a safety net. Branch, commit, revert. Mostly so mistakes are cheap.
• Where the edges are. Which systems are in scope, which are not, and who to ask. Write it down; do not rely on people remembering a conversation.

Governance, kept short enough to survive

A one-page list of approved repositories, a named reviewer per repository, a rule that nothing merges unreviewed, and a written tier list of systems by blast radius. If the policy runs longer than a page nobody will read it, and an unread policy is worse than none because it creates the impression of control.

What to measure — and it cannot be a survey

This matters more than any other decision in the program, because the best-documented finding in this entire field is that people are wrong about their own productivity. METR's participants believed they were 20% faster while measurably slower. DORA 2024 found self-reported productivity up 2.1% in the same data where time spent on valuable work fell 2.6%.

So do not ask participants how it went. Instrument four things and agree the threshold before you start:

• Incidents per pull request, before and after
• Hours your reviewer actually spends on these changes
• Revert rate
• How many of the tools built are still in use 90 days later

That last one is the one nobody measures and the one I would keep if I could only keep one. A 2018 audit of citizen-development projects — single firm, pre-AI, so treat it as directional — found 54% judged failures after the first year, with under 20% clear successes. Tools that quietly stop being used are the normal outcome, not the exception, and they are invisible unless you look.

What I would actually do

One internal tool. One person who genuinely knows the process and has shown they debug rather than abandon. One named reviewer with the hours already carved out. One quarter. One number agreed in advance that decides whether it continues.

That is a much smaller program than “democratizing engineering,” and it is the version the evidence supports. The grand claim is unproven in both directions — nobody has shown a non-developer shipping to a production codebase at scale, and nobody has shown they cannot. The narrow claim is well supported and available now.

If it works, you will know from the numbers rather than the enthusiasm, and you can widen it deliberately. If it does not, you will have spent a quarter and one engineer's review time finding out, which is a genuinely cheap way to answer a question this contested.

The reason I would still do it: the person who understands why the invoice screen is wrong really is the most valuable person in that conversation, and every round trip through a ticket loses some of what they know. That was always the actual problem. It is worth trying to solve — carefully, on something that cannot hurt you, with somebody watching.

If you are weighing this up for your own team and want an outside read on which of your systems could take it, here is what I build and run — or just describe the situation using the button below. I usually reply within a day.