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.
Top comments (10)
This reads like Theory of Constraints wearing AI clothes. Goldratt's whole point was that you never remove the bottleneck, you just relieve it and the next one gets promoted, so the real skill is knowing where the constraint sits right now rather than generating harder at a step that was never the limit. The ergonomics framing is where it gets useful for me. A command center only helps if it shows you the current constraint instead of just more agent output, otherwise you've built a faster way to watch the wrong thing. Curious whether you think that "where is the constraint today" read can itself be tooled, or if it stays a human judgment call.
Thoughtful! A tad abstract, and I might not grasp every nuance, but I do get the wider point you're trying to make ... my biggest question would be: will we all (have to) keep reinventing this wheel for the time being, or will something like standard approaches and standard tooling emerge?
A bit overly abstract was my own opinion on this once I got done, but that is what I'm getting at: I think we're honing in on less wheel re-invention and more opportunity to establish some sense of "best practice" we can cling to.
When I read about the craziness of companies directly incentivizing "token use" as a metric (in the most extreme cases of lunacy) it speaks to a complete lack of direction in our industry. I think we are in a place where better standards are immerging.
Fully with you! The idea to incentivize or even "promote" token usage, as if it should be a goal in itself, is (well, that's the way I see it) crazy boardroom sh*t, and untenable - especially when token usage inevitably stops being 'subsidized' as much as is currently the case, and costs are going to soar ...
Applying common sense regarding token usage, avoiding waste, developing (and applying) best practices, maintaining sane software engineering principles (not throwing the quality/maintainability baby out with the bath water, in a corporate rush to "AI all the things") - I'm saying "yes" to all of that!
push back here. teams failing at AI adoption are mostly not swept up in hype - they fail on execution: no clear owner, no feedback loop. the idea is rarely the bottleneck.
Ben, "the bottleneck doesn't disappear, it just moves" is the one that stayed with me. but I'd push it one level deeper — The bottleneck keeps moving because most developers never built the mental model to see where it went.
if you generated your way to a working circuit breaker without understanding what a half-open state is, you don't see the bottleneck shift to architecture review. you just see a system that worked in staging and fails under load six weeks later. the ergonomics problem and the comprehension problem are the same problem.
Building in Lagos, the bottleneck I hit most often isn't token cost or latency — it's the gap between what AI assumed about my environment and what my environment actually is. the constraint moves, and you can only follow it if you understood where it started.
The 'choke points govern value, not code volume' framing is the most useful lens for cutting through the hype. Infinite code just means the bottleneck moved, and it moved to the steps generation was never the constraint on: understanding, verification, keeping the system coherent. The pragmatic read is that the teams who win won't be the ones generating the most, they'll be the ones who made the choke points cheap to clear. That's the layer we're building Mneme on, treating the verification-and-governance step as the thing that scales, not the generation. The immune system against hype you mention is right; it just has to point at the new bottleneck now.
The "bottleneck moves" framing is accurate, but the current bottleneck in AI engineering isn't just coordination â it's agent state. When you scale from one-off agent tasks to persistent, multi-session agent systems, the coordination problem becomes a data problem: who owns the state, who can read it, and what happens to it across restarts, model swaps, and context evictions.
This is where the pragmatic vs. architectural tension shows up most sharply. A pragmatic response is "just use a JSON file" or "just stream to a log" â and for a single agent on a single machine, that's fine. An architectural response is "design the state layer properly from the start so it survives the transition from demo to production." The developers who get burned are usually the ones who took the pragmatic path without realizing they'd eventually need the architectural one.
The ergonomic "command center" you describe â high-level observability, easy course-correction, downstream blocker clearing â is only possible if the state layer underneath it is queryable, durable, and structured. A flat log is observable but not queryable in useful ways. A structured state store lets you answer "what has this agent tried in the last 48 hours" as a query, not a full-text search. That's the practical difference between a command center you can actually run and one that's just a prettier log viewer.
This might be the next bottleneck to move: not from code review to deployment, but from "we have no state" to "we have state but it's not queryable." The teams that win this cycle will be the ones that designed their state layer before they needed it.
Hi ben, I noticed your post about pragmatism in an age of infinite code and unavoidable bottlenecks. It sounds like you're struggling to manage content volume and prioritize tasks. Clypify helps developers like you automate their content workflows by aggregating RSS feeds, rewriting with AI, auditing for SEO, and auto-publishing to WordPress and Medium. Free plan at clypify.com — no card needed.
This - hits at the core:
"the bottleneck doesn't actually disappear. It just moves somewhere else"