From copilots to agents: how agentic engineering changed the way we build software

A year ago we described how our engineers use AI every day: assistants in the editor, an AI bot that summarises every pull request, and a process with clear tasks, tests and human review around all of it. Since then the way we build software has changed more than in several previous years.

The difference is simple to state. An assistant suggests the next few lines. An agent takes a whole task: it reads the ticket, explores the codebase, makes the change, runs the checks and opens a pull request. The engineer's role shifts from writing every line to defining the work, steering it and reviewing the result.

We have backed this with our own budget. Since January 2026 the company has paid for Claude subscriptions, and by June they cover developers, the software architect, the tech lead and project management, with higher-usage plans for the people who run agents most. The AI-first editor our developers have used on company seats since late 2024 is still part of the toolkit.

From suggestion to task

Since March 2026, in one of our client projects, pull requests prepared with an AI coding agent have become part of the daily flow. A typical change now looks like this:

1. The work is described as a ticket with a goal, and the pull request carries the ticket number.
2. An engineer runs the agent on it inside the repository, with the project's rules loaded from an instruction file.
3. The agent makes the change on its own branch and opens a pull request with a summary of what it changed and why.
4. Within minutes the AI review bot we have used since late 2024 adds its own walkthrough of the change.
5. The engineer reads both, asks for corrections or makes them, and decides whether the change is merged. Deployment remains a human decision.

Agents also work well side by side. At the end of May we ran an audit of unused code in a mobile app with static analysis tools and four agents searching the code in parallel. The result was a written report, not a deletion: nothing was removed automatically, and the audit also surfaced a genuine bug, which went into the backlog like any other finding.

The instruction file is the new onboarding

An agent starts every session knowing nothing about the project. So we write down what a new team member would need on day one, in a file the agent reads first: what the project is, the glossary, who the users are, the conventions, which documents must always be loaded, and what the agent may and may not do. Since January 2026 we keep such files not only in code repositories, but also in analysis workspaces, where agents help turn workshop transcripts into documentation of current and target processes. In the same project a separate instruction file sets up an agent for UX work: it builds clickable prototypes on the application's real components with mock data, and every change it makes to the original files has to be marked and documented.

The same discipline applies to each task. A good brief states the goal, the scope, what "done" means, the relevant parts of the code, what must not be touched and how to verify the result. Writing such briefs is now one of the most important skills in the team. And we keep one principle from our earlier work: no ticket, no code. Every change can be traced back to a described need.

Tests are a precondition, not a bonus

A change produced by an agent without tests is a guess. Tests and a working build are what turn it into something a reviewer can trust. Where a codebase has little test coverage, a sensible first task for an agent is to write tests for the existing behaviour, before anything is changed.

For user-facing changes, passing tests are not enough on their own. Someone has to look at the result in a development environment, on real content, before it goes further.

Security: secrets, permissions and what the agent reads

An agent that can run commands deserves the same care as a new team member with access to your systems, and in some respects more. The rules we work by:

• Least privilege. An agent gets only the access its task needs. No direct access to production.
• Secrets stay out of code and prompts. Credentials are provided by the environment, never committed and never pasted into a task description.
• Work ends on a branch. Agents push their work and open pull requests; merging and deploying stay with people.
• Content is data, not instructions. Web pages, documents and external tickets that an agent reads can contain text written to manipulate it. Agents should treat such content as information, and permissions limit what a manipulated agent could do anyway.
• Client code only where the client agreed. The same contractual rules apply as for any other tool.

Choosing the model for the task

Not every task needs the most capable model. A small, well-described change can go to a faster and cheaper one. Work that spans many files or requires careful reasoning deserves a stronger one. Architecture decisions and ambiguous problems stay with an engineer, supported by the best model available. And when an agent gets stuck, the right move is to escalate to a stronger model or to a person, not to let it try the same thing again.

What it means for engineers and for clients

For our engineers, the job has moved towards understanding the problem, designing the solution, writing precise briefs and reviewing critically. Reviewing well is harder than it sounds: a reviewer has to read a change they did not write as carefully as if their name were on it, because it is.

For clients, well-defined work moves faster, and the quality gates stay the same: a ticket, tests, review, and a human decision before anything reaches production.

There is a wider point, too. If agents have changed our own work this much in a year, they will change the daily processes of our clients as well: how enquiries are handled, how offers are prepared, how documents are read. That is what we will write about next.

Agents did not remove the need for engineering discipline; they made it the deciding factor. If you would like to talk about how this way of working could speed up your product, or how AI could support your own processes, get in touch with us.