The Hidden Cost of Vibe Coding: The Memory You Don't Build

Sometimes you sink so fast that you think you're flying.

A version of this call keeps happening to me. I come in as a fractional AI architect, sit down with a client's engineering team, and somewhere in the first hour I ask the simplest possible question about their own system: why is this piece built this way? The room goes quiet. Someone eventually says, honestly, that they're not sure, and offers to spin up Claude and ask. Nobody in the room can tell me why their own architecture is the way it is.

I've stopped being surprised by it, and I've stopped being annoyed, because I recognize the shape from the inside. I'm fully agentic most days myself, and I genuinely can't remember the last time I opened my IDE to write something from scratch. The team isn't lazy and they aren't junior. Their system works. But the decisions have gotten slow, the confidence is gone, and the architecture feels like something that happened to them rather than something they chose. Teams never fully explained their legacy systems either; bus factor is older than Git. What's new is how fast the not-knowing sets in, and that it can start on day one.

The people running large engineering orgs are all circling the same worry right now. Netflix's CPTO, Elizabeth Stone, says the people her org is increasingly short on are systems thinkers, the ones who can look across all the business domains and abstract them into the building blocks everyone else, agents included, will build on (Lenny's Podcast, 2026). Andrej Karpathy, who coined "vibe coding" in the first place, has already renamed the serious version of it agentic engineering: for production work you're not writing the code most of the time, you're orchestrating agents and holding the judgment (Karpathy, 2026). The pattern is the same across all of them: as the machine takes over the typing, the scarce thing is the architecture in your head. Which raises the question this post is really about: where does that architecture in your head come from, and what happens to it when the agent does the thinking?

▸In their own words: Stone and Karpathy

"We need more systems thinkers, people who can look across all the business domains and abstract that to, here's the building blocks we're going to need." — Elizabeth Stone, Netflix CPTO, on Lenny's Podcast (July 2026)

"'Agentic', because the new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight. 'Engineering', to emphasize that there is an art and science and expertise to it." — Andrej Karpathy, on naming "agentic engineering" (February 2026)

Vibe coding spends two budgets, not one

When we talk about what this new way of building costs, we talk about tokens, and we should. My own Claude Code usage runs into the hundreds of millions of tokens on a heavy day, most of it cheap cache reads, and once a team multiplies that across every ticket, it turns into a real line item. But tokens are the budget you can see. There's a second budget nobody puts on the invoice: the human memory you didn't build, because the agent did the thinking for you. The first is measurable. The second compounds quietly, and you rarely notice it leaving.

The token budget is the easy one to measure

And it genuinely is easy, which is also why it's the bare minimum. Route your agents through a gateway, tag each ticket, and you can see what a piece of work actually cost in tokens. The uncomfortable part isn't the measuring, it's what it reveals: all those impulsive "let's just build it" ideas are cheap to start and quietly expensive to run, and most teams still haven't put that number in their financial model.

The memory budget: the systems model an architect carries

That budget you can put on a dashboard. The other one you can't, and it's the one I want to talk about. So let's be precise about what a good architect actually carries, because it isn't a document and it isn't raw intelligence. It's a systems-level model of how everything connects, held in memory, and there's real science on how it gets there.

Your brain doesn't store a topic as a pile of facts. It distills many concrete experiences into a schema, a map of how the parts relate that it abstracts out of the specific episodes (Nature Reviews Neuroscience, 2025). Systems thinking, in the brain, is close to this: the capacity to hold a lot of relationships at once and feel how a change in one ripples through the rest. You build that map through retrieval and prediction error, over time. Every time you predict how the system will behave and get it wrong, that surprise is the signal that wires the relationship in.

Here's the part that makes me think it's more than a metaphor, though I'll be careful with it. When you actively practice a skill instead of just watching it, the cortex grows new synapses within about an hour, and a subset of the ones formed during the struggle get selectively stabilized so they stick (Xu et al., Nature 2009). That study is motor learning in mice, so I won't pretend it maps cleanly onto holding a software architecture in your head. But the shape of it keeps turning up wherever learning gets measured, and it points the same way for understanding how a system works: people who get to intervene on it, poke it and watch what moves, tend to learn its causal structure more reliably than people who only observe the exact same data (Lagnado & Sloman, 2004). Struggling through the wrong piano keys teaches you more than watching a recital, something I've written about before. The friction is the learning.

