From Autocomplete to Agents: How AI Coding Methods Are Evolving

AI coding methods are moving from local suggestions toward repository-aware, tool-using, and delegated work. The important change is not that typing code disappears. It is that a person can ask a system to take more actions across a larger part of the software process.

As the action surface grows, the durable human work becomes more explicit:

• define the behavior;
• select the context;
• state permissions and boundaries;
• create acceptance checks;
• inspect actions and diffs;
• integrate the result; and
• explain why the final software should be trusted.

Use the smallest assistance level that fits the task. More autonomy is useful only when its saved effort exceeds the cost of context, supervision, review, and recovery.

Treat this as a workflow map, not a settled timeline

Products did not all evolve through the same stages, and developers still use several methods together. A coding session may combine manual work, completion, chat, repository search, and an agent.

The following levels describe changes in the human workflow:

Parallel agents add another coordination layer. They do not create a new proof of correctness.

Completion keeps the decision local

Code completion proposes text near the point where you are already working. GitHub’s documentation for Copilot code completion describes inline suggestions that a developer can accept, reject, or partially accept.

Completion works well when:

• you already know the design;
• the next code follows a visible pattern;
• the suggestion is small enough to inspect immediately; and
• writing the remaining syntax is the main cost.

Its weakness is also local scope. A plausible block can violate a requirement defined elsewhere, call the wrong API version, or repeat an outdated project pattern.

Do not accept a completion because it matches your typing rhythm. Compare it with the specification and nearby tests.

Conversation makes context selection visible

Chat-style assistance lets a student ask for an explanation, compare designs, or request a patch against selected material. The main skill shifts from continuing a local pattern to assembling enough accurate context.

A useful conversational request states:

Objective:
Relevant code or documentation:
Observed behavior:
Required behavior:
Constraints:
Question:
Evidence I will use to check the answer:

Too little context encourages guesses. Too much context can bury the relevant constraint, expose private material, or increase the amount you must inspect.

Context selection is an engineering decision. Include the specification, relevant interfaces, failing behavior, and project conventions. Exclude credentials, private data, unrelated files, and material you are not permitted to share.

Repository-aware work turns context into infrastructure

Repository-aware systems can search files, follow references, read project instructions, and propose coordinated edits. That reduces the need to paste every relevant fragment into a prompt. It does not guarantee that the selected context is current or complete.

GitHub documents repository custom instructions for recording project-specific guidance. Other systems use different files and precedence rules.

Durable repository context commonly includes:

• project purpose and directory map;
• verified build, test, and formatting commands;
• coding and documentation conventions;
• generated files that should not be edited;
• privacy and secret-handling rules;
• scope boundaries; and
• required review evidence.

Keep the current objective in the task, not in permanent repository guidance. Learn the full procedure in Use AGENTS.md to Teach an AI About a Repository.

Agents enlarge the action surface

A coding agent can be allowed to inspect files, edit code, run commands, execute tests, and use connected tools. The method changes from “consider this suggestion” to “delegate this bounded task and inspect the resulting evidence.”

Write a task contract before delegation:

Objective:
Starting state:
Exclusive paths:
Files that must not change:
Requirements and non-goals:
Permitted tools and actions:
Acceptance tests:
Stop or approval conditions:
Required handoff:

The handoff should identify:

Paths changed:
Commands run:
Tests and observed results:
Assumptions:
Diff summary:
Unresolved risks:

Instructions do not create a security boundary. Use sandboxing, least privilege, explicit approvals, version control, backups, and human review appropriate to the consequences of the task.

Tests become part of the request

An agent can optimize toward whatever evidence you provide. If the task says only “make this work,” success may mean producing one plausible demonstration.

Before implementation, separate:

1. the requirement;
2. the acceptance check; and
3. the proposed implementation.

For a parser that should accept integers from 0 through 100:

Do not let the agent define every requirement, write all tests, implement the change, and decide that its own tests are sufficient. Preserve an independent source of expected behavior.

The canonical testing guide explains how to derive expected, boundary, and invalid cases.

Review moves from output to process and diff

Conversational fluency can make a result feel understood before the repository has been checked. Review the actual state:

1. inspect changed paths;
2. read the full diff;
3. map each change to a requirement;
4. identify new dependencies and side effects;
5. run independently derived tests;
6. inspect failures and warnings;
7. remove unrelated scope; and
8. explain the final code without relying on the agent’s summary.

