From Autocomplete to Digital Teammates: Who Owns the Outcome?

AI coding systems have crossed from suggestion into delegated execution. Autocomplete completed a line; today an agent can inspect a repository, edit several files, run tests, observe failures, revise its work, and return a reviewable change.

That is a real change in the unit of work. It does not transfer ownership.

“Digital teammate” is therefore a status a system must earn, not a synonym for a capable model and not a claim of personhood. Current evidence supports useful bounded agency: the system may choose how to execute a task inside a defined boundary, while people and organizations still own the goal, context, verification standard, authorization, accountability, and consequences.

The practical question is not, “Does the agent feel like a colleague?” It is:

This essay stays inside software delivery, where work is unusually observable. It does not claim that code tests settle product judgment, legal responsibility, or social impact. Coding is useful precisely because repositories, tests, sandboxes, logs, and pull requests let us inspect what delegation does—and where it stops.

A model alone is not the relevant unit. The smallest complete operating model has five parts: a person or organization sets a goal; an agent chooses and executes steps; a target system changes; the environment observes that state as evidence outside the agent’s own prose; and an accountable person or organization decides whether to accept, revise, roll back, or stop.

The key edge is target system → external evidence. A fluent explanation of success is not success. A passing regression test, a clean build, a staged replay, a measured response, or a rejected unauthorized action is evidence when the observation comes from a trusted boundary with enough independence from the claim being evaluated. A test written by the same agent is a useful candidate, but its assertion and failure mode still need review or an independent check; existing tests and authoritative state are stronger evidence.

The return edge matters just as much. Evidence does not make the decision. It informs the named human or organization that owns the result.

The history is best compressed into inflection points, not a parade of model releases.

• Language became a programmable interface. The Transformer made large-scale sequence modelling practical, then GPT-3 demonstrated broad task adaptation from instructions and examples (Vaswani et al., 2017; Brown et al., 2020).
• Code made claims executable. Early Codex results paired generated programs with tests, revealing that generation, selection, and verification were different jobs (Chen et al., 2021).
• Reasoning connected to action. ReAct interleaved reasoning with environment actions, while function calling gave models structured interfaces to software rather than leaving actions as prose (Yao et al., 2022; OpenAI, June 2023).
• Tools gained context and a safe place to run. Model Context Protocol provided an open protocol for connecting AI systems to data sources and tools (Anthropic, November 2024). Isolated worktrees and sandboxed execution later made iterative repository work more containable (OpenAI, February 2026).
• The interface became a command center. Agent products began organizing parallel tasks, persistent instructions, scheduled work, diffs, and review queues instead of centring one completion at the cursor.

The durable transition is:

BEFORE: suggestion

Developer drives -> model suggests -> developer integrates and proves

AFTER: bounded delegation

Owner defines -> agent executes -> environment proves -> owner decides

The “after” state does not remove the developer. It moves the developer upstream into task framing and downstream into evidence-based judgment.

On 2 February 2026, OpenAI described the Codex app as a command center for multiple agents. Its architecture exposes the important parts: separate tasks, parallel execution, isolated worktrees, reusable skills, scheduled automations, reviewable diffs, sandboxing, and permission prompts for elevated actions. Automations return results to a review queue. This is not proof that every task succeeds, but it is a concrete architecture for delegated work rather than interactive autocomplete (OpenAI, February 2026).

The original five-box model needs three enabling components: context tells the loop how this repository works, tools let it affect the world, and a runtime gives actions state, compute, isolation, and feedback.

Anthropic’s 16 June 2026 analysis supplies complementary behavioural evidence. Across roughly 400,000 interactive Claude Code sessions, its classifiers attributed about 70% of planning decisions to people and about 80% of execution decisions to Claude. In ordinary language: people mostly decided what to do; the agent mostly decided how to do it (Anthropic, June 2026).

That division of labour is the strongest affirmative case for the phrase “digital teammate.” It is more than suggestion because execution decisions and tool actions have moved into the system. It remains bounded because planning, acceptance, and consequences have not.

Anthropic’s earlier engineering guidance offers a useful architectural distinction. A workflow follows predefined code paths; an agent dynamically directs its own process and tool use. It also warns that agentic systems trade latency and cost for task performance, so teams should add autonomy only when simpler approaches are insufficient (Anthropic, December 2024). Agency is therefore not a badge of sophistication. It is a design choice with a bill and a failure surface.

Consider a hypothetical but realistic defect in a mature checkout service. A background worker retries a timed-out payment request. Under a rare race, two workers can observe the same stale state and both attempt delivery. Years of repository conventions encode idempotency, migration rules, telemetry names, and release constraints that are not visible in the ticket.

Without delegation, a maintainer reproduces the race, traces the state transition, finds the owning module, changes the guard, adds a concurrency regression test, runs focused and full suites, prepares a staged replay, explains risk, and opens the pull request. Product cost: the duplicate-attempt risk remains while one scarce expert owns every mechanical step. Engineering cost: deep expertise is consumed by search, editing, command execution, and evidence collection.

