A days-long AI coding task needs a plan for the middle

The new claim is about staying with the problem

Google announced Gemini 4 Carbon on October 28, describing stronger cybersecurity and long-horizon engineering capabilities. The company reports that internal teams have seen the model work for days on complex tasks. Its announcement describes an initial rollout to selected cyber defenders and trusted partners, with broader product availability still to come. It also reports improvements in alignment and unsupported claims from internal evaluations. Those are vendor findings; we have not independently reproduced them.

For anyone who builds software, the interesting practical question is what happens during a long assignment. A short coding exchange lets you see the proposal almost immediately. A longer task can contain investigation, abandoned approaches, edits, dependency changes, tests, and decisions about what to leave alone. Even if the model is more capable, the person responsible for the software still needs to understand the path to the result.

Our recommendation is to write a plan for the middle of the task. Specify the evidence the assistant should preserve, the conditions that trigger a review, and the changes that remain outside its authority. This is a general delegation method inspired by the announcement, not a claim that Carbon exposes a particular checkpoint interface.

You can practice it with tools you already have. No early access is required. Choose an isolated, non-production software task, keep a human responsible for accepting the result, and make the assignment observable before making it longer. The goal is useful sustained work that remains understandable when you return.

Source: Google: Gemini 4 Carbon announcement and rollout ↗ · NIST: Secure Software Development Framework ↗

Write a completion statement a reviewer can check

Consider a hypothetical student club website that sometimes sends duplicate confirmation emails. “Fix the email system” is too broad to serve as a useful contract. A clearer statement would say: identify why one signup can produce duplicate messages, propose a small repair, and demonstrate the expected behavior with a repeatable local example.

That statement names a symptom, a scope, and a form of evidence. It does not tell the assistant which cause to find. Perhaps the issue is repeated submission, a retry path, or an interaction between two components. Keeping the cause open allows investigation; keeping the acceptance condition clear prevents the task from expanding into a complete redesign.

Add explicit boundaries. The hypothetical task should not send real messages, change live credentials, modify billing, or deploy to production. It can use a local test inbox or a stub chosen by the developer. The particular boundaries should match the real project, but the principle is stable: permission to investigate is not permission for every action that might shorten the investigation.

Now write what counts as unfinished. If the duplicate cannot be reproduced, the deliverable may be a documented investigation and a minimal reproduction proposal rather than an asserted fix. That result is less exciting than a confident patch, but it is more useful than a change justified by an invented cause.

Finally, identify the accepting reviewer. A task that lasts a long time can otherwise end with an ambiguous handoff: the assistant says it is done, a teammate assumes someone else checked it, and the change drifts toward release. One named acceptance role makes the final decision concrete.

Use checkpoints when the meaning of the work changes

A fixed timer can be helpful, but time alone does not describe project risk. Our suggested checkpoints occur when the task changes meaning: after the initial reproduction, before a larger redesign, when a new dependency becomes necessary, or when the proposed repair changes a public interface. These are decision points at which a person might reasonably choose a different path.

For the duplicate-email example, the first checkpoint could contain the reproduction steps and the observed result. The second could describe two possible repairs and why one is smaller. The third could show the final behavior and remaining limitations. These are proposed artifacts, not a requirement to stop every few minutes or to seek approval for routine reversible edits.

Ask for a short decision note at each meaningful branch. What evidence prompted the change? What option was rejected? Which assumption remains unverified? This can be a few sentences. Long transcripts are not automatically more informative than concise notes that explain why the implementation changed direction.

A good checkpoint should reduce the next reviewer’s work. If it merely says “continuing investigation,” it does not help someone decide whether the scope still makes sense. If it identifies that the bug only appears after a particular retry sequence, the reviewer can inspect the next step with a specific question in mind.

Do not turn this into a demand for private model reasoning. The useful record is observable work: commands run, files changed, test inputs, outputs, and decisions that affect the deliverable. You need an engineering trail that another person can inspect, not an imagined transcript of internal thought.

Treat evidence as a deliverable alongside code

NIST’s Secure Software Development Framework describes practices for reducing software vulnerabilities throughout development. It provides a useful independent anchor for treating security as part of the workflow rather than a final decoration. It does not certify an AI model, and citing it does not establish that a generated patch follows every practice.

For our hypothetical task, an evidence bundle could include the original reproduction, the changed files, the tests actually executed, and a concise explanation of what was not tested. Keep these attached to the same version of the patch. A test log from an earlier attempt should not silently become proof for a later implementation.

Separate execution from suggestion. “Add a regression test” is a recommendation. “The regression test passed” is an observation that should have a corresponding result. If the environment prevented execution, preserve the exact limitation. A reviewer can often finish a blocked check quickly when the missing condition is specific.

Avoid expanding the bundle into an archive nobody will read. Include the evidence needed to assess the stated completion condition. If a large log matters, point to the relevant result and retain the full artifact separately. If a screenshot matters, explain what behavior it captures and what it cannot prove.

