I woke up to 77 pull requests. None of them were from a human.

The night before — a Sunday — I had connected the scheduling system to my autonomous development pipeline and gone to sleep. Bug fixes I’d been meaning to get to. Documentation I’d been putting off. Performance improvements the system identified on its own. Some of these I hadn’t even thought of. Seventy-seven completed, tested, reviewable changes to production systems. Generated while I slept.

I sat with my coffee and scrolled through them, and something shifted. A few months ago, I published a post about managing 20 AI agents simultaneously — the rules for orchestration, context management, the shift from writing code to architecting systems. That post described a person directing traffic. This is what happens when the traffic starts directing itself.

The gap between having an idea and seeing it built has effectively collapsed. Not “is collapsing.” Not “will collapse soon.” Has collapsed. Present tense. For a growing number of people, at a growing number of companies, the constraint on what gets built is no longer execution. It’s imagination. I call this building at the speed of thought, and I think it changes more things than most people realize.

There used to be a tax on ideas, and it just hit zero

For most of the history of software, there was a tax on ideas. You had a thought, and then you spent days or weeks or months turning it into working code. The tax was high enough that most ideas never got built. You triaged ruthlessly. You picked the three things that mattered most and let everything else die on a backlog.

The tax is now approaching zero.

I run roughly 60 autonomous AI agents that handle everything from bug fixes to feature development to competitive analysis. I describe what I want in plain language. The system designs it, implements it, tests it, and puts a working PR in front of me. Sometimes I describe it. Sometimes the system identifies the work itself.

This isn’t a demo. I work at a real estate tech company doing around $100M in revenue. Large team. Legacy systems. Real customers. The agents are working on production code, not toy projects.

When the tax on ideas hits zero, the economics of building software invert. You no longer ask “is this worth building?” You ask “is this worth *not* building?”

Speed becomes recursive and the bottleneck keeps moving

Something that used to take weeks takes a day. Something that took a day takes an hour. Between meetings, I deploy skills I spent decades developing — architecture, systems thinking, pattern recognition — at speeds that were previously impossible. But the speed itself generates more ideas, which generate more execution, which generates more ideas. The flywheel spins faster than any individual can track.

Here’s what a typical day looks like now. Between morning meetings, I review overnight work. The system has generated 15-20 PRs. Some are straightforward — dependency updates, lint fixes, test improvements. Some are substantial — a new API endpoint, a refactored data pipeline, a competitive analysis report. I approve, reject, or redirect. About a third get rejected outright — wrong approach, stale assumptions, or solutions to problems we’ve already solved a different way. Each decision takes seconds because the system provides context, test results, and rationale.

During a 15-minute break, I describe a feature I’ve been thinking about. Not a spec. Not a ticket. Just the idea, in plain language. By the time my next meeting ends, there’s a working implementation waiting. Maybe it needs refinement. Maybe it’s 80% right. But the distance from “I wonder if we could…” to “here it is, running” has collapsed from weeks to hours.

Back when I was managing those 20 agents, I was the bottleneck. I was manually directing each one, and my cognitive capacity was the limiting factor. That bottleneck broke. The system now orchestrates itself. It proposes work, executes it, and surfaces results. My role shifted from directing to curating — from choosing what to build to choosing what to keep.

And then the bottleneck moved again. When I started, it was code generation. Then orchestration. Then review — the system generates PRs faster than humans can evaluate them. Each time the bottleneck moves, it reveals the next constraint. Right now, the constraint is organizational: processes designed for human-paced development, review workflows that assume a person wrote the code, deployment pipelines calibrated to the old speed.

The factory model is right about the future

While I’ve been living this shift, two pieces published this week crystallized the poles of the debate. Simon Willison profiled StrongDM’s “Dark Factory” — a team operating under two rules: humans must not write code, and humans must not read code. Nolan Lawson published “We Mourn Our Craft,” an elegy for programming as a human practice.

The factory model is right about the future. The economics are too clear. The capability curve is too steep. Hand-written code won’t disappear overnight, but it’s becoming a specialty rather than the default. The organizations that figure this out first will ship in a week what their competitors plan in a quarter.

The mourning is also correct. Something real is being lost. The act of holding code in your hands and shaping it — the craft that drew most of us into this profession — is becoming optional, then rare, then historical. Engineers are getting hit with gut punch after gut punch: first copilots, then agents, now articles declaring the whole practice obsolete. I work alongside these people. The emotional weight is real.

Both the factory optimists and the craft mourners are telling true stories. They’re just telling them from different vantage points.

It’s a people problem wearing technology clothes

Almost everything about organizational reality is missing from the discourse.

The technology is ready. Genuinely ready. The models can write code, test code, review code, and iterate on code at a level that handles most day-to-day engineering work. That’s no longer the interesting question.

The interesting question is: how do you actually do this at a company that exists?

You need dedicated people who understand both the AI systems and the business domain. You need leaders willing to restructure teams around a fundamentally different model of work. You need investment in infrastructure that doesn’t directly ship features. You need the organizational will to say “we’re going to change how we work” and then actually do it.

At a mature company — with legacy systems, established processes, compliance requirements, and teams of people whose identities are tied to the old way of working — this is where the real complexity lives. The thought pieces make it sound like a technology problem. It’s a people problem wearing technology clothes.

This is addicting

Last Tuesday I closed my laptop at 11pm. At 11:02, the system pinged me. I opened it. Approved three fixes, kicked off two new features, closed it at 11:20. Nothing was urgent. I just couldn’t not.

When execution matches the pace of ideas, every idle minute feels like waste. The feedback loop — idea, execution, result, new idea — is tighter than anything I’ve experienced in two decades of building software. Skills I spent years developing didn’t disappear. They became multipliers. Every instinct, every pattern I learned to recognize, every architectural decision I internalized — all of it now deploys at a speed that makes the old way feel like carving stone with a chisel.

It’s exhilarating. It’s also clearly unsustainable at the personal level, and I haven’t figured out where the boundary is.

At the team level, the unsustainability is more concrete. PRs pile up faster than humans can review them. The system’s output exceeds the organization’s capacity to absorb it. You can build at the speed of thought, but you can only *deploy* at the speed of trust — and trust moves at a human pace.

When building is free, judgment becomes the whole game

If the system can execute anything I can imagine, the value of execution drops and the value of judgment rises. What should we build? What should we ignore? What’s the right sequence? Where are the second-order effects?

These are questions that require domain knowledge, strategic context, and taste — exactly the things that are hardest to automate and most valuable in experienced engineers. The irony: implementation skills lose their value, but the judgment those years of implementation built becomes irreplaceable.

The value of ideas goes down — because ideas are cheap when execution is free — and the value of *good* ideas goes up, because you’ll build all of them, so the filtering matters more than it ever has.

The systems I’ve built are one implementation of something much larger — a condition where thinking something and building it are separated by minutes instead of months.

We’re living in that condition now. The question is what kind of builders we become when building is no longer the hard part.

Related