With bounded delegation, the maintainer writes the outcome and forbidden conditions: reproduce the duplicate attempt; preserve legitimate retries; change no public contract; pass existing checks; show a deterministic concurrency test; stop before deployment. The agent searches, edits, tests, and revises inside an isolated worktree. It returns a diff, the failing-before/passing-after regression test, suite results, and staged replay evidence. The maintainer judges whether the implementation respects the domain’s idempotency contract and whether the evidence is enough.

MATURE-REPO BUG FIX

Before
  expert context -> reproduce -> trace -> edit -> test -> replay -> review
  Product cost: risk waits. Engineering cost: expert drives every operation.

After
  expert goal + constraints -> agent loop -> test + replay evidence -> review
  Product cost: same boundary. Engineering cost: expert judges exceptions.

This scenario earns delegation only if the agent reduces total human attention after review and correction. A large diff that transfers search time into review time is not leverage. It is work-in-progress delivered to a new queue.

The same Anthropic study that shows substantial delegation also shows why “teammate” must remain conditional. Its strictest transcript-based measure—judged success plus at least one hard signal such as tests, matching Git activity, or explicit user confirmation—reached only 28–33% for sessions rated intermediate through expert. More importantly, Anthropic states that it does not observe real-world outcomes: whether the code was later used, discarded, or created economic value. Every classification also depends on a model reading the transcript (Anthropic, June 2026).

Expertise did not disappear. Expert users were more successful and recovered from trouble more often. The evidence supports a division of labour—human planning and domain judgment, agent execution—not autonomous ownership of the whole result.

METR’s task-completion time horizon adds a different limitation. A 50% time horizon is the human-expert duration at which an agent is predicted to succeed half the time on a suite of self-contained, automatically evaluated software, machine-learning, and cybersecurity tasks. METR’s page, updated 8 May 2026, warns that measurements above 16 hours are unreliable with its current suite. It also says the model list is not comprehensive (METR, May 2026).

A time horizon is useful capability evidence. It is not a promise that an agent can own an equally long task in a mature repository, discover unstated requirements, satisfy a reviewer, or absorb production consequences.

Benchmark quality itself is moving ground. On 23 February 2026, OpenAI stopped reporting SWE-bench Verified because flawed tests and contamination weakened its signal. On 8 July, after recommending SWE-Bench Pro, OpenAI reported that roughly 30% of that benchmark’s tasks appeared broken and retracted the recommendation (OpenAI, February 2026; OpenAI, July 2026). If an evaluation cannot reliably distinguish a correct solution from a benchmark defect, its score cannot carry organizational trust by itself.

The most instructive comparison is not between marketing claims. It is between controlled studies that asked different questions.

Peng and colleagues recruited developers to implement a bounded JavaScript HTTP server. Participants with GitHub Copilot completed the task 55.8% faster than the control group (Peng et al., 2023).

METR later studied 16 experienced open-source developers working on 246 real issues in repositories averaging more than one million lines. With early-2025 AI tools available, they took 19% longer. Before the study they expected a 24% speed-up; afterward they still believed AI had made them 20% faster (METR, July 2025).

Vendor telemetry shows that interfaces and behaviour have changed. It does not directly show productivity.

OpenAI reported on 25 June 2026 that, by May, 80.6% of sampled individual Codex users had made at least one request estimated to exceed 30 minutes of human work; 70.2% exceeded one hour; and 25.6% exceeded eight hours. Its heaviest internal daily users generated more than 60 hours of parallel agent turns per day. Those task horizons were estimated by an LLM reading transcripts, should be treated as directional, and used a random 0.1% sample of individual-user queries (OpenAI, June 2026).

Those numbers measure adoption, activity, estimated task length, and parallel runtime. They do not measure accepted pull requests, escaped defects, customer outcomes, review time, or net economic value. Sixty agent-hours can represent enormous leverage, enormous review inventory, or both.

The unit that matters is not tokens, generated lines, sessions, or agent-hours. It is:

Verified outcomes delivered per unit of scarce human attention, inside an acceptable risk boundary.

That metric forces the hidden costs back into view: writing the task, supplying context, reviewing the diff, correcting errors, waiting for runs, recovering from failures, and maintaining the control system.

Context, tools, and runtime make execution possible. They do not make it safe. The model becomes teammate-shaped only when authority is narrow, actions are auditable, and uncertainty has a named escalation path.

The earlier loop is unchanged. Governance wraps it with constraints and records. Least privilege narrows possible damage. The audit trail makes actions attributable and reconstructable. Escalation makes “I cannot safely continue” a correct outcome rather than a failure to be optimized away.

The same system in plain text:

