How I work with coding agents, what I hand over to them and what I keep. Two practices, written guardrails, and a human sign-off before anything ships.
I do not use agents the same way at work and on my side projects. At work, I stay hands-on at every step of the ticket. On my side projects, I hand the execution over to a chain of agents and keep the decisions.
At Groupe La Centrale, the agent works with me on a Jira ticket, from the plan to the PR. The code starts from the tests, two models review it, then I read it and sign it off before testing it in a dev environment or locally.
On my side projects, specialised agents work through the tickets in Multica, a self-hosted tracker. I write the idea, I settle the spec and the ADRs, and nothing is merged without a green CI.
in bluethe steps I do myself.
An agent questions me over several rounds until the grey areas are settled.
The spec and every decision that is hard to undo are written before the code.
Independent tickets for each delivery step, with acceptance criteria that can be checked.
Each ticket goes to a specialised agent (back end, front end, review, QA) in Multica.
A coding agent moves fast, including in the wrong direction. These guardrails are written down, and automated where possible, so that no change gets through on a model's word alone.
The line comes down to one rule: the agents write, I decide what ships.
Review the PRs assigned to me, in parallel and in isolated git worktrees, and work through the feedback on my own PRs: fix, reply and resolve each thread. A personal tool I use at work.
See the projectA kanban board for developers whose cards move on their own when a GitHub PR opens or merges.
See the projectHit a weekly macro target: recipes extracted from a PDF cookbook by an LLM, a meal plan computed by a solver with batch cooking, and a shopping list.
See the projectUpload documents, get a downloadable Claude skill back: an asynchronous conversion on AWS.
See the project