From Autocomplete to Agents: How Agentic Coding Changed Our Workflow in 2025

Six Months That Changed the Tooling

For most of 2023 and 2024, AI in the editor meant autocomplete and a chat panel. Useful, but the developer was still driving every keystroke. The first half of 2025 changed that. The tools now take a task, read the codebase, run commands, edit several files and come back with a diff.

The pace has been hard to keep up with. Cursor's Agent mode became the default way many developers use it. In May, Anthropic made Claude Code generally available alongside the Claude 4 models, OpenAI launched Codex as a cloud agent that works on tasks in parallel sandboxes, and GitHub announced the Copilot coding agent, which picks up an issue and opens a pull request.

The tools differ in where they run (your terminal, your editor, or a cloud sandbox), but the shape of the work is converging: you describe an outcome, the agent plans and executes, you review the result.

Task Shapes That Suit Agents

The biggest lesson so far is that agent success depends far more on the shape of the task than on the model. Some kinds of work go well almost every time. Others waste an afternoon.

The common thread is verification. If the agent can check its own work by running tests, a type checker or a linter, it will usually converge. If the only check is "does this look right to a human", you have just moved the effort to review.

Repository Instruction Files

Every serious tool now reads a project-level instruction file: CLAUDE.md for Claude Code, rules files under .cursor/rules for Cursor, AGENTS.md for Codex and .github/copilot-instructions.md for Copilot. This is the highest-leverage half hour you can spend.

A good instruction file is short and concrete. It tells the agent how to build, test and lint, where things live, and the conventions a new starter would otherwise get wrong. Ours covers the kinds of things below.

# Project notes for coding agents
 
## Commands
- Install: `npm ci`
- Type check: `npm run typecheck`
- Unit tests: `npm test -- --run`
- Lint: `npm run lint`
 
## Conventions
- All money values are integers in pence. Never use floats for money.
- Queue workers must be idempotent; see src/workers/README.md.
- Do not edit generated files under src/generated/.
 
## Before finishing
- Run typecheck, lint and the tests for any package you changed.
- Summarise what you changed and anything you were unsure about.

Two tips. Keep it in version control and review changes to it like code, because it shapes every agent session. And write rules as instructions, not as a wiki page. "Money is in pence" beats three paragraphs on the history of our pricing model.

Review Discipline

Agents make it cheap to produce code. They do not make it cheap to understand code. That imbalance is the main risk, and it lands on reviewers.

The rules I have settled on:

• The person who started the agent owns the pull request. "The AI wrote it" is not a review comment anyone should accept.
• Smaller diffs. Ask for one change per pull request. A 1,500-line agent diff gets skimmed, and skimmed code is where bugs hide.
• Read the tests first. Agents sometimes make tests pass by weakening them. Check that assertions still test what they should.
• Watch for plausible-but-wrong. Invented config keys, APIs that don't quite exist, error handling that swallows failures. The code often reads well, which makes this harder to spot.
• Same bar as human code. Feature flags, observability and rollback plans still apply.

Security and Permissions

An agent that can run shell commands is running with your credentials, on your machine or in your CI. Treat it that way.

• Start with the tool's default ask-before-acting mode, and allow-list the safe commands (tests, linting, type checks) rather than approving everything.
• Keep production credentials off developer machines where agents run. Agents should work against local or sandboxed environments.
• Be careful with MCP servers and other tool integrations. Each one extends what the agent can do, and content the agent reads (issues, web pages, documents) can contain instructions meant to steer it. Prompt injection is a real risk, not a theoretical one.
• Cloud agents that open pull requests should go through the same branch protection and CI as everyone else.

Cost

Pricing is a mix of per-seat subscriptions and usage-based billing, and agents consume far more tokens than autocomplete because they read files, run commands and iterate. My advice is to budget per engineer per month, pick one or two tools rather than letting everyone expense their favourite, and review usage monthly. The comparison that matters is not the tool bill against zero. It is the tool bill against engineering hours spent on work the agent now handles.

What Changed for Junior Engineers

This is the part I think about most. The tasks we used to give juniors to learn the codebase (small bug fixes, test coverage, simple CRUD endpoints) are exactly the tasks agents now do well.

I don't think that means hiring fewer juniors. It means changing how they learn:

• Juniors use agents, but explain every diff they submit in their own words during review.
• Some tasks are done without an agent on purpose, particularly debugging, because that is where understanding forms.
• Pairing shifts towards reviewing agent output together and asking "how would you know this is wrong?"

The skill that separates good engineers now is judgement: specifying work clearly, spotting subtle errors and knowing when to stop the agent and think. Those skills have to be taught deliberately.

Where to Start by Stage

The Takeaway

Agentic coding tools crossed a line in the first half of 2025: they now complete tasks rather than lines. They pay off on well-specified, verifiable work, in repositories with good instruction files and tests, and with review discipline that treats agent code exactly like human code. The teams that benefit most will be the ones that invest in specification and review, not just in seats.