NIST’s AI Risk Management Framework makes the accountability boundary explicit: roles and lines of communication should be documented, oversight should be defined, and executive leadership takes responsibility for decisions about risks associated with AI-system development and deployment. Documentation can improve human review and bolster accountability (NIST AI RMF Core). The system can be auditable. The model is not accountable. Named people and organizations are.

A useful agent interface should show commitments, evidence, limits, and exceptions—not celebrate activity volume.

The valuable view is not “agent busy for six hours.” It is “bounded task, current state, decisive evidence, remaining uncertainty, authority used, and next accountable decision.”

These patterns should be used because they clarify software responsibility, not because an agent organization resembles a human organization.

• Single Responsibility Principle (SRP). Goal framing, execution, evidence collection, and acceptance are distinct responsibilities. Keeping them separate makes it clear which component may change code and which authority may approve the result.
• Don’t Repeat Yourself (DRY). One authoritative acceptance contract should feed tests, reviewer criteria, runtime checks, and status reporting. Copying the rule into prompts, CI, dashboards, and runbooks creates drift exactly where proof needs consistency.
• Inversion of Control and Dependency Injection (IoC/DI). Agent logic should depend on narrow tool interfaces; the runtime injects repository, shell, test, and external-service adapters appropriate to the task. Swapping a production-capable adapter for a read-only or sandbox adapter changes authority without rewriting reasoning logic.
• Publish/Subscribe and event-driven design. When a real broker or event bus exists, test completion, policy denial, deployment state, and runtime alarms can publish events to independent audit, evaluation, and escalation subscribers. A synchronous call to one reviewer is not PubSub; retries, idempotency, ordering, and dead-letter handling must be explicit.
• Model–View–Controller (MVC). Here, “model” means task and evidence state, not the language model. A controller advances the workflow under policy; the command-center view renders status and asks for decisions. This separation prevents UI activity from becoming workflow truth.

Together, these patterns make the system easier to constrain, test, replace, and audit. They do not make its output correct. External evidence and accountable acceptance still close the loop.

Do not award the label after one impressive run. Look for five properties across recurring work:

1. Recurring scope. The system can take a recognizable class of tasks, with a stable boundary and definition of done—not merely one curated prompt.
2. External outcome proof. Success is demonstrated by tests, runtime behaviour, customer-visible state, reconciled records, or another signal outside the agent’s narrative.
3. Human-attention leverage. Total framing, monitoring, review, correction, and recovery effort is lower than doing the work through the previous path.
4. Safe escalation. Missing context, conflicting evidence, policy denial, and boundary crossings return control to a named person before consequential action.
5. Least privilege, audit, and rollback. The system receives only needed authority; actions and evidence are attributable; reversible work can be restored; irreversible steps stay human-gated.

Teams may preregister their own thresholds—maximum review time, required checks, acceptable retry count, allowed tools, rollback time, or outcome error budget—before comparing workflows. Those are team-selected operating thresholds, not universal empirical constants.

Failure on one property does not make the system useless. It tells you what it is. A fast generator without external proof is a copilot. A capable agent with broad credentials but no safe escalation is an operational risk. A well-governed loop that increases review load is an experiment, not yet leverage.

Delegate when the outcome can be stated, the task boundary is enforceable, actions are reversible or human-gated, the environment can produce decisive evidence, and expected review plus recovery costs are lower than direct execution.

Keep the human in the execution loop when requirements are unstable, crucial context remains tacit, correctness cannot be observed soon enough, permission cannot be narrowed, or failure has irreversible legal, financial, safety, or customer consequences.

For the mature-repository bug, that rule produces a concrete contract:

1. Give the agent the bug report, repository standards, relevant logs, and a sandboxed worktree.
2. Allow repository reads, scoped edits, and test commands; deny deployment and production writes.
3. Require a deterministic failing-before/passing-after test, focused checks, full-suite evidence, and a staged replay.
4. Stop on ambiguous idempotency semantics, migration need, flaky proof, broader file scope, or permission denial.
5. Let the maintainer decide whether evidence supports acceptance, more investigation, rollback, or rejection.

That is teammate-shaped work without pretending the system owns the business consequence.

We now have systems that can carry more of the work loop: context loading, planning within a goal, tool use, editing, execution, environmental feedback, retries, and evidence packaging. Product architecture and usage telemetry both show the shift from interaction to delegation.

We also have equally important counter-evidence. Verified transcript signals are not the same as real-world outcomes. Time-horizon benchmarks are bounded abstractions. Benchmark datasets can become contaminated or broken. Productivity changes across task populations, tools, repositories, and verification burdens. Expertise remains load-bearing.

So “digital teammate” should name an operating model, not a personality. The agent may execute. The surrounding system supplies context, limits, evidence, memory, and escalation. Humans and organizations choose the goal, define acceptable risk, judge the result, and own the consequences.

The destination worth building is not software that performs personhood. It is a governed system that can accept bounded work—and prove what changed.