The Big Constraint Flip
What happens when execution starts to outpace ideas?
My friend Sandro Mancuso described in his book Software Craftsmanship (2014) what he believed to be the ultimate aspiration for software teams: a development organization so effective that it can execute faster than the business can generate new ideas, or as he describes “as fast as they change their minds”. No bugs accumulating. No enhancements waiting. No tech debt on roadmaps. Almost no backlog.
“We should be able to change the code almost as fast as they change their minds, giving the business an opportunity to visualise their ideas and also get feedback from the people that will use the application.”
– Sandro Mancuso.
For most of my career, this felt like a north star. Something to orient toward. Never to reach. The backlog always won. There was always more to build than hands to build it.
That constraint just flipped!
For the first time in 20 years, I’m executing faster than my constant flow of new features, bugs, tech debt, enhancements. (and people that worked with me know, that is usually a very long list!) My entire backlog now fits on my daily todo list and by noon most days, it’s gone!! This has never happened before in my entire career.
The bottleneck moved. For the first time ever, the constraint isn’t capacity. It’s choice.
Here’s what’s strange: all those engineering management multi-tasking skills I developed over the last decade (managing a constant stream of 15+ DMs, 10+ threads, 100+ channels on Slack, a COMMAND+K OCD I’m not proud of, a constant stream of RFCs, presentations and postmortems to review, and having more Chrome tabs open than I could ever read at any given time) are suddenly useful in a completely different way. Context-switching isn’t overhead anymore. It’s throughput now.
I’m not alone. My feed is full of experienced engineers building “impossible” projects over the weekend. Things that would’ve required 5-10 engineers and months of coordination before. Domains and parts of the stack they’d never touched alone: mobile, low-level systems, compilers, databases, DevOps. It’s easier than ever to be a true full-stack engineer, a one-person show. Dependency hell on other teams, libraries or micro-services? They just jump in and fix it in a couple of sessions. The learning curve that used to take months? Pretty much gone overnight.
And yes, maybe the code isn’t perfect. Maybe they’re wasting loops that experts wouldn’t. But you know what? They ship. They iterate fucking fast. For most things - especially prototypes, things that would never see the light of day otherwise - it almost doesn’t matter if the initial version isn’t perfect.
And I’m not saying this out of thin air. In the last 30 days alone: 289 sessions. 19 different projects. 7 languages (Python, Go, Swift, TypeScript, Dart, Java, Bash). My highest month of GitHub contributions ever.
And I don’t think I’m the best at this. Not even close! But here’s what I shipped in the last few months:
an iOS app with system-level audio capture (last time I wrote Swift and touched Xcode was 2018, shipped in 9 days).
four Go projects in six weeks (had never written a single line of Go before October).
a semantic code search engine with vector databases and AST parsing (72 hours).
unified 15 years of Amazon purchase history and Kindle reading (226MB of CSVs!) into a searchable timeline (2 sessions!).
found an open source repo visualization tool similar to CodeScene (git-truck), understood the entire Remix + D3.js codebase, and shipped my own modifications - in under 48 hours. Something I had been dreaming of for years. These definitely wouldn’t have been possible before for me.
And a lot more! Built my “gmail second-brain” from my 40GB gmail data dump. Created an AI vision pipeline to process 336+ handwritten notebooks to searchable markdown from my Remarkable 2 tablet. Created a real-time monitoring dashboard for my local ollama that kept crashing as I trying to process 40000 markdowns…
What remains is different: coming up with new ideas and deciding what’s worth building. That’s a hard problem. But it’s a different problem. One most of us are unprepared for.
The question is no longer ‘Can I ship this?’.
It’s ‘Should I?’, and ‘What else could I build?’
That’s a fundamentally different constraint. A higher-order problem. One most of us never had to develop because we were always capacity-bound. Saying no was easy. We didn’t have time anyway.
Now saying no requires taste. Judgment. Strategy. Discipline.
Everybody is talking about agents. 50+ agents and subagents running at any given time. --dangerosly-skip-permissions everywhere. Solving race conditions between paralell workers. Different roles and skills for each…
I might be totally wrong on this. Maybe I’m completely underestimating the capacity of having hundreds of agents for software development. But, as of today, I’m still to find a use case where I would actually need such complex overhead to manage. I’ve challenged myself with some very ambitious projects and five terminal tab tops with agents with a few sub-agents each max for specific things here and there keeps winning for me. At least that is my 80/20 now. To me, most of the complexity to manage dozens to hundreds of agents sounds like an excuse to keep optimizing the system instead of really shipping.
Here’s the 80/20 I reached that made me more productive than I’ve ever been:
First, I see every permission prompt (especially long bash scripts and new plan/plan edits) as a steering wheel, not a speed bump. I have 100+ permissions pre-authorized on my ~/.claude/settings.json. I don't even see them being executed. But, I see every permission ask out of the “ordinary” as a chance for me to interject and correct direction. I co-pilot, not auto-pilot. After a lot of trial and error, I have found that is much easier to adjust course than to rewrite a mistake made 50 messages ago. And a lot less frustration. Vibe coding is exhausting because you review at the end. I review in flight, perhaps even more exhausting, but it works. And seeing the progress on the right direction is rewarding, especially with no or very small surprises at the end.
Second, I create reusable commands for workflows I find myself doing repeatedly. I have 58 custom commands now - for batch-commits, translations, style checks, book analysis, session saves…
Third, I never let Claude Code lose track of session context. /save-progress before the context window fills up and the somehow unreliable /compress messes things up and makes me lost the control of the steering wheel and the agent to go in a completely different direction. /recap to restore. /compound to accumulate learnings across sessions. Claude code gets smarter about my codebase and my preferences over time - but only if I’m intentional about it and keep pulling back the steering wheel from it.
Sandro’s vision was always about entire engineering organizations. But, what happens when a single engineer can reach it?
Exciting times!
---
P.S. Shoutout to Rod Garcia for reviewing and providing feedback on an earlier version of this essay, and to Louie Bacaj for introducing me to Claude Code back in June and sharing some of his top workflows and small tricks along the way.