AI Coding: From Code Completion to End-to-End Delivery

1. The Core Shift: The Delivery Unit Moves from Code Snippets to Engineering Tasks

Over the past two years, AI coding capabilities have gone through three stages. Understanding the differences between these stages is more valuable than memorizing any feature list.

The first stage is completion-driven. When a developer enters a method signature, the model completes the method body; when a developer writes a comment, the model continues with an implementation. At this stage, the model usually only sees the current file or a few lines near the cursor. It acts as a typing accelerator.

The second stage is conversation-driven. Developers can paste an error message or a requirement description and ask the model to generate a three-layer skeleton of Controller, DTO, and Service, or to explain unfamiliar code. Cross-file editing begins to appear, but the workflow is still led by the developer: the developer decides what to change and when the change is complete.

The third stage is task-driven, which is the direction of the current competition. Developers no longer hand over a snippet of code, but an entire task, for example:

Fix the issue in order-service where refund records are created repeatedly.
Constraints and requirements:
1. First analyze the Controller, Service, persistence mappings, and database constraints to confirm the actual path through which duplicate writes occur.
2. The fix must cover both the application layer and the data layer. It must not rely only on frontend deduplication.
3. Add reproducible unit tests and integration tests. If tests fail, the implementation must iterate and fix itself.
4. Do not modify external interface signatures. Do not introduce new external dependencies.
5. After completion, output a change list, an impact analysis, and a rollback plan.

The dividing line between the third stage and the second stage is simple: whether the system has closed-loop capability. The first two stages only include generation. The third stage introduces observation and feedback loops: reading files, checking dependencies, running builds, executing tests, reading errors, and modifying the code again. Whether a task converges depends on whether this loop exists and whether each signal in the loop is trustworthy.

2. What a Complete Delivery Includes

If we break down the capabilities of an autonomous agent, they form six linked parts, each with its own failure modes.

1. Requirement clarification and decomposition. A vague instruction must be translated into verifiable acceptance criteria. A common problem in practice is not that the model cannot write code, but that it interprets “fix the slow query” as adding an index when the real bottleneck may be an N+1 query pattern. The ability to ask clarifying questions and label assumptions is the first sign of maturity in task-oriented tools.

2. Context acquisition. This is the most essential difference between task-level agents and code completion. Real engineering information is scattered across source code symbols, dependency declarations, configuration files, build scripts, database DDL, historical commits, and requirement tickets. Without information such as a database unique constraint, any “anti-duplication” implementation is only a temporary patch at the application layer.

3. Code modification. The difficulty is not single-point generation quality, but cross-file consistency. If the field semantics of a DTO are changed, are the callers, serialization configuration, cache keys, and test cases synchronized? If a new enum value is added, do persistence mappings and historical data require migration?

4. Execution verification. Compilation success is only the minimum threshold. Whether the agent can run unit tests, start dependent databases in containers, and obtain readable failure stack traces determines whether it can correct itself or can only be corrected by humans.

5. Code review. This step turns static checks, dependency license scans, secret leakage detection, and change impact analysis into machine-readable signals that are fed back to the generator, rather than left to manual review.

6. Commit and delivery. Branching strategy, change descriptions, linked requirement tickets, artifact archiving, and release cadence are engineering conventions that must be expressed explicitly. Otherwise, the output of an agent is difficult to merge into existing processes.

It is important to emphasize that the more parts there are, the lower the overall success rate. If each of five parts has a 90% success rate, the end-to-end success rate is only about 59%. This explains the large gap between “looking generated” and “actually deliverable,” and it also explains why the runnability of test assets can directly amplify or offset model capabilities.

3. Four Technical Foundations for Complete Delivery

1. Context engineering: from stuffing the window to precise loading

Context window length determines the upper limit, but retrieval quality determines the actual effect. An effective approach is layered loading. First, use a machine-readable project rules file to declare the technology stack, directory conventions, prohibited actions, and commit standards. Next, load architecture-level explanations such as module boundaries and dependency directions. Finally, dynamically pull relevant symbols, call chains, and change history according to the task.

# Project conventions (example)
- Technology stack: JDK 17, a relational database, and containerized deployment
- Directory convention: controller / service / mapper / domain four layers; direct calls across layers are prohibited
- Database convention: all business uniqueness must be enforced by unique indexes; the application layer should only provide friendly error messages
- Prohibited actions: do not concatenate raw SQL in Service; do not introduce libraries that are not registered in the dependency list
- Verification: ./build verify must pass with zero failures before submission

Context engineering also includes information compression: compressing a call graph of tens of thousands of files into a task-relevant symbol list, and compressing long logs into key exception chains. Poor compression loses information. Excessive compression causes the model to fill gaps with common sense, which is one of the main sources of hallucination.

2. Tools and execution channels: description quality determines call accuracy

Agents need a set of controlled tools: read files, modify files, run builds and tests, query logs, search code, and query database table structures. In practice, tool-call accuracy is strongly correlated with the clarity of tool descriptions. Tool names, parameter semantics, return-value structures, and error-code conventions should be written like interface documentation for a new colleague. At the same time, a failure-information feedback channel should be designed so that compilation errors, test stack traces, and dependency conflicts are returned in a structured form, rather than being pasted by humans.

3. Verifiability: no tests, no closed loop

