From Code Completion to End-to-End Software Delivery

1. From Code Completion to Task Delivery

Over the past two years, developers’ use of AI coding tools has broadly evolved through three stages.

The first stage is code completion: the tool predicts the next piece of code based on the context near the cursor, and the developer reviews each suggestion. The second is snippet generation: the developer describes a requirement in natural language, and the tool generates a class, interface, or test case. The developer then integrates that output into the project. The third is task execution: the developer provides an engineering task with goals, constraints, and acceptance criteria, and the tool is expected to inspect the codebase, modify files, run commands, and use failure information to make corrections.

The key difference between these stages is the division of responsibility. In the first two, people control the engineering workflow while the model produces local output. In the third, the model takes on some of the workflow itself, so the criteria for evaluating it also change. The question is no longer simply whether the generated code looks plausible. It is whether the tool can deliver a result that is reviewable, testable, and ready to submit.

2. Structuring a Task Instruction

Consider a common issue in a Java backend: a client retries a refund request after a network timeout, causing multiple refund records to be created for the same transaction.

A complete task instruction typically includes:

• Problem description: The observed behavior, its impact, and the steps to reproduce it.
• Scope of investigation: The layers to inspect, such as the controller, service, mapper, and database constraints.
• Boundaries: Modules, configuration files, and production-related resources that must not be changed.
• Change principles: Make the smallest necessary change, avoid unrelated refactoring, and preserve compatibility with external interfaces.
• Verification requirements: Add tests for duplicate and concurrent requests, and run the relevant unit and integration tests.
• Deliverables: A list of changed files, test results, and any remaining risks.

This structure clarifies both what needs to be done and what counts as complete. Without boundaries, the work can expand beyond its intended scope. Without acceptance criteria, the result may stop at “it looks correct.”

3. Five Stages of Task Delivery

A reliable task execution process can be divided into five stages:

1. Break down the requirement. Turn the task into verifiable subgoals. For “fix duplicate refunds,” these might include finding the duplicate-write entry point, checking for an idempotency key, adding a unique constraint, and writing a concurrency test.

2. Inspect the code and trace the call path. Starting from the entry point, follow transaction boundaries, remote calls, message delivery, and database writes. Duplicate records may result from retries before a transaction commits, so inspecting a single method may not reveal the root cause.

3. Make the smallest necessary change. Keep the changes within a defined file scope. If a database schema change is required, provide a migration script and rollback plan, and back up the data before applying the change.

4. Run and verify. Run unit tests, integration tests, and static checks. When a test fails, use the failure output to identify the cause and revise the implementation rather than relying on someone to guess through the code line by line.

5. Document the delivery. List the changed files, test scenarios covered, scenarios not covered, and any remaining risks.

4. Example: Enforcing Idempotency with a Unique Constraint

An application-level “check, then write” flow is not reliable under concurrency. Two requests may both check that a record does not exist and then both insert one. A database unique constraint is therefore needed as the final safeguard for idempotency.

First, add a unique index for the idempotency identifier. The following is a generic SQL example. Before running it, check for and clean up any existing duplicate data:

-- Back up the table and confirm there are no duplicate refund_request_no values first
ALTER TABLE refund_record
    ADD UNIQUE KEY uk_refund_request_no (refund_request_no);

Then handle conflicts in the service layer. If the unique constraint is violated, return the existing record instead of propagating an exception:

public RefundResult createRefund(RefundCommand command) {
    Optional<RefundRecord> existing = repository.findByRequestNo(command.requestNo());
    if (existing.isPresent()) {
        return RefundResult.of(existing.get());
    }
    try {
        RefundRecord record = RefundRecord.pending(command);
        repository.insert(record);   // The uk_refund_request_no unique index is the final safeguard
        return RefundResult.of(record);
    } catch (UniqueConflictException ex) {
        // A concurrent request inserted the record first; return the existing record
        return RefundResult.of(repository.findByRequestNo(command.requestNo()).orElseThrow());
    }
}

UniqueConflictException is an exception defined by the project. The data access layer translates the database-specific unique-constraint error into this exception, keeping the business logic independent of the underlying data access implementation.

A concurrency test should start multiple threads with the same request and then check the outcome:

void concurrentSameRequestCreatesOneRecord() throws Exception {
    int threads = 20;
    ExecutorService pool = Executors.newFixedThreadPool(threads);
    CountDownLatch start = new CountDownLatch(1);
    List<Future<RefundResult>> futures = new ArrayList<>();
    for (int i = 0; i < threads; i++) {
        futures.add(pool.submit(() -> {
            start.await();                       // Start all requests together after every thread is ready
            return service.createRefund(sameCommand);
        }));
    }
    start.countDown();
    for (Future<RefundResult> f : futures) {
        f.get();                                 // Wait for completion; exceptions are raised here
    }
    pool.shutdown();
    assertEquals(1, repository.countByRequestNo(sameCommand.requestNo()));
}

Two details matter when designing this test. First, the test database should use the same storage engine and isolation level as production. Differences in locking behavior may cause the issue to disappear in the test environment. Second, also test sequential duplicate requests: submit the same request again after the first has completed and verify that the returned result is consistent.

5. How to Evaluate Task-Oriented Coding Tools

Five dimensions can help determine whether a task-oriented coding tool is suitable for an engineering workflow:

• Verifiability: Can the tool run tests and iterate based on their results?
• Scope control: Can it follow restrictions on files and configuration it must not change?
• Traceability: Are changes recorded clearly enough to review and compare?
• Auditability: Can commands run, logs read, and decisions made during execution be replayed and inspected?
• Failure handling: When tests fail, does the tool investigate the root cause, or does it change assertions, delete tests, or mock away the behavior being tested just to make the tests pass? The latter actions undermine the tests and deserve close scrutiny.

Together, these dimensions assess whether the process is trustworthy, not just whether the final output looks polished.

6. Key Risks and Mitigations

Task-oriented tools introduce risks that differ from those associated with traditional code completion.

Unauthorized changes. A tool may modify files outside the task’s scope. Mitigate this by limiting repository permissions, allowing access only to a feature branch, and blocking access to production configuration and secrets.

Passing tests does not guarantee business correctness. Tests can only validate the scenarios they cover. Critical paths involving funds, inventory, and permissions require human review and additional tests of business rules.