GitHub now documents AI-assisted code review, but an AI reviewer is another source of findings, not the final authority. A generated change reviewed only by another generated response still requires evidence from the specification, tests, documentation, and accountable people.

Use the complete AI-generated code review method before accepting a change.

Repository benchmarks changed what researchers measure

Early code-generation evaluations often focused on producing a function or passing a bounded programming test. Repository work requires locating relevant code, understanding interfaces, editing several files, and running project tests.

The original SWE-bench paper defined 2,294 software-engineering problems drawn from issues and pull requests in 12 Python repositories. A system receives a repository and issue description and must produce a patch evaluated against tests.

This is evidence that repository-level issue resolution became a concrete research target. It does not prove that a benchmark score predicts success in your repository.

SWE-bench Live uses newer repository activity and reports a substantial performance gap between the live evaluation and static SWE-bench settings. Benchmark freshness, task construction, test quality, and repository selection all affect what a score means.

Treat benchmark results as measurements under stated conditions. For a student project, the stronger evidence is performance on the project’s own permitted, representative tasks and independently checked requirements.

Productivity remains conditional

Larger action surfaces do not guarantee faster work.

A randomized controlled trial of early-2025 AI tools studied 16 experienced contributors working on 246 tasks in mature open-source projects they knew well. In that setting, developers took longer with AI access. This result is bounded by the participants, tools, tasks, repositories, and study period.

METR’s 2026 follow-up update explains changes in recruitment, tool use, and study design. The direction and size of an AI effect can change across populations and over time.

Measure your own bounded workflow:

Task and starting state:
Assistance level:
Time spent specifying and preparing context:
Time spent waiting or supervising:
Time spent reviewing and correcting:
Tests passed and failed:
Defects or scope errors found:
Final explanation completed:

Do not use self-reported speed alone. Preserve the diff, test output, and quality criteria.

Parallel work is a coordination method

Multiple agents can work concurrently when tasks have stable, non-overlapping ownership and independent checks. The human role expands to:

• freeze shared interfaces and terminology;
• assign exclusive paths or responsibilities;
• isolate workspaces;
• inspect each result separately;
• integrate one result at a time; and
• rerun combined checks.

Git’s worktree documentation explains how one repository can have multiple working trees. Worktrees isolate checked-out files, HEAD, and index state; they do not make tasks semantically independent or create a security boundary.

Practice the complete method in Use Git Worktrees for Parallel AI Agents. Stay sequential when two tasks depend on the same unfinished design or shared file.

Choose the smallest effective method

Use this decision table:

Move down the table only when the larger method solves a real problem.

Course policy can set a stricter boundary. If an assignment prohibits generated code or requires independent implementation, a technically careful agent workflow does not make its use permissible.

Run one controlled comparison

Choose a small, permitted task with a known specification. A parser validation change is enough.

First pass:

1. State the required behavior.
2. Choose an assistance level and explain why.
3. Define one expected, one boundary, and one invalid test.
4. State which files and actions are allowed.
5. Define what evidence you must inspect before acceptance.

After the work, record the diff, commands, results, corrections, and independent explanation. Mark unknowns honestly. Stop if the task needs private data, unassigned paths, broader permissions, or a changed interface.

Repeat with a second assistance level only if the comparison serves a learning question. Do not turn the exercise into a product tournament.

Common mistakes

• Choosing an agent because it is newer than completion or chat.
• Prompting before writing the required behavior.
• Treating the entire repository as automatically relevant context.
• Storing temporary objectives in permanent project instructions.
• Letting the AI create both the requirement and all evidence of success.
• Reviewing the conversational summary instead of the repository diff.
• Treating passing tests as proof that no defect exists.
• Running unknown commands with broad permissions.
• Assigning parallel agents overlapping files or unstable interfaces.
• Generalizing one benchmark or productivity study to every developer.
• Keeping a workflow you cannot explain because it felt fast.

Do this now

Classify one current coding task by assistance level. Write its five-part first pass, then complete or simulate the bounded workflow. Accept the result only after the specification, repository state, diff, tests, and your independent explanation agree.

To keep this method current without chasing releases, build a low-noise AI update routine.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?