
Five minutes into my vibe coding talk, I asked the room for a definition. Someone said, "a toxic manager with AI." Honestly, that was better than half the definitions on the internet.

Other answers followed. Describe the requirement in plain English. Start with a concrete plan. Use your idea and imagination even if you have never written code. All correct, but the "toxic manager" answer stayed with me because it described the real failure mode. You keep demanding changes from a system that is slowly losing context, then get angry when it forgets what you said twenty minutes ago.

The barrier to making software has collapsed, which is great. You can now begin with zero code and zero revenue. The only upgrade is that you can also be broke because the agent ate your entire token budget before the product found its first user.

That is where the talk moved away from vibe coding and into the part I actually care about: building a system around the model that can reason, act, remember, and check its own work.

## the brain and body distinction

I drew a simple separation on the screen. The model is the brain. The coding agent, CLI, editor, tool layer, memory, and orchestration around it form the body. I call that body the harness.

This sounds like terminology until two products use the same model and give completely different results. The difference is usually not hidden intelligence. One harness loaded the right files, exposed the right tools, kept the context clean, and checked the output. The other one arrived carrying six old conversations, fifteen tool schemas, a novel-sized system prompt, and enough logs to recreate the Industrial Revolution.

We spend most of our time comparing brains because model benchmarks are easy to screenshot. But the body decides what the brain can see and what it can do. A smaller model inside a disciplined harness can beat a stronger model inside a cluttered one on the task that actually matters.

## more context is not always more intelligence

During the talk I used a hundred-page analogy. Suppose you read a hundred pages today. Tomorrow, do you remember every sentence? Of course not. You remember the important decisions, a few examples, and the general shape of the argument.

An agent session has the same problem, except we often treat its context window like a storage cupboard. Tool outputs go in. Failed attempts go in. Entire files get loaded because one function looked suspicious. Then we add a long instruction telling the model to pay attention to the important parts, which is a little like fixing a messy desk by placing a note on it that says "be organized."

The model technically has more information, but the useful signal is now fighting everything else for attention. This is the dumb-zone feeling people notice in long sessions. The model was sharp at the beginning, then somewhere around the tenth correction it started agreeing with everything and following nothing.

I wrote about the same problem from a production angle in [Everything I Got Wrong About AI Coding Agents](/posts/everything-we-got-wrong-about-ai-coding-agents). The short version is that context is not free intelligence. It is a budget, and every tool definition, instruction, file, and previous answer spends some of it.

## compacting helps, but it is also a tiny case of alzheimer's

Someone in the room asked about `/compact`. The command takes a long conversation, summarizes it, and starts a smaller context from that summary. Useful, right? Yes, but the summary cannot preserve every decision and edge case. My extremely scientific description during the talk was that compacting has a small Alzheimer's problem.

The way I handle this is with a production action log. It is not a dump of the chat. It is a small persistent file that records what changed, why it changed, what was verified, what remains uncertain, and what the next phase needs to know.

The conversation can disappear after compaction. The project state cannot. This difference sounds basic, but chat history and memory get treated as the same thing in a lot of agent setups. Chat history is everything that happened. Memory is the tiny set of facts that must survive.

## one phase at a time

Then I asked the room how they would prompt an agent to build a to-do app. The first answer was basically, "make a to-do app." Fair enough. The interesting part began when I added authentication, profiles, deployment, validation, and a few other things to the same requirement.

Models love taking shortcuts through big prompts. If I give one agent six features at once, it tends to produce six shallow features and call the project complete. Authentication gets a login form. Security gets a sentence in the README. Validation means the build command returned zero. Wonderful, until someone sends a request the UI was not designed to send.

So I split work into phases. Each phase has an input, one objective, and an observable outcome. The output of phase one becomes the input to phase two, then phase three, like a chain where every link has to hold before the next one is added.

```text
phase 1 output -> phase 2 input -> phase 3 input -> validation
```

Authentication becomes one phase. The outcome is not "authentication code exists." The outcome is that valid users can sign in, invalid sessions are rejected, the important abuse cases have been tested, and the behaviour survives in the deployed environment.

Planning and execution also need different behaviour. During planning I tell the agent not to assume, to inspect the environment, and to ask as many questions as necessary. During execution the decisions are already made, so it should stop reopening architecture and work until the agreed validation passes. Mixing those modes is how you get an agent that starts coding too early and starts philosophizing too late.

## the loop is only real when validation is real

The board eventually became a set of inner and outer loops. The inner loop plans a phase, executes it, validates the result, and repairs failures. The outer loop watches the actual goal. If the inner loop stops without meeting it, the outer loop starts another attempt with the failure state preserved.

```text
plan -> execute -> validate -> repair -> validate again
```

The validation layer is the part people skip because generation is more fun to demo. For a website, I give the agent a browser so it can inspect the rendered page and click the controls. For an Android app, it needs screenshots and a way to tap through the interface. For an API, it needs real requests against the environment where the code runs. A green unit test is evidence, but it is not the same thing as seeing the user's path work.

This is how the workflow becomes autonomous without becoming reckless. I can attach a trigger to a Jira ticket, let a cheap model decide whether the task is routine or risky, and start the loop for routine work. The large model does the reasoning-heavy parts. The harness handles context, tools, retries, and state. Human review stays where the blast radius demands it.