Vibe coding skips exactly that step. When the agent predicts, runs, fails, and corrects, the agent gets the prediction-error signal, not you. You read the diff, you approved it, you merged. And then comes the trap, which is real enough to have a name: the illusion of explanatory depth. We believe we understand a system in far more detail than we really do, and the illusion is strongest for exactly this kind of how-it-works knowledge, until the moment someone asks us to explain the mechanism or fix it (Rozenblit & Keil, 2002). A clean PR description feels like understanding, right up until the day something breaks in production and you're reading code you technically wrote but never actually encoded. The agent kept the tokens. It also kept the memory.

▸The illusion of explanatory depth, in the original words

"People feel they understand complex phenomena with far greater precision, coherence, and depth than they really do; they are subject to an illusion—an illusion of explanatory depth. The illusion is far stronger for explanatory knowledge than for many other kinds of knowledge, such as that for facts, procedures or narratives." — Rozenblit and Keil, Cognitive Science (2002)

The one abstraction with nothing above it

Here's the objection I'd raise if I were reading this, and it's the strong one. We have been giving up understanding of the layer beneath us for the entire history of software, on purpose, and it kept turning out fine. Assembly programmers warned that C would rot your feel for the machine. C programmers warned that garbage collection would rot your feel for memory. Almost nobody shipping a web app today can explain their compiler's register allocation or their CPU's branch predictor, and the work got faster and better at every rung. "You stopped holding the layer below in your head" has been the deal the whole time, and we took it gladly, because it freed us to think about something bigger.

That's exactly why I think this time is different, not the same. Every one of those trades moved your attention up a level: you stopped tracking registers so you could reason about functions, then services, then the architecture of the whole thing. The abstraction relocated your model, it didn't erase it. But architecture is the top of the ladder. There's no higher layer to climb to and reason from instead. When the agent does the architecture, the thing you're handing over isn't the floor you stand on, it's the ceiling, and there's nothing above it to stand on. That's the new part. Not that we abstracted something away again, but that this time it's the last rung.

Architectural understanding is built like memory, block by block

Architecture gets built the way memory does, block by block and retrieval by retrieval. That's the whole picture in one drawing.

Vibe coding buys a near-vertical start that flattens fast. Understanding built the slow way starts behind and keeps climbing, until it crosses over, and the person who struggled up the slope is the one who can now see the whole mountain. It's the same reason experts and novices differ less in how much they know and more in how it's organized: the expert's knowledge is arranged around deep principles, the novice's is a flatter list, and that structure is what years of retrieval quietly assemble (How Experts Differ from Novices, National Academies).

The hidden cost is already showing up in the data

None of this is anti-AI, and I want to be careful here, because vibe coding went from a Karpathy tweet to Collins Dictionary's word of the year in about ten months, and the enablement is real. But the bill is starting to show up in the numbers. When Veracode ran AI-generated code through dozens of security-sensitive tasks, about 45% of it shipped with an OWASP Top-10 vulnerability (Veracode, 2025). And as the tools went mainstream, one security firm watched monthly vulnerabilities in AI-assisted code climb roughly tenfold in six months (Apiiro, 2025). Now, that measures the code, not the coder. A vulnerability count isn't a direct read on whether a human built the mental model, and I don't want to oversell it as one. But it's the closest measurable shadow we have of the thing I'm worried about, because insecure code nobody caught and un-owned architecture nobody can explain tend to come out of the same moment: the review that waved it through instead of interrogating it. The memory cost is the part you can't put a number on yet. This is the part you already can.

▸The security numbers, unrounded

Veracode ran 80 curated coding tasks through more than 100 models. In 45% of cases the model introduced a detectable OWASP Top-10 vulnerability; the security pass rate was about 55%. Java fared worst at roughly 72% failing, and some categories were near-total: cross-site scripting and log injection failed around 86–88% of the time (2025 GenAI Code Security Report).

Apiiro studied over 7,000 developers across 62,000+ repositories. AI-assisted developers produced 3–4× more code, but exposed cloud credentials and secrets at roughly twice the rate of their peers, and monthly security findings tied to AI-assisted code rose about tenfold in the six months to June 2025 (4x Velocity, 10x Vulnerabilities).

The fast path and the slow path feel identical, until they don't

