Setting aside the internet as THE transformational event of my lifetime and focusing on how we actually build and ship software, I’ve lived through a few real revolutions. Not hype cycles. Permanent rewirings of what mattered.
I wrote software professionally for about half of my career, from 2002-2015, with a hiatus from hands-on coding after moving into a management role. Since 2015, I’ve worked on minimal personal projects, mostly just enough to “keep the sword sharpened”.
I’ve shipped more code in the past three months (on personal projects) than in the last decade.
Prior Revolutions
Web apps and SaaS: Software stopped being something you shipped and became something you operated. Release cycles collapsed. Feedback loops tightened. CI/CD wasn’t even conceptually possible before this.
Open source as default: Using open source went from counter-cultural to insane-not-to. It changed how we learn, how we build, how we evaluate engineers, and how fast ideas spread.
AWS and on-demand infrastructure: Infra stopped being a capital decision and became an API call. Whole categories of work vanished. New ones appeared. “How good are you at servers?” became “how well can you compose systems?”
Each of these rewired the industry’s center of gravity. What was valuable became table stakes. What was rare became irrelevant. New currencies emerged. But in every case, the builders were still engineers. The tools changed what we could do, not who could do it.
And each time, I watched the same pattern inside companies: a small group saw it early, pushed for adoption, and had to make the case while the rest of the org was still comfortable with the old way. Eventually the industry moved anyway. But the teams that leaned in early didn’t just survive the transition, they shaped it.
What I Think We’re Living Through Now
What we’re seeing right now with agentic AI tools feels different from the next framework. It doesn’t feel like the next language. It doesn’t even feel like the next platform shift.
It feels closer to those moments above. Even bigger.
Here’s why: those earlier revolutions were optimizations for engineers. AWS changed how we hosted. Open source changed how we sourced components. Both were force multipliers for people who already knew how to build.
This is different. This changes who can build.
I’ve watched our VP of Revenue write code to solve his own problems. Not “use a no-code tool” to write code. Actual code for personal problem solving. That’s not an engineer getting faster. That’s a non-engineer becoming capable of something that was previously impossible for them.
Multiply that across every role in every company, and you’re not talking about productivity gains for existing builders. You’re talking about a massive expansion of who participates in building software at all.
Because this isn’t just about writing code faster.
It’s about where the work moves.
Once upon a time, the work was literally typing. Text editors. Printed code reviews. The primary currency was time at the keyboard.
Then came IDEs, better languages, better frameworks. The work shifted upward. We became more like software composers: more time spent shaping systems, less time fighting syntax. Bootstrapping accelerated. Patterns hardened. Leverage increased.
Now something fundamentally different is happening.
The New Starting Point
The “bootstrap” layer is no longer file trees and scaffolds.
It’s full implementations. Tests. Refactors. Code review. Screenshots. Documentation. Reasoning.
We are no longer starting from stubs.
We are starting from working software.
That is not linear progress. That is a phase change.
Why This Feels Uncomfortable
Every real revolution in software feels wrong at first.
SaaS felt unserious compared to “real” installed software.
Open source felt risky compared to vendor or home-grown products.
AWS felt like losing control vs owning the hardware.
In each case, what people were really reacting to was a loss of familiar value. Hard-earned skills stopped being scarce. The things that made you good stopped being the things that made you valuable. And new skills didn’t even have names yet.
I feel this too. These tools encroach directly on the most sacred activity in our industry: writing code. The craft we’ve spent years developing. The thing that makes us us.
So it’s natural to wonder:
“Is this real?”
“Is this actually good?”
“Does this undermine what we do?”
We asked similar questions about cloud infrastructure. About open source. About dynamic languages. About frameworks.
The completely bootstrapped, open-source development frameworks that are the basis of most modern applications are as foreign to my 2002 self, equipped with emacs and Cerner’s “feature tracker” SCM system, as fully automated agentic assistants probably feel to many of us today.
But the pattern is always the same: we focus on what’s being automated or “going away” instead of where the human advantage moves.
The Shift in Currency
If the bootstrap layer now probably includes getting all the way to an initial copy of working software, then typing is no longer the bottleneck.
So what becomes scarce? What becomes valuable? What becomes the work?
I think some early candidates are already visible:
Specification becomes a first-class skill. Not tickets. Not vague requirements. Real specs. Clear intent. Constraints. Non-goals. Tradeoffs. Invariants. Success criteria. If you can’t explain what you want, you can’t compound with these tools. The skill isn’t prompting, it’s articulating reality clearly enough that others (human or otherwise) can execute on it.
System shaping beats system building. Designing the architecture of work itself:
- What gets delegated to agents
- What runs continuously
- What gets verified automatically
- What deserves human attention
This starts to look less like coding and more like directing. Coordinating tireless collaborators who work at machine speed.
Taste, judgment, and standards rise in value. When production of code explodes, discernment becomes the constraint. What is acceptable? What is elegant? What is dangerous? What actually solves the user’s problem? This isn’t soft. This isn’t hand-wavy. This is where products live or die.
Orchestration over implementation. Understanding agents, sub-agents, tool boundaries, long-running jobs, verification loops, feedback injection, evaluation harnesses. This is closer to building factories than building scripts.
Learning to Coexist with “Good Enough”
Here’s something worth acknowledging: some of what these tools produce isn’t up to the same standards we’d hold ourselves to.
The code is... not broken. Not wrong. Just less considered. Generic. Functional but not elegant. The kind of code that technically works but doesn’t reflect particular care or craft.
This is real. And it’s probably going to get more common, not less.
But I think we’re asking the wrong question when we focus on “how do we prevent this?” The better question is: where does it matter?
Load-bearing code: Some code touches patient safety, money, user trust, security boundaries. It’s the difference between a recoverable bug and a front-page incident. Here, “good enough” isn’t good enough. But this was already true, we’ve always applied extra scrutiny to these areas. The difference now is making that scrutiny explicit, automatable, and systematic.
Scaffolding code: Other code is internal tools, one-off migrations, glue scripts, tests for low-risk paths, internal documentation. If it works, it works. Spending hours polishing this code was never the best use of our attention, we just didn’t have another option before.
This is a taste problem, not a tooling problem. No linter will tell you which category you’re in. That judgment is yours. And it’s not new, exactly, senior engineers have always known where to be careful and where to move fast.
But the ratio is shifting. When you can generate ten times the output, you need ten times the clarity about where quality is non-negotiable.
The teams that develop this instinct will move fast without breaking what matters. The teams that don’t will either drown in review or ship problems they didn’t anticipate.
Process Has to Evolve
It’s natural to ask: “How do these tools fit into what we already do?”
But maybe that’s the wrong question. Process isn’t sacred. It’s supposed to be a living document of what we believe works. When the evidence changes, process should too.
These tools change what’s possible. That’s new evidence.
We probably can’t design the right workflow upfront, we have to discover it through experimentation, through learning, through sharing what works and what doesn’t. The new process will emerge from that.
We’re still running Shape Up1. That doesn’t change. What probably changes is how much we can accomplish within a cycle, and we’ll learn that through experience.
On Timing
There’s a question worth asking: are we early, late, or right on time?
I think we’re right on time.
We’re not the earliest adopters, the ones who were experimenting with this stuff two years ago, fighting with rough edges and building their own tooling from scratch. Those folks deserve credit for scouting the territory. But early adoption has costs: you spend a lot of energy on problems that get solved for you six months later.
We’re also not late. The playbook isn’t written. The workflows aren’t standardized. The “right way” to integrate these tools into real engineering organizations hasn’t been figured out yet, because nobody has figured it out yet.
That’s the window we’re in: the tools are mature enough to be genuinely useful, but the patterns are still being discovered. We get to participate in shaping what good looks like, not just follow someone else’s template.
In every previous shift I’ve lived through, there was a moment like this. A window where the people paying attention could build intuition, develop taste, and establish practices while everyone else was still debating whether this was real. By the time the debate settled, the early movers weren’t just ahead, they were the ones everyone else was learning from.
I think that window is open right now. And I’d rather be looking back in two years knowing we leaned in than wishing we had.
Why I Care About This Personally
In the earlier revolutions: SaaS, open source, cloud, I was in a junior role. I wasn’t setting strategy or deciding adoption timelines. But I was lucky: I was in the group that got to go first.
I had leadership that gave us room to experiment. Room to learn and adapt early, before the rest of the org caught up. That’s a privilege I didn’t fully appreciate at the time. Being in that group meant I got to build intuition for these shifts while they were still forming, not after they were obvious.
Now I’m in a different seat.
And one of the things I think about constantly is this: I want the people around me to be valuable. Not just here. Not just now. But in the market that’s coming.
None of us will be in the same place forever. That’s life. But when paths diverge, I want the people I work with to be ready for what’s coming, not because I’m planning their careers, but because I’ve seen what happens when shifts like this catch people off guard.
That means staying close to the leading edge. Not recklessly. Safely. But close.
Every real shift I’ve lived through, the engineers and companies that thrived weren’t the ones who protected old workflows the longest. They were the ones who learned in public, experimented early, built internal leverage, and taught each other.
I had leadership that gave me that chance. I want to pay it forward.
What’s Next
I don’t have a playbook for this. Nobody does. But I have questions I think are worth chasing together:
- What does a real AI-native development workflow look like?
- What changes about code review when generation is cheap?
- How do specs, tests, telemetry, and agents fit together?
- How do we design for review instead of authorship?
- How do we measure productivity when output is no longer scarce?
- What are the failure modes we can already see?
- What does senior engineering look like when code is abundant?
- What does junior engineering look like when the simpler tasks can be automated?
These aren’t rhetorical. I genuinely want to work on them, with anyone who’s curious.
So here’s my ask: experiment. Try things. Break things safely. And when you learn something, share it. Not polished presentations. Just “I tried X, here’s what happened.” Threads, videos, docs, whatever.
When patterns emerge, we’ll write them down and that becomes our process. Anything before that is just speculation. We should trust our instincts, but real observations are key.
The teams that figure this out together won’t just be a little faster. They’ll be operating in a different regime entirely. I’d love for us to be among them.
If you haven’t tried Claude Code yet, pick one real task from your current work and try it this week. Not a tutorial. Not a toy example. Real work.
Give it two hours. That’s it. If it’s useless, you’ve lost two hours. If it’s not, you’ve started building intuition you’ll compound on for years.
And if you’re not sure where to start, find someone who’s already using it and pair with them for an hour. Watching someone work is worth more than ten tutorials.
The Gateway Moment
Here’s what I’d tell you to watch for: something I’ve been calling “the gateway moment”. The moment the tool does something that makes you say “holy shit.”
Not a demo. Not someone else’s screenshot. Something you did, on real work, that you couldn’t have done, or couldn’t have done that fast, without it.
For me, it was full-stack apps deployed to production (in my personal AWS account) without a line of code written by hand or AWS console interaction. I’m not a capable day-to-day engineer. I hadn’t shipped anything real in a decade. That’s what made it a gateway, it wasn’t about my skill. It was about what became possible. I’ve also had numerous post-gateway moments on work projects, including creating a demo web app for Inform / Platform services.
You’ll have your own version. And once you do, the question turns to “what else can this allow me to accomplish?”
One Last Thing
Our industry is built on discontinuities. Every major shift rewrites the story of what “real engineering” means.
This one isn’t about writing less code.
It’s about finally having the leverage to work on problems we’ve been paving over for decades. Because now we can afford to.
I’ve written this through an engineering lens because that’s where I live. But this isn’t just an engineering story. The same shift is coming for design, ops, marketing, finance: every role that involves creating or analyzing or deciding. The tools and timelines will differ. The pattern won’t.
I’m excited to figure this out. Together.
A Footnote for Skeptics
If you’re reading this and thinking “I’m not convinced,” that’s fair. Here’s how I’d engage with the most common objections:
“Where’s the evidence?” The evidence will come from your own work. In a year, we’ll have data: cycle velocity, shipped features, bug rates, time-to-production. You’ll either generate that evidence yourself, or you’ll watch others generate it. The proof won’t come from a blog post, it’ll come from performance.
“This could be a fad.” Maybe. But consider the asymmetry: if you bet against it and you’re wrong, you’re behind, and catching up is harder than keeping pace. If you bet on it and you’re wrong, you learned some tools that didn’t pan out. One of these costs is significantly higher than the other.
“Volume isn’t value. AI just generates slop.” Correct. And in a year we’ll know exactly who created value and who just generated noise. The tools don’t change how we evaluate quality, they accelerate how fast we can see who has taste and who doesn’t. If anything, this is an argument for engaging: the people who develop judgment about when and how to use these tools will stand out. The people who either refuse to engage or use them indiscriminately won’t.
“This feels like pressure.” It’s not pressure, it’s describing how incentives work. If a subset of the team ships faster with higher quality, that will be visible. It will show up in planning, in reviews, in compensation. That’s not a threat; that’s just how performance evaluation has always worked. The only thing that’s changed is the tools available.
I’m not asking anyone to believe. I’m asking people to experiment, stay curious, and let the results speak for themselves.
- Shape Up is a product development methodology from Basecamp, written by Ryan Singer. It replaces backlog grooming and sprints with fixed time appetites, shaped work, and dedicated cycles. The book is available free at basecamp.com/shapeup. ↩