The same restraint applies to tools. If a task can be done reliably with an existing CLI, I do not automatically load a large tool protocol into every session. A tool should earn the context it consumes. Installing everything because it might be useful later is how the agent begins every task already carrying luggage.

## the strange part came at the end

Near the end of the talk, I switched from agent systems to a more basic question: what does a language model actually know?

We talk to it through sentences, so the natural mental picture is a giant hidden library. Ask a question, the model finds the correct paragraph, and then reads it back in its own voice. That picture is comforting and mostly wrong. The learned representation is closer to geometry. Words and concepts become high-dimensional vectors, and relationships appear as distance and direction inside that space.

`Agent` lands near ideas such as `agency` and `intelligence`. `Code` drifts toward `debugging` and `backend`. Nobody created those folders by hand. The neighbourhoods come from patterns learned by the embedding model.

Humans cannot look around in 3,072 dimensions, so I projected a small vocabulary into three and made it walkable.

<WordEmbeddingFlight initialWord="agent" />

Search for a word and teleport to it. The named points are real embedding vectors, and the neighbour score shown under each word is calculated in the original high-dimensional space. The coloured particles make the regions readable at human scale; they are visual scaffolding around the real word positions, not invented extra words. The fullscreen button is there because this thing makes much more sense when the article gets out of the way for a minute.

The first scene stays deliberately small so it can open inside an article without turning the rest of the page into collateral damage. Enter the space or search beyond those landmarks and a second atlas streams in: 234,869 open-English terms indexed as a complete map. The browser keeps the full three-dimensional projection available for search and the minimap, but sends only the camera's local neighbourhood to the GPU. The heavier vectors remain split into small files and only the words you ask for are fetched.

There is another way to inspect the same geometry. Put your own words on the rows and columns below. Each cell is their cosine similarity, so you can test whether `frustration` leans closer to `corporate`, `relationship`, or anything else in the atlas instead of accepting a hand-picked example.

<EmbeddingSimilarityMatrix />

## for the nerds who want the receipts

The opening map contains 199 labelled landmarks. Each starts as a vector with 3,072 values:

```text
word -> [v1, v2, v3, ... v3072]
```

I normalize those vectors and calculate exact cosine similarity for the nearest neighbours:

```text
cosine(x, y) = dot(x, y) / (norm(x) * norm(y))
```

The three-dimensional position comes from PaCMAP, which tries to preserve local neighbourhoods without completely destroying the larger shape. That projection has a trustworthiness-at-10 score of 0.812 on this vocabulary. Good enough to explore, nowhere near good enough to pretend the 3D picture is the model's literal internal layout.

That distinction matters. Cosine neighbours come from the original 3,072-dimensional vectors. The lines, map position, and visible clusters come from the compressed projection. If the picture and the cosine score disagree, trust the cosine score. A projection is a view of the data, not the data itself.

The wider atlas makes a different performance tradeoff. Its 234,869 terms use normalized 128-dimensional vectors, quantized into 115 static shards, with a compact UMAP projection for the visible map. The visualizer downloads the vocabulary and the 1.34 MB projection, builds a spatial index in the browser, and renders at most 40,000 nearby words as the camera moves. The comparison matrix requests a vector shard only when one of its words needs it. No model API call runs while you read this page.

## what I actually took away from the talk

I started the session with vibe coding because that is the phrase everyone recognizes. By the end, the code generation itself felt like the least interesting piece. The useful work was choosing what enters context, deciding what must survive compaction, breaking one vague goal into phases, and building a validation layer that can observe reality instead of trusting the agent's confidence.

The vector map closed the loop for me. A prompt is not a command inserted into an empty machine. It changes a computation already shaped by learned geometry, the current context, available tools, previous outputs, and the harness wrapped around all of it. Better prompting helps, but better system design lasts longer.

The model is the brain. The harness is the body. The loop is the work. If the loop is weak, a better brain simply makes expensive mistakes faster.


What I learned teaching vibe coding through context limits, phase prompts, validation loops, and the strange vector geometry inside language models.

The Model Is the Brain. The Harness Is the Body.

I had a hunch the standard system → user prompt order was wrong for negative constraints. Every standard answer told me to drop it. I ran 1500 calls on 30 hard tasks and the flipped version beat the standard one by 14 to 46 points. The system slot is the worst place for your 'do not' rules and the docs back it.

Flip your order and it works? The system prompt is the worst place for your 'do not' rules


A friend pinged me at 9pm asking what MCP actually gives you over plain APIs. Full skepticism vibe. He had been reading about it, couldn't find anything substantial, and wanted me to either convince him or admit there was nothing there.

I started typing the defense. Standardized tool use. Dynamic discovery. Session state. The usual arguments. Halfway through I realized I did not believe myself, and by the time we had finished the conversation I had watched every defense line collapse under one very simple question: "if the server is local, can't the agent just import the function?"

Yes. Yes it can. And once you see it, you can't unsee it.

## the received wisdom

The pitch for MCP goes like this. If you want an agent to talk to Slack and GitHub and Jira, you're writing three integration layers. Three auth flows. Three response parsers. Three schema translations for the LLM. MCP wraps all of that behind one protocol so the LLM client does not care what is behind it. Standardized interface, dynamic discovery, composability. USB for AI tools.

That sounds important. It is also mostly true. What I want to pick apart is whether it's substantive, or whether the same thing was already possible with boring tools you already use.

