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."