Agentic coding in an agency: how to set it up so the work is still yours

Agentic coding is a way of building software where an AI agent does the work in steps. It reads the codebase, plans the change, edits the files, runs the tests, and fixes what fails. A developer directs it and reviews what comes back.

That’s a long way from autocomplete. It’s also where a lot of agencies get stuck, because the first results look impressive and then don’t survive a code review. This is how I set it up in an agency so the work that comes back is yours.

What agentic coding is

There are three ways developers use AI, and they get confused with each other.

• Autocomplete. The tool suggests the next line as you type. Helpful, small.
• Chat. You paste code into a chat window, ask a question, and paste the answer back.
• Agents. You give the agent a task. It works inside the project, makes the change across several files, runs the checks, and comes back when it’s done or stuck.

The third is agentic coding. The developer’s job moves from typing to directing: writing a clear brief, checking the plan, and reviewing the result.

Why agencies struggle with it

A product company has one codebase and one way of doing things. An agency has dozens of clients, several frameworks, and standards that live in the heads of its senior developers.

So an agent turns up with no idea how you work. It writes code that runs, in a style nobody on your team would choose, with components you already have rebuilt from scratch. A senior developer can end up spending longer fixing it than writing it would have taken, and decides the whole thing is hype.

That frustration is common. In the Stack Overflow Developer Survey 2025, 66% of developers said their biggest frustration is AI output that’s “almost right, but not quite”. That’s why the checking matters as much as the building.

The agent isn’t the problem. Nobody told it how your agency builds.

The set-up I use

This is what I use every day, and what I set up inside the agencies I work with.

Write your standards where the agent reads them

Every project gets a plain file of instructions that the agent reads before it does anything: how you name things, which components to reuse, how you handle accessibility, what a finished piece of work looks like, and what it must never touch.

An agent writes code that runs. Your standards make it code you’d ship.

This is your agency’s standards, written into its agents. It takes time to do well, and it’s the single thing that most changes the quality of what comes back. It also makes you write down things you’ve been meaning to document for years.

Work on real tickets, in small pieces

Agents are good at a clearly described change and poor at “build the website”. Break the work into the same tickets you’d give a developer, each with a clear definition of done.

Check each piece as it’s made

I use build loops. Each piece is built, then checked automatically: tests, type checks, linting, a production build. If anything fails, the agent fixes it before it moves on. Nothing is called done on the agent’s say-so.

Have a second model review it

Before the next piece starts, a second AI model reviews the change. A different model catches things the first one missed, in the same way a second developer does. It’s quick, and it means the human review starts from a better place.

Test like a real user

Automated scans miss a lot. So the last step is a QA agent that clicks through the site the way a person would, on phones and desktops, and comes back with screenshots. It finds the button that doesn’t work on a small screen, the form that says “sent” when it didn’t, the menu that traps the keyboard.

Give it designs it can read

An agent can only match a design it can read properly. That means Pencil files or well-organised Figma, with real components and named layers, not a flat picture of a page.

Keep a person deciding what goes live

Agents take on more and more of the work. Your people decide what goes live and own the result. That line doesn’t move.

Rules for client work

Before any of this touches a client project, agree the rules:

• Which tools can see client code and data. Check the terms. Use business accounts, not personal ones.
• What the agent can do on its own. Reading and editing files in a branch is fine. Deploying, deleting and anything involving money or credentials needs a person.
• Where secrets live. Never in a prompt, a chat or a commit.
• What you tell clients. Be straight about how you build. More of them are asking.

These take an afternoon to write. Not having them is how an agency ends up in an awkward conversation.

How to start

Don’t roll it out to the whole team. Pick one developer who is already curious, and one piece of work that matters but won’t sink you if it goes slowly. An internal tool or a small, well-defined client ticket is ideal.

Give it two weeks. Write the standards file first, set up the checks, and have them build the thing properly. Then let them show the rest of the team what they did and what went wrong. That person is your AI champion, and they’ll do more for adoption than any training day.

After that, the second project is quicker, because the standards and the checks already exist.

What changes for your developers

The work shifts. Less typing, more deciding. Your seniors spend more time on architecture, review and the judgement calls. Your juniors need a different kind of support, because reading and questioning code matters more than ever when you didn’t write it yourself.

It doesn’t remove the need for good developers. It makes the difference between a good one and an average one bigger.

If you want this set up inside your agency, it’s what I do on the Lead and Embedded plans. There’s more on how I work with web and development agencies, or you can send me a message.