Code Review at Scale and Enterprise Controls

A team can point many agents at one shared codebase while administrators decide which capabilities are available. The basic discipline from agent mode remains useful: limit the work and retain the evidence. What changes is the volume and the way mistakes travel.

Teams cannot inspect a growing stream of output with the same attention they give one local edit. A confident review can be wrong, a workflow can drift, and a dashboard figure can be mistaken for an outcome. This lesson applies evidence-first review to code comments, agentic workflows, organization controls, and model selection.

Trustworthy automated review across a team

Copilot code review can flag possible defects in changed code. Treat each comment as a lead for a human reviewer. Automated detection identifies a possible correctness, security, testing, or maintainability concern. A developer then checks the relevant contract and tries to reproduce the problem. Human approval still decides whether the complete change meets product, design, and operational requirements. When an automated review is clean, you know only that it reported nothing.

Classify a finding before deciding how urgent it is. Confirmed means code, tests, or a reproduction demonstrates the problem. Assumption-dependent means the finding relies on a contract you haven't established. Not applicable means the evidence contradicts it or another layer already owns the concern. Unverified means a named check remains outstanding. Severity comes afterward: Blocking, Important, Suggestion, or Unassigned while the evidence is incomplete. If a review says "negative subtotals aren't rejected, Blocking," first find out whether negative values can reach that function and where validation belongs.

At team scale, maintain one observable review baseline in .github/copilot-instructions.md. Name the risks to inspect, the evidence an actionable comment must carry, and the low-value feedback to omit. When tuning the instructions, hold the code constant so you can see what the instruction changed. Review output can vary between runs. Count whether the requested validation steps were followed, not how many comments appeared. The GH-300 study guide describes the same need to validate Copilot output.

Bound agentic workflows by output

An agentic workflow is an automation specification that hands an agent a goal, supplies context, sets boundaries, and defines the artifact it must produce. Unlike a fixed script, it lets the agent decide which actions are needed, which is exactly why the boundary has to be explicit. Write it as a Markdown contract with six parts: the trigger, the goal, the context it may use, the constraints it may not cross, how the output is validated, and the delivery it presents for review.

"Update the website" is not a contract. "Read these three named sources, change only docs/updates/navigation.md, map every claim to a source, omit any unstated date, and report validation in the pull request" is one: it names a deterministic output and a visible stopping point.

Two rules keep a workflow from drifting. First, name one exact permitted output and repeat it in the boundary, the delivery schema, and the review checklist, because "one documentation file" could be satisfied by the wrong file. Second, treat the pull request as a review boundary. A completed run or an opened PR is an artifact a human reviews. It's never automatic acceptance.

When you coordinate several agent roles (planner, designer, builder, validator, handoff), the design that matters is the handoff between them. Give each role a named input, a named output, a single ownership boundary, and a stop condition, and make the builder the sole owner of implementation. Then route failure deliberately. When the validator finds a defect, say, a dashboard summary claiming zero at-risk projects when the data has one, it reports the FAIL and returns it to the builder, who corrects only that requirement. The validator then reruns the complete checklist, and handoff begins only when no item is FAIL. The validator never repairs its own finding.

GitHub's gh aw extension packages this as an install-author-run workflow that proposes changes through pull requests. Where its exact commands aren't at hand, you can rehearse the same contract and review manually.

Organization governance is a control loop

Enterprise administration isn't a single switch. It's a control loop: define the intended state, apply policy, licensing, and integration controls, observe activity, compare observed against intended, and correct or roll back. Two facts make the loop legible. First, policy resolves top-down: enterprise sets the baseline, the organization configures its state, and the user experiences the result, so a user's effective behavior is never explained by one page alone. Second, a seat and a policy are different controls: a seat establishes entitlement (who is licensed), while policy establishes availability (which capabilities are on). An enterprise restriction can be exactly why an organization setting doesn't produce the expected result.

The place teams most often overclaim is metrics. Label every statement as a source value (copied from a dashboard), a calculation (derived from source values), or an interpretation (a conclusion that may need more evidence). Eighteen active users out of thirty assigned seats is 18 / 30 × 100 = 60% adoption for that scope and period, and that is all it is. It does not establish productivity, code quality, savings, or why anyone adopted. Aggregate metrics point you at a trend. An activity report or audit event investigates a specific case, and a matching audit event proves recorded activity occurred.

The same honesty applies to state: never report a proposed, view-only, or simulated change as applied. A content-exclusion rule that's configured isn't proven to work on every surface until you test each surface. And MCP governs the same way it did for one developer, now at organization scale: registry, server access, and allowlist enforcement are three separate checks, and a repository configuration is not an enterprise approval. Govern deliberately: record evidence and a rollback condition for every change, and keep live, simulated, and unverified states separate.

Model choice is a design decision

Briefly, yes. Treat it as a design decision grounded in evidence. The GPT-5.6 family offers three variants with different positioning: Sol for the highest reasoning ceiling over large, unfamiliar codebases, Terra as the balanced default for everyday interactive and agentic coding, and Luna as the lightweight, fast option for smaller, explicit tasks. That positioning offers a starting heuristic without guaranteeing correctness. Every model can be wrong, so your task classification picks the initial model while tests, repository evidence, and scope review decide whether the result is acceptable. Start with the least complex tier whose profile fits, and escalate only when the evidence says you need more reasoning.

Two cautions round it out. Auto is automatic per-task routing that honors administrator policy. Record it as "Auto," never as an inferred underlying model, and if you need a reproducible benchmark, pin a named fixed model to remove routing variation. BYOK (bring your own key, for Copilot Business and Enterprise) connects Copilot to an approved provider (OpenRouter, Microsoft Foundry, Google, Anthropic, OpenAI, or Ollama among them) using a key your organization controls. Verify a BYOK setup from the provider and model the picker shows. A model telling you "I am provider X" is not routing proof. The key is a credential: it never belongs in a prompt, a source file, or a committed transcript.