The tools turn over every few months. Which model leads, which editor, which protocol. It changes faster than anyone can write it down, and most of what gets written about it is stale before it's read.
The shape of the work doesn't change. This is the part I'd still be doing if every tool on my desk were replaced tomorrow.
Bad output is almost never a reasoning failure. It's a context failure. Something was asked to build into a system it had never looked at, so it guessed, and it guesses fluently, which is exactly what makes it expensive. Confident, plausible, and wrong is harder to catch than obviously broken.
So nothing starts with building. Work starts with reading: what already exists here, what pattern this system already follows, what was decided before and for what reason. The answer is usually already in the codebase. The job is to go find it instead of inventing a second way to do the same thing.
Every hour skipped here comes back as a week of untangling.
Most teams keep their standards in people's heads and let them out during review. That works when the reviewer has been there three years. It fails completely against something that has no memory of yesterday and starts every session from zero.
So the standards get written down: explicit, checkable, and living with the project. How this system names things. What it never does. Which arguments are already settled and aren't reopened on every task.
This is the part that compounds. A correction I make once becomes a rule I never make again, here or on the next project. A codebase that's been run this way for six months produces visibly better work than one that started last week, with no change at all to the underlying tools.
One generalist asked to do everything does all of it at roughly the same middling quality. Split the same work into narrow roles and each one gets sharper, because each has a single thing to be good at and a single thing it's judged on.
That third role is the one that carries the weight, and only because it didn't do the work. Anything reviewing its own output approves it nearly every time. That's as true of people as it is of this, and it's the whole reason a review step is worth anything.
Work moves through gates. The mechanical checks run first and fail loudly. Then review by something that didn't produce it. Failures go straight back to be fixed and the loop runs again, without me watching it. Only work that has already passed all of that reaches me, and then I'm the one who says yes.
Standards run automatically on every piece of work. What fails goes back to be fixed and re-checked. I don't spend my attention on things a machine can catch.
Review is done by a role that didn't do the work, against criteria written down in advance rather than taste applied after the fact.
Nothing ships, sends, or goes live on its own. That's a real decision made on work I can actually see, not a rubber stamp on a summary.
What changed, what got skipped, what it wasn't sure about. Work I can't inspect is work I can't approve, and I don't approve it.
Nothing above names a product, and that's deliberate. I've rebuilt my own setup several times in the last two years as tools appeared, won, and got replaced. The pieces I use now have almost nothing in common with the pieces I started with.
The shape survived every one of those rewrites. Understand first. Write the rules down. Split the work into narrow roles. Check it before a human sees it. Keep the human deciding. I've yet to see a change in tooling that made any of those less true. Mostly they just make them cheaper to do.
Which is why I don't spend much time on which model is ahead this month. It's the least durable question in the room. A team with a good shape and last year's tools will out-build a team with this week's tools and no shape at all.