In our latest developer survey, code review friction jumped from the middle of the pack to near the top of team concerns. Too many pull requests were conversations that should have happened in design review or asking for corrections for things people didn’t know were wrong. Design intent and standards were clear to some, invisible to others.

Meanwhile…the pressure to adopt AI was already everywhere. But “use AI” isn’t a strategy. It’s a solution looking for a problem. We had a problem and we wanted to find out if this was a solution with value.

We grounded our AI tooling in existing design documentation: DDD principles, architectural patterns for our modular monolith, and concrete code examples. This created a feedback loop. Custom instructions generated enforceable standards. PR analysis surfaced friction. Friction revealed documentation gaps. Better documentation meant better instructions. Eventually, more issues were caught before pull requests.

The result wasn’t replacing human judgment. It was being able to quickly encode the judgment we’d already made and amplifying it across the organization.

Topics covered:
* How to connect AI tooling to existing design intent rather than generating code in a vacuum
* A practical feedback loop for improving documentation, standards, and AI instructions together
* Where AI helps maintain bounded contexts

The job isn’t writing code. It’s solving problems that deliver outcomes. AI should serve that purpose, not the other way around.