AI Architect: Why The Best Engineers Are Solving Code Review Bottlenecks

In plain English

AI now writes code far faster than people can check it, so code review (a person reading each change before it goes live) has become the slow step. Florian argues the answer is not more reviewers but better surroundings for the AI.

He builds automatic checks that run the moment the AI finishes and tell it, in plain words, what it did wrong, so it fixes the problem before a person ever looks.

In his experience the “harness”, the software that wraps the AI model and gives it tools and instructions, matters more than which model you pick. People still decide what to build and how the parts fit together.

Three ideas worth keeping

• Every time you catch the AI doing something you dislike, turn it into a rule a tool can check, so you never have to say it twice.
• Semgrep, a tool that scans code for patterns you’ve banned, lets you write your own house rules, and “architecture tests” stop parts of the system talking to each other in ways they shouldn’t.
• Ask the AI to read back through your past sessions and list what you kept correcting, then turn each item into an automatic check.

What it means for your business

If your team uses AI to write software, ask how its work gets checked, not just how fast it is written. Faster code with the same handful of senior reviewers simply moves the queue and burns those people out.

Budget time for the checks and the up-front design work, and expect the tools to keep changing, so avoid locking everyone into a single product for years.

What it means for software teams

Start small: a formatter, a linter and a few custom rules for the mistakes you see most. Run them as a “stop hook” (a script that fires when the agent says it’s done) so feedback arrives on the laptop, not hours later in a pull request.

Keep modules small with clear boundaries, and enforce those boundaries with fast architecture tests.

What we found, and what we did

We learnt the same lesson: a rule written in the docs did not stop our agents, and the agent that wrote one rule broke it itself, so we made the tooling refuse instead.

We also go back through past agent sessions after bad weeks and turn the failure patterns into fixes, written pipeline rules and guidelines for our AI reviewer.

Where we differ from “no code reviews at all” is that low-risk changes that pass every check now merge on their own, about 91% of the roughly 45 changes we merge a day, while anything hard to undo still waits for one person.

We also keep the AI reviewer advisory, because in our own blind test the best setup caught only 4 of 11 known defects; the full story is in Our Journey to Automated Code Review and Stop Measuring AI by Test-Pass Rate.

Worth watching

• 06:52: why the harness matters more than the model, and his test-first experiment.
• 11:38: using Semgrep to ban a coding habit that makes later debugging painful.
• 36:16: mining your own session logs for repeated corrections and turning them into checks.