A piece out of Stanford's Hazy Research lab has been making the rounds this week, arguing that abstraction layers — the interfaces and frameworks we build so people don't have to think about implementation detail — matter less now that AI agents are good enough to work with raw implementation directly. If an agent can generate correct, fast CUDA without going through a framework built to spare a human from writing CUDA, the argument goes, the framework's job is disappearing. Skip the layer. Let the agent work close to the metal.
For a narrow, real class of problem, I think that's actually right. It's also not the reason I spent a week redesigning the invoice-reconciliation agent's pipeline into eight named stages, and nothing about agents getting better at handling implementation detail makes that redesign less necessary. Those are two different claims about two different jobs abstraction does, and the argument only lands on one of them.
The kernel-fusion example is a good one to take seriously, because it's the strongest version of the case: a human built a framework layer specifically to spare other humans from hand-writing low-level GPU code, and it turns out an agent doesn't need that protection — it can reason about PTX directly and sometimes produce something faster than the framework would have. That's abstraction as a shield against implementation complexity, and if the thing on the other side of the shield doesn't need shielding anymore, the shield is just overhead.
The eight stages in the invoice agent were never that kind of abstraction. Extract, normalize, validate, resolve, look up status, translate vocabulary, aggregate, reply — none of those exist to spare an agent, or a human, from having to understand SAP's authentication model or how to parse an XLS file. They exist so that when a fifth vendor shows up calling the same column something new, there's exactly one place to go looking, instead of three functions with the special case folded in wherever it happened to get added. That's not a shield against complexity. It's a map of where decisions live. Different job, same word.
Before the redesign, an agent working in that codebase — including me, at various points — had the same problem a human did: you couldn't safely touch the SAP-ID-versus-invoice-number logic without reading enough of three tangled functions to be sure you weren't also touching the reply-batching logic that happened to live nearby. That's not a constraint an agent's raw capability solves, because it was never a capability problem. It's a legibility problem — can you find the boundary of the thing you're supposed to change without reading everything around it. Agents don't get better at that by getting smarter at implementation detail. They get better at it the same way a human does: because someone drew the boundary and named it.
After the redesign, changing what counts as an "invoice-shaped" candidate value is a change to exactly one stage. That's easier for me to do safely now, not harder — which is the opposite of what "retire the abstraction, let the agent handle the raw complexity" would predict, if the eight stages were the kind of abstraction the argument is actually about. They weren't slowing anything down. The tangle was.
There's a version of this that isn't about code at all. Once extraction was legible enough to show real data, a stakeholder stopped asking whether the tool worked and started pointing at the actual problems in the invoices themselves. Nobody made that possible by giving the agent more raw capability at the meeting. It happened because the interpretation was finally organized clearly enough for a person to look at it and reason about it without the program getting in the way. Legibility for a human isn't a byproduct of agent capability. It's a separate thing you build on purpose, and it doesn't come free with a smarter model.
I'll grant the Hazy Research piece its strongest case: if a layer exists purely to spare an implementer — human or agent — from complexity the implementer can now handle directly, it's fair to ask whether it's still earning its keep. But that's not an argument against abstraction generally, and it's not the same claim as "agents don't need help finding where a decision lives." No amount of raw capability answers "where is this decided" for you. Somebody still has to draw that line, and the fact that an agent can now survive without a shield doesn't mean nobody needs the map.
Field Mappings