This week, our monorepo passed pull request number 14,948.
We'll probably hit 15,000 before you read this.
That number needs a caveat. We haven't opened 15,000 pull requests this year, and a pull request number is not the same thing as 15,000 shipped features. It's still a useful marker, though, because the pace at which software can be produced has changed dramatically.
Pull requests opened across all TextureHQ repositories each month in 2026. August runs through August 27. “Fleet Agent” means our hosted autonomous agents; “Human-opened” includes work accelerated by Claude Code, Codex, and similar tools.
There are really two curves hiding in this chart. The Fleet Agent segment is the work produced by the hosted agents I've been describing in this series, but the human segment has grown substantially too. Our engineers have been using Claude Code, Codex, and other agentic coding tools, so a pull request opened under a human identity often represents a human working with considerably more leverage than they had a year ago.
We haven't added a single human engineer during this period. Both forms of output increased with the same team, which is honestly remarkable, but it also reinforces the point of this article: more production capacity means more decisions about what deserves to be produced.
There's another part of that story hiding behind the chart. Early in Texture's life, we made a deliberately contrarian hiring decision. Instead of building a large, junior team, we hired a small number of deeply experienced people who had already learned which shortcuts are recoverable, which technical debt is structural, and which problems aren't worth solving. I wrote about that philosophy in Why Texture Bets on Experience.
The agent fleet has made that bet compound in a way I did not anticipate. We originally hired these people to operate as senior engineers. Now each of them increasingly operates like an engineering leader with a team behind them. They frame problems, supply context, split work, delegate implementation, review the result, and remain accountable for what ships. The difference is that the teams underneath them are agents, not additional human hires.
We didn't add layers of management or double the engineering headcount. We gave an already senior team far more production capacity, and the nature of their jobs changed. They still write code, especially with tools like Claude Code and Codex, but more of their value now comes from judgment: knowing what to delegate, how to constrain it, when the result is good enough, and when to reject it entirely.
That's a strange and fascinating organizational trajectory, and it could only have happened at this moment in history. Our engineers grew into leaders of a much larger production system without the company needing to hire a conventional team underneath each of them. The organization matured because the humans did, not because the humans multiplied.
At Texture, AI agents now find bugs, propose fixes, build internal tools, and open pull requests alongside our engineers. I recently wrote a five-part series about how we built and operate that agent fleet, including the identities, access controls, review gates, and infrastructure that make it useful inside a real company.
The obvious conclusion is that we're getting much faster at writing code.
We are, but that isn't the most important change.
When code becomes cheap to produce, judgment becomes the expensive part.
The bottleneck moved
For most of my career, turning an idea into working software required a meaningful amount of engineering time. Even a small feature competed for a limited supply of people who could understand the system, write the code, test it, and get it into production.
That scarcity shaped how companies worked. Product teams built roadmaps around engineering capacity, technical leaders argued for headcount, and worthwhile improvements sat in backlogs because nobody had time to implement them.
AI hasn't eliminated that work, but it has compressed a surprising amount of it. A well-equipped agent can inspect a codebase, trace a bug through several services, write tests, and prepare a reviewable pull request in the time it once took a person to gather enough context to begin.
That sounds like the bottleneck disappeared, but it didn't. It moved upstream and downstream.
Upstream, someone still has to decide which problems deserve attention and what a good solution should do. Downstream, someone has to decide whether the proposed change is correct, safe, maintainable, and worth shipping.
The typing got cheaper. The deciding didn't.
More output creates more decisions
Imagine that your engineering organization could produce 10 times as many plausible changes tomorrow. Would you be ready to ship 10 times as many?
Probably not, because every change creates questions that code generation can't settle on its own.
Is this the right problem? Does the proposed behavior match what a customer actually needs? Are we fixing a symptom while making the architecture worse? Is the added complexity justified? What happens when the happy path breaks? Should this exist at all?
Those aren't coding questions, although you need technical depth to answer many of them. They're judgment questions, and producing more code produces more of them.
We've seen this directly with our agent fleet. The agents are very good at turning a clear objective and enough context into concrete work. They're much less useful when the objective is vague, the constraints are implicit, or nobody has decided what “done” means. In those cases, speed doesn't remove ambiguity; it lets you manufacture ambiguity faster.
This is why I don't measure the value of our fleet by lines of code, tickets touched, or pull requests opened. A flood of technically valid changes can still be a terrible outcome. The useful measure is whether we solved the right problems and made the system better without creating work we will regret later.
Taste is becoming an engineering skill
“Taste” can sound soft, especially in engineering, but I mean something concrete: the ability to look at several workable solutions and recognize which one fits the product, the architecture, the team, and the moment.
A solution can be correct and still be wrong for us. It might introduce a new abstraction for a problem we only have once, add a dependency we don't want to own, make the common path harder to understand, or optimize for a future that may never arrive.
Experienced engineers have always made these calls. What has changed is the ratio. When implementation was expensive, a lot of weak ideas died because nobody had time to build them. Now an agent may be perfectly willing to build every one.
The friction used to protect us accidentally. We have to replace it with deliberate judgment.
That means a strong engineer in an AI-heavy organization won't merely be the person who can produce the most code. It will be the person who can frame a problem clearly, identify the real constraints, reject attractive distractions, and explain why one solution is better than another.
Those skills were always important. They're becoming the job.
Review is not a ceremonial gate
In What Made It Actually Work at Scale, I described a hard boundary in our system: an agent can open a pull request, but a human has to review and approve it before the change is merged.
It would be easy to treat that as a compliance step, the software equivalent of clicking “I agree.” That would miss the point.
Review is where responsibility lives. The reviewer isn't checking whether the agent produced code-shaped output; they're deciding whether Texture should own this change. Once it's merged, we own its behavior, its maintenance burden, its security implications, and the customer experience it creates. “The agent wrote it” isn't an explanation we can give a customer when something breaks.
This is also why faster code generation won't automatically make engineering organizations faster. If you multiply output without improving problem definition and review, you'll simply move the queue. Pull requests will pile up, reviewers will skim, and the organization will trade an implementation bottleneck for a decision bottleneck with more risk attached.
The answer isn't to slow the agents down. It is to invest in the humans and systems around them: clearer specifications, better tests, explicit constraints, smaller changes, stronger observability, and reviewers who have enough context to make real decisions.
Responsibility cannot be delegated
There is a seductive story about autonomous software development in which a person states a goal and an agent handles everything else. I understand the appeal. I also think it confuses autonomy with accountability.
We give our agents substantial autonomy. In Watch It Work, I shared examples of agents picking up bug reports and production alerts, investigating them, and turning that work into something a human could review. That autonomy is valuable because it removes translation work and shortens the distance between a problem and a proposed solution.
But the agent doesn't carry the consequence of the decision. We do.
If we choose the wrong problem, ship the wrong behavior, or accept a risk we didn't understand, that responsibility belongs to the humans running the company. The more capable the tools become, the more important it is to be honest about that distinction.
You can delegate implementation. You can delegate investigation. You can even delegate the first draft of a decision.
You cannot delegate ownership of the outcome.
The next constraint
Software organizations spent decades optimizing the production of code. We built better languages, frameworks, cloud platforms, deployment systems, and development processes, and then AI changed the slope of the curve again.
Now we need to optimize the production of good decisions.
That'll require better ways to preserve context, define intent, evaluate tradeoffs, and review work at the speed it can be generated. It'll require technical leaders who remain close enough to the system to exercise judgment, and product leaders who can distinguish a real customer problem from something that's merely easy to build.
Most of all, it'll require restraint. When almost anything can be built, deciding what not to build becomes a competitive advantage.
We are about to pass pull request number 15,000, and I expect the next 15,000 will arrive much faster than the first.
I'm not worried about whether we'll be able to produce enough code.
I'm thinking very hard about whether we'll make enough good decisions.