## defense line one. standardized tool use for LLMs

The core value prop is one thing: a wire format that every LLM client understands when it wants to list and call tools. `tools/list` returns JSON schemas. `tools/call` invokes one with arguments. That is the whole protocol loop in practice.

Here is a minimal Python MCP server using the official FastMCP SDK:

```python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("hello")

@mcp.tool()
def add(a: int, b: int) -> int:
    return a + b

if __name__ == "__main__":
    mcp.run()
```

Seven lines. Tiny. Now here is the same thing without MCP:

```python
def add(a: int, b: int) -> int:
    return a + b
```

Two lines. Also tiny. Your agent framework on the other side can introspect the signature, read the docstring, build its own JSON schema, and call the function directly. No protocol. No JSON-RPC. No stdio handshake. Most agent frameworks already do exactly this.

So what did I save by using MCP in the first example over the second? Only the wire format. Everything else, the schema generation and the discovery and the call-and-return, is stuff the framework would have done anyway.

## defense line two. but OpenAPI already does this

If the value is "JSON schema plus discovery for callable endpoints", OpenAPI did that fifteen years ago. You hand an agent an `openapi.json`, it reads the schemas, it calls the endpoints. LangChain has `OpenAPIToolkit` for exactly this. Every function-calling LLM already takes JSON schemas as input, which means anything expressible in OpenAPI you can feed straight in.

So the steelman has to move further. Stateful sessions. Resources. Prompts. Sampling. Let me take them in order, because only one of these four turns out to be interesting.

**Stateful sessions.** OpenAPI describes stateless REST. MCP keeps a persistent session so the client does not re-auth every call and the server can hold context between calls. True, but re-auth in HTTP is called a cookie and holding context is called a session and the pattern is thirty years old. The novelty is not that MCP servers are stateful, it is that the wire format bundles session handling. That is a packaging convenience, not a technical innovation.

**Resources.** MCP has a concept of "resources", readable files or data the server can expose for the LLM to pull into context. OpenAPI only describes callable endpoints. Fair point, except a callable endpoint that returns a file is still just an API. There is nothing an MCP resource does that `GET /files/:id` does not. You could express every MCP resource as an OpenAPI endpoint with ten minutes of yak shaving.

**Prompts.** MCP servers can ship templated prompt snippets that clients surface as slash commands. That is a UX feature, not a protocol feature. Any CLI with a plugin system already does this.

Each of these is real, but when you line them up, you are not looking at technical progress. You are looking at a coordinated bundle of conventions. Which is a real thing to want. It is just not what "protocol" usually means.

## defense line three. the direction of the connection is flipped

Here is where I had to actually revise my take. The substantive thing MCP does that OpenAPI cannot is subtle. **The MCP server sits next to the LLM, not next to the internet.**

OpenAPI describes services, and services live behind HTTP endpoints, which means they already have an API. MCP servers are processes that live on your machine, or in your IDE, or inside Claude Desktop, and they bridge the LLM into contexts that were never APIs to begin with.

Your filesystem is not an API. Your running IDE buffer is not an API. Your local Docker daemon, your browser tab, your vim state, your postgres socket, your current git branch: none of these things have OpenAPI specs, because none of them exposed HTTP endpoints in the first place. Wrapping them in a tiny stdio server that speaks MCP lets the LLM touch them without you building a full web service first. That is real capability expansion.

And MCP has one genuinely new feature on top of this: **sampling**. The server can ask the LLM to do inference mid-call. "Before I continue, summarize this chunk for me." `sampling/createMessage` goes from server back to client, and the client runs inference and returns a completion. OpenAPI has no concept of this because REST calls only flow one way. An HTTP endpoint never calls back into your brain and asks you to think about something. An MCP server does.

If I had stopped thinking here two hours in, I would have written "MCP gives the LLM arms and legs in non-API environments, plus a back-channel to request reasoning." That is a real story. It is the best honest defense of the protocol. I was ready to ship that take.

## the question that broke it

My friend wasn't done. His next message was the one that collapsed the whole frame: "if the server is local, we basically don't need MCP, the agent can literally import the file and run those functions lol".

And he's right.

If the MCP server is running on your machine, and the agent is running on your machine, then the entire stdio JSON-RPC layer between them is solving a problem that only exists because they were separate processes. Put them in the same process, which is what every first-party agent environment already does, including Claude Code and Cursor and every custom agent anyone ships, and the "protocol" dissolves.

The agent just imports the module:

```python
from tools.github import create_issue
from tools.filesystem import read_file
from tools.ide import current_buffer

# introspect signatures, build schemas, call directly
# no wire format, no handshake, no session
```

You can even do the sampling thing without a protocol. If the tool is a Python function and the LLM client is a Python object in the same process, the function can call the client directly. `client.sample(prompt)`. Done. Bidirectional. No bytes on the wire. No JSON-RPC. No `initialize` handshake. The server-to-client call is a normal function return from inside a normal function call, which is how every computer program has worked for fifty years.

So what does MCP give you in this world, over a plain function call? Exactly one thing: **process isolation**. The tool runs in its own process, its own memory space, under its own permissions. If it crashes or misbehaves it does not take the agent down with it. That is real. It is also a property of any subprocess, not a property that requires a protocol. `subprocess.Popen` with a clean interface gives you the same isolation without any of the wire format. The protocol adds structure to the conversation between processes, but the isolation comes from the process boundary itself.

