Most of the recent blogs I’ve read about engineering teams using coding agents focus on the same question: How much more can we hand over? Can I give the agent a ticket? Can I point the agent to an error and expect a fix? Can I use the agent for the boring migrations I keep putting off?

Agents are part of our normal workflow at Studio Jadu as well. We use them to write code, review pull requests, pick up tickets, debug errors, and much more.

But somewhere along the way, I found myself asking a different question:

What should I not hand over?

This question has helped shape how our current processes work at Studio Jadu. Some tasks go straight to the agent. Some need human planning before starting. Some require human intervention in the middle of a task before the agent can resume.

A big part of keeping humans in the loop is making sure the next person, or the next agent, can see the right context in the repository. I don’t mean just having an AGENTS.md file that outlines the structure, guidelines, dos, and don'ts, Instead, I’m referring to a document that helps us iterate on features quickly and reliably: a handoff doc, a document that helps someone, human or agent, carry forward a task or an attempt from a previous agent.

In this post, I’ll go into more detail about our general framework for how we use coding agents in our workflow at Studio Jadu and where we still keep humans making the call. It's possible that by the time you read this, some things are already outdated given the pace of development, but nonetheless the principles will stay.

How we use handoff docs at Studio Jadu

At Studio Jadu, we have a global engineering team working across time zones, so handoff docs are an important part of our workflow. When a work session stops, the person or agent doing the work writes a handoff for whoever picks it up next.

We’ve found this to be a much better system than asking the next person or agent to reconstruct the work context from git history alone. Even if they tried, they probably could not fully do it, because the next person or agent cannot see the earlier discussion: which decisions were made, what was still unfinished, and why this approach was taken instead of another one.

Our handoff docs put focus on what did not work, what is still pending, and what should be left alone. They only briefly touch on what was done and what went well.

That “left alone” part matters more than I expected. It prevents another human or agent from repeating something that has already been tested when they come across the same bug or task.

As soon as you start using handoff docs, you find more uses for them.

One use that came up recently was how the handoff doc improved our work across repositories and services. If a task touches frontend and backend, the handoff can say what changed on each side, what still needs to connect, and what was deliberately left alone. The next person or agent does not need to start by scouring every repository from scratch.

Here’s an example of a section from a recent handoff doc:

Figure 1: Snapshot of a real handoff written by one agent after completing its task

Plans before the code, handoffs after

The other document we use for non-trivial work is the plan.

The plan is where the human decisions are explicit: what the goal is, what the current state is, what is out of scope, which architectural decisions have been made, which components to touch or not touch, and how to test the work.

We review the plan before implementation starts. This helps us catch the wrong assumptions early so we are able to identify them beforehand instead of discovering them later on during a pull request review. We keep the plans as dated files and do not edit them once they are merged. They live in a folder that agents do not read by default because a plan only talks about things that were decided at that time instead of the current state.

Here is an example of a plan document:

Figure 2: Part of a real plan for adding metrics around our AI provider calls

What goes in the agent instruction file and what doesn't

Initially, we got this wrong in two ways.

First, the file got too long.

Every repository has an AGENTS.md file containing architecture overview, commands, logging conventions, code style etc. You can find plenty of content on what this instruction file should contain, so I won’t go too deep into that.

The one thing I’ll point out is what actually helped us: local gotchas. For example, The 'err' field has to be an actual 'Error' instance or no issue gets created' or 'Store hooks need a selector or components re-render for no reason'

But over time, our frontend instruction file grew to almost 3,000 words. At that length, it became difficult for agents to separate out important rules from good to have, so we had to cut it down.

We moved longer explanations into docs that the agent can read when needed, and we kept AGENTS.md closer to a repo map plus the gotchas that come up often. For repeated workflows, we used focused skills instead: a handoff-doc skill, a “Grill Me” flow to turn a vague idea into a structured plan, React best-practice guidance, and a few others.

Second, some rules belong in tools, not in 'AGENTS.md'.

Things like 'Don’t use 'console.log' or 'don’t add another toast library' can easily be checked by lint, dependency checks, or pre-commit hooks, so they should move there. If a rule has no real exception, you don’t want it to depend on the agent reading and remembering a sentence. The tool should catch it automatically.

Figure 3: our pre-commit hook to check for console.log in staged changes

Reviews: What we still want a person to check

Every pull request gets an automated review from an agent before a human reviews it. This is probably not unusual for most development teams.

What matters to us is deciding what the human review should focus on after the automated review.

First, the person opening the PR has to resolve or reply to the automated comments before requesting human review. And we don’t want the human reviewer to just repeat the same pass.

The questions we care about are different; questions like:

Did the plan make sense?

Did we solve the right problem?

Are the tests proving the behaviour we actually care about?

Did the automated review focus on the important risks, or did it spend time on easy comments while missing the bigger issue?

See the example below of a PR that added a new API endpoint to list the voices in use on our voice-provider account. The bot checked the new endpoint and approved it. The human asked why the new endpoint needed to exist when a pre-existing endpoint could do the job.

Figure 4: Bot review on the left, human review on the right

That is where human review still matters for us.

Not because we require that humans must read every line first but because someone still needs to check whether the work makes sense as a whole.

When a ticket can go straight to an agent

Honestly, this has been one of the more useful productivity hacks for our engineering team.

You do not need to spend time fixing every small bug, issue, or follow-up by hand, especially when it can be worked on with local context. An agent can fix a bug from error monitoring, pick up a Linear ticket, and make iterations directly on a PR.

But you still have to decide what is safe to hand over.

Figure 5: Human triggering coding agent to go and fix a bug

Is this small and bounded enough? Does the agent already have the right context, or do you need to add more? Is this actually a design decision pretending to be a small task? In those cases, it should go through a plan first.

So yes, the agent can be triggered from the tracker. But we still decide when that is the right move.

Integration Tests: humans choose the journey, AI writes the steps

An agent can write the test steps, but it should not be the one deciding what is worth testing.

For our end-to-end tests, a person picks an important user journey and walks through it once. The AI turns that journey into a test: go to this page, click this button, fill this field, expect this thing to appear.

The test itself is a JSON flow over Playwright. We also record the network traffic once into a HAR file, so the test can replay the same backend responses later. If the test tries to call something that was not recorded, we abort it instead of accidentally hitting a live service.

The AI handles the mechanical part: selectors, steps, and test structure. But you decide which journeys deserve protection, whether the assertions prove anything or did we just create a test that clicks through the happy path and tells us nothing.

That is the part I don’t want to hand over.

A checklist if you are starting today

Do not start with building a big agent framework.

Start by giving agents a few bounded tasks: repeated work, easy to review and correct if the agent gets it wrong. Code review is a good first one. Set up your repo guidelines, structure, and rules. Let the agent do the first pass on a PR. Only add a human reviewer once the agent comments are resolved and you also agree that the PR is ready.

Then increase the scope slowly.

Over time, you start figuring out where the human decision still matters. For us, it was when the agent outputs were although complete, the approach was wrong.

A simple example: we wanted to show a quality score on generated images. The easy fix was to copy the score onto the image itself, because then the UI could render it directly. But the score actually belonged to the generation job that created the image. Copying it onto the image would create two sources of truth, and the next person would have to guess which one was current.

Also, not everything needs an LLM.

Some deterministic flows should stay as tools, lint rules, or heuristic checks. Did the code add 'console.log'? Did it import a package we already decided not to use? If it can be checked mechanically, make the tool check it.