What gets reviewed, and how
Output went up and confidence went down
Review has to change when most of the diff was not typed by a person. What a reviewer checks first, what they can skip, and what nobody is allowed to wave through.
AI coding standards
Teams are shipping more code than they can review and inheriting decisions nobody made on purpose. The bottleneck moved. It is no longer typing, it is knowing what should exist and who is accountable for it.
I help engineering teams keep that part human: the conventions, the boundaries, and a review process built for code a person did not write.
Assessment and first conventions in 1 to 2 weeks. Fixed price, agreed before the work starts.
None of this is about prompting. It is the engineering practice around a team that now produces code faster than it can agree on it.
Output went up and confidence went down
Review has to change when most of the diff was not typed by a person. What a reviewer checks first, what they can skip, and what nobody is allowed to wave through.
The same problem now has four different solutions in the codebase
Models copy whatever is nearby. Written conventions and a clear owner for each behaviour keep generated code converging instead of branching.
Nobody is sure which parts are safe to let a model touch
Which parts of the system a tool can work in freely, which need a human first, and which need a second pair of eyes regardless of who wrote it.
Tests pass and you still do not trust the change
The narrow checks that actually prove a change is safe, and where a green suite is telling you less than it appears to.
Half the team is fluent, half are guessing
Working sessions on your own codebase rather than generic training. What to delegate, what to specify, and when to stop and write it yourself.
I look at how the team works now, agree what good should look like here, and then work alongside people until it is the normal way.
People. The tools are good and getting better on their own. What does not arrive with them is the judgement about what should exist, where the boundaries sit, and what a reviewer is responsible for. That is the part I work on.
Adoption is usually the easy half. The harder half is that generated code arrives faster than a team can agree on what good looks like, so the codebase starts holding several answers to the same question. The work is agreeing on one and making it the path of least resistance.
No. I build with these tools daily and I am not interested in arguing anyone out of them. The goal is more output that you actually trust, which usually means changing review and conventions rather than changing usage.
I wrote the AI coding guidelines for a regulated healthcare team and trained the developers on Codex, Gemini, and Claude while keeping code review, testing, and engineering ownership human. I also run a full product build this way now, across web, iOS, and backend.
An assessment and a first set of conventions fits in one to two weeks. Getting a team to actually work that way takes longer, and is better done in sessions across a few weeks than in a single workshop nobody remembers.
A fixed price, scoped on the first call once I know the size of the team and the shape of the codebase. No hourly meter.
Yes, across North American hours, from Toronto. Sessions work well remotely because we are looking at a screen either way.
Someone still has to decide what belongs in the product, where the boundaries sit, and whether a change is safe to ship. If the more pressing problem is that the frontend itself has become hard to change, start with the audit instead.