As AI agents become part of everyday software development, teams need clearer expectations around delegation, review, performance, accountability, cost, and engineering practice.

Agentic software development is changing more than how code gets written. It is also changing how engineering work is performed, compared, and evaluated inside teams.

On a recent project, AI agents became part of everyday development before we had a shared understanding of what good usage looked like. Everyone experimented and gradually developed their own approach to delegation, review, validation, model selection, and cost.

That experimentation was useful, but it exposed a broader problem. Questions such as how much work to delegate, how deeply generated code should be reviewed, what level of validation is sufficient, or how much model capability and reasoning effort a task deserves may look like individual workflow decisions. Once engineers answer them differently while working in the same organization, however, they become team-level questions about performance, accountability, onboarding, and governance.

A New Layer of Technical Fit

Joining an engineering team has always required understanding its codebase, domain model, conventions, testing philosophy, review culture, and development process. Agentic development adds another layer: how the team expects engineers to work with agents.

Two teams may use similar tools but operate very differently. One may expect aggressive delegation and rely heavily on automated validation. Another may require much deeper human inspection of generated changes. One may consider expensive models worthwhile because developer time is the dominant cost, while another may expect engineers to actively optimize inference spend.

The same workflow can therefore look effective in one team and inappropriate in another. The problem is that these expectations are often undocumented. Engineers discover them by watching coworkers, interpreting review feedback, responding to delivery pressure, and noticing what gets rewarded or criticized. Whether intentionally designed or not, agent usage is becoming part of a team's engineering culture.

Individual Experimentation Is Not a Team Practice

Experimentation is necessary while the technology is still evolving. My own workflow improved substantially through trial and error. Large, loosely defined requests often produced weak results. Outcomes improved when work was broken into smaller pieces, ambiguities were resolved before implementation, and constraints were made explicit. Domain concepts, engineering rules, and important decisions were maintained in living Markdown files so agents could reuse that context later.

The development process also became more deliberate. Instead of continuously generating features, there were moments to stop, inspect the state of the system, refactor where necessary, update project guidance, and then continue. Testing and lower-level validation could often be delegated to agents. Model choice, reasoning effort, latency, and cost also became engineering decisions rather than incidental choices.

The important realization was not that this workflow was universally correct. It was that it was still an individual workflow. Other engineers could arrive at different approaches based on different experiments and assumptions. A team can therefore end up with several engineers contributing to the same product while effectively using different software production systems. That is where individual experimentation starts becoming an organizational concern.

Delivery Speed Becomes Harder to Interpret

Engineering productivity has always been difficult to measure. Agentic development makes visible output even harder to interpret. One engineer may delegate aggressively and produce changes quickly, while another spends more time clarifying requirements, validating design choices, reviewing critical behavior, or restructuring existing code. One may consistently use highly capable models with substantial reasoning effort, while another reserves expensive inference for difficult tasks. One may rely heavily on automated validation, while another performs more manual review.

Their delivery rates may differ substantially, but that difference is not necessarily a clean measure of engineering capability. The organization may think it is comparing two engineers when it is partly comparing two delegation strategies, two review models, two cost profiles, and two levels of risk tolerance.

This does not make speed irrelevant. It makes speed more dependent on context. Without shared expectations around agent usage, differences in workflow can easily appear as differences in individual performance. That is an organizational measurement problem, and it is likely to become more significant as agents become more capable.

The Real Rules May Appear After Something Goes Wrong

The absence of shared expectations becomes particularly visible when outcomes are disappointing. An engineer may use agents conservatively, review extensively, intervene frequently, and write important parts manually. If others are moving much faster through aggressive delegation, that engineer may eventually be told they are not using the available tools effectively enough.

Another engineer may delegate heavily, move quickly, and rely primarily on automated validation. If a serious defect reaches production, the discussion may suddenly focus on why the generated implementation was not reviewed more carefully. Both concerns can be legitimate. The problem is when the expectations behind them were never clear beforehand.

In that environment, engineers discover the team's actual standards during difficult reviews, incidents, or performance conversations. The organization effectively defines acceptable AI usage after seeing the outcome.

