Agentic Development Is Standardizing Faster Than Its Operating Model

The fundamental change brought on by agentic development is to redefine who or what initiates change. In a traditional workflow, it’s the developer to gather context, update and edit code, run tests, and open pull requests. In an agentic workflow, however, some or most of those steps can swiftly be delegated to an AI coding agent operating under instructions, permissions, and context — the same instruments originally in the hand of the developer.

The ecosystem is moving quickly — GitHub's Octoverse report shows its coding agent created over 1 million pull requests in its first five months. Teams are gaining knowledge about how to organize agent instruction files, which agents are best suited for various tasks, and when agent-generated code is helpful. Yet, there are still disparities in general operational procedures for agentic development. Certain organizations may already rely on explicit policies, with set rules in place for processes and clear answers to the inevitable variables of software development. A lot of them, however, may still operate on specific “local” conventions that function within a team and vanish elsewhere. This happens when rules are built and defined to fit a situational context without necessarily taking into consideration the bigger picture: one team may let an agent modify dependency manifests as long as CI passes, while another requires explicit review for the same change. Once both teams contribute to shared services, the organization is left with a circumstantial solution, but no consistent rule for an identical risk across two different teams and situations.

The lack of standardization is a risky business precisely because it lets the same agent operate under completely different rules depending on the team, repository, or developer who configured it. As agentic workflows are considered day-to-day tools, a need for an operating model that serves as source of truth for companies that want to scale their use beyond isolated team experiments begins to emerge. This is the problem that engineering leaders must solve before agentic workflows become deeply integrated into production software delivery.

Why tools usually arrive before operating models

This pattern is far from new. Engineering tools often spread before the practices around them become durable.

Consider Git adoption, which came before many teams standardized branching strategies, protected branches, code ownership, and other approaches that nowadays we come to consider almost Git-native. CI/CD pipelines, too, spread before organizations began to share a general agreement about which checks were mandatory, how promotions worked, who was allowed to deploy, and how rollbacks should happen.

The very same pattern appeared with infrastructure-as-code. Teams adopted tools for repeatable provisioning before policy-as-code, drift detection, secrets handling, and environment governance became common practice.

None of that means adoption was wrong. Rather, it means that, more often than not, operating models end up lagging behind tooling. A tool might have a will of their own, revolutionizing practices before anyone in the team is truly aware of it—until the workflow spreads beyond the team that introduced it and the shared rulebook is nowhere to be seen. This is exactly when flustered engineering teams discover the enforcement problem: the rules they thought everyone followed were local conventions all along.

Inevitably, agentic development appears to be following that cycle. Individual developers and teams are finding real value, but the organization-level answers are still forming.

What makes agentic development operationally different

Agentic development deserves operational attention because agents act inside the development workflow.

Earlier AI coding tools mostly assisted a developer who remained clearly in control of the edit loop. Previously-mentioned ground-breaking tools, such as Git and CI/CD pipelines, also left the developer with a hand securely placed on the process. Agentic tools, however, can take larger steps (such as making multi-file changes, inspecting dependency graphs, running tests, installing packages, to name just a few), which means they can hold more power, and developers may feel as if a lot of the control is given over. It is not.

While AI-generated code comes with its own vulnerabilities out-of-the-box, the larger problem of agentic development is inconsistent behavior across repositories, developers, agents, instructions, permissions, and integration points.

Today, the question is shifting from “Is the model good enough to sustain our work?” to “Can we operate this workflow consistently and everywhere?”. This is an established change of narrative. DORA’s 2025 research describes AI as an amplifier of existing organizational strengths and weaknesses. Which means that an organization with poor policies in place would only see this flaw magnified.

The 6 questions to answer to boost standardization

The core operating questions around agentic development are practical. They determine whether policy exists only in a document or actually affects how code changes enter production.

Which agents are allowed to touch production code?

Some teams allow agents only for local experimentation. Others let agents generate pull requests. Some allow agents to edit production service code through developer-controlled workflows, as long as the final change passes review.

Those are different operating models. They carry different expectations for permissions, audit trails, and review.

The first gap is often inventory. Many organizations cannot answer which AI coding agents are active across repositories, which teams use them, which instruction files shape their behavior, or which integrations they can call. Without that inventory, policy becomes aspirational.

