GitHub says software agents went from starting 17% of code changes in March to more than 40% in September. Here is what that six-month move did to the value of every skill on a small team, including mine.
I have been rewarding the wrong thing.
Not maliciously. By habit. For most of my working life, the person who produced the most usable work the fastest was obviously the most valuable person in the room, and I built every instinct I have around that.
Then GitHub published a number this week that made me sit down.
Software agents originated more than 40% of pull requests in September, up from 17% in March. That is GitHub's own Octoverse report, on GitHub's own platform, counting the thing GitHub can actually count. Six months.
Here is the direct answer to the question in the title, and I want to give it before the evidence because it is not complicated. The skills that matter now are the ability to specify a task precisely enough that the output comes back usable, and the ability to look at a confident, polished, plausible answer and tell whether it is actually right.
Producing is not worthless. It is just no longer scarce.
And scarce is where value lives.
What has stayed with me since I read that number is not the strategic implication. It is the personal one. I have a team. I have been praising speed. I have been quietly impatient with the person who slows down to check things, and that person has saved me more money this year than anyone else on the payroll.
Candidly, that is an uncomfortable thing to notice about yourself in public. But I think a lot of owners reading this are in the same position and have not framed it yet.
So let me frame it.
Key Takeaways
- GitHub's own data shows agent-originated pull requests moved from 17% to more than 40% in six months, which is the clearest public measure of how fast first-draft production is being displaced.
- A randomized trial found experienced developers were about 19% slower with AI tools while believing they were 20% faster, with the extra time going into prompting, waiting, and reviewing.
- The bottleneck moved from producing work to specifying and verifying it, and most teams are still staffed and praised for the side that is no longer scarce.
- Review is invisible labor, because it consists of mistakes that never reached anyone, which is why it goes unrewarded.
- The practical response is to teach specification deliberately, make review fast enough to actually happen, and change who you promote.
The Problem
Your team is producing more than it ever has and you have a quiet feeling that the quality is sliding.
You are probably right, and it is probably not anyone's fault.
Here is what happened. Six months ago, drafting a proposal took two hours and reviewing it took twenty minutes. The ratio made sense. One reviewer could keep up with three producers without breaking a sweat.
Now drafting takes twenty minutes and reviewing still takes twenty minutes.
Nothing about your review capacity changed. Everything about your production volume did. So the ratio broke, and the thing that gives first is the step nobody is measuring.
I see this constantly in the community I run, and the owners describing it never describe it as a review problem. They describe it as a quality problem, or a team problem, or a "my people are getting sloppy" problem.
It is a math problem.
And it has a second layer that is harder to see. When a human writes something wrong, it usually looks wrong. The sentence is awkward. The number is in a strange place. The tone is off. You catch it because the error announces itself.
When a machine writes something wrong, it looks exactly like something right. Same confident sentences. Same clean formatting. Same tone you asked for. The wrong price sits in a beautifully constructed paragraph and nothing about the presentation tells you to slow down.
That is a genuinely new skill requirement. Catching an error that has no tell.
And here is the part that makes it personal rather than operational. The people on your team who are good at this are not the people you have been rewarding. Error-catching is slow, it does not generate visible output, and its entire product is a list of things that never happened. You cannot put "mistakes that did not reach a client" in a performance review. So we do not, and then we wonder why nobody wants to be the one who checks.
The Evidence
Start with the number that prompted this. GitHub's Octoverse report puts agent-originated pull requests above 40% in September, up from 17% in March. GitHub announced it alongside Copilot Fusion for coding agents, a model-routing system, and Copilot code review, Max. Notice the shape of that product lineup: one thing that generates, and one thing that reviews. The company with the data built both.
Now the finding that should humble all of us. METR ran a randomized controlled trial in July 2025 with 16 experienced developers completing 246 real tasks from their own repositories, averaging five years of prior experience on those codebases. Each task was randomly assigned to allow or forbid AI tools.
Developers were about 19% slower when AI was allowed.
They forecast a 24% speedup beforehand. After doing the work, they estimated they had been sped up by 20%.
Read that sequence again. They were slower, and they believed they were faster, after the experience. METR was careful about scope and said this does not show AI fails to help developers generally, only that in this specific setting the measured effect was a slowdown. METR also stated plainly that self-reports of speedup are unreliable.
The mechanism is the part that matters for this article. When AI was allowed, the developers spent less time actively coding and searching for information, and more time prompting, waiting on outputs, and reviewing them.
The time did not disappear. It moved into specification and verification. Which is exactly the claim I am making, demonstrated by accident in a study that was asking a different question.
Third, the market is voting with money. Look at what rose to the top of Product Hunt the same week as the GitHub report. Revix AI, a code reviewer that learns your repository's own conventions rather than applying generic rules. Overmind, an open-source platform that turns production traces into a specialized model your company owns. Spacesheep, which generates and maintains living documentation from code and conversations. PulseDev, which fixes the bug you point at.
Not one of the top developer launches that week was about generating more code.
Fourth, the hiring signal. An Anthropic engineering manager published a piece arguing that traditional coding interviews have stopped working, because the model can now pass the small coding tests his team used to evaluate candidates with. His advice to junior engineers was to demonstrate judgment through actual built products rather than accumulated framework knowledge.
One finding to hold loosely. Coverage of a Princeton-linked paper reports that model reliability has improved with each release but more slowly than average accuracy, and notes that benchmarking on average accuracy can hide wildly inconsistent performance. The figures quoted put the best models around 85% overall reliability. I have not read the paper directly, so treat the number as reported rather than verified. The direction, though, matches everything else here: the headline capability improves faster than the consistency, and consistency is what a business runs on.
What Changed For Me
I want to tell you what I actually did with this, because I think the useful version of this article is not the trend, it is the response.
I wrote down what correct looks like. This sounds obvious and it was not. We had been judging our highest-stakes deliverable by feel, which meant three different people had three different standards and the output varied by whoever happened to pick up the work. I sat down with two examples of it done well and one done badly and wrote five criteria a reviewer could mark present or absent without a judgment call.
That document took ninety minutes and it eliminated most of the arguments.
I made the review short enough to survive a busy week. My first version had fourteen checks. It was thorough and it was fiction. Nobody completes fourteen checks on a Friday afternoon with three deliverables stacked up.
Seven, ordered so the highest-catch items come first. A review that runs every time at 70% coverage beats a review that runs occasionally at 100%.
I started teaching specification on purpose. This is the part I had been leaving to osmosis. People on my team were getting poor AI output, redoing the work by hand, and concluding that the tool was not very good. The tool was fine. The handoff was vague.
So we train it now, using the same four-part structure I teach publicly. State the job and who it is for. Give the background, the facts, and what to leave out. Name the deliverable, the format, and what must be in it. Then tell it to ask questions instead of guessing.
That last part is the one nobody expects to matter and it matters most. An AI that asks you three clarifying questions produces dramatically better work than one that fills the gap with a confident invention.
And I changed what I praise. Out loud, in meetings. When someone catches something before it ships, that gets named. Specifically. In front of everyone.
That is not a management technique I read somewhere. It is a correction of something I was doing wrong.
Your Practical Steps
1. Count what nobody checks. List the work your business produces weekly and mark who verifies each type before it reaches a customer. Write what actually happens, not what is supposed to happen. The number you are looking for is how much weekly output has no verifier at all. For most small teams it is higher than the owner expects.
2. Write the quality standard for your single highest-stakes deliverable. Not "professional." Five criteria a person can mark present or absent. Pull two real examples of it done well and one done badly, and derive the criteria from the difference. Ninety minutes.
3. Build a review pass of seven checks or fewer, ordered by what catches the most. Include one check that specifically targets a confidently stated wrong fact, and one that targets wrong tone. Add a stop rule that says when to send it back rather than fix it yourself, because fixing it yourself is how you end up back in the bottleneck.
4. Teach specification as a skill, with your own work as the material. Here is the prompt I would use to build the training:
[The Job]
Write a short training on how to specify a task well enough that AI output comes back usable the first time.
This is for: my team members who currently get poor AI results and redo the work by hand.
It matters because: the redo work is cancelling out the time AI is supposed to save us.
[The Background]
Here is what you need to know: my team's roles are [LIST]. The tasks they try to use AI for are [LIST]. Here are real prompts they have used and the output they got: [PASTE EXAMPLES]. Our quality standard is [PASTE].
Do not use: generic prompt engineering tips. Train on our tasks.
[The Deliverable]
Return: a one-page training with four rules and one worked example from our actual work.
Must include: the four elements of a complete request, the job, the background, the deliverable, and an instruction to ask questions rather than assume.
Optimize for: a non-technical reader.
[The Questions]
Ask me any questions you have.
5. Move one review off your desk this month. Pick the one that would free the most of your time, write down the specific error type the new reviewer must be able to catch, train for that one thing, and set a sign-off criterion. Then spot-check a sample rather than reviewing everything, so you are neither blind nor back where you started.
6. Document the errors your review already caught. This is the one most people skip and it has the highest strategic value. Your verification work is invisible because it consists of problems that never happened. Write down three real catches, anonymized, with what each would have cost if it had shipped. That becomes the clearest explanation of your value to a client weighing you against a cheaper AI-only option.
7. Say the quiet thing out loud at your next team meeting. Name the person who caught something. Specifically. If the skill you need is the one that produces no visible output, you have to supply the visibility yourself or nobody will develop it.
Frequently Asked Questions
Does this mean I should stop using AI for drafting?
No. Drafting is where the time savings are real. The point is that the savings get consumed by rework if you have not built the specification and review layers around it. Keep the drafting and add the two things that make it hold up.
How do I interview for judgment instead of speed?
Give the candidate a plausible-looking draft with one confident error planted in it and ask them what they would change before it goes to a client. The people who find it tell you something a portfolio cannot. The people who praise the writing tell you something too.
Should I hire someone whose whole job is review?
Rarely, in a small business. Review usually works better distributed, with named owners per category and a short standard everyone shares. A dedicated reviewer becomes a new bottleneck and removes the incentive for anyone else to develop the skill.
My team says the review slows them down. How do I answer that?
They are right that it does, and that is the wrong comparison. Measure review time against rework time plus the cost of an error reaching a client. If your review pass takes five minutes and your last correction took half a day, the math makes the argument for you.
What if I am a solo operator with nobody to review my work?
Build the standard anyway and separate the two roles in time rather than in people. Draft today, review tomorrow morning with the checklist in front of you. The distance is what gives you the fresh eyes, and a written standard is what keeps you honest when you are reviewing your own work.
The Close
I have been rewarding the wrong thing.
That is where I started, and I want to come back to it, because the trend is interesting and the self-examination is the part that actually changes a business.
For years, the fastest producer was the most valuable person in the room, and that was true. It is now less true than it was in March, and GitHub has the receipts. Six months took agent-originated work from 17% to more than 40% on the largest code platform in the world. Whatever your industry's version of that number is, it is moving in the same direction.
So the person on your team who slows down. The one who asks the annoying clarifying question. The one who says "where did this figure come from" when everyone else is ready to send it.
That is not friction. That is the function.
I spent a long stretch of my life learning what it costs to get something consequential wrong, and I am not going to pretend that experience was pleasant or that I would recommend the curriculum. But it left me with one conviction that has only gotten more useful: the person who checks is doing the most valuable work in the building, and almost nobody thanks them for it.
Be the one who thanks them. And then go find out whether you are the person who checks, or the person who has been quietly impatient with them.
I know which one I was.
P.S. If this landed, I would rather hear your version than sell you anything. Come find me in the free Facebook community and tell me who on your team catches the things nobody else does. I will probably steal your answer for a future post, and I will credit you when I do.
About the author
Jonathan Mast is the founder of White Beard Strategies LLC, where he teaches non-technical entrepreneurs how to use AI to amplify the skill and experience they already have. He runs a Facebook community of roughly 500,000 entrepreneurs. He has been to prison, built a seven-figure agency, lost it, and rebuilt, and he will tell you about all of it if you ask. He is still, by his own admission, learning to be patient with the person on his team who slows down to check.