That creates a form of retrospective governance. Engineers are expected to make judgment calls about autonomy, review depth, cost, and risk, while the standard against which those decisions will later be evaluated may not yet exist. Teams do not need perfect rules to avoid this. They do need enough shared understanding that engineers know what kinds of decisions are considered reasonable before something fails.

Accountability Exists at Two Levels

Agentic development does not remove individual responsibility. Engineers remain accountable for what they ship, regardless of how much of the implementation was generated. They still need to understand the consequences of a change, validate important behavior, recognize risk, and exercise engineering judgment.

At the same time, accountability also exists at the team level. If an organization encourages agent usage but provides no shared expectations around delegation, review, validation, model usage, cost, or acceptable risk, every failure cannot reasonably be reduced to an individual engineer using AI incorrectly.

Two questions matter:

• Did the engineer exercise reasonable judgment?
• Did the team establish what reasonable judgment was supposed to look like?

The first is individual accountability. The second is organizational accountability. This distinction becomes especially important when organizations want the speed advantages of automation while also expecting the confidence associated with more traditional development practices. Those goals may both be achievable, but they require more than telling engineers to "use AI responsibly." Responsible use needs enough shared context to mean something.

Governance Does Not Have to Mean Bureaucracy

Governance can sound heavier than it needs to be. It does not have to begin with approval committees, long policy documents, or rigid restrictions. At its simplest, governance means that a team has discussed how it expects agentic development to work and has made those expectations visible.

That conversation might cover what kinds of work are reasonable to delegate, how ambiguous tasks should be approached, what level of validation is expected, how much understanding engineers should retain over generated work, and when stronger models or higher reasoning effort are justified. It can also clarify how cost should be considered and what ownership means when an agent produced most of an implementation.

Different teams should arrive at different answers. A team working on sensitive infrastructure will reasonably operate differently from one building internal prototypes. A mature product with years of accumulated domain behavior will require different safeguards from an early experiment.

The objective is not to discover a universal rulebook. The objective is to move important assumptions out of individual engineers' heads and into a shared team context. Even a lightweight agreement creates a useful reference point for implementation decisions, reviews, incidents, and performance discussions.

Existing Engineering Practices Still Matter

Agentic development should not be treated as a replacement for the software engineering practices that came before it. In many cases, those practices become more important as implementation gets faster.

Clear specifications reduce the ambiguity that agents can otherwise propagate through large amounts of code. Living documentation gives agents persistent context about domain concepts, constraints, and prior decisions. Automated testing and validation prevent human review from becoming the only bottleneck. Periodic refactoring matters because faster feature generation can also accelerate structural drift.

The opportunity is not to replace the software development lifecycle with an agent. It is to examine each part of that lifecycle and decide where AI can increase leverage without removing the discipline that keeps the system understandable and maintainable. Some activities can be automated. Some can be accelerated. Others may require more deliberate human attention precisely because everything around them is moving faster.

Agentic Development Belongs in Onboarding

Once agent usage affects how work is performed and evaluated, it becomes part of what a new engineer needs to learn. Teams already onboard people into repository structure, development workflows, testing expectations, coding conventions, and review practices. The team's approach to agentic development increasingly belongs in the same category.

A new engineer should not need months of observation to discover whether the team expects aggressive or conservative delegation. They should know how generated work is validated, where project guidance lives, how agents are expected to use that context, how model cost and capability are considered, and what accountability looks like.

This does not require a large training program. Even a concise explanation of the team's current operating assumptions is better than forcing every new engineer to reconstruct them independently.

The Goal Is Not Less AI

None of this is an argument for reducing the use of AI agents. The opportunity is too significant for that. The challenge is to capture their leverage without creating an environment where every engineer operates according to different assumptions and the organization only discovers those differences when evaluating performance or investigating failures.

Agentic software development is still evolving, so any practice created today will eventually need to change. That is not a reason to avoid creating one. A team's first version can be simple, incomplete, and explicit about the fact that everyone is still learning. What matters is having a common starting point.

Teams can sit down together and discuss what should be delegated, what engineers are still expected to understand, how generated work should be validated, how model capability and cost should influence decisions, how delivery should be interpreted, and how accountability should be shared. Those answers will evolve with the technology.

An imperfect shared operating model that evolves over time is still better than leaving every engineer to independently discover what responsible agentic software development means while evaluating everyone as though they were working under the same rules.