Andrej Karpathy posted a thread this week that put numbers to something a lot of us have been feeling in our bones. In roughly six weeks, he went from 80% manual coding with 20% agent assistance to the complete inverse — 80% agent coding with 20% manual edits and touchups.
I’ve been living this same shift. And like Karpathy, it happened fast enough to give me whiplash.
But here’s what I keep coming back to, and what I think Karpathy’s thread only scratches the surface of: when AI agents are writing 80% of your code, the game doesn’t just change for developers. It changes for everyone responsible for understanding what that code actually does.
The Shift Is Real — and It’s Not Just Syntax
Karpathy nailed something important about the nature of the errors we’re seeing now. The mistakes aren’t syntax errors anymore. They’re “subtle conceptual errors that a slightly sloppy, hasty junior dev might do.” Wrong assumptions. Missing edge cases. Overcomplicated abstractions. Code that works but isn’t what you meant.
This is the shift from syntax to architecture. From “does the code compile” to “does the code do the right thing in the right context.” The 20% of human work that remains isn’t cleanup — it’s the hard part. Business logic. System design. Understanding what the code should do and why.
That remaining 20% is where the real engineering lives. And honestly, it always was. The agents just made it impossible to pretend otherwise.
Do You Know What Your Agents Did Today?
Here’s the question that keeps me up at night: in a world where AI agents are generating the vast majority of your codebase, do you actually know what happened?
Think about it. Karpathy describes watching an agent “relentlessly work at something” for 30 minutes — never getting tired, never getting demoralized, just grinding through until it finds a solution. That tenacity is incredible. It’s also a black box if you don’t have the right observability in place.
In traditional software development, a human writes code, reviews it, and commits it. The provenance is clear. With agent-driven development, you have an AI making hundreds of micro-decisions — choosing libraries, structuring APIs, handling edge cases, managing state — all based on its interpretation of your natural language instructions.
Every one of those decisions is a potential failure point. Not because the agents are bad, but because the gap between what you said and what you meant is where bugs live. And now that gap is being crossed by a probabilistic model instead of a deterministic compiler.
Your observability stack just became the most important part of your development infrastructure. Not your IDE. Not your CI pipeline. Your ability to trace what agents did, why they did it, and whether the output matches your intent.
Prompt Injection Is Not a Theoretical Problem
While we’re busy marveling at agent productivity, the security community is raising alarms that aren’t getting enough attention. In our Austin AI Middleware User Group (AIMUG) meetings, we’re seeing novel prompt injection attacks surface with increasing frequency and sophistication.
These aren’t the “ignore previous instructions” parlor tricks from 2023. We’re talking about:
- Supply chain prompt injection — malicious instructions embedded in dependencies, documentation, or training data that agents consume during code generation
- Context window poisoning — carefully crafted content in repos, issues, or PRs designed to manipulate agent behavior when they’re used as context
- Instruction hijacking via tool use — exploiting the interfaces between agents and their tools (MCPs, APIs, file systems) to redirect agent behavior
When an agent is writing 80% of your code and consuming context from across your entire development environment, the attack surface isn’t just your application — it’s the entire information supply chain feeding your agents.
This is why detection and prevention frameworks need to evolve at the same pace as the capabilities themselves. We need to instrument our agent workflows the same way we instrument our production systems — with traces, metrics, and alerts that tell us when something looks wrong.
The Dream of Self-Improving Code
Here’s what makes this moment genuinely exciting rather than just concerning: we are building toward self-improving code. Karpathy’s observation about “declarative over imperative” — giving agents success criteria and watching them iterate — is the beginning of something much bigger.
The pattern is clear: write tests first, give agents clear success criteria, let them iterate until they pass. That’s not just a productivity hack. That’s a feedback loop. And feedback loops, given the right constraints, are how systems improve themselves.
But self-improving code without observability is a car without a dashboard driving at 200 mph. You might be going in the right direction. You might also be heading off a cliff. The only way to know is to instrument the entire loop:
- Trace every agent action — what was the prompt, what was the context, what was the output?
- Monitor for drift — is the agent’s behavior changing over time? Are the patterns shifting in ways you didn’t expect?
- Alert on anomalies — did the agent access something it shouldn’t have? Did it generate code patterns that match known vulnerabilities?
- Audit the feedback loop — when agents iterate on their own output, are the iterations converging toward your intent or diverging from it?
Where This Leaves Us
Karpathy is right that 2026 is going to be “a high energy year as the industry metabolizes the new capability.” I’d add that the metabolism metaphor is apt — the industry needs to digest what’s happening, not just consume it.
The engineers who thrive in this environment won’t be the ones who can prompt the fastest. They’ll be the ones who can:
- Define clear intent — the 20% that matters is knowing what to build and why
- Build observable systems — if you can’t see what your agents are doing, you’re flying blind
- Harden the supply chain — treat every piece of context your agents consume as a potential attack vector
- Close the feedback loop — self-improving code needs guardrails, not just gas pedals
The shift from 80% manual to 80% agent is the beginning, not the destination. The real work — the architecturally interesting, professionally challenging, genuinely exciting work — is building the systems that make agentic development trustworthy, observable, and secure.
We’re moving toward self-improving code. Let’s make sure we can actually see where it’s going.