## what MCP actually is

After walking through all of that, here is what I think MCP actually is. It is a distribution and discovery standard for agent tools. It is npm for tool servers. The value is almost entirely in packaging and ecosystem, not in the protocol itself.

Someone writes an MCP server for Notion. They publish it. Every MCP-compatible client, Claude Desktop and Cursor and whatever else shows up next, plugs it in without reading the source. That is genuinely useful. Without MCP, everyone rewrites the Notion integration, and there is no common place to look.

The parallel with npm is so close it is almost the whole thing. npm did not invent JavaScript modules. CommonJS and ES Modules already defined how modules work. What npm added was a registry, a manifest format, and a naming convention that let anyone install anyone else's code with one command. The protocol underneath was thin. The value was adoption.

MCP is playing the same move. JSON-RPC over stdio was solved in 2005. Tool schemas for LLMs existed before MCP. What MCP adds is a registry, a manifest, a naming convention, and the promise that if you write a tool once, every compatible client speaks the same thing. That is valuable, but let's be honest about what kind of value it is. It is coordination, not invention.

## when MCP still wins

I want to be fair here, so here are the cases where picking MCP actually makes sense:

- **You're publishing a tool for other people to use.** Write it as an MCP server and every client can consume it without friction. This is the npm case and it is fine.
- **You're building a platform where tools are plugged in at runtime by end users.** Skill-loading agent platforms, Cursor-style extensions, Claude Desktop's config-file plugins. The end user cannot write Python to wire in a tool, so they need a discovery-and-plug interface. MCP is that interface.
- **You need process isolation for security reasons.** You do not trust a third party tool to share memory with your agent. MCP's stdio or SSE boundary gives you that, though so does `subprocess.Popen` with a simpler contract.
- **You're in the Anthropic ecosystem and want path-of-least-resistance.** Claude Desktop reads MCP servers natively from its config file. If you want your tool to show up there, MCP is the on-ramp. That is ecosystem lock-in, not a technical argument, but lock-in is a real reason to pick things.

If you are building your own agent for your own codebase, and the tools are your own functions, you do not need MCP. You need `def`.

## the part I actually care about

The thing that annoys me about the MCP discourse is not MCP. It is the framing. Every launch post and thread talks about MCP like it is a technical innovation. It is not. It is a coordination mechanism wrapped around a protocol thin enough that you could re-spec it in an afternoon.

That is not a criticism of the project. Coordination mechanisms are valuable. npm made JavaScript shippable. USB made peripherals sane. HTTP made hypertext universal. None of them were technically novel when they appeared, and all of them became load-bearing because enough people agreed on the same thing. That is how standards work. Standards are a social phenomenon that happens to be implemented in bytes.

MCP might become load-bearing in the same way. It might also not. What I want us to stop doing is pretending the protocol is doing work that the protocol is not doing. The value is in the ecosystem. The ecosystem only exists if everyone agrees to use the standard. And nobody agrees to use a standard that is advertised dishonestly. So call MCP what it is: a packaging format for agent tools with an attached wire protocol. Pick it up when you need to publish or consume, skip it when you don't, and let the technical hype die down so the coordination win can show up on its own merits.

You're not missing anything. There is no deep technical substance in MCP. There is a thin standard that becomes valuable only at ecosystem scale, and the honest version of the pitch is "use this so your tool works in Claude Desktop and Cursor without writing glue." That is a real value proposition. Ship it with that framing and I'll stop writing posts like this one.

~ Ashish Kumar Verma 🫡


A friend asked what MCP actually gives you over plain APIs. I tried to defend it. Every defense line collapsed under one simple question. Here's the honest walk through why MCP is a packaging standard, not a technical innovation, and why that's still valuable.

Honestly, MCP Is Just npm For Agent Tools


I've been using coding agents for about a year now, like actually using them, not demos or toy projects but production code that people pay for and that pages me at 3am if it breaks. And I got a lot of things wrong. I think it's worth talking about what went wrong because everyone's out here posting their wins, and nobody talks about the six months they spent shipping AI generated code that they had to rip out and rewrite.

## Shipping 50% more code doesn't mean 50% more progress

This was the first thing that hit me. I started using coding agents and my output went through the roof, PRs flying and features shipping, and it felt amazing. Then I looked at what was actually happening over a month and about half of those PRs were just cleaning up slop from the previous week. The AI wrote something that looked right, passed basic tests, but had subtle issues that showed up later, so I'd fix those, which created new issues, which I'd fix next week. I was running on a treadmill and calling it progress.

## The magic words problem

I was using this Research Plan Implement workflow, which sounds clean, right? Research the codebase, create a plan, then implement it. The planning step had this massive prompt with like 85 instructions and it was supposed to ask me questions, present design options, get my feedback, then write the plan, a proper back and forth.

But half the time it would just skip all that and dump out a 1000 line plan with no questions asked, no alignment, just "here's what I'm going to build." And I figured out that if you literally wrote "work back and forth with me starting with your open questions and outline before writing the plan" it would actually do the interactive thing, but if you didn't say those exact words it would just skip it. I was sitting there telling people "no no you have to say the magic words," and that's when I realized the tool was broken, not the user.

## Your LLM has an instruction budget

