AI Agent Coding: From Writing Code to Orchestrating Parallel Agents

1. The Shift: “Writing Code” Is No Longer the Main Workload

An engineer who has worked on AI coding tools said in a public talk that he no longer writes business code himself. The model now handles almost all implementation work, while his daily focus is on the dozens of changes being submitted, with a peak of more than one hundred in a single day. The devices supporting these parallel outputs have also changed: what used to be a workstation with three monitors and a mechanical keyboard has become a phone.

This individual practice should not be treated as an industry benchmark, but it does point to a real structural change: the bottleneck in software delivery is moving from implementation speed to task-definition quality, parallel orchestration capability, and acceptance reliability. In other words, the engineer’s main work object is no longer text characters, but a set of task units with clear acceptance conditions.

To understand this shift, it helps to look at three stages in the evolution of AI coding.

2. Paradigm Evolution: Completion, Chat Generation, and Agent Takeover

Stage 1: Inline completion.
The model predicts the next few tokens at the cursor, functioning like a stronger form of autocomplete. Its key limitation is the absence of environment feedback: the model cannot see runtime results, and correctness is judged entirely by the human. The human’s interaction rhythm—pausing, waiting, accepting, or rejecting—becomes the upper limit of throughput.

Stage 2: Chat-based generation.
The unit of interaction changes from a line of code to a function or file. Users can paste error messages, interface definitions, or other context and ask the model to produce a more complete snippet. Feedback still relies on human relay: the model cannot directly read the codebase or execute commands.

Stage 3: Agent takeover.
The unit of interaction becomes the task. The system forms a closed loop: read repository context → make a change plan → edit files → run builds and tests → read failure output → self-correct → produce a submittable change. Humans appear only at two points: defining the task and acceptance criteria, and making a risk judgment before merge.

The dividing line among these stages is whether an environment feedback loop exists. Only a third-stage system can use “tests pass or fail” as an objective reward signal and advance longer task chains without step-by-step human guidance. This is also the fundamental reason why throughput levels such as “dozens of changes per day” become possible: parallelism is no longer limited by human typing speed, but by how many tasks can be independently verified and how much change flow the review and merge pipeline can absorb.

3. The Prerequisite: The Product Skeleton Must Be Designed in Advance

Early attempts were often disappointing. The model could do far more than the product allowed it to do, while the tool form remained stuck in a “completion box.” The experience was flat for the first few months, and the market response after launch was also modest. The real turning point appeared only after model capability crossed several thresholds: sufficiently long context to carry repository-level information, stable tool-invocation formats, long-horizon instruction following, and reliable code retrieval and self-correction.

This yields a principle with direct guidance for engineering teams: the capability ceiling is determined by the model, but the experience ceiling is determined by the product skeleton. If the product architecture assumes that AI only completes one line, then even a very strong model will be constrained inside a completion box. The practical approach is to build agent-facing infrastructure early, even before capabilities are fully mature:

• Make the codebase machine-retrievable: clear module boundaries, parseable dependency declarations, and convention docs that evolve with the code.
• Engineer acceptance conditions: tests, static checks, and type checks should run with one command and produce structured results.
• Provide isolated execution environments and controlled permission boundaries for agents.
• Keep human review and merge gates in place rather than adding them later once models become stronger.

4. Five Engineering Elements for Parallel Orchestration

Driving dozens or hundreds of tasks from a single device does not depend on a stronger model alone. It depends on a repeatable set of engineering constraints.

1) Slice tasks to an “independently verifiable” granularity.
Each task should have clear input context, a unique ownership boundary covering which files it may touch, and a completion condition that can be automatically determined. A task such as “optimize the payment module” is not parallelizable. By contrast, tasks such as “add unit tests for a specific refund scenario in the payment module” or “change the return structure of a given interface to include pagination metadata and update the callers accordingly” are suitable parallel units.

2) Isolate environments and write permissions.
Each task needs an independent working copy, such as a separate branch or workspace, an independent dependency environment, and an independent runtime sandbox. Write conflicts are the primary cause of parallel failure, followed by shared-state pollution, such as multiple tasks modifying the same configuration file or database schema at the same time. In practice, orchestrating by “file ownership + dependency order” significantly reduces conflict probability.

3) Make acceptance criteria executable.
Translate vague goals such as “should be more robust” into assertable conditions. A schematic task description could look like this:

