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

Why “Being Able to Write Code” Is No Longer Enough

For the past two years, the most common action for developers using AI coding assistants has remained completion: provide a method signature and let the assistant fill in the method body; describe an API requirement and generate the controller, data transfer objects, and service-layer skeleton; paste an exception stack and ask the model to explain likely causes. Humans still own the engineering process, and the assistant only handles local code.

That division of labor is loosening. When an assistant can read a repository, trace call chains, modify multiple files, and run tests, the competitive focus is no longer just “whose generated snippet looks more human-written.” It becomes whether an assistant can move an engineering task from requirement to a state that can be reviewed, tested, and committed. For Java teams, this change matters more than model leaderboard rankings: production incidents rarely come from whether a single method looks elegant. They often come from misaligned constraints, incorrect transaction boundaries, duplicate requests that are not blocked, or tests that do not cover concurrent paths.

Lower prices or a different base model can reduce the barrier to trial, but they do not explain why end-to-end delivery has become a new evaluation standard. What has really changed is task granularity: developers no longer hand over a piece of code; they hand over a work item with acceptance criteria.

The Essential Difference Between Two Usage Modes

In local completion mode, the responsibility boundary is clear.

• Humans decide which modules to change, whether to add locking, and how to design database constraints.
• The assistant fills in blanks within the visible context.
• Correctness depends on humans selecting, compiling, and manually verifying in the IDE.

In end-to-end delivery mode, the assistant is asked to own a flow, not a function.

• First, locate which layer the problem belongs to: API idempotency, service orchestration, persistence constraints, or message replay.
• Then change code, add tests, explain risks, and finally provide a reviewable diff.
• Humans shift from “writing line by line” to “defining tasks, providing constraints, and accepting results.”

The two modes can coexist. For fixing a null pointer or adding a field mapping, local completion is still efficient. For fixing a cross-layer defect such as “duplicate refund records are created,” asking the assistant to change only one condition inside a service method often treats the symptom rather than the root cause.

Defining the Engineering Task Clearly Matters More Than Stacking Prompts

Most end-to-end delivery failures are not because the model is “not smart enough,” but because the task is not executable. A deliverable instruction should contain at least five things.

1. Phenomenon and scope: which service, which business path, and under what conditions duplication occurs. For example, the order service creates multiple refund records for the same order when a timeout retry occurs or a user clicks repeatedly.
2. Invariants: what must hold. A single business refund number should have at most one successful or processing record in the refund table; duplicate requests should return the existing result instead of inserting another record.
3. Allowed change boundaries: controllers, services, mappings, and database constraints may be changed; payment channel integrations, reconciliation jobs, and historical data repair scripts are out of scope unless separately authorized.
4. Acceptance method: which tests must pass, and which logs or metrics indicate that no new failures have been introduced.
5. Prohibitions: do not delete validation just to make compilation pass; do not relax permissions; do not write secrets or connection strings into code or commit messages.

An illustrative task can be written like this. It describes engineering constraints, not the usage of a specific product:

Fix duplicate refund records in the order service.
First analyze whether controller input, service-layer transactions, persistence writes, and database unique constraints are aligned.
Goal: only one valid record is allowed for the same refund business key of the same order; duplicate requests return the existing refund.
Add concurrency and duplicate-submission tests. Do not change payment channel protocols or perform historical data cleanup.
Output: root cause, changed files, test results, and risks that still require human confirmation.

The more the instruction resembles a work ticket, the less likely the assistant is to “look fixed” at the wrong layer.

Build Context Before Changing Code

Defects in Java services often span layers. If you paste only the service class to the model, it may patch an in-memory check while failing to see whether the database allows duplicate inserts, or whether the client automatically retries after a gateway timeout.

A safer reading order is:

• Entry point: how the controller or message consumer generates the business key, and whether retries carry the same key.
• Application service: where the transaction starts and commits; whether the code checks before inserting, and whether there is a concurrency window between the check and the insert.
• Persistence layer: whether the insert statement relies on the database to reject duplicates or only on an application-layer if check.
• Constraints: whether the columns covered by the unique index are exactly the business idempotency key; whether soft deletes or status fields can make the unique constraint ineffective.
• Callers: whether the timeout is longer than the server processing time, creating a situation where “the service succeeded but the caller treated it as failed and sent another request.”

