Onsite programming sessions that survive contact with agents

Why onsite programming still beats a webinar

The hard part of agent-assisted work is not the tool. It is the twenty minutes where an engineer stares at a 900-line diff and has to decide whether to read it or trust it. That moment does not happen on a webinar. Someone has to be standing behind the chair when it does.

We run onsite programming days in the client's own codebase, on the client's own laptops, with their VPN and their flaky test suite. The first hour is usually spent discovering that half the room cannot get the agent to see the monorepo because their editor opened a subdirectory. That hour is not wasted. It is the actual onboarding problem, surfaced early.

What a day actually contains

• Setup and repo config. Writing an AGENTS.md that describes how to run tests, what not to touch, and which directories are generated.
• One real ticket per pair, picked from the backlog the week before. Not a toy exercise.
• A review block where each pair reads someone else's agent-produced diff out loud.
• A failure hunt. We deliberately let an agent produce something wrong and ask the room to find it.
• A short decision session: which parts of the workflow the team keeps, which they drop.

The backlog tickets matter more than anything else on that list. Pick tickets that are boring and well specified. A migration, a test-coverage gap, a batch of small refactors. Save the ambiguous architecture work for a normal week, because ambiguity produces confident nonsense and the room learns the wrong lesson from it.

Where the format falls down

Onsite programming is a poor fit for teams that cannot get an agent approved by security before the date. We have arrived to find the tool blocked at the proxy and spent the morning on a workaround. Ask the security question six weeks out, in writing.

It also fails with groups over about twelve. Past that, the trainer becomes a lecturer and the whole advantage evaporates. Two rooms of ten on separate days is better than one room of twenty.

And it does not stick on its own. A day produces enthusiasm and a shared vocabulary. Four weeks later, half the team has drifted back to typing everything by hand unless someone owns the follow-up. Name that person before the session, not after.

Judging an onsite programming offer

Ask the vendor three things. Will you work in our repository? What do you need from us before the date? What does the team have at the end of the day that they did not have at the start? If the answer to the last one is "an understanding of the possibilities", book something else.

A useful deliverable is concrete: a committed AGENTS.md, three merged pull requests, and a written note of the two workflows the team agreed to try. That is checkable a month later.

What to do next

Pick five tickets from your backlog that you would be happy to see closed by a junior with a good reviewer. Send them to whoever is running the day. If you cannot find five, the problem is the backlog, and a training day will not fix that.

If you want help putting this into practice, talk to us.