Give the agent a proper brief
A repository, the brief, logs, live constraints and the relevant records give an agent something real to investigate.
Ben Townsend / Digital product + infrastructure
TOOLS + WORKING METHOD
Agents are useful for groundwork when they have the repository, a decent brief, logs and the right constraints. I set the boundary, question the output and decide what happens next. They are capable junior colleagues. I remain accountable for the work.
HOW THE WORK MOVES
A repository, the brief, logs, live constraints and the relevant records give an agent something real to investigate.
Look across the code, configuration and operational evidence. A quick answer built on a bad reading is still a bad answer.
Set the boundary, test the assumptions and choose the next move. It might be a decision, a draft, a small change or a reason to stop.
Review the diff, run the tests, inspect the rendered page or query the service. A neat response is not proof.
Leave the next person with what changed, why it changed and how to tell whether it is still behaving.
THE TOOL BENCH
TypeScript, React, Next.js, JavaScript, HTML, CSS, GitHub Actions, Azure DevOps and Jenkins.
AWS, Azure, OCI, Docker, Terraform / OpenTofu, NGINX, Linux, MySQL and YAML.
Cloudflare, Fastly, DataDog, Grafana and New Relic.
First-pass repository research, change plans, code and infrastructure drafts, review preparation, documentation and test coverage. Each needs a source, a boundary and a check.
A SHORT CASE STUDY
A personal site exposes every compromise. It has to work as a portfolio, an accessible interface, a print document and software that does not come apart at the first update.
CHAKRA UI V2 → V3 / NEXT.JS / EMOTION / PRINTMake the portfolio feel like mine rather than a stock developer site. Keep the CV printable, make the shared chrome consistent and keep both light and dark modes.
I moved the UI foundation from Chakra UI v2 to v3, updated the provider and component patterns, then tracked down an Emotion hydration mismatch in Next.js.
I used the repository, runtime output and rendered pages together. I kept changes small, ran lint, type checks and builds, then looked at the site in the browser and on paper.
The site has a firmer point of view, a print CV that works and fewer shared building blocks. The design and engineering work were inseparable.
KEEPING THE HANDS ON THE WHEEL
Finding the relevant configuration, comparing environments, turning notes into a first draft, tracing a failing route and preparing a review checklist.
I keep the access decisions, production scope, architectural trade-offs, user impact and the call on whether a technically tidy answer is right for the team.
The CV has the longer record. It covers full-stack delivery, platform rebuilds, cloud migrations, observability and the less glamorous work that keeps a service useful after launch. That experience makes the steering useful.
Read the CV