A common root cause is that check-then-insert does not provide idempotency under the default isolation level. Two requests both see that the record does not exist, and both insert successfully. The correct enforcement point is usually to create a unique constraint on a stable business key, and when an insert conflict occurs, read back the existing record by that key and return it instead of throwing the exception as a new failure. The application layer can still perform a fast-path check, but the database constraint must be the final arbiter.

The sample code only expresses the idea; it cannot replace verification of the transactions and indexes in the actual repository:

public RefundView createRefund(CreateRefundCommand cmd) {
    String key = cmd.orderId() + ":" + cmd.refundBizNo();
    try {
        Refund saved = repository.insert(cmd.toNewRefund(key));
        return RefundView.from(saved);
    } catch (DuplicateKeyException ex) {
        return RefundView.from(repository.findByBizKey(key)
            .orElseThrow(() -> ex));
    }
}

If the unique index does not include the correct columns, this catch block is meaningless. If the insert runs only at the end of a large transaction, the read after the conflict may see an uncommitted or rolled-back intermediate state. The assistant must look at constraints, transactions, and exception types together, not just generate a catch block.

Verification Loop: A “Fix” Without Tests Is Not Delivery

The minimum standard for end-to-end delivery is not that the diff looks reasonable, but that the behavior is pinned down by tests. For duplicate refunds, at least three types of cases should be covered.

• Sequential duplicates: the same business key is called twice in succession; the second call returns the refund identifier from the first call, and the table still has one row.
• Concurrent duplicates: two threads submit at the same time; the final result is one row, and no unhandled constraint exception leaks to the API layer.
• Different business keys: two independent refunds for the same order should still succeed, so the unique constraint is not tightened too far.

Tests should hit real constraints, not mock out the entire persistence layer. An in-memory fake implementation will not throw a unique conflict, and it can make an incorrect implementation pass. Integration tests can use an embedded database or a team-standard test database, asserting row counts, statuses, and returned identifiers.

Beyond tests, check side effects: whether the channel was charged more than once, whether domain events were emitted repeatedly, and whether an idempotency failure was recorded as a system error that triggers infinite retries. The assistant should list these checks in the change description; tests that were not run must be marked “not executed,” not written as passed.

Human Review Is Still Required

Handing a task to an assistant does not cancel review. The review focus shifts from “is this line syntactically correct” to the following items.

• Whether invariants are actually protected by constraints, not merely declared in comments.
• Whether failure semantics are stable: whether a duplicate request returns 200 with the existing refund number or 409. Both can be acceptable, but they must be consistent with the caller’s contract and must not change from one day to the next.
• Whether the transaction scope has grown: wrapping external calls in a local transaction for convenience increases lock hold time.
• Permissions and data scope: whether a tenant condition was removed while fixing a query.
• Rollback safety: whether an index change on a large table needs a separate change window and cannot be tied to the same irreversible release as business code.

A practical review checklist is short: does the root cause match the phenomenon, do constraints align with the business key, do tests hit concurrency, are error codes compatible, and have new external calls been introduced? If any item cannot be explained clearly, send it back instead of merging because the diff is short.

How Teams Can Make End-to-End Delivery a Habit

A beautiful fix in a single conversation is not reproducible. Teams need to embed the assistant into existing engineering discipline, not create a separate process.

Task templates. Write separate templates for defects, small features, and refactoring. A defect template requires the phenomenon, reproduction steps, invariants, and forbidden change scope; a small-feature template requires the API contract and compatibility strategy. Templates stored in the repository drift less than templates stored in personal prompt collections.

Context sources. The assistant should be allowed to read repositories, build files, tests, and API documentation, not raw production logs pasted at will. Logs should first be sanitized to remove ID numbers, phone numbers, tokens, and internal addresses. For connection information involving configuration centers, secret management, and object storage, describe only “where to read it from,” not the values.

