Write-up · Ways of working

Agent-assisted engineering, with guardrails

Most of my work now is deciding where an agent needs a guardrail rather than writing the code by hand. This is what that actually looks like in a production codebase, including the parts that don't work.

Why write this down

"Uses AI tooling" has become a line on everyone's CV and it means almost nothing. It covers someone who occasionally autocompletes a function and someone who has restructured how their team ships. The difference is not enthusiasm, it's what you've had to change about your engineering practice to make the output trustworthy — so that's what I want to describe.

Where agents run in my workflow

• Task preparation. Before implementation, an agent gathers the context a change needs: the relevant code paths, prior decisions, the ticket history. This is the highest-value and lowest-risk place to use one, because being wrong costs a re-read rather than a production incident.
• Code review. An agentic review pass runs over changes before I look at them. It doesn't replace review; it catches the mechanical class of problem so my attention goes to design.
• Backlog triage. Scheduled agents work through incoming issues on a cadence rather than on demand — categorising, reproducing where possible, and flagging the ones that actually need a human.
• MCP integrations across the tools the team already uses — project management, analytics and bug tracking — so an agent can read the same context I would, instead of being handed a paraphrase of it.

The principle: the value isn't the generated code

The generated code is the cheap part. What makes agent-assisted development actually faster is the layered checking that lets you accept that code quickly, and the honest answer is that a lot of teams have adopted the generation without adopting the checking. That's why it feels fast and then doesn't.

So the work migrates. Time I used to spend writing implementation now goes into: making the boundaries type-safe enough that a wrong assumption fails at compile time rather than at runtime; making the checks cheap enough to run constantly; and making failures legible enough that the agent can act on them without me translating.

Where I don't let them run

Anything where the failure mode is silent and expensive. In my case that's the paths that touch money, orders and manufacturing instructions — a wrong configuration doesn't throw an exception, it produces a physical object that is wrong and a customer who is unhappy. Agents assist there; they don't drive.

The other category is anything that requires knowing why a decision was made rather than what the code does. Agents are good at the codebase and bad at the politics, and a surprising amount of engineering is the second thing.

The hiring consequence

When we hired a front-end developer, I designed the take-home exercise with AI tooling explicitly permitted, and said so in the brief. Banning it would have tested whether a candidate could simulate 2021, which is not a skill I need. Permitting it moved the assessment onto the thing I actually wanted to know: can you tell when the output is wrong, and can you explain why you kept what you kept? I screened around 30 applicants and ran the interviews on that basis.

What I'd tell a team adopting this

• Invest in the checks before you increase the generation rate. The order matters, and doing it the other way round is how you end up with a large codebase nobody understands.
• Give agents the same context you'd give a new engineer, through real integrations rather than pasted summaries.
• Be explicit about the blast radius of each place you let one operate. "Can an agent do this?" is the wrong question; "what happens if it does this wrong and nobody notices for a week?" is the right one.