This approach also makes a rejected patch useful. You may decide that the implementation is too broad, yet retain a valid reproduction and a clearer account of the bug. Sustained AI work should create inspectable knowledge even when its first proposed code change is not the one you keep.

Give the task a budget for uncertainty

A long task can spend its time resolving the wrong unknown. To make that visible, list the assumptions most likely to invalidate the plan. In the email example, one assumption might be that the duplicate arises inside the application rather than from the external mail service. Another might be that the reported behavior still occurs in the current version.

Assign each uncertainty a next observation. Reproduce the behavior in a controlled environment. Inspect whether two application events are recorded for one signup. Compare the intended retry behavior with the actual one. These are examples of questions, not a diagnosis of a real system. The point is to connect investigation time to a shrinking set of unknowns.

Set a stopping condition that returns useful work. If an essential service cannot be accessed, ask for the reproduction attempt, the access limitation, and the smallest next check a person can perform. If two causes remain plausible, ask for an experiment that would distinguish them. Repeatedly trying unrelated edits is not progress merely because the task is still active.

A budget can be expressed in elapsed time, resource spending, or scope. For a small project, you might allow one bounded investigation session before reviewing the evidence. Do not copy a generic number from someone else’s project. Choose a limit that makes the potential value and the cost legible to the person who owns both.

When the task resumes, preserve continuity with a short status note. State the current hypothesis, the latest accepted artifact, and the next planned observation. This is especially helpful when a human picks up the work. The project should not depend on one uninterrupted conversation to remain understandable.

Keep stronger capability separate from broader authority

The ethical issue in a longer coding assignment is not only whether the model can solve it. It is who bears the consequences of the actions taken along the way. More persistence may justify attempting a harder investigation. It does not by itself justify access to customer records, permission to contact users, or authority to change a live service.

Use the least consequential environment that can answer the technical question. For the fictional website, a local reproduction with synthetic signup data is preferable to experimenting on actual registrations. If real data is essential, the responsible team should decide what access is appropriate. The assistant should not infer that necessity from convenience.

Also consider the people who will maintain the result. A patch that only its generator can explain creates a handoff burden. Ask for ordinary code, a clear account of behavior changes, and documentation proportionate to the change. Avoid making the demonstration impressive at the cost of leaving the maintainers unable to support it.

Stronger vendor safety results can inform your interest in a model, but they do not erase the need to define local authority. A benchmark or internal evaluation has its own scope. Your application has its own users, data, and operational limits. Keep both scopes visible rather than treating either as a complete substitute for the other.

For students and solo builders, this can be lightweight. A branch, synthetic inputs, a written completion statement, and a final review may be enough for a small exercise. The objective is to make responsibility clear without creating an elaborate process that overwhelms the work.

Rehearse the assignment and review the handoff

A useful final review can be organized around four ordinary questions. What did we ask for? What did the assistant actually change? What evidence supports the change? What responsibility remains with us? These questions keep the discussion connected to the project rather than to an abstract opinion about AI.

For the fictional email defect, a reviewer might accept the local reproduction but reject a repair that introduces a new service. That is a productive outcome. The investigation reduced uncertainty while the proposed implementation exceeded the project’s needs. Record both judgments, so the useful evidence survives the rejected design.

A second reviewer might agree with the repair but notice that the test only covers the first submission. That should trigger a targeted follow-up on the retry behavior, not an automatic restart of the entire investigation. The checkpoint record makes it easier to identify exactly which part is incomplete.

Treat documentation the same way. Ask whether a maintainer can locate the changed behavior and understand the remaining limitation. If the answer is yes, adding more prose may not improve the handoff. If the answer is no, a short example can be more valuable than another broad explanation.

This acceptance conversation is where sustained work becomes accountable work. The assistant can supply the artifacts, but the project owner decides whether those artifacts meet the actual need. Keeping that decision explicit is useful even when the patch is small and the review takes only a few minutes.

Choose a small repository you own and a harmless defect or improvement. Before opening an assistant, write the current behavior, the desired behavior, and one condition that must remain unchanged. Then name the evidence you would need to accept the result. This preparation should be short enough that you will actually do it.

Run the task in an isolated branch. Ask the assistant to preserve a reproduction, explain material scope changes, and report executed checks separately from unexecuted recommendations. Let it make routine reversible progress within the stated boundaries. Review only at the meaningful decision points you selected, so the experiment tests delegation rather than constant supervision.

At the end, put the proposed patch aside and read the evidence first. Can you tell what changed and why? Can you identify a remaining uncertainty? Can another person rerun the important check? Then inspect the code. If the explanation and the implementation disagree, resolve that disagreement before accepting either.

Now compare the experience with your usual process. Did the task save investigation time? Did review become easier or harder? Were there moments when the assistant needed broader context? These are observations you can make without pretending that one exercise predicts a model’s performance on every project.

The useful lesson from a longer-running AI announcement is that the middle of the task deserves design. Plan the checkpoints, preserve the evidence, and keep acceptance attached to a person. Then additional capability has a clear place to create value.