So here's the dilemma, and I don't think it's use-it-or-don't, because I'm agentic most days and I'm not giving that up. It's that the fast path and the slow-compounding path feel identical from the inside, until one day they don't. And it surfaces in two ways. The loud one is the one everyone pictures: a high-stakes, ambiguous bug at the worst possible time, the kind where nobody remembers why the system is the way it is. But the quiet one is more common, and over a quarter it costs more. It's the planning meeting that stalls, because the decision on the table needs a judgment call about how the system actually behaves and nobody in the room can make it, so it gets punted up the chain or made on a guess. In the rooms I sit in, that's the version I watch happen. The velocity you can measure, the PRs merged and the tickets closed, still looks great, because each engineer is fast. The velocity that actually matters, how quickly the team can make a sound call it will stand behind, is the one that slips. It's the same gap I wrote about from a different angle in Enabled, Not Mastered: the motor gets you onto the trail, but it can't read it for you.

I want to be honest about the other side too, because the easy doom version is also wrong. The risk isn't automatic. If you stay genuinely active, predicting, verifying, and getting your hands dirty on the parts that matter, you can orchestrate agents all day and still build the model. The danger is specific: it's the reviewer who rubber-stamps, and it's the newer engineer who never gets the hands-on reps that later compress into a big picture. That's where the memory quietly fails to form, and it's a choice about how you work, not a fate the tools hand you.

Maybe none of this matters: the case against my own argument

Everything above assumes the memory is worth having. So let me argue the other side as hard as I can, because it might not be. Agents are getting smarter and cheaper at the same time, and neither trend is marketing. The price of a fixed amount of capability has been falling something like tenfold a year (a16z, 2024), and on some tasks a lot faster than that. The length of task a model can finish on its own has been doubling roughly every seven months for years (METR, 2025). If that line holds, at some point the agent's judgment passes yours and it holds the whole system in a context far larger than your memory, and the model you never built stops being a liability, because a better mind is keeping it for you. In that world this entire essay ages into a nostalgia piece, and I genuinely can't rule it out.

But the same evidence cuts the other way, and this is where I've actually landed. Cheaper tokens have not meant smaller bills so far; they've meant we generate far more, so total spend keeps climbing even as each unit gets cheaper. And the headline capability scores hide a reliability gap: the impressive numbers usually mean "succeeds about half the time," and on the benchmarks scrubbed of contamination the same top models fall by more than half (SWE-bench Pro, 2025). Getting cheaper lowers the price of producing code. It does not obviously lower the price of being accountable for a system nobody understands, and I can't find any evidence that second cost is falling at all.

So I won't pretend to know the trajectory. What I can do is lay out the futures that look live to me and be honest that I can't rank them. Click through them:

Three of those four are mostly out of your hands, because they turn on how the models and the market move. The fourth one, keeping the loop, is the only curve you actually control. That's the one worth defending. Not because AI is bad, but because staying in the loop is the cheapest insurance across every future where the machine doesn't fully arrive. It isn't free: staying active is slower, and the chart above is honest that you pay for it up front. But it's a small premium against the future where you needed the model and never built it, and only a small waste in the one where the machine really does arrive and it turns out you didn't strictly need it.

How to protect the loop that builds the model

So what do you actually do about the second budget? It depends on where you sit. The one principle underneath all of it: protect the loop where you predict, act, get surprised, and update, because that loop is the only thing that builds the model, and automation removes it unless you defend it.

The bill you won't see coming

One caveat before the last word, because I've earned the doubt and so have you: the ground is moving fast, I don't know how much of this survives the next year, and if the models get good enough fast enough, the memory may stop mattering. I'm not betting against that. I'm just not willing to bet everything on it, because nobody predicting this field has stayed right for long.

There's a line I wrote in a notebook and keep circling back to: what we do everywhere matters more than what we do once in a while. The token bill will get your CFO's attention soon enough. The memory bill won't, because it never arrives as a line item. It shows up first as decisions that take a little longer than they used to and meetings that end in "let's circle back," and only much later as the day you need someone who actually knows why the system is the way it is. You spend that budget without ever noticing it was going.

What I do feel sure of is the older, smaller thing underneath it, the part that isn't really about AI at all: you can sink so fast it feels like flying, right up until you need the altitude you never gained.

Spend the tokens. Just don't spend the memory you're going to need later.