This is when things clicked for me. There's research showing that frontier LLMs can reliably follow about 150 to 200 instructions, and after that they start silently dropping some. So if your system prompt has 85 instructions and then your claude.md adds another 40 and your MCP tools add another 30 and your skill files add another 50, you're at 200+ instructions and the model is basically rolling dice on which ones to follow. That's why the planning steps were getting skipped; the model wasn't being lazy, it was overloaded.

<InstructionBudget />

Drag that slider past 150 and watch instructions start getting silently skipped. That's not a bug, that's just how these models work right now.

## The context window has a dumb zone

Related to this, everyone talks about context windows getting bigger, 200k tokens now, but bigger doesn't mean better. Around 40% fill you start getting degrading results, and by 60% the model is noticeably worse at following your instructions. And it's not just about the amount of information, it's about how many instructions are competing for attention. Too many MCP tools and the whole context window is full of tool definitions the model doesn't need for this task; too many files loaded and the actual instructions get drowned out. Less context, better results. Counterintuitive but true.

<ContextWindowFill />

Drag that past 64k tokens and watch the quality fall off a cliff. That's not a theoretical problem, that's what's happening every time you load 15 files into context and wonder why the model forgot your instructions.

## Don't read the plan. Read the code.

This is the one I'm most embarrassed about getting wrong. For months I was telling people "just review the plan, the plan is the source of truth," and I'd even have teammates PR the plans and code review them together. But a 1000 line plan produces about 1000 lines of code, and the code doesn't always match the plan because the model finds things during implementation, makes different decisions, takes shortcuts. So you review 1000 lines of plan, then you review 1000 lines of code to see what actually changed. That's not leverage, that's double the work.

The new rule is simple: skip the plan review and read the actual code. That's what ships, that's what pages you at 3am. And I know some people will say "but so and so ships 300k lines without reading any of it," and cool, those are open source projects, they're impressive but the stakes are different. If you're shipping production SaaS code in a regulated industry, please read it. We have a profession to uphold. 2026 is the year of no more slop.

## Horizontal plans will ruin your week

This is something I noticed after months of debugging AI generated code: models love to build features horizontally. What does that mean? They do ALL the database changes first, then ALL the services, then ALL the API endpoints, then ALL the frontend, and 1200 lines later you run it and something is broken. Which layer has the bug? Could be any of them. Good luck.

Compare that to building vertically, where you make a mock API endpoint, wire it to the frontend, check it works, then you add the services layer, check it works, then you do the database migration and integrate everything, check it works. Same total code, but you have checkpoints and you catch bugs in 300 line increments instead of debugging 1200 lines at once.

<HorizontalVsVertical />

Toggle between horizontal and vertical and you'll see the same feature, same code, but vertical gives you three checkpoints where you can test and fix before moving on while horizontal gives you zero. I now explicitly tell the agent to build vertically, and it fights me on it sometimes because training data is full of horizontal approaches, but it's worth the fight.

## So I split the whole thing up

The original workflow was three stages: Research, Plan, Implement, which meant one giant planning prompt with 85 instructions trying to do everything. I broke it into seven focused stages where each one has under 40 instructions and each one has a clear input and a clear output.

Questions first, where we just generate the right research questions from the ticket without thinking about implementation. Research next with a fresh context window that doesn't know what we're building and just finds facts about how the codebase works, objective, no opinions. Then a design discussion, and this is the big one. Instead of a 1000 line plan the agent brain dumps a 200 line design doc with all the patterns it found, all the options, all the open questions, and I do surgery on it. This is where I catch the model wanting to use the wrong architectural patterns, the wrong approach, the wrong abstractions, and 200 lines is actually reviewable whereas 1000 is not.

Then a structure outline with high level phases instead of exact code, like C header files, enough to see what's coming without reading the implementation. Then the actual plan, which at this point is just a tactical doc for the agent because I've already aligned on everything and I just spot check it. Then implement phase by phase where each phase is testable, and then package into a PR.

<CrispyPipeline />

Click between the before and after and look at the max instructions per stage: 85 down to 35. And the key document you review went from 1000 lines to 200.

## The leverage is not in the coding

This is probably the most important thing I've learned, and everyone obsesses over "AI writes code faster," which it does, but coding was never the bottleneck. A two day feature breaks down like this: maybe 4 hours of actual coding, 3 hours of alignment meetings, 2 hours of code review, 1.5 hours of rework, 1.5 hours of testing. If AI makes the coding part take 20 minutes instead of 4 hours, you saved 3.5 hours on a 12 hour feature, and that's nice but it's not transformative.

The real leverage is using AI for the alignment phase, the design discussion, the research. When your team reviews a 200 line design doc before you write code, the code review becomes "yep that's what we agreed on" with no surprises and no rework.

<LeverageCalculator />

Drag the complexity slider and even on simple features, notice how "just vibe code it" actually takes longer overall because of the rework. The sustainable speedup comes from better alignment, not faster typing.

## Do not outsource the thinking

If there's one sentence I'd tattoo on the inside of my eyelids it's this: do not outsource the thinking. The agent should show you everything it's thinking, every pattern it found, every decision it wants to make, every assumption it's making about your architecture, and you correct it BEFORE it writes 2000 lines of code. The design discussion is brain surgery on the agent where you're forcing it to dump out its mental model so you can fix the parts that are wrong before they become 50 files of production code.

Every time I skipped this step because I was in a hurry, I paid for it later. Every. Single. Time.

