--- title: "Resend: Why one-shot AI coding breaks on real codebases" newsletter: "MLOps Community" date: 2026-06-23 source: https://aaif.live/newsletters/mlopscommunity/2026-06-23-resend-why-one-shot-ai-coding-breaks-on-real-codebases --- # Resend: Why one-shot AI coding breaks on real codebases *Mihail Eric on why production AI coding needs research, planning, and review before the model writes a line* *MLOps Community — Agentic AI Foundation, 2026-06-23* A SPECIAL EDITION: MIHAIL ERIC, HEAD OF AI AT MONACO AND LECTURER AT STANFORD, TAKES OVER THE NEWSLETTER TO EXPAND ON HIS REPPIT BLOG POST [https://mlops.community/blog/reppit-a-framework-to-ship-production-code-2-3x-faster]. OVER TO MIHAIL. ## The problem with one-shot coding You open a coding harness, describe the feature, accept what comes back, and hope the model understood enough of the system to make the right calls. That works for a weekend project, but not on a codebase that already exists. Real codebases have history: naming conventions, hidden dependencies, half-documented decisions, test patterns that matter more than they look, and architecture that only makes sense once you know why it was built that way.  A model can write useful code, but the problem is what it does when it doesn't have enough context. It guesses. It invents APIs that aren't there, copies patterns from the wrong part of the repo, changes code you never asked it to touch. It solves the prompt instead of solving the problem inside the system you already have.  In a greenfield project there's little to clash with, so you might not notice. In a large existing codebase, guessing is the failure mode, and it usually doesn't show up as obviously broken code. It shows up as plausible code that passes a narrow test and quietly pushes the system in the wrong direction. Slow down before the model writes. The fix is boring, which is usually how you know it has a chance of working. Stop letting the model write code before it understands what it's writing into. That's the idea behind RePPIT, the framework I use for shipping production code with AI: RePPIT breaks the work into five stages: research, proposals, planning, implementation, and testing, with a human checkpoint before each major commitment. None of these steps are new. The difference is making the sequence explicit and turning each stage into a prompt, command, or skill the agent runs. Research comes first. Before the model suggests a feature or proposes a solution, it reads the relevant code and documents what's there: architecture, dependencies, file structure, data flow, integration points, the decisions the system seems to have made. No recommendations, no feature ideas, no implementation plan. Just a map of the codebase as it exists. That map is your first checkpoint. You read it and ask whether the model has understood the system or is already making things up. If it's misunderstood something fundamental, you catch it before any code exists, which is the cheapest place to catch it. For production work the biggest speed gain often comes before the first line is written, because a model that has read the codebase wastes less time proposing changes that were never going to fit. Then proposals, and don't accept the first idea. I ask for two options, specifically. Ask for one and you get an answer. Ask for too many and you get one real idea with a few reskins. Two forces a trade-off. In the full post I used Conduit, a vibe-coded Medium clone, and asked the model to add article search. One route was a database-agnostic SQL ILIKE search with no migration. The other was a Postgres TSVECTOR full-text search with an Alembic migration. That's the moment for a human tech lead. You can challenge the trade-offs, reject both, ask for a third, or take the data model from one and the API shape from the other. The model has done the legwork. You're still choosing the direction. Only then do you plan. The chosen approach becomes a design doc: functional and non-functional requirements, key decisions, data models, integration points, files to change, and files not to touch. That out-of-scope list matters more than it looks. A lot of agent mistakes aren't syntax errors or broken tests, they're scope errors: the model spots a nearby cleanup or a pattern it wants to improve, and suddenly your feature branch is carrying unrelated changes. Production codebases need constraint management as much as code generation. Reviewing a plan is cheaper than reviewing six hundred lines of code that should never have been written. Implementation follows. By now the model has context, a chosen direction, and a plan, so it has much less room to guess. The code won't be perfect, but the errors are more likely to be local and reviewable rather than baked into the shape of the solution. Testing and review close it out. One rule I care about: don't let the model instance that wrote the code be its only reviewer. It carries too much context from its own choices, so it can overfit to the implementation it just produced, or miss an assumption it carried through from the first prompt. Use a different model family, clear the context fully, or run a separate review pass that starts from the research doc, the plan, and the diff. Ask what matches the plan, what drifted, and what was added that wasn't in scope. Then run the tests, whatever your codebase has. You can also write the tests first if you prefer. The order of implementation and testing isn't the point. Doing the research, proposals, and planning before the model touches production code is the point. None of this is clever on its own. The value is in the order and the gates between the steps, each one a place to catch a bad assumption while it's still cheap to fix. The slow-looking part is the part that saves you, because the alternative doesn't remove the cost, it moves it into code review, debugging, and production. Stop treating the model like a prompt box and start treating it like part of an engineering workflow. I wrote up the full framework, with the worked Conduit example and the exact flow I use, here: RePPIT post [https://news.mlops.community/e/c/eyJlIjoxNTY4NzAsImVtYWlsX2lkIjoiZXhhbXBsZSIsImhyZWYiOiJodHRwczovL2dvLm1sb3BzLmNvbW11bml0eS9NaWhhaWxfUmVQUElUX3Bvc3Q_dXRtX2NhbXBhaWduPVdlZWtseStOZXdzbGV0dGVyKy0rMjAyNi0wNi0wOSslMjhBTEwlMjkrLStNaWhhaWwrdGFrZW92ZXJcdTAwMjZ1dG1fY29udGVudD1XZWVrbHkrTmV3c2xldHRlcistKzIwMjYtMDYtMDkrJTI4QUxMJTI5K01paGFpbCtUYWtlb3Zlclx1MDAyNnV0bV9tZWRpdW09SVFRUkZpeFhlbEFrQWlBRUlRVktCaUlJXHUwMDI2dXRtX3NvdXJjZT1jdXN0b21lci5pbyIsInQiOjE3ODE4ODIxMjV9/0031ea777fb7939f4fc181a647f2d3877621a993bcf29c80bc904d4100eb6946]. Mihail Eric is Head of AI at Monaco and a lecturer at Stanford, where he created and teaches The Modern Software Developer [https://news.mlops.community/e/c/eyJlIjoxNTY4NzAsImVtYWlsX2lkIjoiZXhhbXBsZSIsImhyZWYiOiJodHRwczovL2dvLm1sb3BzLmNvbW11bml0eS9OTF9BSVJUMV9KdW4wMT91dG1fY2FtcGFpZ249V2Vla2x5K05ld3NsZXR0ZXIrLSsyMDI2LTA2LTA5KyUyOEFMTCUyOSstK01paGFpbCt0YWtlb3Zlclx1MDAyNnV0bV9jb250ZW50PVdlZWtseStOZXdzbGV0dGVyKy0rMjAyNi0wNi0wOSslMjhBTEwlMjkrTWloYWlsK1Rha2VvdmVyXHUwMDI2dXRtX21lZGl1bT1JUVFSRml4WGVsQWtBaUFFSVFWS0JpSUlcdTAwMjZ1dG1fc291cmNlPWN1c3RvbWVyLmlvIiwidCI6MTc4MTg4MjEyNX0/ff2b4ce9a3d6c12d0ac18af92527a8102f0b501a348dedd6166ae23ed875a981], the university's first course on AI software development. --- Source: https://aaif.live/newsletters/mlopscommunity/2026-06-23-resend-why-one-shot-ai-coding-breaks-on-real-codebases