Leading into the AI Engineer event in San Francisco, I’m looking forward to having my mind blown. That being said, I’m also compelled to think deeply about how we actually get things done in today’s software development landscape.
There is competitive pressure to align on the principles of AI-driven software development. As developers and technical leaders, we are constantly trying to balance our pragmatism in the moment with our visions for the future.
Throughout the history of software development, our collective immune system against hype has been our greatest asset. The safest, most reliable strategy has almost always been to not get swept up in the current fad. You let the early adopters bleed on the bleeding edge, you wait for the dust to settle, and then you adopt the tools that actually survive contact with production. Separating hype from reality is a critical skill for developers at all levels, and erring on the side of hype rejection has usually been smart money in the long run.
In the AI revolution, separating real from hype is still valuable, but our heuristics are failing us, because the revolution is clearly here. Yet, even though there is obviously a massive amount of substance to AI-assisted development, the actual daily discourse is still hype-driven. It is an unhelpful, deafening mix of extreme utopian sentiment on one end and cynical over-dismissal on the other.
Finding the signal in that noise requires a hard look at what has actually changed, and more importantly, what hasn't.
The Fallacy of Infinite Code
AI has permanently rewritten the rules for how much software we can produce. In a purely quantitative sense, we now have the capacity to generate effectively infinite amounts of code. But if you’ve spent any time maintaining real-world systems, you know that raw code generation is rarely the true blocker to success.
Actual value delivery is governed by choke points.
These choke points are almost always driven by complex, human-centric factors: decision-makers needing consensus, cross-team collaboration, the friction of merging conflicting ideas, and the overriding need for architectural cohesion. Cohesion is that critical phase where the raw, sprawling net of potential features actually has to be distilled into a product that makes sense.
In software, more is not necessarily more. In fact, unguided “more” usually just means accelerating your technical debt. We still need to deliver precise, focused, and intentional value.
While AI is a massive help in attacking individual choke points — it can scaffold the boilerplate, write the tests, or debug the syntax — the bottleneck doesn't actually disappear. It just moves somewhere else. If we write code 10 times faster, the bottleneck shifts to code review. If we review faster using LLMs, the bottleneck shifts to product alignment and deployment infrastructure. The constraint always moves.
Any development shop that still operates in a “traditional sense” is undeniably falling behind. Writing a spec the way we traditionally have is starting to feel completely redundant—that spec should simply be described directly to your agent of choice. We know there is a need to collaborate at a higher level on the problem at hand, allowing the individual developer to execute many cycles of development without the constant need for specification realignment.
Realizing the value of infinite code in a competitive environment where the bar has been raised for everyone is a fundamentally unsolved problem.
The “Wait for the Next Model” Trap
Because this bottleneck keeps shifting, it creates a specific kind of developer paralysis. Sometimes it feels like building tooling or workflows to resolve the bottlenecks we are seeing today is inherently just a stopgap.
The nagging thought is always there: Why spend cycles optimizing this workflow or building around this friction? We could instead just wait for the models to get smarter. Give it six months, and the agents will just talk to each other and sort this out natively.
This is the trap of anticipating the S-curve. A year or two ago, this logic actually held up. Some of yesterday’s bottlenecks genuinely weren’t worth solving because the next model intelligence leap made those local optimizations totally irrelevant. Building highly specific, complex wrappers around early LLMs was often a waste of time once the next foundational model dropped.
But I think we are at a point where that logic is failing us because we’ve had enough time to collectively learn how we work with our core AI productivity tools. Things are settling down — for the moment. The bottlenecks we face today in software development and value delivery are inherently complicated on a human level, and they extend beyond the scope of near-term AI.
Nothing short of Artificial Superintelligence (ASI) is going to overcome the natural, messy bottlenecks of real-world impact. Until an AI can sit in a room, navigate the political dynamics of a stakeholder meeting, understand the company’s runway, and empathize with the end-user’s actual day-to-day frustrations, these choke points remain tethered to human reality.
We Don’t Need Autopilot, We Need Ergonomics
Yes, we’ve automated some things away. Most things are still semi-autonomous at best, and if those things exist in a black box that surprises us too often and doesn’t hand things off in a usable way to move them along productively, we’re not actually beating our bottlenecks.
Because of this reality, I don’t believe we are at the point where we resolve bottlenecks by taking our hands off the wheel. The prevailing sci-fi vision — that we just let the AI have full, unsupervised control of our computers as a magic bullet for productivity — misses the point of how good software gets built.
Instead, the frontier of real productivity is about intuitive, human-in-the-loop workflows. It’s about ergonomics.
We need environments and command centers where we can ergonomically understand the entire system at a glance. The goal isn’t to completely remove the human from the loop; it’s to make the loop so seamless that the human can operate at a fundamentally higher level of abstraction. We need tooling that helps reduce the cognitive burden of orchestrating developer agents, while still leaving us firmly in the driver’s seat. We need to be able to effortlessly send signals out, course-correct the AI, and manually clear the downstream blockers that the system can’t contextualize.
When a developer can easily see what an agent is attempting, guide it with a single keystroke, and merge that work cohesively into a larger system architecture — that’s when the real value unlocks.
On Skating Where the Puck is Going
We don’t gain much waiting for massive, ground-up system design rethinking to save us from our current bottlenecks. The solution is resolving the friction where we see it, today, with the tools we have right now.
Yes, the models will get better. Yes, the agents will get smarter, and our methods for getting things done will evolve from our successes and failures. But we have reached a spot in the current S-curve with enough maturity to make solving today’s friction highly valuable.
Skate to where the puck is going, not where it has been (to quote Wayne Gretzky). It’s true in AI as well. We can absolutely skate to where the puck is going, but we don’t need to pretend the puck is in a whole different arena. Pragmatism in AI tooling today means accepting the incredible leverage we have right now, building the ergonomic, human-in-the-loop systems to actually harness it, and getting back to delivering precise, cohesive value.
Today we are radically capable of solving yesterday’s problems with tremendous efficiency. However, the tug and pull between day-to-day iterative progress and step-change innovation is still generally a problem we have to manage ourselves. The most pragmatic thing you can do right now is stop waiting for the perfect autonomous system to clear your blockers and start orchestrating the tools you have. Build out your own command centers today — interfaces and workflows that give you high-level observability over your agents and complex workstreams. Invest in the tooling that keeps you effectively in the loop, rather than trying to engineer yourself out of it. The developers who win this cycle won’t be the ones with the smartest unsupervised agents; they will be the ones who build the most ergonomic systems to manage them.
Evolving Our Outcomes
It’s reasonable to build a human-in-the-loop productivity flow with the next phase in mind where the idea of “in the loop” is expected to keep changing. It’s reasonable to build for the future in this sense, but it is not practical to push off today’s problems in favor of waiting around to solve for a hypothetical future.
Build for your people, your team, and your productive customers, not around and in spite of them. They’re more capable than ever. Recognizing this is how we push our outcomes forward.
