DEV Community: Omi0

ChatGPT Was the Interface. MCP Is the Infrastructure.

Omi0 — Sat, 12 Sep 2026 16:04:26 +0000

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.

How I Shipped 1,000 Deployments in a Month Without Opening My Codebase

Omi0 — Sat, 12 Sep 2026 15:12:57 +0000

A few weeks ago I shipped the 1,000th production deployment of an application I built almost entirely through conversation with an AI. Not "AI helped me write some functions." I mean I didn't open the codebase. Every migration, every deploy, every rollback happened through a chat window talking to Claude Code, which then talked directly to every service in my stack.

This isn't a hype post. I want to walk through the actual stack, the actual wiring, and what a real feedback loop looks like when an AI has direct access to your infrastructure instead of just generating code for you to paste somewhere.

The product, briefly

The app is called Klyf. It's an AI YouTube analyst that lives inside Claude, connecting a channel's data and analytics so Claude can give tailored advice on what to do next. Not relevant to the mechanics of this piece, but useful context for why I needed the pieces below.

The core idea: two-way integration, not one-way generation

Most people's experience with AI and code still looks like this:

Ask the AI to write something
Copy it
Paste it into your project
Run it yourself
See what broke
Go back and explain what broke
Repeat

That loop still has a human in the middle relaying information back and forth. What changed for me is that Claude Code has direct access to every service in the stack through MCP (Model Context Protocol), a standard that lets an AI model call out to external tools and services directly rather than just producing text about them.

That means the loop above collapses into something closer to:

Ask for the outcome
AI writes it, deploys it, watches what happens, and fixes it if something's wrong

No copy-paste. No relay. The AI can read the result of its own actions.

The stack

Here's what's actually running underneath Klyf:

Claude Code as the development environment. Has file system access, a working shell, and MCP connections to everything below.
GitHub for source control and CI.
Supabase for the database and cloud functions.
Vercel for build, hosting, and deployment.
Sentry for error tracking, integrated with GitHub for commit-level tracing.
PostHog for product analytics.
Stripe for payments.
Resend for transactional email.

None of this is exotic. What's different is that every one of these tools is a two-way channel for Claude Code, not a one-way destination.

3 Loop 1: GitHub

Claude Code pushes a commit, and a CI run kicks off. If the PR fails, it doesn't just sit there waiting for me to notice. Claude Code can pull the CI logs directly, see exactly which check failed and why, and fix the code in response. It'll recommit, watch the new run, and repeat until the pipeline is green.

The part that matters here isn't that AI can write a fix. It's that AI can see whether its own fix actually worked, without me relaying the error message back to it manually.

3 Loop 2: Supabase

Same pattern for the backend. Claude Code writes migrations and cloud functions, runs them against the actual database, and can see if a migration fails or a function throws. If something's wrong, it adjusts and reruns. I'm not the one pasting error output back into a chat window. It already has it.

Loop 3: Vercel

Deployments are visible to Claude Code directly: which ones succeeded, which failed, and why. If something goes out broken, it can roll back to a previous deployment on its own, without me needing to go find the dashboard and click the button myself.

Loop 4: Sentry, wired to GitHub

This is the one I'd point to if you only have room to build one feedback loop well.

Sentry catches runtime errors in production, and because it's integrated with the GitHub repo, every error is traceable back to the exact commit that introduced it. When Claude Code pulls an error from Sentry, it isn't just getting a stack trace, it's getting the specific change that caused the regression. That's the difference between "something broke" and "this exact line, in this exact commit, broke this."

The lesson underneath this, if you're setting up something similar: the quality of the fix an AI can produce is directly tied to the quality and specificity of the data it's working from. A vague error report gets a vague fix, or no fix at all. A precise one, tied to a commit, tied to a stack trace, tied to the conditions that triggered it, gets a precise fix.

Loop 5: PostHog

This is less about bugs and more about direction. PostHog tracks custom events across the app: signups, feature usage, drop-off points, whatever you define. Claude Code can pull this data and use it to inform what actually gets built next, instead of me guessing what users want based on gut feel.

Concretely, this is the loop that answers "should we build this feature at all," where the others answer "is what we already built working correctly."

Loop 6: Resend

Smaller, but still two-way. Claude Code can see which emails went out, to whom, with what content, and whether they landed or bounced. That's useful for anything from debugging a broken notification to noticing that a particular email is getting ignored and needs rewriting.

What this actually requires from you

If you want to set something like this up, the honest answer is that most of the work isn't the AI part. It's making sure every one of these services actually produces data specific enough to be useful when something goes wrong.

A few things I'd treat as non-negotiable from day one:

Error tracking wired to source control, not standalone. A bug report with no commit reference is much less useful than one with it.
Structured logging, not just print statements. If the AI is going to read your logs, they need to be parseable, not prose.
Analytics events defined early, even if minimal. You can't get direction from data you never collected.
A rollback path that doesn't require you to manually intervene. If a deployment can fail, plan for it to be undone automatically, not manually.

None of this is new advice for engineers. What's new is that if you set these up properly, an AI can act on them directly instead of you being the one reading dashboards and deciding what to do about it.

Where this leaves things

I didn't know several of these tools well before this project. Supabase, PostHog, and Resend weren't things I'd used at any depth. Claude Code suggested them based on what I was trying to build, and I said yes. What let me trust those suggestions wasn't familiarity with the specific tools, it was fifteen years of knowing what a backend needs to do, what visibility into users actually looks like, and what a red flag in a suggested architecture looks like even in an unfamiliar tool.

That's the actual shift here. The tools changed. What still matters when picking and wiring them together didn't.

If you're setting up something similar, start with the error tracking and commit tracing loop first. It's the one that pays for itself fastest, and it's the clearest example of what "AI with real feedback" looks like compared to "AI that just writes code."