AI-Native Coding Workflows: How Engineers Move from "Transcriber" to "Author"

1. An emerging workflow: humans no longer write the implementation

Once coding agents gained the ability to make multiple tool calls across a session, the division of labor in software engineering shifted. Previously the agent’s role was “complete the next line.” Now it can read the repository, run tests, modify multiple files, submit changes, and wait for review feedback. This has pushed some teams to an extreme: shut down the graphical IDE, describe the goal in natural language, and let the agent handle the whole path from locating the code to modifying it to verifying it, while the human only decomposes requirements, chooses an approach, and gates the merge.

The value of this case study is not “how many change requests get produced per day.” It is that it exposes a fact: once implementation work is outsourced to an agent, the center of gravity of a team’s competitiveness moves from “how fast you can type code” to “the engineering infrastructure that makes code verifiable, revertible, and reviewable.” Without that infrastructure, agent-written code is not a productivity gain — it is a defect accelerator.

One common misunderstanding needs clearing up first: agents do not lower engineering requirements, they move them earlier. Human-written code implicitly carries a great deal of common sense and aesthetic judgment (this interface should not be designed that way, this branch can never be reached). An agent only faithfully executes the constraints you give it. Where constraints are missing, it fills the gap with whatever “looks reasonable” — which in practice shows up as over-engineering, invented APIs that do not exist, or quietly loosened test assertions.

So the question for evaluating whether this workflow fits your team is not “can the agent write code?” It is these four questions:

1. Can the correctness of this code be verified by machine without reading the entire implementation?
2. Can the agent find all the context needed for the task within a bounded number of steps?
3. Can a wrong change be located and rolled back within minutes?
4. Does every merge carry an accountable record of intent and a trace of human judgment?

If the answer to any one of them is no, the bottleneck in that area will surface immediately.

2. Four engineering preconditions: why “turning off the IDE” is not the point

2.1 Verifiability: tests change from “quality assurance” to “carrier of requirements”

In traditional development, testing is an optional step before you commit. In an agent workflow, tests are the only medium that can translate “what I want” into a machine-executable criterion. A verification matrix is best built in three layers, with a clear boundary of responsibility for each:

Layer	Focus	When it runs	Handling on failure
Static and convention layer	Syntax, formatting, types, dependency legality, complexity thresholds	Before every save/commit	Feed directly back to the agent for self-repair
Unit and contract layer	Single-module behavior, interface input/output contracts, boundary conditions	Every change	Require the agent to add cases and rerun
Integration and end-to-end layer	Real request paths, data consistency, fault injection, performance and security checks	Before merge and during canary	Block the merge; a human makes the call

Three design principles matter most. First, criteria must be written in advance by someone other than the change itself, otherwise the agent can make tests “pass” by editing the assertions. Core cases for high-risk modules should therefore go on a protected list that the agent is forbidden to modify. Second, write the tests before letting the agent touch anything — this is the most efficient way to converge a vague requirement into acceptance conditions. Third, failure output must be structured enough: an agent cannot recover from “test failed,” but it can locate the problem itself from output that includes a stack trace and the expected-vs-actual diff.

An illustrative verification entry point is a single unified script that pins down the definition of “can this be called done”:

#!/usr/bin/env bash
set -euo pipefail
./scripts/lint.sh          # Static and convention layer
./scripts/typecheck.sh     # Type and contract layer
./scripts/unit.sh          # Unit and contract layer
./scripts/integration.sh   # Integration layer, may spin up dependencies via container orchestration
./scripts/security-scan.sh # Dependency vulnerabilities, secret leakage, dangerous patterns
echo "verification passed"

2.2 Context availability: turn the repository into a knowledge base the agent can read

An agent’s performance depends heavily on the quality of its input context. The practice that holds up is to maintain a repository-level instruction file (at the root, versioned along with the code) that contains only what “the machine needs to know and cannot read out of the code itself”:

# Project conventions (for automated agents)
## Stack and build
- Build entry point: ./scripts/build.sh; test entry point: ./scripts/verify.sh
## Architectural constraints
- The domain layer must not depend on the interface adapter layer; cross-module calls must go through public interfaces
- Database schema changes must ship with a reversible migration script
## Coding conventions
- New public interfaces must add contract tests; do not modify cases under protected-tests/
- Commit message format: <type>(<scope>): <subject>, with a body explaining motivation and how it was verified
## Prohibited
- No unreviewed new dependencies; no loosening existing assertions; no real network access in tests

Beyond static documentation, three kinds of dynamic context are needed: the task description (goal, acceptance conditions, non-goals), retrieval results (relevant modules and call chains, so the agent does not start editing based on guesses), and prior experience (review comments from similar past changes, to avoid repeating mistakes). For large repositories, it is worth having the agent first produce an “analysis conclusions + impact surface list” and wait for confirmation before entering the implementation phase — this step significantly reduces wasted rework.

2.3 Change reversibility: small commits and atomic changes

“Several dozen change requests a day” only holds up when each one is small enough, independent of the others, and carries a clear record of intent. Conversely, a giant change that spans ten modules, mixes refactoring with behavior changes, and has no verification record will cost so much to review that it cancels out the benefit — even if an agent produced it.

The recommendation is to constrain a change to a single intent and to make verification evidence part of its metadata:

• One change solves one problem; refactoring and behavior changes stay separate.
• Branch names and commit messages carry the task ID so the originating requirement can be traced.
• Attach a verification summary before merging (which scripts ran, which cases were covered, which were skipped and why).
• Database and configuration changes carry a rollback path by default; anything without rollback capability is never auto-merged.

2.4 Review traceability: making review the new form of “coding”