task:
  id: pagination-meta
  scope: [api/order/**]            # unique ownership scope
  goal: Return pagination metadata consistently in list APIs
  acceptance:                      # all conditions can be checked by commands
    - cmd: make lint               # expected exit code 0
    - cmd: make typecheck
    - cmd: make test               # coverage no lower than baseline
    - assertion: New cases cover empty results and last-page boundaries
  constraints:
    - Do not change the semantics of existing fields in public contracts
    - Do not add third-party dependencies
  report: { pr_title: ..., risk_notes: ... }

4) Build an orchestration layer: concurrency, retries, and gates.
The orchestrator only needs to do four things: schedule tasks, run them in isolation, collect structured results, and decide whether a change enters the human review queue based on gates.

# Illustrative orchestration skeleton, not any specific product API
async def run_batch(tasks, concurrency=20):
    sem = asyncio.Semaphore(concurrency)          # rate limiting to protect backend services and quotas
    async def one(t):
        async with sem:
            ws = await sandbox.create_workspace(t.branch)   # isolated environment
            for attempt in range(MAX_RETRY):
                r = await agent.solve(t, workspace=ws)
                gate = await run_gates(ws, t.acceptance)    # lint/type/test
                if gate.passed:
                    return await ws.open_change()           # produce a change ready for review
            return Failed(t.id, reason=gate.first_failure)
    return await asyncio.gather(*(one(t) for t in tasks))

5) Apply context engineering and specification injection.
The benefits of parallelism can be eroded by architecture drift: dozens of tasks changing code independently can quickly produce inconsistent style, duplicate implementations, and broken layering. To mitigate this, turn conventions into machine-verifiable constraints, such as module-dependency checks, directory-boundary checks, and naming or error-handling rule checks. Each task should also retrieve existing repository conventions before starting work, rather than relying on temporary memory in a conversation.

5. The Review System Must Be Rebuilt: From Line-by-Line Reading to Risk Tiering

When changes increase from one or two per day to dozens per day, line-by-line review no longer holds up mathematically. A practical alternative is layered gates:

• Layer 1: Fully automated hard gates. Build, type checking, static scanning, unit tests, dependency and license compliance checks, and secret or sensitive-information scans. If any check fails, the change does not enter human review.
• Layer 2: Semantic review. Humans focus only on design-level issues: whether an API contract should change, whether a data migration is acceptable, whether new cross-system implicit dependencies are introduced, and whether error handling and degradation strategies are reasonable.
• Layer 3: Sampling and retrospective analysis. Sample changes that pass the gates, track defect escape rates, and use the results to identify gaps in the gate rules and add new checks.

Two kinds of “false passes” should be watched closely. First, insufficient test validity: the model may write tautological assertions or assertions derived from the implementation itself. Mutation testing or manually designed negative examples can help identify such problems. Second, dependency hallucination: the model may invent libraries or methods that do not exist. This can be blocked through dependency allowlists, private mirror repositories, and offline installation validation.

6. Cost and Throughput Governance

Parallelism increases resource consumption almost linearly, so explicit governance is needed:

• Tiered model routing: Use smaller models for boilerplate code, formatting, and test completion; use larger models for architectural changes and difficult defect localization. Choose model tiers based on task value rather than habit.
• Prompt caching and reuse: Make stable context such as repository conventions, coding standards, and API contracts reusable prefixes to reduce repeated billing and latency.
• Priority queues: Separate release-blocking fixes from technical-debt cleanup, and avoid low-value tasks consuming quota.
• Observability: Build dashboards for task success rate, average retry count, gate first-pass rate, and resource consumption per task, and connect them to monitoring and alerts. Without these metrics, increasing parallelism only makes failures harder to locate.

7. The Device Change: Moving the Control Plane, Not the Work Plane

The phrase “commanding with a phone” is easy to misread. The real change is the separation of the control plane and the work plane: heavy computation runs continuously in remote isolated environments, while the device in the human’s hand handles task dispatch, notifications, approvals, and log viewing. This makes asynchronous long-running tasks possible: submit the task, leave, and get notified when it finishes.

The real constraint of mobile use is input bandwidth. Typing a detailed requirement description on a phone is highly inefficient. A practical form is to dispatch tasks in a templated, structured way: choose a repository, choose a task type, fill in a few parameters, and attach an acceptance checklist. Complex context should be retrieved by the system from the repository, while the human only confirms key tradeoffs. Approvals must be understandable, rejectable, and traceable: change summaries, impact scope, gate results, and risk notes should be visible on one screen, and a rejection should be able to send a reason back to the agent with one click.

8. Capability Boundaries: Where Humans Still Matter

The same interview also points to areas where agents still struggle, and these deserve attention. Extremely large and complex legacy codebases, as well as modules using niche languages or edge runtimes, can still stall the model. The common industry response is to wait for the next model version rather than forcing a solution.

Several other categories of work still depend heavily on humans:

• Implicit cross-system contracts maintained through meetings, verbal agreements, or historical incidents.
• Performance hot paths that need measurement on real data distributions rather than inference from code alone.
• Problems requiring debugging in physical environments, special permissions, or external collaboration.
• Irreversible operations such as data migration, permission-model changes, and outward-facing interface shutdowns.

A practical approach is zoned governance: divide the codebase into “agent-friendly zones,” such as well-tested areas with clear boundaries and localized changes, and “human-core zones.” First use agents to expand the agent-friendly zones rapidly, then gradually refactor the human-core zones until they can be handled safely by agents. This itself is architectural work worth investing in.

9. Organizational Rollout Path and Metrics

A suggested rollout order is: pilot on low-risk modules that can be automatically verified → accumulate a task-template library and convention-check rules → establish gates and layered review → use data to decide whether to expand scope.

For measurement, do not focus only on output metrics such as the percentage of AI-generated code. Delivery-side metrics are more important: change lead time, rework rate, defect escape rate, average review time, build failure rate, and cost per task. Output-style metrics are easy to inflate, while delivery-side metrics reflect real benefit.

10. Conclusion: The Threshold Has Moved, Not Flattened

The claim that “domain experts who do not understand traditional programming can also build applications” is broadly correct: as the abstraction level rises, the value of syntax and API memorization declines, while the value of requirement expression, domain modeling, and result acceptance rises. But the threshold has not disappeared. It has moved from “can you write it” to “can you clearly state what you want, judge whether it is done correctly, and take responsibility for the consequences.”

For engineers, this means a role reconstruction: from implementer to specification setter and quality gatekeeper. The truly scarce ability is translating vague business intent into executable, verifiable, and parallelizable tasks, and building a constraint system strong enough to backstop an automated pipeline. Tool forms may move from workstations to any screen, but the location of judgment does not move.