An agent can write, test, and change code at a speed that changes the scale of a team's work. That speed does not remove the need for decisions. It moves the decision to before execution and to after the result is produced.
This shift appears in Anthropic's research on about 400,000 Claude Code sessions, analyzed between October 2025 and April 2026. In a typical session, people make most of the planning decisions, while the agent makes most of the execution decisions. The research also links greater domain expertise with a larger volume of work done per instruction.
For a team, the consequence is not simply buying a tool and measuring how many lines it produces. It is reviewing where human knowledge enters the delivery cycle and what evidence makes it possible to accept what was executed.
Speed raises the cost of a bad instruction
When a person implements a change by hand, execution time limits the reach of a mistaken interpretation. The error can still be large, but the slowness itself creates moments to discover that the request was incomplete.
An agent shortens that interval. A vague instruction can produce changes to the database, API, interface, and tests before anyone notices that the business rule was misunderstood. The team gains execution capacity and loses part of the accidental brake that existed in the manual process.
That is why the first job of the person using the agent is to make the objective verifiable. "Update the sign-up flow" does not say which users are affected, which states are valid, which integrations cannot change, or how the result will be accepted. The agent can fill the gaps with a coherent solution and still produce the wrong one.
A useful instruction defines at least four things:
- the behavior that should change;
- the behavior that must stay the same;
- the parts of the system that are authorized;
- the evidence that shows the change works.
This preparation looks like conventional planning. The difference is that it now controls a much larger execution capacity.
Domain knowledge is still a multiplier
Anthropic's research found a relationship between domain expertise and session success. The agent fills implementation gaps, but it does not replace understanding of customers, contracts, historical data, and operational consequences.
This changes the conversation about generalist teams. With the agent's help, one person can work across frontend, backend, database, and infrastructure. That widens their reach, but it does not automatically turn shallow knowledge into reliable judgment.
The risk appears when the organization mistakes the tool's fluency for domain competence. Code that compiles does not prove a policy was applied correctly. A green test does not prove the change respects an agreement with another system. A visually correct interface does not prove a user can recover from an error.
The agent increases the capacity of whoever knows how to frame the problem and evaluate the answer. The team needs to protect that evaluation work instead of treating it as a minor step because the code was produced quickly.
Acceptance has to keep pace with delegation
Delegating execution does not mean delegating the acceptance criteria. Each type of change needs evidence proportional to its risk.
For a localized change, existing tests and a short review may be enough. For a change that crosses data and permissions, the team needs to check migration, compatibility, logs, recovery, and access outside the happy path. For a product change, acceptance should include the expected behavior, the language shown, and the error states.
A simple policy helps keep every pull request from getting the same treatment:
Type of change | Required human decision | Minimum evidence |
|---|---|---|
Localized fix | confirm scope and regressions | targeted tests and a small diff |
Business rule | confirm the domain interpretation | acceptance cases and behavior tests |
Data or permissions | confirm impact and reversibility | reviewed migration, logs, and a recovery plan |
Critical interface | confirm understanding and recovery | complete states, accessibility, and a flow test |
The goal is not to create bureaucracy for every use of the agent. It is to keep execution speed from hiding decisions that still belong to the team.
What should live in the repository
If the agent needs context to decide well, that context cannot depend only on someone's memory or an old conversation. Project conventions, validation commands, access limits, architecture decisions, and examples of accepted changes should sit close to the code they explain.
That does not mean turning the repository into an endless manual. Short, up-to-date records are more useful: a decision, its reason, the known limit, and how to verify the effect. When a rule stops applying, the record also has to change.
The benefit shows up for humans and agents alike. A new person runs into less tribal knowledge. The agent gets less room to invent conventions. Review can discuss the current decision instead of reconstructing its history in every pull request.
The question for the team
Before expanding the use of agents, the team should list the decisions that cannot be inferred from code alone: commercial rules, limits of authority, sensitive data, fragile integrations, and success criteria. Then it can separate delegable execution from judgment that requires context.
That separation is a better measure of maturity than counting AI-generated tasks. The organization is ready when it knows what it can speed up, what it needs to watch, and what evidence stops execution.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