A production repository should not have the same agent policy as a prototype. Customer-data paths, infrastructure code, regulated systems, and authentication flows deserve tighter boundaries than sandbox projects. Teams cannot apply those boundaries consistently without knowing where agents are at work.

What requires human review?

Most organizations say they keep a human in the loop. That phrase, however, hides a lot of nuance.

One team may treat AI-generated code like any other code. Another may require explicit human approval for agent-generated pull requests. A third may require additional review when the change touches authentication, authorization, payment logic, infrastructure, dependency manifests, or data processing.

AI-assisted development also increases code volume. If review capacity stays flat while change volume rises, teams risk shallower review. The result is a process that still contains human approval, but carries less assurance than is expected by most stakeholders.

Human review becomes a control only when the requirement is specific, enforced, and auditable. Branch protection, CODEOWNERS rules, pull request workflows, required checks, and CI gates are where that control becomes real.

How are agent permissions scoped?

Agents, like human developers, need repository read access, write access, shell execution, dependency installation, issue tracker access, documentation access, or general access to internal tools. Some workflows may benefit from network access. Others should not have it.

In early adoption, these permissions are often configured locally by developers or team leads. That is understandable during experimentation, but it does not scale well once agents are allowed to get their “hands” on production code.

A more mature approach starts with least-privilege defaults. For example, an agent may be allowed to inspect a repository but not write files. It may be allowed to run tests but not make arbitrary network calls. It may use approved MCP servers only, and it should not read secrets, production credentials, or local environment files that contain sensitive values.

The exact boundaries will vary by organization. The important part is that permissions are centrally understood and tied to repository risk.

How should memory and context be managed?

Agent quality depends on context. Instructions, repository conventions, architectural notes, prior conversations, and persistent memory can all improve output. They can also create governance questions.

Teams need to know where context is stored, who is allowed to modify it, whether it contains sensitive data, and how it affects future changes. A stale instruction file can push agents toward deprecated patterns. A memory entry may preserve assumptions that no longer hold. A local rule may instruct an agent to bypass tests because one developer found that convenient.

Agent memory becomes part of the development environment, even when it is less visible than source code, configuration, or documentation. Treating it casually creates a rather glaring blind spot.

This is why agent instruction files (such as AGENTS.md, CLAUDE.md, and .cursorrules) should be reviewed like governed artifacts. They influence code behavior, even though they are written in prose.

Are MCP servers being governed like dependencies?

MCP servers expand what agents can access and do. They can connect agents to ticketing systems, databases, documentation, cloud APIs, observability tools, internal services, and source control systems.

That increases agentic power, but it also makes MCP server governance a software supply chain dimension. If it exposes sensitive systems or lets an agent execute actions, an MCP server ceases to be a harmless configuration.

Engineering teams should ask the same kinds of questions they ask about dependencies and integrations. Who approved this server? Who owns it? Are versions pinned? What data can it access? Are tool calls logged? Can access be scoped by repository, team, or user? What happens when the server changes?

Many organizations are still treating MCP servers as convenience integrations. That may be fine for local experiments. However, it is not enough for production workflows.

Where should controls live?

Agentic development has a fragmented enforcement surface. Controls may exist in the IDE, the agent runtime, local developer machines, repository configuration, pull request checks, CI/CD pipelines, secrets scanning, SAST, SCA, policy engines, and audit logs.

No single layer, though, is enough.

Agent instructions provide early guidance, but they are fragile as the main control. CI/CD provides repeatable enforcement, but it may catch issues after the agent has already generated a large change. Pull request checks give reviewers signal, but they depend on clear policy and manageable noise.

Controls work when they are placed at the point where change happens. Some belong before code is written, some belong when the pull request is opened, and some belong in CI/CD before merge or deployment.

The operating model needs to define that placement deliberately.

What an emerging control layer looks like

Early signs of a control layer are starting to appear around agentic development workflows. The focus is moving from model capability toward inventory, policy, instruction quality, provenance, and enforcement.

