ExpertsFMAI Can Write Code. Why Isn’t Software Better?
The a16z Show · September 28, 2026
5 Selected Lessons:
heuristic · 2 reasoning_pattern · 2 interpretation · 1
Coding agents: strong syntax, weak architecture — gray-area speed/quality tradeoff
Source
The a16z Show — AI Can Write Code. Why Isn’t Software Better? (September 28, 2026) · at 28:14 ▸
When this applies
when deciding how much autonomy to grant an AI tool across a spectrum from mechanical execution to creative/structural decision-making
The takeaway
When delegating a task to an AI tool, separate the mechanical sub-task (where it's reliable) from the judgment/creative sub-task (where it's mediocre), and consciously choose how much quality to trade for speed on the latter.
Why it works
Coding agents are good at syntax (mechanical correctness) but weak at architecture (creative, structural judgment), so handing architecture to them trades quality (e.g., 50th percentile outcome) for speed (unattended overnight work).
One level up
Autonomy should be granted task-by-task based on where the tool's competence actually lies, not uniformly across a whole workflow.
Where it stops holding
This stops working when the human lacks domain knowledge to evaluate architecture quality at all, in which case even a mediocre AI architecture may be acceptable by default — removing the need for a tradeoff decision.
Detail
approach: Evaluate coding-agent output by splitting syntax correctness from architectural soundness.
signals:
- agent handles syntax well
- agent is mediocre (e.g., 50th percentile) at architecture
- speed is the knob teams turn when willing to accept lower architecture quality
rationale: Architecture is 'the most human creative part of software,' so handing it fully to an agent is a deliberate speed-for-quality tradeoff, not a free win.
In their words
my experience is that they are really good at syntax and really bad at semantics. I would say incredibly bad at architecture
Work backwards from the end-state to decide where reliability investment should go
Source
The a16z Show — AI Can Write Code. Why Isn’t Software Better? (September 28, 2026) · at 37:32 ▸
When this applies
when deciding where in a stack to invest in robustness, work backward from the fully mature future state of the technology, not just the current visible use case
The takeaway
To decide where to invest in hardening a capability, project forward to its fully mature, pervasive deployment and ask what proportion of future usage will be in the most demanding (infrastructural) tier — then invest ahead of current demand to be ready for that tier.
Why it works
Imagining the full end-state (AI embedded everywhere in software) reveals that most calls to the capability will eventually be deep infrastructure rather than user-facing, and infrastructure-level use demands much higher ('many nines') reliability than consumer-facing chat — so starting the reliability investment early, even though adoption starts at the visible layer, is necessary to eventually reach the guts.
One level up
Build for the end-state requirement even while adoption is still only visible at the surface, because the step-up in rigor needed for deep/infrastructural use takes long lead time.
Where it stops holding
This stops working when the technology's trajectory never actually reaches deep infrastructural use, making the extra investment premature or wasted.
Detail
approach: Imagine a fully AI-saturated economy, estimate what fraction of AI calls are for human-facing consumption versus embedded deep inside systems, and conclude the deep-systems fraction needs 'many nines' of reliability.
signals:
- most future AI calls will be embedded in infrastructure, not chat
- adoption historically starts at the visible/first layer
- failing to aim at the guts early delays ever reaching them
rationale: If you don't aim for the guts from the start, it will take a while to get there — reliability work has long lead times.
In their words
And I think that it's going to be many nines in the guts, but it will start at the first layer. But we need to, if you don't aim for the guts, if you don't aim for the guts, it's going to take you a while to get there.
Intelligence per dollar as design North Star
Source
The a16z Show — AI Can Write Code. Why Isn’t Software Better? (September 28, 2026) · at 6:00 ▸ · at 37:32 ▸
When this applies
when choosing where to embed a scarce, costly capability inside a system — optimize for cost-efficiency of use, not just raw capability
The takeaway
When designing for pervasive use of an expensive capability, optimize the dominant unit economics metric for your intended scale, even at some short-term cost to speed.
Why it works
Optimizing for cost-per-unit-of-intelligence rather than speed-per-unit lets a capability be embedded pervasively and cheaply, enabling the 'guts' of systems to use it, not just the visible top layer.
Where it stops holding
This stops working when latency/speed is the actual constraint for the use case, making 'intelligence per second' the right metric instead, as Diogo himself concedes may be true in the short term.
Detail
rule: Design the system around intelligence-per-dollar rather than intelligence-per-second or raw capability.
threshold: Explicitly named as 'my North Star right now' with an acknowledged caveat that 'intelligence per second might be more valuable in the short term.'
rationale: To let intelligence be embedded deep in program internals (treated 'like a database') at scale, cost efficiency matters more than raw speed or capability.
In their words
But like intelligence per dollar is my North Star right now. And it could be wrong, just to be clear: intelligence per second might be more valuable in the short term.
Reliability over demos as the real product
Source
The a16z Show — AI Can Write Code. Why Isn’t Software Better? (September 28, 2026) · at 15:27 ▸ · at 24:47 ▸
When this applies
when building any product on a probabilistic or AI-driven component, resist optimizing for flashy showcase cases at the expense of unattended, trustworthy operation
The takeaway
Optimize for the component working unattended and composably, not for the best anecdote you can show a customer.
Why it works
A feature that must be babysat or double-checked cannot be trusted to run unattended with real resources/access, which caps how much new application surface it can unlock; reliability is what lets humans stop supervising and start building on top.
One level up
Avoid the anti-pattern of judging a capability by its best demo rather than its worst-case or background behavior.
Where it stops holding
This stops working when the use case genuinely requires human-in-the-loop oversight by design (e.g., high-stakes irreversible decisions) rather than autonomous operation.
Detail
rule: Judge and build AI capabilities by whether they can run safely and consistently in the background without paging a human, not by best-case demos.
threshold: 'Every nine of reliability is going to be so valuable... even if it's not the most valuable thing market cap-wise, because it will just enable new applications.'
rationale: Composability and safety (statistical guarantees around resource/access use) are prerequisites for building further automation on top.
In their words
I think that if we were going to be really intellectually honest and we are really aiming for the North Star of automation, we cannot fall into the same anti-patterns that AI has fallen into, which is really focusing on outliers and demos, right?
AI industry bifurcated into overpromise/underdeliver due to human-judged evaluation
Source
The a16z Show — AI Can Write Code. Why Isn’t Software Better? (September 28, 2026) · at 18:42 ▸ · at 21:54 ▸
When this applies
when a product's success metric is a proxy (judge approval, demo appeal) rather than the real outcome it's meant to deliver (task completion)
The takeaway
When you optimize the proxy metric instead of the real outcome, apparent quality and real capability can diverge, creating a gap between perceived and delivered value.
Why it works
Optimizing to please human evaluators (the judge) makes outputs look increasingly impressive without necessarily increasing the system's ability to autonomously complete real tasks, since the judge and the task are different targets.
One level up
Always ask whether your optimization target is the actual outcome you want or merely a stand-in judge for it.
Where it stops holding
This stops working when the proxy judge metric is tightly correlated with the real outcome, in which case optimizing it does translate to real capability.
Detail
approach: Compare what's being optimized (human judge approval of output) against what's claimed to be delivered (automation of real economic tasks).
signals:
- model looks impressive to human raters
- but can't handle unattended real-world tasks like drive-throughs or customer service
- GPT-3 was 'quite calibrated' before this shift
rationale: Because humans evaluate how good models are, it looks good, but the industry has been optimizing that judge instead of the automation outcome itself.
In their words
GPT-3 was actually quite calibrated back in that day. But because humans evaluate how good the models are, it looks really good because they are the judge, but we've been optimizing that judge instead of the automation part. And that has been the missing thing.