This is the most underestimated part in current implementation. If a team has long lacked unit and integration tests, the output quality of autonomous agents will degrade significantly, because the agent cannot determine whether it is correct and can only keep rewriting until the result “looks reasonable.” A practical path is to first add runnable tests and contract tests for critical paths, then gradually expand the scope of autonomy. At the same time, the generator should be required to add tests for its own changes, and gates should be set for test effectiveness, for example by prohibiting empty-assertion tests and requiring that injected defects can be detected by failing test cases.

4. State, permissions, and boundaries

Long-running tasks need work ledgers and checkpoints: task plans, completed steps, retry counts, and rollbackable checkpoints. On the permission side, the principle of least privilege should be followed, and capabilities should be graded:

• Read-only analysis: can search code, query logs and monitoring, and produce diagnostic reports.
• Restricted modification: can modify code on isolated branches and run tests, but cannot push or release.
• High-risk operations: operations involving database schema changes, production configuration, or credential access must require human confirmation.

The execution environment should preferably be isolated in disposable containers. Network egress should use a whitelist. Credentials should be injected through key-management capabilities rather than written into repositories or logs.

4. Making the Task Clear: Structured Description and Implementation Example

Returning to the refund duplicate creation scenario at the beginning, the value of task-oriented tools is not only to find duplicate save calls, but to recognize that “anti-duplication” must be enforced at the data layer.

Data layer:

ALTER TABLE refund_record
  ADD UNIQUE KEY uk_order_biz (order_id, biz_type);

Application layer (illustrative):

public RefundApplyResult apply(RefundApplyCommand command) {
    RefundKey key = RefundKey.of(command.getOrderId(), command.getBizType());
    // The unique index serves as the final consistency safeguard; the application layer only recognizes the condition and returns an idempotent result.
    try {
        refundRecordMapper.insertIgnore(key, command);
    } catch (DuplicateKeyException e) {
        return RefundApplyResult.alreadyProcessed(key);
    }
    return doRefund(key, command);
}

A task description should include six elements: goal, scope, constraints, verification method, prohibited actions, and definition of done. The definition of done is most often omitted, but it determines when the agent stops. It is also recommended to require changes to be committed in stages: analysis conclusions, implementation changes, and test additions should be independent, making it easier for humans to locate problems during review.

5. Integrating into Existing R&D Systems: Process and Metrics

Task-level capabilities must be embedded in processes to produce value. Otherwise, they will only increase rework. There are four key integration points:

• Move gates earlier. Let continuous integration provide trustworthy signals without human intervention. Make compilation, static checks, unit tests, dependency license scans, and secret scans mandatory passing gates.
• Make conventions machine-readable. Write coding standards, layering constraints, and commit formats as rule files and check scripts, rather than only putting them in documentation.
• Move review points earlier. Require agent output to include impact analysis and rollback plans, so that humans can make judgments during review rather than re-deriving them.
• Connect observability. Changes produced by agents should also enter logging services and monitoring/alerting systems. After release, core metrics such as error rates, latency, and slow queries should be observed.

For metrics, avoid vanity metrics such as “lines of code generated.” More meaningful metrics include task pass rate on the first attempt, average number of rework rounds, change in review time, change size per task, defect escape rate, cost per task, and retry amplification. These data are also the basis for deciding whether it is worthwhile to expand the scope of autonomy.

6. Risk List and Governance Recommendations

• Semantic correctness risk: compilation success does not equal business correctness, especially for implicit semantics such as concurrency, transaction boundaries, idempotency, and eventual consistency.
• Missing implicit knowledge: historical baggage and undocumented conventions are unknown to the model and need to be supplemented through rule files and code comments.
• Security risk: prompt injection (reading instructions from malicious repositories), credential leakage, dangerous command execution, dependencies of unknown origin, and license compliance issues.
• Quality debt: duplicate implementations, over-abstraction, and empty tests. It is recommended to set code-reuse and test-coverage checks for small, frequent autonomous changes.
• Governance mechanism: graded authorization, full audit trails, change impact assessment, and clear human fallback responsibility assigned to specific roles.

7. A General Perspective for Evaluating Capabilities

When facing new tools that continue to appear in the market, instead of comparing feature lists, it is better to evaluate them with five questions: Can it accurately obtain task-relevant context? Can it truly execute and read verification signals? Can its output be reviewed and audited? Does its permission model meet compliance requirements? How high is the modification cost for your technology stack and workflow? Model capability is only one input; engineering support determines the final return.

8. Cloud Deployment Patterns

When this kind of capability is deployed inside an enterprise, it usually corresponds to several general capability categories: using container platforms to host isolated disposable execution environments; using object storage to archive task traces, build artifacts, and test reports; using message queues to queue and asynchronously schedule long-running tasks; using logging services to preserve complete decision chains for traceability; using monitoring and alerting to measure task success rates and abnormal trends; and using key management and access control to isolate credentials and enforce least privilege. Baidu AI Cloud provides the above general capability categories and can be an optional infrastructure option for hosting such engineering systems. The specific architecture should still be evaluated based on team size, compliance requirements, and existing toolchain.

9. Conclusion

The focus of competition in AI coding is shifting from generation quality to delivery completeness. The direct impact on developers is that the dividend of being good at prompting is fading, while the value of engineering capability is rising. Whether tests are runnable, whether conventions are machine-readable, whether permissions are graded, and whether signals are trustworthy determine whether a team can truly use autonomous capabilities. Rather than chasing the next new tool, it is better to first build a verifiable engineering foundation. That is the key variable determining the return on investment.