Software engineering as we know it was built for a world where code was expensive. That world is gone and is now legacy.
Here’s something I keep seeing on repeat. I pick up a ticket, spend some time getting the agent and myself aligned on the problem, agree on some test data and what done looks like, and send it off to do the thing while I go make a peanut butter sandwich.
While the clanker is clanking, which is to say implementing the code, checking its own output against the test data we agreed on, and iterating until completion, it trips over a few other bugs along the way. Let’s say, for example, one is clearly related, one is sort of related, and one is just sitting there broken, minding its own business.
By the time I’m back with my sandwich, the agent has all of it in context and I’ve got all of it in my head. Fixing the other three would take maybe another five minutes. And yet the process says to write three new tickets, toss them on the backlog, and stay in scope.
Yeah, so, I don’t think we should be doing that anymore.
Code is cheap, context is not
The cost structure of software has flipped, and our process hasn’t caught up. Sprints, tickets and tightly scoped PRs were all designed for a world where writing code was the expensive part, so we rationed it: scope it, estimate it, get it approved, and only then spend the hours.
Manu Martínez-Almeida, the creator of the Gin framework, put it well in his notes on software engineering. Pull requests, CI, testing, linters and git hygiene are “all heuristics,” and those “heuristics evolved when code was expensive.”
That world is pretty much gone. AI writes the code now, and it should be the one reading and reviewing it too, so another fifteen lines costs next to nothing. What’s expensive now is loading context, and I’m referring to that here in two separate regards. There’s human attention, meaning my time, my focus, and the mental setup of getting my head around a problem. And there’s token spend, the agent reading files and running tests until the two of us are actually on the same page.
You pay that cost every time you start a new unit of work. So when one ticket spawns ten follow-ups, you pay it ten more times, with ten more cold starts and ten more rounds of syncing up, quite possibly by a different developer each time. Fixing those same things while everything is already loaded costs a little over 1x. The “little over” is real, since you still have to chase each bug down, but a little over 1x and 10x are very different numbers, and we keep picking 10x because a process from 2001 tells us to.
The labs see this too. OpenAI just shipped 12-hour prompt caching so that persistent agents like Dots can “reuse context throughout the day.” If the platform vendors are building features specifically to avoid reloading context, maybe our process should stop forcing us to reload it.
Receipts, not permits
A ticket used to be a permit. Before you spent expensive engineer hours on something, you got permission first. Is this worth doing, is it in scope, and who owns it? For the small stuff, that permission step is now pure overhead, because when the fix is cheap and I’m already looking at it, asking permission costs more than just doing it.
So let’s flip it around and make the ticket a receipt. Do the work while the context is loaded, then have the agent write the ticket after the fact, covering what was broken, what changed and why. The board still gets updated and the record still exists. You’ve just stopped paying for cold-starts to create it.
Even Linear, a company that literally sells tickets, works this way. Karri Saarinen says they open issues even when the work gets done right away, “just to log conversation and the decision maker.” Their own agent created and merged 700 PRs in a single month, often fixing bugs straight from triage.
My rule is pretty simple, which is if the agent finds it while we’re in there, we fix it. It gets verified the same way as everything else we touched, and it ships with the rest of the work. We’ve already paid for the human labor in terms of my attention and focus and the tokens, so we might as well get our money’s worth.
The smallest possible change is a trap
While we’re on the subject, let’s talk about “make the smallest possible change.” That rule made more sense when a human had to write and review every line. The trouble with that is every fix turns into a local patch with a special case here and a workaround there. Each patch might be small and safe on its own, but together they add up to entropy.
The part that’s new with AI is that the codebase is the prompt. Agents copy the patterns they see, so a codebase full of workarounds teaches your agent at least for now to write more workarounds, and to do it confidently. Refactoring used to feel like a luxury. Now it’s maintenance on the thing that steers your agent, and it costs almost nothing.
So my approach is to refactor freely. Code is malleable now, and if something doesn’t work out, you just change it again. If you still want separate tickets or PRs for stakeholder visibility, that’s fine, and the agent can split them out for you. But it’s starting to feel a little silly when some teams have stopped doing PRs altogether and push straight to main.
What I’m seeing in practice is that we spend as much time writing tickets and deciding what goes in which PR as we do actually changing the code, if not more. That made sense when software moved slowly. But Anthropic’s merges went up more than tenfold in four months, and plenty of teams are seeing their own version of that jump.
We can’t all be Anthropic, but if you hang on to the legacy approach, the overhead will cost you ten times more than it should. Be a team who cooks with agents or get cooked by someone who does.
No PRs, no problem
The pull request is next on the chopping block. Peter Steinberger has been calling PRs prompt requests since January. Contributors usually spot a real problem but bring a mid solution, so he skips the whole song and dance, rewrites the change himself, and credits the reporter as co-author.
The Amp team went a step further and dropped PRs entirely. Here’s how Thorsten Ball put it a couple of weeks ago:
That’s a team of 21 shipping a hundred releases a day, with one meeting a week and bugs fixed in minutes. And before anyone brings up compliance, they have SOC 2 and push to main.
Git along little dogge
Earlier this month, Anthropic published Redesigning source control at Anthropic, and the numbers are pretty wild. Merged changes went from about 2,500 a day in May to over 30,000 a day in September. A team of just seven people built Scion, their in-house source control system, along with a code review tool called Antique, and moved the entire monorepo off Git in five months.
There’s no global merge queue lock, either. They lean on post-merge and pre-deploy testing instead, and Claude typically sorts out conflicts faster than a human would even notice them. Human reviewers, meanwhile, now focus on the intent of each change rather than reading every line.
To be fair, they’re explicit that Scion is “by no means a suitable replacement for git for general use.” Still, it’s a glimpse of where the bottleneck moves once code gets cheap. It isn’t the writing of code anymore so much as everything we built around writing code.
One agent to rule them all
So here’s where my head is at. We need an always-on team agent running in the cloud, connected to everything the team produces: the repo, the board, the docs, Slack, and every teammate’s agent sessions. Personal agents keep doing their personal-agent thing, while the team agent gets to see the whole picture.
Boris Cherny, who created Claude Code, says Claude Tag in Slack writes more than half of his PRs every day and “fixes most of our product feedback + bugs.” In his words, “It’s not like a regular Slack bot. It is proactive, programmable, it has memory, it has access to your connectors.” That’s pretty much the team agent I’m describing, already on the job.
Once a team agent is in the picture, a few things change. Review gets a lot better, because instead of reverse-engineering a diff I can read your session transcript, and if I want to try a different approach I can fork it from the exact message where you made the call.
Claude Code and Codex already let you fork conversations. The missing piece is making those sessions visible to the rest of the team. The board turns into an output, with the agent keeping Jira or Linear current based on the work that actually happened. And collisions get caught early, since a quick “heads up, two sessions are refactoring the same module right now” can save a lot of wasted afternoons.
It all comes back to the same idea. Context is the expensive asset, and a team agent makes it shareable.
Show me the money
Okay, one more sacred cow, and it’s story points. They were always a proxy, something we invented because nobody could actually measure what software cost, but now we can. Take a developer making $165k a year plus 25% in benefits, and you’re at roughly $100 an hour. Add the token spend, which you know to the cent, and you’ve got a real dollar figure for every unit of work.
Say I spend an hour setting up a gnarly ticket while Claude runs for hours iterating on it. That’s $100 of my time and maybe $200 in tokens. If it would have taken me a couple of days by hand, that’s $1,600 of work for $300. And while Claude grinds on that one, I’m setting up the next three. Four tickets in parallel comes to about $1,200, for work that would have cost over $6,000 by hand.
Dollars are the language the business already speaks. Nobody outside engineering cares that a feature is 8 points, but “$300 instead of $1,600” means something to a client.
Meanwhile, the simple stuff like version bumps and dependency updates is already going fully automated, from ticket to ship. As the models get better, more of the work will follow. Maybe someday humans aren’t needed for software development at all. We’re not there yet, but the direction seems pretty clear.
Okay, but
I’m not saying we should burn it all down tomorrow, and a few things still deserve some respect.
Verification is the new bottleneck. Writing ten fixes is basically free, but knowing they didn’t break anything is not, and the teams pushing straight to main get away with it because their automated verification is strong. That’s what replaces the PR, not nothing.
It’s also worth remembering that AI reviewing AI shares blind spots. Even Anthropic notes that Claude’s adversarial review can be overly cautious and needs steering, and that a big part of the engineer’s job turned out to be telling Claude “no.” Tests that pin down behavior beat a second opinion from the same kind of brain.
“Access to everything” needs guardrails, too. A team agent should inherit the asker’s permissions rather than pooling everyone’s DMs, and an agent that reads external email and can push to your repo is in theory open to prompt injection.
And finally, people have their reasons. Your skeptical teammate might be the one who gets paged at 3am, so lead with an experiment and some numbers rather than a hot take. (Says the guy writing a blog post full of hot takes.)
The world already changed
Software engineering is the first industry AI has flipped on its head, and it’s flipped further than anything else so far. The tooling has noticed, the labs have noticed, and Anthropic is merging 30,000 changes a day on a version control system it built because Git couldn’t keep up.
The thing that’s lagging is our process, which still rations code like it’s expensive and pays the context tax ten times over to do it. So fix the bug while you’re in there, let the agent write the receipt, share the session, and put a dollar figure on it.