{"slug": "how-to-govern-ai-coding-agents-across-development-teams", "title": "How to Govern AI Coding Agents Across Development Teams", "summary": "SapientPro, a software house whose CTO Max Tatarenko wrote the account, now commits a per-repository instruction file alongside client code and routes four change categories — authentication and permissions, schema migrations and production-data writes, new dependencies, and modules under regulatory constraint — to mandatory human review rather than automated merge. The agency also approves MCP servers with write access to client systems the way it approves a package, requiring the client's written sign-off. The rules were introduced after reviewers flagged syntactically valid but architecturally foreign code produced when developers carried agent configuration across client projects.", "body_md": "# How to Govern AI Coding Agents Across Development Teams\n\n*By Max Tatarenko, CTO at SapientPro*\n\nA software house finds out faster than most companies whether its rules for AI coding agents hold up. We run parallel teams across client codebases that share almost nothing, and the client owns every line at the end of an engagement. An agent that writes something careless inside one repository puts a contract at risk.\n\nGoverning AI coding agents across development teams turned operational for our engineers at SapientPro the first time a client asked who had written a particular module. This article covers where our rules live now and which changes still stop for a human decision. It also covers how we judge whether a codebase we hand back will survive two more years of edits by somebody who never met us.\n\nWhat follows is what our reviewers argue about on a Tuesday.\n\n## **Why an agency hits this problem before a product company does**\n\nA product team governs one codebase. The conventions belong to them, the CI configuration belongs to them, and a bad habit spreads inside a boundary they control.\n\nOur situation inverts that. A developer might spend Monday inside a Symfony rebuild for a booking marketplace and Tuesday inside a Node service for a logistics company. The architectural rules differ. The security posture differs. The client’s appetite for a new dependency differs, sometimes sharply. Agent configuration travels with the developer unless somebody stops it. An instruction file that produced idiomatic output on one project will produce confident nonsense on the next, because the agent has been told to prefer patterns the second codebase does not use.\n\nThat gap surfaced in review comments long before it surfaced in any metric. Reviewers began flagging code that was syntactically fine and architecturally foreign. The author had done nothing wrong except carry their own setup across a project boundary.\n\n## **Agent rules belong in the repository**\n\nOur first correction was moving agent instructions out of internal documentation and into the projects themselves. Every client repository carries its own instruction file, committed alongside the code and reviewed like any other change.\n\nThe file describes the architecture boundaries a change may not cross, and it names the libraries already present so an agent reaches for what exists before it adds anything. It also states the test expectations for whichever module is being touched.\n\nTreating that file as source code has a practical payoff. It has an owner and a history. When agent output degrades on a project, somebody opens the file history and finds the commit responsible. A developer joining the project inherits its rules on the first pull.\n\nThe same reasoning extends to whatever the agent can reach. An MCP server granting an agent access to a client’s staging database is a dependency with production consequences, and we approve it the way we approve a package. Anything carrying write access to a client system needs that client’s sign-off in writing.\n\n## **What still stops for a person**\n\nGates differ according to what the change touches. Four categories never merge on automation alone, regardless of how confident the diff looks.\n\n- **Authentication and permissions.** A reviewer with real context on the client’s access model has to approve the change.\n- **Schema migrations and anything writing to production data.** The developer demonstrates the rollback before the merge, in front of somebody else.\n- **New dependencies.** We check the license and the maintenance record against what the client already carries, because an agent will happily add a package to save itself forty lines.\n- **Modules under regulatory constraint.** The client’s compliance contact reviews alongside our engineer.\n\nEverything outside those four runs through automated gates first. Static analysis and secrets scanning happen before a human opens the diff, which leaves reviewer attention free for the design questions.\n\nWe approve an agent’s work on one condition. The reviewer has to understand the change well enough to modify it a year later without rereading the whole module. When they cannot, the diff goes back regardless of green checks. That rule costs us time in the short run, and it is the single reason our handovers still work.\n\nWhat that condition protects is architectural judgment. On one shopping assistant, our engineer moved vector storage out of a dedicated vector database into Postgres with pgvector because filtering and aggregation belonged next to the relational data. Nothing in the ticket asked for it. An agent solves the problem placed in front of it and leaves the surrounding architecture where it found it, which is reasonable behavior and also how a codebase accumulates decisions nobody made on purpose.\n\n## **Reviewing code that nobody typed**\n\nThe failure mode we meet most often involves code that works. An agent produces something that compiles and passes the suite, yet answers a slightly different question than the ticket asked. We have watched an agent add a second HTTP client to a project that already had one. Another reimplemented a helper living three directories away.\n\nHuman review catches this at low volume. Volume is precisely what changed. A reviewer reading forty lines a day reads them properly, and the same reviewer facing nine hundred lines of plausible code starts approving on impression.\n\nThe checks we depend on now run at the repository level. Duplication detection across a codebase catches the second HTTP client. Trend lines on complexity and coverage catch the drift that any single review would miss. A pull request is simply too small a frame. It looks healthy in isolation even as the code around it degrades.\n\nOur teams run small, which sharpens the problem. A recruitment automation platform we delivered took two developers and a project manager. A shopping assistant answering product queries in under a second took one person and 180 hours. Teams that size hold no review depth in reserve. One reviewer distracted for a week is the entire quality process on that project, and an agent working at full speed alongside them will produce more code in that week than the previous month.\n\n## **Generated tests are the quiet problem**\n\nAsk an agent to add test coverage, and it will do exactly that. The coverage number rises. The tests assert whatever the code currently does, including the bug.\n\nThis one took us a while to name, because every dashboard said things had improved. Coverage percentage stopped being enough on its own around the point where agents began writing most of the tests. As a map of which code no test touches, it still earns its place. What it leaves open is whether the tests covering the rest would catch a bug. We now check that directly, by breaking the behavior a test claims to protect and watching whether the test notices, which is slower to run and considerably harder to fake.\n\nOn critical paths, our rule is that a person writes the assertion and an agent may write the scaffolding around it. Reversing that order produces suites nobody trusts and nobody deletes.\n\n## **Agents inherit the security problems you already have** \n\nAgents rarely invent an exotic vulnerability. They copy what is already in the repository. Point one at a codebase containing a hand-rolled query builder, and it will produce three more functions in the same style, each carrying the same injection surface, each looking consistent with its neighbors. Consistency is exactly what makes the result hard to spot in review.\n\nA second pair of patterns costs us real time. Agents reach for permissions wider than the task requires, particularly when an MCP server exposes a whole database where a single table would do. And context windows get filled with configuration files that carry credentials, which then travel to wherever that provider logs requests. We treat any credential an agent has seen as one requiring rotation, on the grounds that assuming otherwise gives us nothing we can defend to a client.\n\nStatic analysis handles the first pattern reliably enough once it runs across an entire repository. The other two are governance questions about what the agent may reach, settled before anybody writes code.\n\n## **Clients move faster than their own review process**\n\nMost of the companies we work with are [__adopting AI technology__](https://sapient.pro/ai-development-services) at a pace their engineering process was never designed to absorb. The tooling arrives in a week. The review culture takes a year.\n\nWe get called in after that gap opens. A team of twelve has released eight months of agent-assisted work; nobody can say which parts were generated, and the CTO has an investor asking about code provenance.\n\nOur answer is usually an inventory. Which repositories carry agent instruction files? Who approved the MCP servers currently connected? What share of merged pull requests carries a substantive review comment?\n\nTeams are routinely surprised by that last number.\n\nAssembling that picture by hand works once. Keeping it current across dozens of repositories is where teams start looking for tooling that maintains the inventory for them.\n\n## **Maintainability is the part that arrives late**\n\nQuality problems in agent-written code surface late. They wait for the moment somebody else has to change the code, which in our work is often a clien’s internal team eighteen months after handover.\n\nTwo measurements predict that pain better than anything else we track. The first is duplication, because generated code repeats itself in places a person would have refactored on the second occurrence. The second is coupling between modules that have no business knowing about each other, which happens when an agent has read the entire repository and connected things nobody intended to connect.\n\nWe report both to clients as trend lines across quarters. A single bad number invites an argument about methodology. A line moving the wrong way for three months invites a decision.\n\n## **Where to start**\n\nAn engineering leader setting this up across several teams gets most of the value from six moves.\n\n1. Put agent instructions in every repository and review changes to them like code.\n2. Decide which change categories require a named human approver, then write that list somewhere the team actually reads.\n3. Automate the mechanical pass on every pull request. Static analysis and credential detection should finish their work before a reviewer arrives.\n4. Treat MCP servers and agent tool access as dependencies with an approval process attached.\n5. Move duplication and coupling checks up from the pull request to the repository, where they can see across an entire codebase.\n6. Track the share of merged agent-assisted pull requests that received substantive human review and watch that line move across quarters.\n\nNone of this slows an agent down much. It changes what happens around the agent.\n\nThe teams handling this well share two habits. Their rules live where the work happens, and their reviewers can still explain what they approved.\n\n*Max Tatarenko is CTO at SapientPro, a custom software development company, with 14 years of experience in solution architecture.*", "url": "https://wpnews.pro/news/how-to-govern-ai-coding-agents-across-development-teams", "canonical_source": "https://blog.codacy.com/how-to-govern-ai-coding-agents-across-development-teams", "published_at": "2026-10-02 12:18:58+00:00", "updated_at": "2026-10-02 12:36:44.477814+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "agent-protocols", "developer-tools"], "entities": ["SapientPro", "Max Tatarenko", "Symfony", "Node", "MCP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-govern-ai-coding-agents-across-development-teams", "markdown": "https://wpnews.pro/news/how-to-govern-ai-coding-agents-across-development-teams.md", "text": "https://wpnews.pro/news/how-to-govern-ai-coding-agents-across-development-teams.txt", "jsonld": "https://wpnews.pro/news/how-to-govern-ai-coding-agents-across-development-teams.jsonld"}}