Three thousand developers packed a conference in San Francisco to hear that their profession is becoming something else entirely, and they left enthusiastic. That tells you something about the current moment in the future of software development, and about the gap between real change and a well-packaged narrative.
The conference was AI Dev 26 x SF, organized by Andrew Ng’s DeepLearning.AI and attended by more than 3,000 people. The central message: the bottleneck in software development is no longer writing code. It’s our capacity to imagine what to build. AI agents write 100% of the code. Teams shrink. Generalists orchestrate.
It’s a provocative thesis. On some points, it holds. On others, it conceals something uncomfortable that nobody at the conference had an interest in naming.
The Future of Software Development as Andrew Ng Sees It: Imagination as the Bottleneck
Jonathan Heyne, COO of DeepLearning.AI, told the conference “the bottleneck is our imagination.” That works as a claim if the old constraint was technical execution. But the prioritization problem doesn’t disappear when you delegate implementation to agents. It scales up.
Now you can build anything in a fraction of the previous time. The temptation to build too many things, the wrong things, unnecessary complexity, grows proportionally. Deciding what to build, in what order, with what trade-offs, requires organizational context and the capacity to say no to good things in order to do better ones. No AI agent resolves this. No language model decides for you which feature actually matters to your business.
Teams already using agents to develop faster are discovering this firsthand: costs shifted from writing code to reviewing it, testing it, maintaining it long-term. The work doesn’t disappear. It transforms, often into less predictable forms.
There’s also a detail Thomas Claburn noted in his piece on The Register: skeptics about AI’s direction in software development probably weren’t at the conference. The three thousand attendees benefit, directly or indirectly, from the prevailing narrative. It’s a structurally biased sample.
Spec-Driven Development: The Approach That Requires More Discipline, Not Less
Marc Brooker from AWS made the most operational contribution of the day. His proposal: “spec-driven development,” where technical specifications become the guide AI models follow to generate verifiable, auditable code. The focus shifts from producing features to systematically reducing defects.
This inverts the vibe coding logic. Instead of generating code and hoping it works, you write the specification precisely first, then let the model handle the implementation. It requires more technical rigor, not less. A vague spec produces unpredictable code, and you find out in production, not in development.
I covered this in the piece on AI-generated code as security debt: the core problem isn’t AI writing code: it’s who understands that code when it goes to production. Spec-driven development is one of the few approaches that addresses this question before creating it.
The other panelists, from Oracle, Replit, and LandingAI, scored the future of software development between 7 and 10 out of 10. The discussion about what happens when those systems fail wasn’t on the agenda.
The TechMonk Take: Three Things the Conference Didn’t Name
Who Answers When the Code Crashes at 3am?
Andrew Ng envisions small teams of generalists supervising agents that write 100% of the code. The key word is “supervising.” Supervising code you didn’t write, in a system you didn’t build, from specifications you described at a high level, is not software development. It’s delegated trust on a chain.
When that system goes down in production, the difference between resolving it in ten minutes or four hours depends on who genuinely understands how it works. A generalist who orchestrated agents doesn’t have that understanding, not because they’re less capable, but because they were never forced to acquire it. Deep system understanding is built by writing the system, making mistakes inside it, debugging other people’s.
The cost of this gap is invisible until it manifests. And it always manifests at the worst possible moment.
The Bottleneck Is Priority, and AI Doesn’t Fix That
An architecture that produces code much faster amplifies every prioritization error. The team that yesterday couldn’t build all the features on the roadmap now builds them in a week, and ends up with ten times the complexity to maintain. Execution speed without better judgment about what to execute is a technical debt accelerator, not a reducer.
According to the Stack Overflow Developer Survey 2025, 65% of developers use AI tools at least weekly. But perceived productivity and actual productivity diverge significantly on projects with timelines beyond six months. More production velocity, more accumulated complexity, more time spent understanding what the code actually does.
“The bottleneck is imagination” works as a conference slogan. As a map of the problem, it’s incomplete. It ignores the cost of everything we imagine in excess.
The Craft We’re Giving Up Without Naming It
The three thousand in San Francisco were enthusiastic. The conference presented a future where the tedious work disappears and only the “creative” work remains. But writing code wasn’t tedious for many of them. It was the part they understood best, controlled, and got immediate and verifiable satisfaction from.
“Less development” isn’t a neutral liberation. It’s the removal of a skill built over years, one that generates intuition about what can go wrong and creates developers with systems-level thinking. A developer who hasn’t written code in two years progressively stops understanding their own systems. They become an interpreter between the business and the machine, without real technical mastery of either level.
That may not be a net negative for the industry long-term. But presenting it as purely positive evolution, in front of three thousand people who have an interest in believing it, isn’t intellectual honesty.
The question isn’t whether AI will change software development. It already has. The question is whether teams that stop writing code will continue to understand what they’re building, or whether they’ll notice the difference only when it’s too late to recover that understanding.