# When the Agents Write the Code, the Human Checks Themselves [1/2]

First, a distinction. Vibe coding means “you describe things on the fly, the AI builds, you keep whatever sounds right”. Fast, creative, risky, and in serious codebases usually not production-ready. Agentic development means something else: an orchestrated setup of several subagents, each with a clear mandate, running against a repository base with good E2E test coverage, and a human who holds the strategic layer. Both keep getting lumped together. Skeptics see vibe output and judge the method by it. Cheerleaders celebrate vibe output and call it engineering. Both miss the point.

In my setup, three models run side by side, each with a clear job. A large reasoning model for what truly needs depth: architecture proposals, larger refactorings, hard-to-pin-down bugs. A mid-sized model for everyday implementation. A small, fast model for everything that is really routine: formatting, code comments, research summaries, documentation updates.

Why three and not one? Because several effects show up at once. Quality, because the right model for a given task noticeably improves the result. The large model delivers the depth an architecture proposal or a difficult bug needs. The small one stays with routine and does not try to turn a two-line doc fix into an architecture debate. Speed, because the small model answers in seconds where the large one takes minutes; when the bulk of your requests stay small, your day is noticeably faster. Cost, because the price difference per token is an order of magnitude or more; generating every code comment at the price of an architecture query makes no economic sense. And the climate footprint, because larger models really do need more compute, more energy, and more water for cooling. A peer-reviewed study by Luccioni and colleagues from 2024 compares the energy use of model inference across 88 models and 30 datasets and finds differences of several orders of magnitude between small and large models for the same task [2]. Anyone who does not differentiate here drives up the energy use of their setup for no reason.

Which model exactly takes which task is a matter of taste and changes with every new release. What stays is the separation. Refactorings cost almost nothing in this world, because an agent does them in twenty minutes, verifies them against the E2E suite, and delivers a diff that I read. The old rule of thumb “make the change easy, then make the easy change” [1] becomes economically viable. And I keep two axes explicitly with the human: the planning beforehand and the gut check afterward. What gets built, I decide. Whether it feels right, I decide. The rest I do not do.

Anyone who takes this setup seriously notices quickly: the work does not disappear, it moves. Away from typing, toward judging. In the same amount of time, the agents produce a multiple of the material that used to appear. Every line of it wants to be evaluated. That is exactly the skill good testers and experienced reviewers have always had: holding context, assessing quality, weighing risk. It does not disappear in an agentic world. It becomes more central.

This is where the interesting part begins. Because this setup only works over the long run once you know the price it demands of the human. Where two hours used to hold maybe eight conscious decisions, it now feels like forty. Typing was never the exhausting part. Judging is.

That price, the three cognitive bottlenecks behind it, and the concrete guardrails against them are the subject of Part 2.