"Vibe Coding" Is Over. What Karpathy's New Term Means for Finance Leaders, Not Just Developers.
"Vibe Coding" Is Over. What Karpathy's New Term Means for Finance Leaders, Not Just Developers.
Andrej Karpathy says vibe coding raises the floor — agentic engineering preserves the ceiling. That distinction matters well beyond software teams.
A Term Karpathy Himself Has Already Moved Past
Andrej Karpathy coined "vibe coding" in early 2025 — the term that, more than any other, captured what it felt like to build software by describing what you wanted and trusting an AI agent to produce it. By mid-2026, he'd already moved on. At a Sequoia-hosted AI event earlier this year, he drew a sharp line between two things people had been treating as the same: vibe coding raises the floor, he said. Agentic engineering preserves the ceiling.
I've referenced vibe coding on this blog more than once — it's been a genuinely useful entry point for explaining how a finance professional with zero formal coding background, like me, can end up building working tools. Karpathy's refinement doesn't contradict that entry point. It describes what has to happen after it, once you're no longer building a weekend side project and you're building something other people are going to rely on.
|
Floor
Vibe coding: anyone can prototype. Exploratory, forgiving, "can I make this work?"
|
Ceiling
Agentic engineering: professional discipline. "Can I make this work reliably, without introducing vulnerabilities?"
|
"You Are Still Responsible for Your Software, Just as Before"
The line from Karpathy's talk that stuck with me most wasn't about the technology at all — it was about accountability. His warning was that vibe coding has no quality bar by default: the agent makes a plausible-looking decision, you accept the change without scrutinising it closely enough, the code runs, and the product is quietly broken in a way nobody notices until it matters. You're not allowed to introduce vulnerabilities because you were vibe coding, he said. You're still responsible for your software, just as before.
That sentence translates almost word for word into finance. If I ask an AI tool to build a reconciliation script, a payroll calculation, or a budget model, and I accept the output without genuinely checking the logic — not just whether it ran without an error, but whether the underlying rule it applied was actually correct — I haven't reduced my risk. I've just moved it somewhere less visible. The classification error, the wrong absorption rule, the misapplied threshold: these don't throw an exception. They quietly produce a number that looks plausible and is wrong.
Orchestration, Not Outsourcing
Karpathy's framing of agentic engineering centres on a specific word: orchestration. You're not a passive recipient of generated output. You're coordinating fallible, capable agents toward a result you're still accountable for — which means spec design before you prompt, genuine review of what comes back, and a clear sense of where the failure modes actually sit.
For a finance leader, I think this maps onto something we already understand instinctively, even if we've never used this language for it: the difference between delegating a task to a junior team member and abdicating it. A good manager doesn't hand off a reconciliation and stop thinking about it — they specify what "correct" looks like, they review the output against that standard, and they know which parts of the process are genuinely safe to trust versus which parts need their eyes every time. Agentic engineering is asking finance leaders to apply exactly that same discipline to AI tools, rather than treating "the AI did it" as if it removes the need for review.
Where I See This Show Up in Practice
Looking back, parts of how we approached the PFL Super Tool — which I wrote about earlier this week — resemble what Karpathy is now describing, even though we weren't using this language at the time. The validation rules for a compliant SuperStream file (ABN checksums, USI verification against live ATO data, the different requirements for SMSFs versus regulated funds) aren't things you can vibe your way through and hope an agent gets right. They had to be specified precisely, reviewed against the actual government standard, and tested against edge cases — because a quietly wrong validation doesn't throw an error. It produces a file that looks correct and gets rejected by a clearing house weeks later. Whether that counts as "agentic engineering" in Karpathy's formal sense or just ordinary due diligence applied to AI-assisted work is somewhat beside the point — the discipline required is the same either way.
The same applies to anything a finance team builds or automates with AI assistance — a month-end commentary generator, a wage calculation model, a budget variance tool. The AI can write the logic fast. Whether that logic is correct is still entirely the human's responsibility, and that responsibility doesn't transfer just because the code compiled and ran without error.
What This Means for How You Build, Not Just What You Build
- Before prompting an AI tool to build something you'll rely on, write down what "correct" actually means for that specific task — the spec, not just the goal
- Review AI-generated logic against the actual source of truth (the award, the regulation, the accounting standard) — not just whether the output looks plausible
- Treat "it ran without error" and "it's correct" as two completely different bars — the first is necessary, the second is the one that actually matters
- Keep ownership of the parts of any process where a quiet, undetected error would do real damage — fund verification, payment calculations, anything touching compliance
Comments
Post a Comment