Agentic engineering for teams: What changes when every engineer runs agents

Key takeaways

• Agentic engineering is building software with coding agents that write, run and revise code while engineers define the work and verify the result. At team scale, the hard part moves from writing code to deciding who reads it, what proves it works and who answers for it after merge.
• Review breaks first. In Faros AI's 2025 telemetry across more than 10,000 developers, teams with high AI adoption merged 98% more pull requests while review time rose 91%.
• Put the team's agent context in one checked-in instruction file, AGENTS.md or CLAUDE.md, and put the rules that must hold in hooks, CI and branch protection, where an agent can't skip them.
• Whoever merges the code owns it. An agent-opened pull request needs an approver other than the engineer who asked for it, a rule GitHub already enforces for its Copilot coding agent.
• Plan in review and verification hours, and make the tech lead the owner of the instruction file, the review policy and the map of where agents can run freely.

Why this question matters

Most of your engineers already use AI tools, and some of them run agents that open pull requests on their own. The Stack Overflow 2025 Developer Survey found 84% of developers using or planning to use AI tools and about 31% using agents at work, yet only about 17% agreed agents had improved collaboration within their team, the lowest score of any impact it asked about. The gap is between individual workflows and a team practice, and it shows up as a review queue nobody planned for, rules that live in one person's prompt history, and code nobody on the team can explain. This guide is about closing it: what to standardize, who owns each piece and what changes in planning. If your question is who to hire for this kind of team, hiring for agent-enabled teams covers the profiles and the interview.

The frame: Five decisions agentic engineering moves from the engineer to the team

One engineer working with an agent settles five things privately, usually without noticing: what the agent knows, what it's asked to do, who reads its output, what proves the output works, and who answers for it later. On a team, each of those has to become an artifact everyone can see and change. The table maps the move. Everything after it works through one row.

Agentic coding vs agentic engineering: What's the difference?

Agentic coding is the activity: an agent such as Claude Code, OpenAI Codex, Cursor's agent or GitHub's Copilot coding agent reads a codebase, writes changes, runs them and iterates without a human typing each step. Agentic engineering is the discipline around that activity. Simon Willison, in his Agentic Engineering Patterns guide, defines it as "the practice of developing software with the assistance of coding agents," and puts the engineer's job in specifying the problem, giving the agent the right tools, and verifying and iterating until the result is robust.

The term arrived as a correction. IBM's explainer (February 27, 2026) traces it to Andrej Karpathy, who coined "vibe coding" in 2025 for prompting without reading the code and proposed "agentic engineering" in 2026 for the professional version, where a human oversees and validates what agents produce. IBM's advice to organizations is a team-level one: set governance for when agents are used, with playbooks covering review requirements, testing expectations and guardrails. Willison and IBM both describe the practice from the individual's desk. Agentic software development at team scale is where those playbooks get written.

How does a team share what its agents know?

Give every agent the same instructions by checking one file into the repository and reviewing changes to it like code. Two formats cover most of the tools teams use as of October 2026. AGENTS.md is an open format read by Codex, Cursor, Copilot's coding agent, Gemini CLI, Devin and others, used by more than 60,000 open-source projects and stewarded by the Agentic AI Foundation under the Linux Foundation. Claude Code uses CLAUDE.md, where the project file is shared with the team through version control, and it can also read an AGENTS.md. In a monorepo, the nearest file to the code being edited wins, which is why OpenAI's main repository carries 88 of them.

Two rules keep the file useful. Keep it short: Anthropic's documentation suggests under 200 lines, because longer files cost context and reduce adherence. And write down only what the code can't tell the agent, which is Addy Osmani's line in Brownfield Agentic Engineering: the deploy ordering, the migration rule, the third-party API that needs retries.

The file is advice, though. Claude Code's documentation is explicit that instructions are context, not enforced configuration, and that blocking an action takes a hook. Osmani makes the same point from the other side: once the team has corrected an agent on the same thing twice, the correction belongs in a lint rule, a hook, a type or a test. A.Team's field note on context engineering for AI coding walks through one team's setup in detail, including how the files get pull-request review when a convention changes.

zoom_in

Where does the review load go when every engineer runs agents?

Into a queue, unless the team plans for it. Agents raise the number and size of changes faster than they raise anyone's capacity to read them, so review becomes the constraint on agentic engineering at team scale. The fix is a written review policy: the author reviews before anyone else, changes stay small, and review depth follows risk.

The numbers are consistent. Faros AI's 2025 telemetry, drawn from more than 10,000 developers across 1,255 teams, found that high-AI-adoption teams completed 21% more tasks and merged 98% more pull requests, while review time rose 91% and average PR size rose 154%. Those gains didn't show up in company-level delivery metrics. Faros's September 2026 follow-up, covering 22,000 developers across 4,000 teams, found PRs still 71.8% larger, time in QA up 300.6%, and the count of PRs merged with no review at all up 76.3%. Faros sells engineering analytics and its findings are correlations from telemetry, so read them as direction rather than precise effect sizes. The direction matches what the 2025 DORA AI Capabilities Model found from the other end: working in small batches and strong version control practices are two of the seven capabilities that amplify AI's effect on a team.