Transparency standards are part of this shift. The OWASP AIBOM project, which Codacy sponsors, is one example of work aimed at improving visibility into AI use across software delivery. Separately, OWASP’s Top 10 for Agentic Applications, developed through collaboration with more than 100 industry experts, researchers, and practitioners, addresses security risks specific to autonomous and agentic AI systems. The broader direction is clear: organizations need better ways to understand where AI contributed, what context was used, and what governance evidence exists.

In practice, this control tier may include inventory of agents and models, policy checks for instruction files, AI-generated code review signals, MCP server governance, and audit trails for tool calls or generated changes.

For code quality and security platforms, this means enforcement has to span the same workflow developers already use. Static analysis, secrets detection, dependency risk, and policy checks need to work across IDE, pull request, and CI/CD stages. AI code governance becomes part of the normal change control system rather than a separate review ritual.

What a mature agentic development operating model should include

The industry has not fully converged on operational practices for agentic development, but mature patterns are becoming visible and should be readily embraced.

A more mature operating model will likely include an inventory of agents, models, MCP servers, and instruction files by repository. It will define which agents are approved for production repositories, how permissions differ by repository risk, and what review requirements apply to agent-generated changes.

It will also treat AI-related artifacts as governed inputs to software delivery. That includes AGENTS.md, CLAUDE.md, Cursor rules, tool manifests, memory configuration, MCP server definitions, and local automation scripts that influence agent behavior.

Security and quality checks will remain central. Agent-generated code should pass the same standards for static analysis, secrets detection, dependency risk, test coverage, and maintainability as any other code. The review path may differ because AI changes can arrive faster and larger, but the standards should not be weaker.

Auditability will matter more over time. Teams will need evidence of what agents changed, which tools they called, what context they used, who approved the result, and which checks passed before merge. This evidence is especially important in regulated environments where compliance evidence must be produced without reconstructing history from scattered logs.

This operating model should not slow developers down. Quite the opposite, in fact, is true. Its purpose is to make agentic development repeatable enough to scale beyond individual experimentation.

Practical guidance for engineering leaders

Engineering leaders do not need to wait for perfect industry consensus. It is good practice to start by making the current state visible, then adding enforcement where risk is highest.

• Begin with visibility. Identify which AI coding agents are used across repositories, which agent instruction files exist, and where AI-generated code is entering pull requests. Map the MCP servers and external tools agents can call. This gives you a working inventory, which is the foundation for policy.
• Classify repositories by risk. Production services, regulated systems, customer-data paths, authentication code, payment logic, and infrastructure repositories should not follow the same rules as prototypes. Risk tiers help you decide where stricter permissions, additional review, or stronger CI/CD gates are necessary.
• Define minimum review expectations. Specify when human review is required, when additional reviewers are needed, and which types of changes demand security-sensitive review. Then enforce those requirements through branch protection, pull request workflows, CODEOWNERS, and required checks.
• Treat agent instruction files as governed artifacts. Changes to AGENTS.md, CLAUDE.md, .cursorrules, and similar files should be reviewed because they shape future code changes. Look for unsafe permissions, ambiguous guidance, references to secrets, bypass language, and conflicting instructions.
• Govern MCP servers like integrations. Approve allowed servers, scope access by team or repository, track ownership, pin versions where possible, and retain logs for sensitive tool calls. If an MCP server can expose data or trigger actions, it deserves the same attention as other software supply chain components.
• Place controls where enforcement happens. IDE and agent configuration can guide developers early. Pull request checks can enforce review and policy. CI/CD can provide repeatable quality and security gates. Audit logs and inventory provide oversight across repositories.

Tools can help, but the operating model has to come first. A unified code quality and security platform such as Codacy can support this control layer by applying static analysis, security scanning, dependency checks, secrets detection, policy enforcement, and compliance evidence across the delivery workflow. The value comes from consistent enforcement at the point of change, not from adding another disconnected dashboard.

Conclusion

The industry is standardizing tools and model capabilities faster than it is standardizing operational practices for agentic development.

That means engineering leaders should start building visibility, permission boundaries, review expectations, MCP server governance, instruction-file hygiene, audit trails, and enforceable AI development guardrails now.

Agentic development is already a paramount component of production software delivery. The tools are arriving faster than the operating models. The organizations that develop repeatable practices early may have an advantage as the ecosystem matures.