Everyone's been talking about how good the models have gotten. Fewer people are talking about the thing that actually changed what those models can do, which has nothing to do with model quality at all.
I spent the last month building and shipping an application almost entirely through conversation with Claude Code, never opening the codebase myself. A thousand production deployments in a bit over a month. The part people usually ask about is the model. The part that actually made it possible is a protocol most people haven't heard of: MCP, the Model Context Protocol.
The old loop
For a long time, using an LLM to help you build something looked like this:
- Ask the model to write some code
- Copy it
- Paste it into your project
- Run it
- See what broke
- Go describe what broke, in words, back to the model
- Get a fix
- Repeat
Notice what's happening in steps 3 through 6. You are the transport layer. The model has no idea what actually happened when its code ran. It only knows what you choose to tell it, translated into whatever level of detail you bothered to type out. If you leave out a detail, the model doesn't have it. If you misremember the error message, the model works from the wrong one.
This isn't a small inconvenience. It's a structural limit. The model was extremely good at generating plausible next steps, but it was flying blind on ground truth. Every loop between "AI suggests something" and "AI learns whether that suggestion worked" ran through a human doing manual translation.
What MCP actually changes
MCP is a protocol that lets a model call out to external tools and services directly, in a structured way, instead of just producing text about them. Instead of a bespoke integration for every single tool a model might need to touch, MCP standardizes how a model discovers what tools are available and how it calls them.
The practical effect is that the model stops being a text generator that you operate on behalf of, and starts being something that can act and then observe the result of its own action.
Take a concrete example from my own stack. Sentry catches production errors, and it's integrated with GitHub so any error traces back to the exact commit that caused it. Under the old loop, I'd read a Sentry alert, dig up the relevant stack trace and commit, and describe all of that back to an AI in a chat window, hoping I captured enough detail for it to help. Under an MCP-connected setup, the model pulls the Sentry error directly, including the commit reference, without me acting as the messenger. It gets the same information I'd get, not a lossy paraphrase of it.
Multiply that across every service a real application touches: source control, CI, database, hosting, error tracking, analytics, payments, email. Each one becomes a two-way channel instead of a one-way destination for AI-generated output.
Why this isn't just "function calling, rebranded"
If you've been doing this a while, you're probably thinking: models could already call tools before MCP. Function calling has existed for a couple of years. What's actually new here?
Function calling required a bespoke integration for every tool, defined and maintained by whoever was building the application. If you wanted a model to talk to GitHub and Supabase and Vercel and Sentry, you were writing and maintaining four separate integrations, each with its own schema, its own quirks, its own failure modes.
MCP standardizes that layer. A service exposes an MCP server once, and any MCP-compatible model or agent can talk to it without a custom integration built specifically for that combination. That's the difference between "technically possible with enough glue code" and "actually practical for one person to wire together eight services in a weekend." The ceiling was always there. The floor moved.
Worth being fair to the skeptical read here: MCP doesn't make any individual tool call smarter, and it doesn't fix a badly designed API on the other end. If a service's MCP server exposes bad endpoints or vague error messages, the model still gets bad information, just through a more efficient pipe. The protocol changes how information flows, not the quality of the information itself. That part's still on you.
What the loop looks like now
Instead of the eight-step loop above, a lot of my actual workflow collapsed into something like:
- Describe the outcome I want
- The model writes the change, deploys it, and checks whether the deployment succeeded
- If it failed, the model pulls the actual failure reason itself and tries again
- If a runtime error shows up later, the model pulls it from Sentry, complete with the offending commit, and fixes it without me relaying anything
I'm still the one deciding what should be built and whether the result is actually good. That part didn't change and I don't think it should. What changed is that the feedback between "the model did something" and "the model knows if that something worked" no longer has to pass through me typing a description of reality into a chat box.
Why this matters more than the model getting smarter
Model quality improvements are real, but they're incremental and expected. Everyone assumed the models would keep getting better. Fewer people expected the plumbing between models and the actual systems they affect to become standardized enough that an individual developer could wire together a full production stack and have the model observe and correct its own actions across all of it.
That's the part I'd point people toward if they want to understand why the last year feels different from the two before it. It's not that the AI got better at pretending to understand your codebase. It's that it stopped needing you to describe the codebase to it in the first place.
Top comments (1)
"You are the transport layer" is the sharpest description of the pre-MCP loop I've read, and it explains something people misattribute to model quality: hallucinated fixes usually aren't the model lying, they're the model reasoning correctly over a lossy paraphrase you typed of the actual stack trace.
One thing I'd add from running a similar setup in production: the harder half of MCP is scope and blast radius. When the model can pull the Sentry error itself, you also want it unable to touch anything beyond read paths unless you say so, otherwise the feedback loop that fixes bugs can also ship them. Did you run those thousand deployments with the model having write access to CI, or did you keep the deploy button human?