Every Session Is Day One

AR-1 / SECTION 1 — PARTICULARS OF ENTRY

Part 1 — The Ritual

There's a ritual every engineering team knows. Someone new starts on Monday. You sort their laptop, get them onto the VPN, add them to the right repositories, and find out which of the six things in the README are still true. You walk them round the architecture. You tell them which service is load-bearing and which one nobody has touched since 2019. You explain that billing-v2 isn't the billing system, it's the invoicing system, and the billing system is called ledger.

That takes days. Often weeks. Nobody minds much, because it happens a handful of times a year.

AR-1 / SECTION 2 — PERIOD OF ENGAGEMENT

Part 2 — The Compression

Every agent session is that same induction.

Same access problem. Same which-of-these-is-still-true problem. Same billing-v2 problem.

Except it gets about thirty seconds.

Then it does the whole thing again from nothing a few minutes later. Then again. Fifty times before lunch.

Processed

AR-1 / SECTION 3 — MATTERS WITHHELD

Part 3 — What Thirty Seconds Rules Out

Thirty seconds rules out the way engineers actually learn a codebase.

Most of what a new starter knows after three months, nobody ever told them. They picked it up sideways.

REDACTED — HOVER OR PRESS TO REVEAL

From a standup where someone mentioned the migration is still running.

From a review comment explaining why that function only looks stupid.

From the face someone made when they suggested touching the payments service.

From turning to the person next to them and asking.

None of it is available. There is no standup, no next desk, no face. A session gets the repository, and the repository is the entire world. Anything your team knows but has never written down does not exist. It isn't buried, and it isn't hard to find. It is not there.

Tacit Knowledge — Not Supplied

There's a second problem. A new starter who doesn't know something asks, or at worst stalls. A session doesn't know that it doesn't know, so it fills the gap with something plausible instead. Which means a half-true README is worse than no README at all. A human spots the rot. A session trusts it completely.

AR-1 / SECTION 4 — COMPLAINTS AND REPRESENTATIONS

Part 4 — So You Blame the Model

This is where the argument usually goes wrong.

When a session flails, the explanation reaches for the model. It isn't clever enough. The other tool is better. Agents just make things up. I've heard all of these. I've said some of them.

Most of the time I don't think it's the model. I think the repository couldn't induct anybody in thirty seconds, and it never could. The agent is simply the first newcomer to turn up fifty times a day, which makes it the first one whose confusion you can't ignore.

You can see the same mistake in how people talk about their side projects. They fly at the weekend and grind at work, and conclude the tools must be different. The tools are identical. The side project has no history, fits in one head, describes itself completely because one person wrote all of it last month, and nobody minds if it breaks. That's not a better model. That's a better induction.

AR-1 / SECTION 5 — PAY AND ALLOWANCES

Part 5 — Why the Gains Didn't Arrive

Which brings me to where the productivity went.

They bought the agent. They upgraded the model when a better one turned up. They added the rules files, the context management, the tooling. All of that is real work and all of it raises the ceiling.

The repository sets the floor. If a session burns its first stretch working out how to install the thing, what the test command is, and whether it's allowed to run migrations, the ceiling barely matters. You've hired a faster engineer and kept the three-week induction.

N.B.There's an asymmetry here. A better model arrives every few months whether you do anything or not. It's free, and it's someone else's problem. This other work has never once turned up on its own.

AR-1 / SECTION 6 — KIT ISSUED ON ENTRY

Part 6 — What the Repository Issues

Most repositories induct anybody the same way. Here's the README. Ask if you get stuck.

!!There's nobody to ask.

So the useful question stops being how good is the agent, and becomes what does this repository issue to whoever turns up.

Eight things, in my experience.

The failures are rarely dramatic. A private registry token nobody documented, so a fresh checkout dies during install and the error says nothing about a missing credential. A human hits that and knows who to ask. A session cannot reach step one, so everything below it on the list is unreachable too. Somebody has to hand over a secret before any work can begin, and at that point you don't have an autonomous anything.

Or the quieter version, where everything installs and runs and nothing can be proved locally. Then you're capped at agents that write plausible code nobody can verify without a human, which is a strange thing to have spent money on.

Notice that none of the eight say how. Judge outcomes, never implementations. A Makefile counts. An npm script counts. A compose file counts. A paragraph in the README counts. Any mechanism that answers the question is the right mechanism, and anyone telling you their framework is the agent-ready one is selling something.

AR-1 / SECTION 7 — REMARKS ON DISCHARGE

Part 7 — Writing It Down Is the Easy Half

Most of those eight questions are questions about human onboarding too. Write down how the team actually works and the next new starter reads it instead of absorbing it over a quarter. Make a fresh checkout run itself and Monday morning stops being a write-off. Get one command to prove a change is sound and everybody stops guessing, including the people who've been there nine years.

But writing it down is only half of it, and the other half is the part I think is most underrated.

If something is hard to explain to an agent, that's information. Often the process itself is the problem. It was built around one person working at a time, a review queue that assumes a queue, a shared environment only one change can occupy, an approval that lives in somebody's head. You can document all of that accurately and it still won't work, because the knowledge was never the constraint. The shape of the work was.

Fifty things at once doesn't fit a process built for one thing at a time. So the answer isn't always a longer document. Sometimes it's changing how the team works, so that it can be explained at all, and so it survives being done in parallel.

N.B.That takes deliberate effort, and it's the step almost everyone skips. The default is to try to make agents work the way we always have.

We've known the write-it-down half for twenty years and never got round to it, because the benefit was spread thin across the three people who joined each year while the cost landed squarely on whoever had to write it all down. That arithmetic has changed. The induction now runs fifty times a day.

Every session is day one. That isn't going to change, so it's worth making day one work.

Returned to Depot