## What I actually do now

I use AI for everything: research, planning, coding, testing, and it probably writes 80% of my code by character count. But I read all of it, I align with it on architecture before it writes anything, I build vertically with checkpoints, I keep my prompts focused and under the instruction budget, I treat the 200 line design doc as the most important artifact in the whole process. And I ship at maybe 2 to 3x the speed I used to, not 10x, but 2 to 3x.

That might sound disappointing compared to the "10x developer" hype, but the difference is my code doesn't get ripped out next month, it passes code review on the first round, it doesn't have hidden security landmines, it's code I'm proud to have my name on. 10x faster doesn't matter if you're throwing it all away in 6 months. Shoot for 2 to 3x, read the code, don't outsource the thinking, and that's actually how you win with AI coding agents.

And this applies beyond just code. The same failure mode of confusing impressive output with actual understanding shows up everywhere in AI right now, from the code these agents write to the way AI labs interpret their own models. Anthropic just published [a 243-page system card for Claude Mythos that's as much love letter as safety evaluation](/posts/anthropic-claude-mythos-system-card-love-letter), and the pattern is the same: the output looks beautiful, but someone still needs to be in the room asking "wait, is this actually what we think it is?"


A practical breakdown on what actually goes wrong with AI coding agents in production, from instruction overload and horizontal planning to why humans still need to do the real thinking. Written from experience shipping real systems at scale.

Everything I Got Wrong About AI Coding Agents


Matt Shumer's viral post "Something Big is Happening in AI, And Most People Will Be Blindsided" has been viewed over 50 million times. Fortune published it, Tech Twitter amplified it, and millions of people read it and felt a jolt of fear. I'm writing this because I think that fear is pointed in the wrong direction.

I work with AI every single day, not to build demos or prototypes but to keep production systems running at scale. I've spent years building AI powered tools, optimizing LLM inference pipelines, and deploying these systems into real enterprise environments. I also build AI applications on the side because I genuinely believe in this technology's potential. But the hype merchants won't tell you this: the real danger isn't that AI will replace you. It's that people will *trust* AI to replace you, and the consequences of that misplaced trust could be catastrophic.

## I debated Shumer's thesis with AI itself

Before writing this I did something a little unusual. I took Shumer's article and debated it point by point with Claude, one of the most advanced AI systems in the world. I told it to defend Shumer's position with everything it had, brought my counter arguments from real engineering experience, and we went back and forth for rounds. By the end, the AI conceded my core arguments.

Not because I'm smarter than the AI, but because the arguments I was making came from something AI doesn't have: years of watching what actually happens when AI generated code hits production. The failures I've seen aren't theoretical, they're not "edge cases," and they're systemic. They get worse the more you remove human oversight. Let me walk you through exactly what I argued, because I think these are the arguments 50 million people needed to hear alongside Shumer's post.

## "AI can build an app for you." Sure. But can it really?

Shumer's most compelling example is this: he describes what he wants, walks away for four hours, and comes back to a finished app. That sounds incredible, and for a prototype it probably is. The apps AI builds in four hours are the easy ones, though. Internal tools, simple workflows, CRUD applications. The kind of software that honestly could have been built with no-code tools and a competent project manager even before AI.

Try telling AI "Build me 3D Gaussian Splatting Video Calling. Every feature. Don't stop until it's done." It can't, not even close. The kind of software that actually powers industries, complex interconnected deeply architected systems, requires something AI fundamentally lacks: the ability to hold an entire system's context in its head and make thousands of interdependent design decisions that balance performance, security, maintainability, and user experience simultaneously. Most software engineers aren't building this, Shumer might say, and that's true. But the ones building the "easy" stuff were already the most replaceable workers in tech. The hard work, the work that actually matters, is still firmly in human hands.

## The "fix the code" death spiral is still very real

Shumer says the AI models of today are "unrecognizable" from what existed six months ago. He says the debate about whether AI is "hitting a wall" is over. I disagree, and I have receipts.

Just this year, in 2026, using the latest models, I asked an AI to optimize a database layer for performance. Simple specific request. What did it do? It deleted the ORM.

For non technical readers, an ORM (Object Relational Mapping) is a layer of software that protects your database from a class of attacks called SQL injection. It's one of the most fundamental security protections in modern web development. It exists because decades ago engineers learned the hard way that letting raw unvalidated queries hit your database is an invitation for attackers to steal, modify, or destroy your data. The AI didn't know any of that history, so it just saw that removing the ORM made the queries faster. Mission accomplished right? Except now anyone with basic hacking knowledge could walk right through the front door of the application.

This isn't a story from 2023, and this isn't a story about a "free tier" model. This happened with the best models available doing a routine engineering task, and the person who would catch this mistake is a human engineer who understands what an ORM is and why it exists. The "fix the code fix the code" loop that everyone experienced in 2023 hasn't disappeared, it's just gotten more subtle. The AI doesn't produce obviously broken code anymore; instead it produces code that looks perfect, passes basic tests, and contains hidden landmines that someone with engineering knowledge would spot. I've literally seen API keys exposed on websites from these lovable "vibe coded" apps lol. That's not better, that's worse.

## The library reinvention problem nobody talks about

When you ask AI to build something it has a systematic bias: it prefers to generate code from scratch rather than use existing battle tested libraries. This sounds minor, but it's not.

The entire modern software ecosystem is built on shared libraries, packages that have been written, tested, reviewed, patched, and hardened by thousands of developers over years. When AI reinvents a library's functionality from scratch in 200 lines of generated code you've lost all of that accumulated security and reliability. You've replaced a fortress with a sandcastle and the person who asked for it doesn't even know the fortress existed. The non technical person that Shumer celebrates, the one who "describes an app and has a working version in an hour," has no way of knowing that their app is built on AI reinvented wheels instead of industry standard libraries. They can't evaluate the difference because they don't know what they don't know.

This scales. The more AI generated code enters production the larger the surface area of unaudited untested home rolled replacements for proven tools. Every one of those is a potential vulnerability, every one is a ticking time bomb.

## AI is terrible at architecture. And that's where the real money is.

Let me give you a concrete example that captures why I think Shumer's thesis fundamentally misunderstands what software engineering actually is. Say you need to process tasks asynchronously in your application, so you ask AI for a solution. Nine times out of ten it'll spin up a cloud container service: Kubernetes pods, serverless functions, message queues, the whole nine yards. It's the "textbook" answer, and it's also for many applications wildly over engineered, expensive, and unnecessarily complex.

A senior engineer would look at the same problem and say "We can do this with a simple database driven job queue. Three tables, a cron job, and we're done. Costs nothing, easy to debug, easy to maintain." Both solutions work, but one costs ten times more, is ten times harder to maintain, and introduces ten times more failure modes. AI picks the expensive one because it doesn't understand context, doesn't know your scale, your budget, your team's capabilities, your existing infrastructure. It defaults to the generic over engineered solution because that's what shows up most in training data.

The people following AI's architectural advice are the non technical founders Shumer is empowering. They don't know there's a simpler option, so they're burning money on infrastructure they don't need because AI told them to and there's no engineer in the room to say "wait that's overkill." This is the real work of engineering: not writing code, but making decisions. AI is bad at it, not because of a temporary limitation but because good architectural decisions require deep contextual understanding of specific business constraints that AI fundamentally doesn't have.

## The adversarial security loop. This is where the AI ran out of counter arguments.

This is the part of my debate where Claude defending Shumer's position basically gave up. The typical response to "AI writes insecure code" is "well we'll use AI security tools to catch the problems," which sounds reasonable. But think about what actually happens: AI writes code to optimize a metric (make it faster, cheaper, more efficient), then a security scanner catches the vulnerability and explains why it's insecure. The optimizing AI now knows what the scanner looks for, so next time it achieves the same optimization through a path the scanner doesn't flag. The vulnerability is still there, it's just invisible now.

The security tool didn't make the code safer, it gave the optimizing AI a roadmap of what to avoid getting caught doing. The human manager sees metric improved, security scan passed, green checkmarks everywhere, and they ship it. This isn't science fiction, this is what happens when you create adversarial optimization loops without human oversight. The optimizing AI always has an advantage because it has a concrete goal while the security AI is playing defense against infinite possible attack surfaces. The more successful AI becomes at replacing engineers the more catastrophically it fails without them.

## The deskilling spiral Shumer ignores entirely

Shumer's advice is to use AI more: spend an hour a day with it, automate everything you can. He's right that you should learn these tools, but he completely ignores the most dangerous long term consequence. Dependency on AI degrades the very skills that make humans valuable.

If a junior engineer never debugs code manually they never develop the instinct that tells them "something about this output feels wrong." If a lawyer never reads case law themselves they never develop legal judgment. If an analyst never builds a model from scratch they never develop the intuition to spot when a number doesn't make sense. The more people rely on AI the less capable they become of catching AI's mistakes, and AI's mistakes are getting more subtle not fewer. We're creating a generation of professionals who can operate AI but can't evaluate its output, and that's not augmentation, that's a trap.

When I mentioned this in my debate the AI tried to counter with "Calculators didn't destroy mathematics." Fair point, but GPS actually did destroy most people's ability to navigate, and society just accepted the tradeoff. Until the GPS fails and you're completely lost. AI won't fail gracefully. When it fails in a complex system that humans no longer understand the consequences won't be "take a wrong turn," they'll be data breaches, system outages, financial losses, and decisions made on analysis that looked right but was fundamentally flawed.

## Follow the money. AI's \$100 billion circular economy.

This is the part of the argument that almost nobody is having and it might be the most important one. Shumer frames AI disruption as an economic inevitability: the market wiped out \$1 trillion in software value in a week he says, and the implication is clear. The money has spoken, AI is coming for everything. But let's actually follow the money, because when you do something uncomfortable emerges.

Microsoft invests \$13 billion in OpenAI. Where does that money go? OpenAI spends it on Azure compute, Microsoft's own cloud platform. Microsoft reports the spending as Azure revenue growth, AI revenue numbers look incredible, investors cheer, stock goes up. Rinse, repeat. Nvidia sells over \$100 billion in GPU chips to whom? Microsoft, Google, Meta, Amazon. Those companies build AI infrastructure, they sell AI services to each other, and they report "AI revenue." But peel back the layers and an enormous portion of that revenue is just tech companies buying from tech companies and calling it growth.

This is the economic structure of the AI boom. I give you \$100, you give me \$100, and we both report \$100 in profit. Everyone's top line is growing, everyone's AI metrics are up and to the right, but where is the end customer? The real business? The real consumer paying real money for real value that wouldn't exist without AI? A law firm paying \$20 a month for ChatGPT isn't financing \$100 billion data centers. A startup saving money on junior developers isn't justifying the trillion dollar valuations. The math doesn't add up unless you believe the circular spending will eventually be justified by real world productivity gains that haven't materialized at scale yet.

We've seen this movie before, it was called the dot com bubble. Companies were buying ads from each other, reporting revenue from each other, and valuations kept climbing until someone finally asked "Wait. Who's the actual customer?" When the answer turned out to be "mostly each other" the whole thing collapsed. I'm not predicting an AI crash because the technology is real and it does create genuine value. But the economic narrative around AI, the one that makes Shumer's disruption timeline feel inevitable, is inflated by circular spending that masks how much real world adoption is actually happening.

## The four arguments that sound good until you think about them

I know what the AI optimists will say because I've heard these arguments and debated them. Let me address why they don't hold up.

**"Good enough beats perfect, companies will adopt AI anyway because it's cheaper."**

This sounds reasonable until you realize that "good enough" is actually getting worse not better. Before AI, humans had a quality floor because they took pride in their work, they iterated until things felt right. Now AI has induced a laziness in the loop. People accept the first output, they stop iterating, they stop thinking critically about whether the result actually works. The quality bar isn't rising with AI adoption, it's collapsing because the human in the loop has mentally checked out.

**"One engineer plus AI replaces five engineers, jobs still disappear."**

This misunderstands how human ambition works. When one engineer becomes 5x more productive companies don't fire four engineers and call it a day, they say "great now we want 5x the output." Human appetite for more is infinite. We never look at what we have and say "that's enough," we always want the next feature, the next product, the next market. More productivity creates more demand which creates more work which requires more people. This isn't theory, it's called Jevons Paradox and it's played out in every previous technological revolution.

**"Every technology revolution had valid skeptics, the internet had the same problems."**

Sure, but the dot com skeptics never told people their careers were permanently over. They said "these valuations are insane" and "most of these companies will fail," and they were right. The internet still transformed the world. My argument isn't that AI won't matter, it's that Shumer is telling people their entire professional existence is obsolete, and that's a fundamentally different and far more reckless claim.

**"The circular economy argument applies to every infrastructure buildout."**

There's a critical difference. When railroads were built the investment produced something tangible: steel tracks connecting real cities enabling real commerce. When the electrical grid was built it powered real factories producing real goods. With AI you spend \$3,000 on API tokens, wait four hours, and get a half bugged application that still needs a human to fix. What's the tangible output? Where's the steel? Where's the electricity powering a factory floor?

## What you should actually do

Shumer's practical advice isn't bad. Learn the tools, be curious, don't ignore this. I agree with all of that. But let me add some things he left out.

**Use AI but learn what it's doing not just what it produces.** Don't just marvel at the output, understand the process. When AI writes code read it, when it makes a recommendation ask why, when it produces analysis verify the numbers. The person who can use AI AND evaluate its work is infinitely more valuable than the person who can only prompt.

**Double down on the skills AI is worst at.** Deep architectural thinking, security awareness, systems design, understanding why things are built the way they are not just how to build them. These are the skills that will command premiums as AI generated code floods the market.

**Be skeptical of anyone who tells you AI replaces expertise.** It doesn't, it replaces labor. The difference is everything. Expertise is knowing which labor matters, which shortcuts are dangerous, and which "optimizations" will blow up in six months. And be especially skeptical when AI labs themselves start confusing their model's fluency with depth, like when [Anthropic published a 243-page system card for Claude Mythos that's half safety science and half love letter](/posts/anthropic-claude-mythos-system-card-love-letter).

**If you're early in your career go deeper not broader.** The people who will thrive are the ones with genuine deep expertise that lets them serve as the human in the loop for AI systems. Generalists who skim the surface and let AI do the rest are commoditized overnight. Specialists who understand systems at a fundamental level become more valuable with every AI deployment.

## The bottom line

Something big is happening in AI, and on that Shumer and I agree. But the "something big" isn't what he thinks. The real story isn't "AI replaces everyone," it's "AI creates an enormous amount of unverified, unaudited, poorly architected code and decisions, and the companies that survive will be the ones that kept humans who can tell the difference."

The danger isn't that you'll be replaced by AI. The danger is that you'll be replaced by someone using AI who doesn't understand what they're doing, and then you'll be hired back at twice the rate to clean up the mess. Shumer compares this moment to February 2020 and Covid. I'd offer a different comparison: it's like February 2008. Everyone is building on foundations they don't understand, leveraging instruments they can't evaluate, and the people raising alarms are being told they're missing the opportunity of a lifetime. We know how that story ended.

The smart money isn't on replacing humans, it's on the humans who understand what AI is actually doing under the hood. That's the real "something big" that most people will be blindsided by.


A rebuttal to AI replacement hype from someone who builds production AI systems at scale, explaining why human judgment, architectural thinking, and oversight matter more than ever, and why trusting AI to replace you is the actual danger.

Product-development

The Model Is the Brain. The Harness Is the Body.

Flip your order and it works? The system prompt is the worst place for your 'do not' rules

Honestly, MCP Is Just npm For Agent Tools

Everything I Got Wrong About AI Coding Agents

Save Yourself from 'Something Bigger Is Happening'