Verification commands. Agree on the minimum set the assistant should run before committing, such as relevant module tests and static checks. If it cannot run them, state the environment gap instead of skipping them. Continuous integration remains the final gate; the assistant’s local result is only a pre-check.

Change descriptions. Require a fixed structure: problem, cause, changes, tests, risks, and rollback. Reviewers should read the cause and risks first, then the code. This also discourages the assistant from hiding real logic changes behind large blocks of irrelevant formatting.

Measure delivery, not generated lines. More useful metrics are whether a task merges without rework, whether defects recur on the same business key, how many review round trips occur, and what proportion of assistant changes are overridden by humans. Faster generation with more rollbacks means task boundaries or verification have not kept up.

Tasks Suitable for Assistants, and Tasks That Are Not

Suitable: defects with a relatively concentrated root cause, repetitive boilerplate changes, adding tests, adding API adapters in an existing style, and small-step refactoring under a clear contract.

Not suitable for direct “one-click delivery”: changes to financial definitions, permission model adjustments, data migrations across multiple teams, intermittent failures without a reproduction path, and reconciliation discrepancies that require production data to diagnose. For these, the assistant can produce investigation notes and candidate options, but option selection, change windows, and data repair must remain human-owned.

The criterion is simple: if the cost of failure is mainly compilation errors or red tests, let the assistant go further; if the cost is financial loss, unauthorized access, or irreversible data damage, humans must first write invariants into constraints that automatically reject incorrect implementations.

Common Pitfalls in Adoption

Fixing only the symptom layer. Adding debounce at the API layer while the database can still insert two rows and message replay can still double-write. Debounce is an experience optimization, not a consistency solution.

Context that is too narrow or too broad. Giving only one class leads to one-sided conclusions; stuffing an entire monorepo into the conversation without discrimination drowns key constraints in noise and increases the exposure surface for sensitive information. Collect context along call chains and limit secrets and production data.

Replacing design with generation. If the idempotency key is chosen incorrectly, the subsequent code and tests will diligently implement a wrong rule. The business key should be confirmed by someone familiar with the order lifecycle: is it the refund application number, or the order number plus reason plus amount? If the amount participates in the business key, the amount unit and rounding must be decided first.

False completion. The assistant claims tests passed, but there is no test report in the workspace, or tests were skipped. Deliverables must be reproducible by a third party: commands, results, and uncovered items.

Ignoring runtime companions. Even after code idempotency is in place, caller retry policies, message delivery semantics, and gateway timeouts must still be reviewed together. Otherwise, the database may keep only one row while upstream systems continue to treat “processing” as failure and keep hammering the service.

Working with Cloud Engineering Environments

End-to-end delivery does not depend on a single chat window; it depends on the surrounding engineering environment: code repositories, build and test systems, logs and monitoring, configuration and secret management, and artifact release. In the industry, these capabilities are usually combined from code hosting, continuous integration, logging services, monitoring and alerting, container platforms, and configuration management. The assistant can read build failures and test reports, but it should not replace these systems as the source of truth.

In practice, the workflow can be connected like this: write the phenomenon and business key in the defect ticket; start changes in the repository using task templates; run module tests locally or in the pipeline; search logs by business key to see whether duplicate writes decrease; and still release through existing change windows. If your organization uses cloud engineering and operations capabilities such as Baidu AI Cloud, the same principle applies: the assistant produces candidate changes, and the pipeline, monitoring, and human review decide whether they enter production. Do not put unconfirmed private APIs, billing details, or performance numbers into the plan, and do not let the assistant hold production permissions directly.

Conclusion

The next stage of AI coding will be measured by whether a task can move from requirement to reviewable, testable, and committable, not by whether a single completion is impressive. For Java developers, this means making idempotency, transactions, constraints, and tests part of the task, letting the assistant change code within boundaries, and having humans and the pipeline accept the invariants. Local completion is still valuable; when a problem spans multiple layers, upgrading from “write a method” to “deliver a behavior protected by constraints” is the usage worth investing in.