A review policy that holds up has four parts.

1. The author reviews first. It's the one anti-pattern Willison's guide names: don't file a pull request with code you haven't reviewed yourself. The agent's PR description needs reading too, because agents write convincing ones. A teammate's review time is the scarcest resource on the team, and an unread agent diff spends it on work the author skipped.
2. Changes stay small. Set a soft limit on lines changed per PR and ask agents to split work along it. Reviewers read several small pull requests properly and tend to wave a large one through.
3. Review depth follows risk. Osmani's brownfield post divides a codebase into zones: green, where an agent can run a tight loop; yellow, where tests come first; and red, where a person is involved at every step. A human draws the map, and a module moves from yellow to green only after its owner has reviewed the agent's first changes there. CODEOWNERS and branch protection turn the map into something the repository enforces.
4. An agent reads before a person does. Faros found many companies already run AI review on 50 to 80% of pull requests, and heavy users of agentic review saw faster first reviews and lower change failure rates. Let the review agent catch the mechanical issues so the human reviewer spends their time on intent and design.

Review capacity is also a staffing question. Who owns what on an AI team, agents included treats it as a seat to fill before you scale agent use.

Who owns code an agent wrote?

The engineer who merged it, and the module's named owner after that. An agent can author a change but can't answer for it in an incident review, so every agent-authored line needs a human who understood it well enough to approve it.

Two-person review is the rule that makes this real. GitHub builds it into its own agent: when a repository requires approvals, your approval of a Copilot pull request doesn't count toward the total, so another reviewer has to approve, and Actions workflows don't run on the agent's pushes until someone approves them. Teams using other agents should write the same rule into branch protection, since the engineer who prompted a change is the person least likely to see what it missed.

Ownership also covers what an agent is allowed to touch. Workflow files, infrastructure definitions, authentication and data migrations usually belong in the red zone, with hooks or permissions that stop an agent from editing them unattended. Osmani suggests agents leave an ownership record behind with each change. In practice that means a PR description that states what changed, which tests prove it and how to roll it back, so the owner six months from now can reconstruct the decision.

How do tests and evals change when agents write the code?

Tests become the specification agents work against, so they have to exist before the agent starts. Willison's guide gives testing its own section, with chapters on red/green test-driven development and on running the existing tests first. Osmani adds the team rule: don't let the same agent session write the tests and then make them pass. Pin the current behavior in a separate pass, or have a person write the characterization tests, then let the agent change the code.

Two habits follow. CI becomes the gate every agent PR passes before a human looks at it, which keeps reviewers from spending time on changes that don't build. And verification has to be built in up front, because Faros's 300.6% rise in QA time is what happens when it isn't: the work reaches QA larger and less reviewed, and the burden of proving it correct lands there.

For features that call a model, unit tests aren't enough, because the output varies from run to run. That's an eval problem, and how to know your AI actually works covers building eval sets and running them on every change.

What changes in planning and staffing?

Planning shifts from estimating how long code takes to write to estimating how long it takes to specify, review and verify. Staffing shifts toward people who can do those three things for code they didn't write, with the tech lead owning the team's agentic engineering setup as part of the job.

Tickets get written for an agent to act on. A ticket an agent can pick up names the files in scope, the acceptance criteria, the test that has to pass, and which zone the change sits in. Writing that ticket is engineering work, and it belongs in the estimate. Teams that skip it pay later: Faros's 2026 data shows restarts, where work is abandoned and started over, up 66.7%, and it reads the rise as agents starting without enough context to get the work right the first time.

Parallel work changes the unit of capacity. One engineer can now run several agent sessions at once. Claude Code, for example, runs parallel sessions in separate git worktrees so one builds a feature while another fixes a bug. That multiplies changes produced per engineer, while review and verification capacity stay where they were. Size a sprint by the review hours available, and treat review wait time as the number that tells you when the team has overcommitted.

Measure what ships. PR counts and lines changed go up almost automatically once agents arrive, and Faros's 2025 finding was that those gains vanished at the company level. Track lead time, change failure rate, review wait and restarts instead, and review them monthly while the practice settles.

The tech lead's job grows. Someone has to own the instruction file, the zone map, the review policy and the merge bar, and revisit them as the tools change. That's a tech lead responsibility, and it takes real time each week. On a team without a lead who has the time, the files go stale and each engineer drifts back to a private workflow.

Reviewers have to be senior enough to judge code they didn't write. That's the main staffing consequence. How it changes team size and the senior-to-junior mix is covered in team composition with agents, and the interview that tests for it is in the hiring guide linked above.

What to do next

Pull last month's merged pull requests and mark the ones an agent authored. For each, check three things: how long it waited for review, whether anyone other than the requester approved it, and whether a test that existed before the change proves it works. The gaps tell you which of the five decisions your team hasn't made yet. Start with the review policy, then the instruction file, then the zone map.

If the team you'd need to run this doesn't exist yet, A.Team's team engagements come with a senior lead inside the team, in a builder seat, and put the team in your standups within 48 hours of sign-off. Ask the lead on the first call how they'd write the review policy for your repository.