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

At a glance

What this is: Ory argues that AI agents are taking over routine engineering tasks, shifting humans into a conductor role focused on coordination, coherence, and review.

Why it matters: For IAM and NHI practitioners, the governance lesson is that machine-speed change demands stronger constraints, approval boundaries, and failure-mode oversight before code reaches production.

Context

Engineering work is moving from direct implementation toward orchestration as AI agents take on more repeatable coding tasks. The governance gap is no longer whether work can be produced faster, but whether organisations can still ensure that generated changes fit the intended architecture, risk posture, and release controls.

This matters for identity and security programmes because the same pattern applies wherever automated systems act with delegated authority. When agents can write code, generate infrastructure, or trigger downstream changes, the real control problem becomes who or what is authorised to act, under what constraints, and with what review path.

Key questions

Q: How should teams govern AI-assisted development workflows that use coding agents?

A: Treat them as identity-governed execution paths, not just productivity tools. Define who can start the workflow, which tools and data sources it can reach, what evidence is required for review, and how access is revoked if the workflow expands beyond its intended scope. The key is to govern the chain of delegated action, not only the final code output.

Q: Why does agent-driven coding create more risk when review does not scale with output?

A: Because the volume and pace of generated change can exceed the team’s ability to validate design fit, integration impact, and failure interactions. A change that is correct in isolation can still destabilise the system when combined with other fast-moving updates, so review has to shift from file-level checking to system-level assurance.

Q: What are the signs that AI-generated engineering work is becoming a governance problem?

A: Common signals include too many changes reaching review too late, repeated integration conflicts, unclear ownership of agent outputs, and defects that only appear after multiple generated changes interact. Those symptoms show that the team is optimising for speed while losing coherence control.

Q: Should organisations use the same controls for agent outputs as for human code changes?

A: No, not by default. Human code review assumes a slower, more traceable workflow, while agent-driven development can create larger volumes of change and more rapid dependency shifts. Organisations should preserve review intent but adapt the controls so they validate orchestration, permissions, and interaction risk rather than only authorship.

Technical breakdown

Agent-generated code and the review bottleneck

When agents generate implementation code, refactors, tests, and infrastructure changes, the development process becomes more parallel and less predictable. That shifts quality control away from line-by-line authorship and toward system-level review of what changed, why it changed, and whether the change still matches the intended design. The risk is not simply bad code, but high-volume code that arrives faster than humans can meaningfully validate. In that model, architecture, policy constraints, and release governance matter more than raw coding speed.

Practical implication: move review and approval controls earlier in the delivery flow so generated changes are checked before they can accumulate into production risk.

Orchestration as the new engineering control plane

The conductor analogy maps well to modern software delivery because orchestration is about sequencing, constraint-setting, and dependency management. Engineers increasingly need to define what agents may do, how multiple outputs are combined, and which conditions block promotion. This is a control-plane problem, not just a productivity one. If the system accepts machine-generated work without strong constraints, then coherence, safety, and reliability depend on after-the-fact inspection rather than governed execution.

Practical implication: treat orchestration logic, prompts, and workflow constraints as security-relevant controls that require design review and change management.

Failure modes created by machine-velocity change

The article’s core warning is that accelerated output compresses the window for detecting defects, dependency conflicts, and architectural drift. In practice, failures appear when one generated change is technically correct in isolation but unsafe in combination with other changes already in flight. That is the same pattern that breaks large distributed systems: the parts look valid, but the system is no longer coherent. The governance challenge is therefore not only correctness, but interaction risk across the whole stack.

Practical implication: test for interaction failures, not just unit-level correctness, before agent-generated changes are allowed to ship.

NHI Mgmt Group analysis

AI-assisted engineering creates governance debt when organisations keep human-era review assumptions. The article describes a shift in which agents take over routine implementation while humans supervise the whole system. That changes the control problem from individual productivity to orchestration integrity, because review models built for slower human output do not scale to machine-speed change. Practitioners should treat that mismatch as a governance debt issue, not an efficiency issue.

Software delivery now needs the same kind of identity thinking used in privileged access governance. If an agent can write code, trigger tests, or modify infrastructure, then the question is not just whether the action is valid, but whether the actor was authorised to perform it in that context. That makes delegated authority, constraint design, and release approval boundaries central controls. The practitioner conclusion is that agent permissions must be governed as carefully as privileged human access.

System coherence becomes the real security objective in agent-led development. The article is right to focus on failure modes that emerge when many specialised actions are coordinated too quickly for humans to track. In security terms, this is closer to orchestration risk than isolated defect risk, because the damage comes from misaligned interactions across code, infrastructure, and release pipelines. Practitioners should design for coherence checks, not just faster generation.

AI engineering orchestration is a control-plane problem before it is a coding problem. The valuable skill is no longer only writing code, but setting the rules under which code is produced, reviewed, and promoted. That aligns closely with broader IAM and NHI governance patterns where authority is issued, constrained, and revoked through policy rather than trust. The practitioner takeaway is to govern the system that governs the agents, not merely the output they produce.

What this signals

Orchestration debt is the emerging risk pattern in AI-assisted engineering. The more work agents absorb, the more the organisation depends on constraints, review paths, and release logic that were never designed for machine-speed output. Teams should expect security and engineering governance to converge around the control plane that decides what gets produced, when it ships, and who can approve it.

The practical test is whether your delivery process can still detect system-level failure before deployment, not just individual defects after generation. If generated work is moving faster than architecture review, your programme is already relying on luck rather than control.

For practitioners

• Define agent operating boundaries Specify which development tasks agents may perform, which require human approval, and which are prohibited from autonomous execution. Tie those boundaries to environment, repository, and pipeline permissions rather than informal team expectations.
• Strengthen architecture review for generated changes Require design-level review for changes that affect dependencies, deployment flow, or cross-service behaviour. Focus review on whether multiple generated changes still fit the intended system architecture, not just whether each change compiles.
• Add failure-mode checks before promotion Test generated code for interaction failures, rollout conflicts, and hidden dependency changes before it reaches production. Use release gates that evaluate system coherence, not only unit tests or static analysis.
• Treat orchestration logic as a governed control Version and review prompts, workflow rules, and approval paths with the same discipline used for other security-sensitive configuration. Changes to orchestration determine what agents can do next, so they deserve formal change control.

Key takeaways

• AI agents are shifting engineering from direct implementation to orchestration, which raises the importance of system-level governance over individual coding speed.
• The main risk is not that agents write code, but that machine-speed change outruns review, architecture checks, and failure-mode validation.
• Practitioners should tighten approval boundaries, review orchestration logic, and test for interaction failures before agent-generated changes reach production.

Key terms

• AI Orchestration: The use of an AI system to coordinate multiple attack steps, tools, or targets in sequence. In this context, orchestration matters because it compresses human decision time and increases the rate at which valid credentials can be discovered, tested, and used across an environment.
• Review Bottleneck: A review bottleneck happens when too few people are available to examine pull requests, causing delays and workflow friction. It can create backlog, slow delivery, and increase the chance that rushed reviewers miss important defects or system impacts.
• System Coherence: The degree to which components, workflows, and changes still operate as one intended system rather than a collection of individually valid parts. In AI-assisted development, coherence is often lost when multiple generated changes interact in ways no single review catches.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of delegated access. It helps practitioners translate identity controls into practical oversight for modern automated systems.