From Coder to Agent Orchestrator: Mastering AI Coding Agents
Andrew Ng outlines a three-step iterative workflow (Plan, Execute, Deploy & Monitor) and five core capabilities—directing workflows, enabling autonomy, verifying output, customizing environments, and understanding failure modes—for AI engineers to effectively steer coding agents, emphasizing that judgment outweighs tool operation as coding becomes cheaper.
Andrew Ng, in The Batch #369 (September 4, 2026), argues that the key AI engineering skill is not merely invoking a coding agent but steering it. As agents grow more capable, the engineer’s value shifts from writing code to defining problems, designing systems, writing specifications, verifying results, and directing agents.
Coding Agents Are No Longer Just Code Completion
Ng broadens the definition: a coding agent can write code, analyze data, manage operations, and troubleshoot systems. Mastering this skill requires a continuous Experiment → Build → Learn loop because both proprietary agents (Claude Code, Codex, Cursor) and open-source agents (OpenCode, Pi) evolve rapidly via harness and model improvements.
The Iterative Three-Step Workflow
Interviews with top AI engineers reveal a consistent, highly iterative workflow:
① Plan : Brainstorm (research, experiments, codebase understanding) → write spec (requirements, technical design, architecture, execution plan) → review plan, challenge assumptions, check for safety and over-engineering.
② Execute : Build, test, verify; balance agent autonomy with human oversight. Let the agent build at a calibrated autonomy level; verify output via automated and/or manual checks.
③ Deploy & Monitor : Deploy via CI/CD or manual gates; use agents to watch logs, surface issues, propose and execute improvements.
This high-level workflow resembles pre-agent software development. The shift is attention moving away from code toward deciding what to build, designing architecture, writing clear specs, and verifying output.
Step duration varies: a greenfield prototype may need only a one-sentence prompt as spec; a brownfield project with many users demands extensive spec writing and validation. The term Prompt Engineering gives way to Spec Engineering —defining problem, requirements, constraints, and acceptance criteria clearly.
Writing code is getting cheaper; what’s expensive is deciding what to do, how to design it, and how to verify it. The center of gravity moves from “writing code” to “steering.”
Five Core Capabilities for Steering Agents
These are five facets of “knowing how to use” an agent, not a sequential learning path.
Directing the Workflow — Knowing when to research, when to build, when humans must intervene.
Enabling Agent Autonomy — Granting autonomy by risk level, not blanket permission.
Reviewing the Work — Judging “the agent did it right,” not just letting it run.
Customizing the Agent & Environment — Deciding what the agent can see, call, modify, and must not touch.
Coding Agent Foundations — Understanding why it fails to stop it before it goes off track.
Capability 1: Directing the Workflow — “Knowing When to Intervene” Is Harder Than “Letting AI Write”
You must answer: when to research vs. build? How to architect? How fine-grained should the spec be? How to split a large task into verifiable chunks? When to let the agent continue vs. when a human must step in? This requires balancing speed, cost, technical risk, and human effort .
The engineer’s role migrates from “doing the work yourself” to “organizing the work so the agent can do it.”
Capability 2: Enabling Agent Autonomy — Autonomy Must Be Tiered
Autonomy ≠ laissez-faire. Mature practice assigns autonomy levels by task risk:
Agents need correct context : architecture, historical decisions, user feedback, business rules, data logic, coding standards, and emerging project knowledge. “If context is mismanaged, even the strongest model can reason correctly on wrong information.”
For complex tasks, decompose work among multiple agents (planner, coder, tester, reviewer, monitor) coordinated by a human or an orchestrator agent—key step toward multi-agent collaboration.
Capability 3: Verifying Agent Output — “It Runs” ≠ “It’s Correct”
Coding agent output is non-deterministic. We don’t know in advance what good ideas it will have or what bugs it will introduce.
Never ship agent output directly. Use a closed loop: Build → Test → Verify → Review → Improve . Verification toolkit:
Design task-matched tests and verification (behavioral + functional).
Test user flows; agents can provide screenshots as pass/fail evidence.
Qualitative/behavioral evaluation using eval sets and LLM-as-a-judge.
Decide automation level: some workflows fully automate test/verify so the agent knows when it’s done.
Evaluate your tests: confirm they match goals; iterate if not.
Agentic code review + AI safety/architecture audit; insert human review when AI review is insufficient (review behavior, occasionally code), while exploring further automation.
A team’s AI engineering maturity is judged not by “can the agent do it?” but by “after the agent finishes, can we judge whether it did it right?”
Capability 4: Customizing the Agent & Environment — An Agent Is More Than “Model + Prompt”
A mature coding agent is a composition:
Engineers decide what the agent can see, call, modify, and must not touch. Tools, skills, plugins, and MCP let agents access repos, call APIs, query databases, run tests, read logs—turning a chatbot into a digital engineer.
Two practices worth adopting:
Persistent Context : Use AGENTS.md, CLAUDE.md files to continuously feed the agent project structure, architecture, code style, data access, business rules, test methods—turning engineers’ tacit knowledge into explicit, agent-readable knowledge.
Hooks for Automation : Attach code review, testing, security checks, CI/CD to hooks. Software engineering moves from “human-driven processes” to “agent-driven processes.”
Capability 5: Understanding Agent Foundations — Know Failure Modes to Intervene Early
You needn’t build an agent from scratch, but you must grasp mechanisms: codebase search, retrieval, context window, tool calling, MCP, sub-agents, agent harness. “Only by understanding how the agent works can you understand why it fails.”
Common failure modes:
Overengineering — Simple problem designed into abnormal complexity.
Lack of verification — Code runs but final result is incorrect.
Premature completion — Work not truly done, agent declares “Done”.
Context loss — Long-running project, key constraints ignored.
Unsafe actions — Accidental file deletion, config overwrite, production data corruption.
Knowing these failure modes lets you intervene before the agent goes off track, instead of waiting until it confidently announces “completed” after doing the wrong thing.
Running Long ≠ Using Advanced
Addressing the social-media trend of letting agents run autonomously for hours burning millions of tokens:
Social media often oversimplifies coding agent use. Letting an agent run autonomously for hours, burning millions or tens of millions of tokens, can sometimes be useful. But today, the practical utility of ultra-long-horizon tasks—especially relative to cost—is exaggerated to a degree detached from reality. Conversely, the most effective coding agent usage is a complex, highly iterative process; timely intervention with high-skill judgment yields far better results.
In plain terms: Running long doesn’t mean using it well. If the initial goal, assumptions, or architecture are flawed, letting the agent run longer just executes the wrong direction more efficiently. The key skill is knowing when not to intervene and when you must intervene.
From Coder to Agent Orchestrator
As coding agents grow stronger, engineers spend more time on four things:
Deciding what to build
Designing architecture
Writing clear specs
Verifying results
“Knowing how to use a coding agent” and “knowing how to operate a coding agent tool” are different. The former is judgment—when to grant autonomy, when to intervene; defining goals, providing context, establishing verification, owning the outcome. The latter is mere operation—triggering, filling parameters. Tool operation will only get simpler; judgment will never be replaced.
The real question is no longer “Can AI write code for me?” but “Now that AI can write more and more code, where should I invest my time and judgment?” The answer is becoming clearer: code is getting cheaper, while problem definition, business understanding, system design, engineering judgment, verification, and the ability to steer agents are becoming more valuable.
This leads to the final item on the AI Engineering Skill Map: Shaping the Build —deciding what to build when agents can already write and test code and autonomously complete increasingly long development tasks.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
