DEV Community

Abdul Moiz Qazi
Abdul Moiz Qazi

Posted on

How do you stop AI coding assistants from wrecking your architecture once you've got 100+ engineers on it?

Every engineer on a team is probably already using some AI coding assistant. Claude Code, Cursor, Copilot, Codex, whatever they've picked. Individually, they're all fine. This isn't a "AI writes bad code" post.

The problem shows up once you scale past a handful of engineers working on the same codebase.

The part nobody's really solved

Most teams handle architecture conventions the same way: a CLAUDE.md or AGENTS.md file with the rules written out. Layer boundaries, naming conventions, what's allowed to depend on what.

The problem is that file is just an instruction. The model can follow it, or it can drift from it under a long session, a vague prompt, or just enough context pressure that the instructions get deprioritized. There's no independent check happening after the model generates something and before it lands in your codebase. You're trusting that the model read the file and decided to comply, every single time, for every engineer, regardless of how well they prompted it.

At small scale, code review catches this. One or two senior engineers can eyeball every PR and catch a boundary violation. Past a certain team size, that stops being realistic. Review becomes a rubber stamp, or a bottleneck, and architecture drift becomes something you find out about during a postmortem instead of before merge.

The other part: cost

Related but separate problem. If you've got 100+ engineers each running their own AI coding sessions against the same repo, a lot of what gets sent to the model is redundant. Same architecture context, same conventions, same files being explained over and over to different sessions that have no shared memory of each other.

Prompt caching helps if you're disciplined about keeping your prompt prefix identical across calls (worth its own post honestly, most teams leak this discount without realizing it by having non-deterministic content in what should be a stable prefix). But caching only covers the exact-match part. The actual per-engineer, per-task context still adds up fast at that scale.

What I'm working on

I'm building something called Arclask around exactly these two problems. A layer that sits alongside whatever AI coding tool your team already uses:

  • Every AI-generated change gets checked against your actual architecture rules before it's allowed to merge, independent of what the prompt said or how the session went
  • Leads get visibility into what's being overridden and why, instead of flying blind on whether policy is actually holding
  • The team shares context instead of every engineer's session starting from zero, which cuts a real chunk of the redundant token cost

Still early, no polished product, just a landing page while I validate this against real teams.

Landing page here if you want to take a look or sign up: arclask-landing-page

Genuinely asking

If you're on a team past the point where one or two people can review everything by hand, is this something you've actually run into? Or does normal code review handle it fine at your scale and I'm overthinking a problem that isn't real for most people?

Would rather hear "this doesn't matter, here's why" than have people just agree with me.

Top comments (0)