Post-Scarcity Engineering

Or: How I Learned to Stop Rationing and Love the Merge Button

We gave the rest of Gearflow the means to fix the product. I wish we’d done it sooner.

On a Thursday morning in October, a support specialist posted in our urgent product channel. A customer clicked “Approve Request.” Nothing happened.

Seven minutes later, an agent had the answer. The ship-to location didn’t match the equipment’s project. The server rejected the approval, and the screen swallowed the error. The agent posted a workaround, filed an issue and started the fix. The fix merged 22 minutes after the first message. The support specialist was the only person involved.

I’m an engineer. For most of my career, that report would have gone into a queue that people like me controlled. We would decide how urgent it was, who had time and what other work had to slip. This time, nobody needed us.

We built the queue because we had to. Then we kept it.

Engineering time is expensive. You learn to protect it. You ask for a ticket. You ask for reproduction steps. You ask whether this affects one customer or twenty. You put it through triage. Each step has a reasonable explanation. Meanwhile, the customer still can’t approve the request.

We built our agent harness to make our engineers faster. We gave agents access to our systems, shared context and explicit rules about what they could do.

It worked. Then we had to face an awkward question: why did everyone else still need an engineer’s permission to get a bug fixed?

Our support specialists knew what was broken. Our salespeople knew what blocked a rollout. They could explain the problem and judge the result. The agent could do the engineering. We kept asking them to get in line anyway. So we changed the rules.

Four engineers. Ten times the pull requests.

Gearflow has four engineers. We had five until one left in August. We didn’t replace them. Before the harness, we merged about 39 pull requests a week. Over the last four weeks, we averaged about 388.

Pull requests are a crude measure. You can merge plenty of code and accomplish nothing. What makes this number interesting is the work behind it.

On a Monday at 5:40 pm, an engineer asked an agent to clear our backlog of out-of-date dependencies. The agent created a project and filed about 40 issues. The rules were specific: one dependency per pull request, security fixes first, proof on every change. Certain changes required approval. The engineer went home.

By 8 the next morning, agents had merged 29 pull requests. The board was clear that afternoon. The engineer’s only input overnight was one “yes.” That work used to compete for time with everything customers wanted. Now it can run overnight.

We haven’t run out of engineering work. Cheaper fixes produce more requests for fixes. Things we used to tolerate become things we can repair. I stopped writing code, and the product moves faster than when I did.

Sales got tired of waiting, too.

Our sales and customer success team held customers back from our new platform because they kept finding bugs during customer use. On an internal call, they asked for their own environment. They wanted to find and fix problems before customers hit them.

The harness read the recording and filed the request. The next day, the team had a shared test app. Nine days later, that app contained 33 pull requests. Two people outside engineering drove 28 of them.

One was a salesperson. A contractor had said it would not start its rollout until parts orders could carry a cost code.

The salesperson promised it in a week and a half to two weeks. Then they worked through two rounds of design options with an agent, published a clickable prototype and had the agent build it. It was live on the test app 55 hours after the issue was filed.

The person who heard the customer’s requirement stayed with it through design and implementation. They could judge whether it solved the problem because they understood the problem. That used to qualify them to write a ticket.

“We’ll look into it” got a lot shorter.

On a weekly customer call, a fleet leader pointed out that our maintenance dashboard showed their office’s typical response time as zero seconds. “How beta is this beta?” Our support specialist said they would look into it.

The harness read the transcript, filed the issue and pulled three frames from the call video that showed the bug. An agent fixed it about 75 minutes after the customer raised it. Nobody had to remind anyone. Nobody had to transcribe the complaint into a better complaint for engineering.

Production data follows its own permission rules. Our support specialists have explicit authority for those corrections, too.

When a race condition marked a paid order as canceled, a specialist asked an agent to correct it. The agent ran a dry run. It caught that approval through the app would charge the card again, corrected the record and posted the undo steps. A second agent fixed the race in code. Both were done 68 minutes after the vendor reported the problem.

Fixes started by people outside engineering went from about five a week to about 25. The backlog was never a complete account of what needed work. It also reflected how much effort people would spend to get our attention.

Engineering still has a job.

We own the harness. We own the hard design problems. We own the checks that let these changes merge. And when the harness wastes time, we fix that too.

Every evening, a review session reads the day’s sessions for problems. One night, it found five sessions that had each researched the same partner API from scratch. Our notes incorrectly said the API lacked a feature.

The correction merged four minutes after the issue was filed. When a correction fails to hold, the review raises it again.

There are limits. People still authorize production deploys. Agents need approval to spend money. A merge grant determines whether an agent can finish the work.

Those permissions have consequences. One bug waited seven weeks under a human-merge requirement. The call-recording fix above had a merge grant and took 41 minutes from issue to merge. You can buy the same models and keep the same queue.

I don’t want the old job back.

Our support specialists know how a parts manager orders a part. They know which records are wrong and what a customer means by “it’s broken.” Our salespeople know which missing feature stands between a contractor and a rollout.

We made those people explain themselves to engineering, then wait for us to find time. We lost detail at every handoff and called the delay prioritization. Now they can carry the work through.

In the last 30 days, agents wrote 1,963 of our 1,968 merged pull requests. Since go-live, 731 fixes started with a report from someone outside engineering.

Those people always had the knowledge. We finally gave them somewhere to use it besides a ticket. I have no interest in taking the merge button back.

Figures and examples use the supplied draft’s GitHub and Linear data through October 8, 2026. A pull request counts as agent-written when it carries an AI-agent signature. A merged fix still needs a production deploy to reach customers.