Review is the one part of this workflow that cannot be outsourced, and it is where the new skill center of gravity sits. Effective review is not reading the implementation line by line; it is checking a fixed sequence:

1. Intent match: does the implementation stay strictly within the task description and acceptance conditions, with no unrequested functionality smuggled in?
2. Boundaries and exceptions: are nulls, timeouts, concurrency, retries, idempotency, and permission checks considered?
3. Security and compliance: input validation, secret management, log redaction, dependency licensing.
4. Maintainability: naming, duplicated logic, and whether there are complex branches only an agent could follow.
5. Test effectiveness: do the cases actually assert behavior, rather than restate the implementation logic or assert too broadly?

3. Division of labor: from “transcriber” to “author”

A transcriber’s value lies in accurately landing a design that is already decided. An author’s value lies in deciding what to write, why to write it, and what not to write. That shift raises the weight of three specific capabilities.

Requirement specification. Turning a sentence like “optimize checkout performance” into a task card with quantified targets, constraint boundaries, and acceptance cases. When the goal stays vague, the agent will produce an implementation that looks correct but is beside the point.

Architectural adjudication. Module boundaries, data consistency strategy, and failure degradation plans are judgments an agent cannot easily own on its own; they must be written into the constraints explicitly, or they will drift with every change.

Risk pricing. Deciding which classes of change can be auto-merged and which must pass a human. One workable classification: changes whose impact is confined to a single module with complete case coverage go through the automated path; changes touching public interfaces, data models, permission models, or cost structure require mandatory human review.

It is worth stressing that abandoning the graphical IDE is a personal preference, not a methodological prerequisite. What actually decides success or failure is the quality of the verification system and the context, not the shape of the tooling.

4. Common failure modes and a governance checklist

Failure mode	Typical symptom	Countermeasure
Invented dependencies	Calling libraries, methods, or parameters that do not exist	Enforce dependency validation at build time; list available dependencies explicitly in the instruction file
Self-deceiving tests	Editing assertions, skipping cases, mocking away the logic under test	Protect the core test directory; track assertion count and coverage changes, block on abnormal drops
Over-engineering	Introducing unnecessary abstraction layers or config options	State “non-goals” in the instruction file; review for whether the abstraction is justified
Scope creep	Refactoring unrelated code along the way, review cost spirals	Alert on line-count and file-count thresholds; single-intent commit convention
Security regression	Hard-coded secrets, logging sensitive fields, loosened authentication	Secret scanning before commit plus mandatory human review for permission-related changes
Slow rot	Duplicated logic accumulates, local complexity keeps rising	Monitor complexity and duplication trends; set thresholds, not just gates

5. Platform-side support: which generic capabilities must exist first

The infrastructure requirements of this workflow can be described in terms of generic capability categories rather than any specific product:

• Continuous integration and pipelines: orchestratable build, test, and scan pipelines supporting parallel jobs and fast failure feedback.
• Artifact and dependency governance: a private artifact repository, dependency version locking, and license and vulnerability inventories.
• Secret and permission management: centralized secret hosting, with credentials issued to agents under least privilege and auditable.
• Containers and elastic compute: isolated execution environments that can be started and torn down quickly for parallel verification jobs.
• Logging, metrics, and alerting: an observability loop after a change ships, including error rate, latency, and resource consumption trends.
• Audit and traceability: every automated change maps to a traceable task ID, verification record, and the person who merged it.

In cloud and engineering practice, enterprise-grade platforms such as Baidu AI Cloud offer general capability categories (container platforms, continuous delivery pipelines, logging and monitoring/alerting, secret management, and so on) that can serve as the foundation for this kind of workflow. The specific capability boundaries should be taken from each platform’s official documentation; designing an architecture on assumptions is not advisable.

6. Adoption roadmap and metrics

Stage 1: assisted completion (0 → 1). The goal is not headcount reduction but establishing a verification baseline. Fill in static checks, type checks, core test cases, and a unified verification script so that “done” can be determined by machine first.

Stage 2: task-level agents (1 → N). Pilot in low-risk scenarios such as defect fixes, logging instrumentation, unit test backfill, dependency upgrades, and documentation sync. Require the agent to produce an approach and an impact surface first, execute only after human confirmation, and keep review on every merge.

Stage 3: agent-led with human gating (N → M). Bring sufficiently well-verified modules into the auto-merge scope while keeping a manual adjudication list. The core work here shifts from writing code to writing specifications and reviewing.

Stage 4: organizational process adaptation (M → steady state). Adjust review conventions, change thresholds, and incident post-mortem mechanisms so the process matches the new division of labor.

For measurement, track two groups of indicators rather than output alone:

• Efficiency: average delivery time per task, review wait time, rework rounds.
• Quality: change failure rate, rollback rate, escaped defect density, verification coverage trend.
• Health: duplication and complexity trends, average impact surface per change, share of auto-merges.

The reading rule: the workflow genuinely holds only when the auto-merge share rises while change failure rate and rollback rate stay flat. If all of them rise together, the verification system is lending credibility to throughput rather than protecting it.

7. Conclusion

“Let the agent write all the code” is an extreme but useful experiment. It exposes a team’s real weaknesses thoroughly: are the specifications clear, are the tests trustworthy, are changes revertible, is review evidence-based? These capabilities already determined engineering quality in the era of hand-written code; they were simply masked by individual experience. Agents amplify the cost of missing constraints, and they also amplify the return on infrastructure investment.

For most teams, the pragmatic path is not to imitate the extreme form immediately but to get the verification baseline and context engineering right first, then loosen up gradually from low-risk scenarios. The change in the engineer’s role follows from this: from chasing implementation speed to defining problems, constraining solutions, and owning outcomes. That is what “author” means — and it is the one part of this workflow that cannot be automated.