A working thesis
Software Is Changing
A working thesis on where software is going — and what it means for the people and institutions building it.
I’ve spent twenty years watching the ground shift under software more than once. This shift is bigger. Here’s how I see it, and why I think most teams are still planning for a world that’s already gone.
We’re still underestimating the models
The most common mistake right now is anchoring on what today’s models can’t do. The relevant question isn’t how good they are — it’s how fast they’re improving, and how good they’ll be by the time the system you’re designing actually ships. We keep underestimating both the slope and the ceiling. Plan for the trajectory, not the snapshot.
Most code will be written by agents
The default author of code is changing. Increasingly, agents write it — and they write it whether or not anyone is sitting at a keyboard. Work runs overnight, in parallel, on its own. The unit of work stops being “the code to be written” and becomes “the task to be delegated.” That’s a different job, and it rewards different skills.
The bottleneck has moved
Writing valid code used to be the hard part. It’s now close to trivial. What remains hard are the errors of engineering: choosing the right priorities, sequencing the work, and weighing tradeoffs. As implementation gets cheap, review stops being about code and starts being about decisions. The scarce skill is judgment, not syntax.
Software development as we’ve known it is ending
For forty years, the profession has rested on the assumption that writing code is hard and error-prone, and the industry has rested on the assumption that code is scarce. Both assumptions are breaking at the same time. When code is cheap and abundant, much of what we built around its scarcity — the roles, the rituals, the org charts — no longer fits the world it was designed for.
The old processes no longer fit
Planning, prioritization, handoffs, staged reviews — these rituals were invented for a world where implementation was slow, costly, error-prone, and bound to human hands. That world is receding. Why spend an hour prioritizing what can be built in thirty minutes? Why wait days for a review when you can spin up five agents to review in parallel? The deep point isn’t that AI makes each step faster. It’s that AI changes whether a given step should exist at all.
Software changes form
Until now, software was built for humans to use. Increasingly it will be built for agents to use — and that changes its shape, its interfaces, and its contracts. More software will be assembled just-in-time, for the moment it’s needed, rather than built and maintained ahead of time. And the line between “using software” and “building software” blurs. It may disappear entirely.
Value moves away from code
This is the uncomfortable part for a lot of businesses. Software whose only job is to do X has little value once an agent can simply do X. Code someone else wrote for you, software that encodes a workflow — its value declines. What rises in its place is everything code can’t conjure: data, permissions, distribution, trust, compliance, regulatory position, and physical assets. The moat was never the code. We’re about to find out where it actually was.
The engineer changes — but doesn’t disappear
Software engineering doesn’t go away. It moves. It shifts away from producing code and toward product thinking, shaping systems, judging tradeoffs, and driving business outcomes. The most valuable engineers will be the system thinkers and operators who can increase business value — which, notably, is the one thing that has always been true and stays true. The job was never really typing. It’s clearer now than ever.
Every serious institution needs a camp at the frontier
Large organizations cannot sit this transformation out, and they cannot learn the future through a committee. What they need is a small, autonomous team built around the models — close enough to touch real systems, real data, real constraints, and real consequences.
Its purpose is not to bolt AI onto the old way of working. Its purpose is to discover the new way of working and pull the rest of the organization toward it. And its output isn’t only software — it’s people and practices that the institution didn’t have before.
This is the work I care about most, and it’s why Laguna Labs exists.
Where I come in
I help teams build that camp at the frontier — and do the work inside it. Not a slide deck about AI strategy, and not “add a chatbot.” A hands-on technical partner who can architect the systems, ship the code alongside your team, and leave behind the people and practices that make the new way of working stick.
If any of this resonates — or if you think I’m wrong about part of it and want to argue — I’d like to talk.