When we adopted Cursor and Claude on the team, the question was never whether AI could write code — we already knew it could. The real question was different: how do we stop a team that produces twice the code from producing twice the bugs?
After months working this way in a monorepo with thousands of commits — where a meaningful share of the code goes through AI-assisted workflows — here is what worked, what failed, and what I would do differently from day one.
AI doesn't replace judgment, it demands it
The first mistake we made was treating AI like just another junior developer: hand it a task and trust the result. The code compiled, the tests passed… and it still broke project conventions that were written down nowhere, because they lived in the team's heads.
The fix was to invert the flow: before generating code, we generate context. We documented the implicit conventions — how we name services, where shared types live, which error patterns we use — in files the tools read every session. AI is only as good as the context you give it.
💡 Team rule: if a pattern gets corrected twice in code review, it gets documented for the AI. The third time shouldn't exist.
What we automated (and what we didn't)
Not all work benefits equally. Our split ended up like this:
- We automate: module scaffolding, edge-case unit tests, repetitive migrations, mechanical cross-package refactors, and the first version of any CRUD.
- We assist: API design, business logic and complex queries — AI proposes, the human decides.
- We never delegate: architecture decisions, security, permissions and anything touching money or personal data.
Code review changed shape
Reviewing AI-generated code is not like reviewing human code. AI code looks good — it's formatted, sensibly named and commented. The danger is in what looks correct. So we shifted the focus of review: less style, more behavior.
// Review checklist for AI-assisted code
// 1. Are the edge cases real or invented?
// 2. Does it reuse what exists or duplicate a helper?
// 3. Does error handling follow our pattern?
// 4. Are there tests that fail if behavior changes?
// 5. Did it touch anything outside the ticket's scope?
Point 5 turned out to be the most important: AI tools tend to "improve" neighboring code nobody asked them to touch. A clean, scoped diff is worth more than a brilliant, sprawling one.
What I'd do differently today
I'd start with context documentation from day one, not after the first incident. And I'd set one simple metric that is, in the end, the only one that matters: not how much code the team generates, but how much code survives six months in production without being rewritten.
AI made us faster, yes. But the real change was something else: it forced us to make explicit all the knowledge that used to be tribal. And that would have been worth it even without the speed.
