# Don't look at unreviewed code > Prompts became loops, and the loop's most valuable step is the one most people skip: a review by a model from a different family, wired into the prompt itself, so findings get addressed before a human ever opens the diff. - Author: Jonas Rohde (@edhor) - Published: 2026-07-25 - Canonical: https://edhor.me/blog/dont-look-at-unreviewed-code/ - Tags: ai-agents, agentic-coding, code-review, loops, developer-workflow You maybe heard about that "prompts are dead, use loops", "loops are dead" etc. Things really evolve daily, or it seems to. Yes, it really makes sense to adapt how you work and how you use these tools, but don't get distracted by these things. You need to figure out what works best for you, what feels right and how you get the best results for you and the team. So instead of arguing about the naming… here are the three things I would actually defend: - don't look at unreviewed code - code → review → code (you can call that a loop) - use an external / different model family for review The rest of this post is why. ## TL;DR - You should be the _last_ reviewer, not the first one - One pass is not a loop → the value sits in the second iteration - Review with a different model family, always with its most intelligent model - Put the review into the prompt as a final step, so it also addresses the findings directly - What you review changes → intent and architecture, not typos ## Why you shouldn't be the first reader The workflow most people fall into is: prompt, wait, read the diff. That's the old habit (code appears, a human looks at it) and it wastes the cheapest reviewer you have. If you are reading code that no model reviewed yet, two things are true at the same time. You are doing work that could have happened before you even came, and you are doing it on a worse draft than the one you could have had. Every finding you catch by hand is a finding a review pass would have caught _and fixed_ while you were doing something else. And there is a second cost which is maybe even worse. Reading raw agent output pulls you down to the level of typos, missing null checks and style nits… which is exactly the level where you feel productive and contribute the least. You are the one with the context nobody else has: is this even the right thing to build? Spending that on mechanical review is the real waste. ## One pass is not a loop "Code → review → code" looks trivial written down, but the shape I see most of the time is code → review → _human reads the review_. That's not a loop, that's a report. The value sits in the second iteration. A review that produces findings nobody acts on cost you tokens and produced a document. A review whose findings go straight back to the agent that wrote the code produces a better artifact. And it's fast, because that agent still has the full context of why it did what it did. This is also where the tempting mistake is: making the loop longer instead of tighter. Three review passes on a bad plan is still a bad plan. The loop fixes execution quality, not direction. ## The key move: a different model family This is the one I would push the hardest, and it's the cheapest change on the list. Let your code be reviewed by an external agent or subagent from a different model family, and always use the most intelligent model of it. If one family wrote it, another family reviews it. The reason is blind spots. A model is the least likely to catch exactly the failure modes it is prone to itself: same training, same habits, same confident wrong turns. Ask a model to review its own output and you get a competent sounding pass that systematically misses the category of mistake it just made. Ask a different family and the disagreements get interesting immediately, because they come from a different idea of what good code even looks like. And use the strong model here, not the cheap one. Review is judgment work → it's the wrong place to save money, and it's where a more capable model pays for itself the most directly. ## Put it into the prompt The mechanical part that makes this actually stick: integrate that in your prompt directly as a final step, so it's also addressing possible findings, even before you look at the code the first time. Not as a separate command you remember to run afterwards. As part of the task itself. The point is not automation for the sake of it. The point is that no human decision should sit between "code written" and "code reviewed"… because that's exactly the decision that gets skipped when you're busy, which is when you need it the most. ## What kind of review "Review this code" is a weak prompt and the reviews you get back show it. What works much better for me is steering the review to one specific lens at a time. Three that earn their place: - **a rigor pass for quality and maintainability** → the `thermo-nuclear-code-review` skill is a very sophisticated steering for exactly that, I really like it - **a simplification pass** → a completely different concern from correctness, and generic review prompts nearly never surface it on their own. `ponytail` is a super nice one and also includes hooks if you want to integrate it even further - **a bug hunt before CI** → if you have a review bot in your pipeline: running the same kind of check locally means you find things inside the loop instead of waiting for a pipeline round-trip Take those as examples for the _categories_, not as a shopping list. The tools will change. The useful part is that separate lenses give you better findings than one review prompt that has to do everything at once. ## What's left for you None of this takes you out of the process. It moves you. You stop reviewing on the level of "this should be a const" and start reviewing on the level of "this solves the wrong problem", "this shouldn't be a new abstraction", "this contradicts a decision we made for a reason". That's the review only you can do. It also changes what review structurally _is_: continuous, inside the loop, happening while the work happens. Instead of a handoff at the end to a colleague who has to context-switch into a 40 file diff. I think that shift takes the whole pull request ceremony with it eventually, but [that's a separate argument](/blog/we-need-to-get-over-git/). For now, just don't be the first one to read it.