AI engineering becomes conductor-led as agents take over routine code

At a glance

What this is: This is an editorial argument that AI agents will take over routine engineering tasks while humans move into an orchestration role that preserves coherence, safety, and architectural intent.

Why it matters: It matters because agentic workflows change where risk sits in engineering programmes, forcing IAM, NHI, and AI governance teams to rethink oversight, delegation, and control boundaries.

👉 Read Ory's perspective on AI agents as conductors of software engineering

Context

Agentic software development changes the governance problem, because the unit of work is no longer only a human developer making a direct change. As agents generate code, tests, migrations, and documentation, the control question shifts to who can direct those actions, validate them, and stop them before they affect production. That creates a genuine identity and access management intersection, because the agent itself becomes part of the control plane even if it is not a human identity.

The article’s central claim is that engineers will increasingly act as conductors rather than hands-on performers. That is a useful metaphor for AI operations, but it also exposes a broader security concern: faster generation can outpace review, and orchestration failures can look like ordinary application defects until they hit runtime.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why do agentic SecOps workflows create new governance risk?

A: Because the system is no longer just recommending actions, it is exercising delegated privilege inside production security tooling. That makes it an identity problem as well as an operations problem. Teams need to know what the agent can access, which changes it can authorise, and how those permissions are reviewed, revoked, and audited over time.

Q: What breaks when AI agents can make code changes faster than humans can review them?

A: Manual review stops being a meaningful control if it cannot keep pace with change volume. Teams then miss unsafe dependencies, unintended privilege use, and subtle architecture drift. The failure is not only in code quality, but in the programme’s ability to detect and contain agent-driven mistakes before they reach production.

Q: How do organisations decide which controls matter most for agentic development?

A: Start with boundary controls, then add traceability and validation. If an agent can act on production systems, you need scoped authorisation, logged execution identity, and automated policy enforcement before human approval. That combination matters more than trying to inspect every output manually after the fact.

Technical breakdown

How agent-driven code generation changes the engineering control plane

Agentic development separates task execution from oversight. An AI agent can produce code, transform modules, write tests, and draft infrastructure changes much faster than a human engineer, but it does not inherently understand system-wide safety, privilege boundaries, or production dependency chains. That means engineering becomes a control problem as much as a productivity problem. The important question is no longer only whether the code compiles, but whether the agent was constrained to the right scope, approved for the right actions, and monitored for unexpected side effects across the delivery pipeline.

Practical implication: treat AI coding agents as governed runtime actors, not just productivity tools.

Why orchestration matters more than local correctness in multi-agent workflows

The article’s conductor analogy maps to a core systems issue. Individual agent outputs can be locally correct and still produce a globally unsafe outcome when combined without coordination. In practice, that means architecture, sequencing, and dependency management become the decisive controls. A safe workflow needs explicit boundaries for which agent can change what, when approval is required, and how outputs are validated before they reach deployment. This is where identity and privilege design matters, because the orchestration layer determines whether agents have ephemeral, bounded access or broad standing permissions that can be abused or misapplied.

Practical implication: design orchestration so each agent has narrowly bounded access and explicit handoff points.

How review, telemetry, and failure analysis become the real safeguards

The article points to a familiar failure mode in a new form: acceleration without effective review. When machines produce more changes than humans can manually inspect, governance shifts toward automated validation, telemetry, and exception handling. That requires clear logging of what each agent did, which prompts or instructions triggered the action, and which identity or credential was used to execute it. Without those records, teams cannot reconstruct failure paths or distinguish an agent mistake from a systemic control gap. The security issue is not only code quality, but accountability across the full toolchain.

Practical implication: build traceability for agent actions before scaling autonomous code generation.

NHI Mgmt Group analysis

Agentic engineering creates governance debt faster than it creates delivery velocity. When code production becomes machine-assisted, the weak point moves from typing speed to control design. Teams that keep human review as an informal backstop will find that the volume and pace of changes outrun their oversight model. The practical conclusion is that orchestration, authorisation, and traceability must be designed as first-class controls, not added after deployment.

The conductor metaphor is useful because it describes an identity and privilege problem, not just an engineering model. If agents can write code, trigger tests, open pull requests, or touch infrastructure, they are acting as non-human identities in the delivery chain. That means the security question is who or what is authorised to act, under what conditions, and with what scope. IAM and NHI governance teams should treat agent workflows as part of identity lifecycle management, because delegation without lifecycle control becomes permanent exposure.

Orchestration gaps are the named failure mode this article exposes. The risk is not that individual agents are incapable, but that multiple capable agents can be coordinated poorly enough to create unsafe outcomes. That aligns with broader governance patterns in NIST AI RMF and NIST CSF, where accountability, monitoring, and response must exist at the system level. Practitioners should read this as a warning that local automation is not the same as controlled automation.

Engineering teams will need policy-aware automation, not just faster generation. The article’s model only holds if the conductor can set constraints, validate outputs, and stop unsafe actions before they propagate. That is the same logic behind least privilege in identity programmes: capability without boundary becomes risk. The practical conclusion is that AI-assisted engineering should be governed like any other privileged production workflow.

What this signals

Agentic engineering will force security and platform teams to converge on a shared control model. The organisations that cope best will be the ones that design identity, approval, and telemetry into the delivery pipeline before agent usage becomes normalised.

Orchestration trust gap: the emerging risk is not merely that agents can act, but that teams cannot reliably prove which agent did what, under which identity, and with what privilege. That makes execution traceability a governance requirement, not an operational nice-to-have.

For practitioners

• Define agent approval boundaries Map exactly which code, test, deployment, and infrastructure actions an AI agent may perform without human approval, and require explicit escalation for everything else.
• Separate generation from release authority Ensure the identity used to generate code is not the same identity permitted to merge, deploy, or modify production infrastructure, reducing the blast radius of agent errors.
• Log every agent action with identity context Capture prompts, tool calls, resource targets, and execution identity so you can reconstruct what happened when a generated change behaves unexpectedly.
• Add automated validation before human review Use policy checks, tests, dependency analysis, and secrets scanning to reject unsafe agent output before it reaches engineers, so review focuses on exceptions rather than volume.

Key takeaways

• AI agents are changing engineering from direct task execution into supervised orchestration, which shifts the primary risk from coding speed to control design.
• When multiple agents can generate and modify systems, local correctness is no longer enough. Teams need boundaries, validation, and traceability to keep the workflow safe.
• The most important security decision is whether agent actions are governed as privileged non-human identities or treated as informal automation.

Key terms

• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Orchestration: Orchestration is the coordination of multiple systems, tools, or agents so their actions occur in the right order with the right constraints. In AI engineering, orchestration determines whether individual agent outputs become a safe workflow or an uncontrolled chain of changes.
• Execution Identity: An execution identity is the non-human identity that performs a task at runtime, such as a Terraform role, Kubernetes controller, or CI/CD service account. It is the identity that matters when evaluating who can actually retrieve or decrypt a secret in production.

What's in the full article

Ory's full post covers the narrative framing and engineering perspective this analysis intentionally leaves at a higher level:

• The orchestra-and-conductor analogy used to describe future engineering roles
• The Amazon outage reference and the article’s interpretation of code velocity risk
• The author’s view of how senior engineers will evolve into system orchestrators
• The specific skills the article says will matter for AI-assisted engineering

👉 Ory's full post expands on the orchestration metaphor, the outage example, and the changing role of senior engineers.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners translate governance principles into controls for modern automation and agentic systems.