The volume of code multiplied

When I say AI in this post, I mean the current wave: LLMs, agents, coding assistants.

Every week more code and more features ship to production. The hours I have to review all that are the same as always.

Before, my time went into writing. Now it goes into reviewing.

What can go wrong?

On critical work you have to be careful:

• It makes things up. It pulls out something that doesn't exist.
• It adds things nobody asked for. Layers and dependencies somebody has to maintain later.
• It fails in the middle of an important feature, and leaves the work half done.
• It solves your problem as if you were a different company. An architecture built for a scale you don't have.
• It gets things wrong more often when you leave it alone. With no context on how the project works, it decides on its own and lands it less often.
• Some days it performs worse. Same model, same task, and the result isn't the same. There isn't always an explanation.
• The service goes down. And it catches you in the middle of something.

My loop

1. Define the tasks well.

2. Make sure they come out as good as they can, leaning on the tools the project already has in place and on skills that say what to do and how. Handing it everything and letting it run loose is tempting, and sometimes it brings problems.

   New tables. Whole flows nobody uses. Then you have to delete them.

3. Deploy fast.

4. Check periodically that everything still works. Part automated, part by hand.

   Sitting down, opening it and seeing whether the thing makes sense. Not only whether it passes the tests, whether it makes sense. The work here is shared, and it takes iterating to find what gets delegated and what gets done by hand.

The fourth point is what holds up everything else. And there is one rule: the loop has to give you value, not blockers. That's why validation is periodic and not a gate that stops you before every single thing.

What I validate with

This is what I use today.

• End to end tests, one per complete flow, running periodically in production. For me they're the most important ones today. They don't tell you whether a piece works, they tell you whether the whole path still works, which is what people actually use.
• Unit and integration tests, which today have to be better than ever. With this much generated code, they're the ones that warn you when something new broke something old.
• A model reviewing every PR in a loop, against skills I already have defined. The simple stuff it approves on its own. On critical work it gets stricter and validates deeply. I don't want it giving nice opinions, I want it checking specific things.
• A model reviewing quality on its own, every so often, which instead of leaving scattered comments creates tickets for what's critical. That way the finding lands in the real work and doesn't get lost.

• Integrations over MCP so everything goes through one place. The model reaches the repo, the database, the browser and the tickets without me jumping from tool to tool. That's what makes the loop one thing instead of five loose pieces.

  Careful with permissions and with what you let it do. Giving it access to everything also gives it what it needs to delete things in production. That one deserves its own post.

• On the frontend, letting the model navigate the interface itself. With Chrome DevTools MCP, the official one from the Chrome team, the model opens the page, clicks around, looks at the console and tells you whether the thing came out right. Reading the code and looking at the result are two different things.

• Skills to organize the work. Addy Osmani's agent-skills come with the cycle already built (plan, build, test, review, simplify) and different review profiles (code, security, performance). And superpowers for planning and for picking up where you left off.
• The review and security skills that already come included, /code-review and /security-review. Plus your own, which are worth it because they're the ones that know how your project works.
• CodeRabbit as an extra layer on the PR. Another set of eyes, and it doesn't find the same things the others do. It helps a lot.

The same setup all week

I try to keep the same version, the same effort and the same mode for a whole session, or a whole week. That way I avoid the model seeing things differently every little while and shifting my judgment halfway through.

It goes against what usually gets recommended, which is picking the best model for each task and moving the effort around based on what you're doing. I'm not much for following rules, so I tried it the other way around. And it has worked better for me.

Before playing with settings I'd rather optimize something else: managing tokens well. Documents with the plan written down, so I don't have to think through the same thing every time. And tools like graphify so it doesn't have to re-read the whole project on every question.

If I do have to vary it, roughly like this:

• Reasoning mode for planning. That's where it shows the most.
• High or very high effort for bugs. A hard bug pays for itself.
• Less advanced models for documentation. No need for heavy artillery there.

First the written plan and saving tokens. Then the settings.

Sharpen the saw

A woodcutter spends hours cutting down a tree with a dull saw. Someone asks why not stop and sharpen it:

I don't have time, I'm too busy cutting.

From the seventh habit of The 7 Habits of Highly Effective People, by Stephen Covey.

It's worth spending a little time getting each project polished with its tools and its way of working, so the model already knows how everything runs there and doesn't have to improvise. Each project with its own way, written down, and always the same one.

It costs you a while up front. After that everything comes out faster, and above all it comes out closer to what you wanted.

In the end

The model generates. What to review, and how far, you decide.

I still have the doubt of whether this is the best way. I feel like something is missing, that it isn't quite there yet. Maybe it never gets there, and what's left is to keep iterating.

And questions remain for the next one:

If the same model performs differently from one day to the next, and each new version sees things the previous one let through:

• What do you do with all the code and documentation that already shipped?
• Do you send it back for review with the new model?
• And what if that review hands you findings that don't make sense?
• Do you rewrite it?
• How do you know whether it really came out better?