An "Everything Just Changed" Moment in AI Coding
Moving from Single Horse Power Coding to a 400HP Car
Five Paradigm Shifts in 25 Years of Building Software
I’ve had five “everything just changed” moments in my career. Not incremental improvements. Moments where the ground shifted and what was possible afterward looked nothing like what came before.
1. Java: Write Once, Run Anywhere Wasn’t Marketing
The first was Java in grad school. I was a confident C++ developer. Then I turned in an assignment that worked perfectly on my machine and completely broke on the professor’s.
Next assignment, I tried Java on a lark. Sun’s “write once, run anywhere” promise wasn’t marketing copy—it was real. The friction I’d accepted as normal just... disappeared.
I spent the next decade at Sun building Java EE. That one broken assignment changed the trajectory of my career.
2. Jenkins: Software Delivery Could Be Automated
The second was discovering Jenkins—built by my colleague Kohsuke Kawaguchi at Sun. At the time, software delivery was manual, painful, and treated as someone else’s problem after you wrote the code.
Jenkins made a simple proposition: software delivery could be as automated as software building.
That insight led to 15 years of working together. It spawned the entire DevOps movement. Billions of builds later, the friction we accepted as normal had vanished again.
3. Cloud: Infrastructure as Someone Else’s Problem
The third was the advent of cloud computing. Suddenly the entire infrastructure layer—servers, networking, scaling—became someone else’s problem.
This led me to CloudBees PaaS. We were building Heroku for Java, or in more modern terminology, something like Lovable—but a decade too early. The market wasn’t ready. But the insight was right: developers shouldn’t manage infrastructure.
More importantly, cloud changed how I thought about building products. Everything I built afterward was SaaS-first. The mental model shifted permanently.
4. AI/ML: The Signal in the Noise
The fourth was 2018. Something clicked. The convergence of cloud maturity, DevOps tooling, and AI/ML capabilities felt like it was reaching a tipping point.
That conviction led to Launchable—an AI/ML company applying machine learning to software testing. We were probably a couple of years early there too. The pattern recognition was right, but the market needed more time to catch up.
Being early is its own kind of lesson. You see the shift coming, but timing matters as much as vision.
5. Claude Code: Something Shifted Last Week
The fifth happened last week with Claude Code.
I’ve played with AI coding tools since GPT-3. Copilot was useful—like a smart autocomplete. Cursor was better—more context-aware, more capable. But neither felt like a paradigm shift. They were incremental.
Then I started using Claude Code’s multi-agent workflows. I haven’t opened an IDE in days. Not because I’m lazy. Because I’m building faster than I ever have.
The 400 Horsepower Problem
My friend Sameer Karmarkar, CTO CloudHedge put it well: we learned to code and came out with a single horsepower engine. Copilot gave us maybe 2-3x. But with agentic workflows, it feels like every developer is about to have a 400 horsepower engine.
The question isn’t whether you can code. It’s whether you can drive.
This is where it gets interesting—and where most of the current discourse misses the point.
I’ve heard observations like “AI assistants will just expose your process inefficiencies” and “you need to clean up your processes first.” That’s not wrong, but it’s missing the bigger picture.
Here’s my contrarian take: a large number of these processes are going to be rewritten entirely. We’re not going to clean up our existing workflows and bolt on AI. We’re going to discover that many of the workflows existed because of constraints that no longer apply.
Think about it. We have code review processes designed for human attention spans. Deployment pipelines built around the assumption that builds are expensive. Testing strategies that assume developers won’t write enough tests because it’s tedious.
What happens when the cost of generating code drops 10x? When an agent can write and run 500 tests in the time it takes you to write one? When the bottleneck isn’t writing code but deciding what to build?
The processes we’ll need are fundamentally different.
From Driving to Fleet Management
Here’s where I think this is headed.
Right now, we’re in the “horseless carriage” phase. If you look at early automobiles, they literally looked like horse carriages with engines bolted on. The driver sat up front, in the same position as someone holding reins. It took decades for car design to reflect what cars actually were—not horses.
We’re doing the same thing with AI coding tools. We’re sitting at our IDEs, prompting one agent at a time, reviewing its output like we’d review a junior developer’s pull request. We’ve bolted a 400HP engine onto our horse carriage.
The next evolution is fleet management. Not one agent you supervise, but multiple agents you orchestrate. The mental model shifts from “I’m coding with AI assistance” to “I’m directing a team of AI developers.”
This changes everything—what skills matter, how we organize work, what “senior” even means.
Where the Hard Problems Are
I don’t have this figured out. Nobody does. But from experimenting with multi-agent workflows, here’s where I see the friction:
Governance. When multiple agents collaborate, who’s responsible for the output? How do you audit decisions? The compliance and security implications are massive for enterprises.
Merge conflicts. Not just Git conflicts—conceptual conflicts. Agent A builds a feature assuming one architecture. Agent B builds another feature assuming a different architecture. Human judgment is still required to resolve the contradictions.
Abstraction layers. We need new primitives. Just like we went from assembly to C to Python, we need new abstractions for orchestrating agent work. The current tools feel like writing shell scripts to manage processes—it works, but it’s not the right level of abstraction.
I’m early in exploring this. But it feels like the same kind of “something is shifting” sensation I had with Java, Jenkins, cloud, and Launchable.
The Compound Effect
Each shift made the next one possible:
Java made Jenkins possible—you needed portable code before you could automate delivery.
Jenkins made cloud-native development possible—you needed automated pipelines before you could deploy continuously to elastic infrastructure.
Cloud made AI/ML accessible—you needed scalable compute before you could train models economically.
And now AI-native development is emerging from all of it.
I’ve been experimenting with new workflows—multi-agent orchestration, tools like Beads, new patterns for how software gets built. The compound effect of these five shifts is just starting to become visible.
The question for anyone building software: are you still driving a horse carriage with an engine bolted on? Or are you learning to manage a fleet?