Judgment Day

For many years, process was the villain in every engineering story I told. Tickets were paperwork. Estimation sessions were theatre. The Definition of Done was a page nobody opened, written by someone who hadn't shipped anything since the floppy disk.

The fastest teams I worked with shared a secret: they talked. A quick message, a call, a screenshot dropped into a thread, and the thing was done before the ticket would have survived grooming.

And it worked. Mostly. It worked because the context lived in a few heads, and those heads sat close to each other. When someone asked why a field was nullable, someone else remembered. Meanwhile the tracker filled up with tickets titled "fix the thing", with a description that read "as discussed".

As discussed. Two words carrying more architecture than most design documents.

We called this speed. We called the people who wanted a ticket for everything bureaucrats. I was one of the people doing the calling.

The Reprogramming

In the first Terminator, the machine comes through the door to kill you. In the second, the same model walks through the door to keep you alive. Nobody rebuilt it. Somebody changed its instructions. The film doesn't ask you to like it. It shows you that you need it.

That's what happened to process. Tickets didn't change. The reader did.

An agent starts every session with an empty head. It wasn't on the call. It wasn't in the thread. It can't open the spreadsheet on someone's laptop called final_v3_REAL.xlsx. "As discussed" means nothing to something that has never been present for a single discussion.

So the agent fills the gap the way agents do: confidently. It guesses the missing requirement, builds it cleanly, writes tests that prove its guess, and hands you a green pipeline. The work looks finished. It is finished. It's the wrong work.

Humans used to soak up missing context by asking around. Agents don't ask around. They ask you, if you remembered to tell them to, and you're currently babysitting six of them.

The Ticket Is the Prompt

Look at a decent ticket. Why this exists. What's in scope and what isn't. How we'll know it works. Links to the decision, the related work, the previous attempt that died.

Now look at a good prompt for a coding agent. Same sections. Often the same order.

We spent years writing these for humans who skimmed them. Now there's a reader that takes every word literally and executes it faster than any reviewer can follow. A vague ticket used to produce a clarifying question at standup. Today it produces three hundred lines of plausible code before anyone notices the question was never asked.

Acceptance criteria stopped being a formality. They are the only thing standing between the agent and its imagination.

The trail matters after the fact too. When someone reviews a diff, human or machine, the first question is always "what was this supposed to do?" If the answer lives in a chat that scrolled away three weeks ago, the review is a vibe check. If it lives in the ticket the PR links to, the review finally has something to check against.

No Fate But What We Write

The real reason we hated tickets was never philosophical. It was cost. A good ticket meant fifteen minutes of typing after an hour of talking, and nobody volunteered to be the typist. So the ticket said "as discussed" and everyone went back to work.

That excuse is gone. The tools writing the code can write the ticket. Paste in the thread, the meeting notes, the half-baked idea, and ask for context, scope and acceptance criteria. Ask it to split the work. Ask it to list the questions nobody answered, which is usually the most useful part. Most trackers have an API, most agents can call one, and the PR can link itself to its ticket without anyone opening a browser tab.

Once writing it down costs almost nothing, skipping it stops being a speed decision. It becomes a decision to keep the context hostage in your head. And as I wrote last time, your head doesn't autoscale.

There's a second dividend. The chat thread is where decisions go to die. Three people agree on something at 18:40, one of them is on leave next week, and a month later nobody can explain why the retry limit is five. A ticket is boring. It is also searchable, and the next agent touching that code can read it. When the reader is a machine, boring is a feature.

Checkpoints, Not Campfires

Meetings get the same treatment, and most of them fail it.

A standup is a checkpoint. What moved, what's stuck, who needs whom. Fifteen minutes and everyone goes back to work. The moment someone says "quick one about the design" and four people lean in, it stops being a standup and becomes a campfire. Somebody tells a story, everyone nods, and the decision drifts off with the smoke.

Requirements deserve their own room. A workshop with a scope, or an RFC people argue with in writing, with a decision at the end and a name next to it. Not twenty minutes wedged between "yesterday I worked on" and "no blockers".

The cost of deciding things in the wrong meeting was never the lost time. It's the gap it leaves. The ticket says one thing, the meeting agreed another, and nobody updated the ticket because the meeting felt like the update. The agent reads the ticket. It builds exactly what the ticket says. Two weeks later you're holding code that matches the documentation perfectly and contradicts what everyone remembers agreeing.

So the rule now: the discussion happens in the ticket, or in the RFC the ticket points to. Meetings are for checkpoints and for answering the questions writing couldn't settle. If a meeting does decide something, it goes into the ticket before anyone leaves the call. Otherwise it didn't happen.

Hasta la Vista, Spreadsheet

I haven't converted all the way. Some process is still Skynet.

The test I use now is short: who reads it? If a machine or the next engineer reads it to do the work, it earns its place. Tickets, acceptance criteria, decision records, the linked PR. If the only reader is a status meeting, it's the old enemy in a new leather jacket. Estimating in points nobody believes. The weekly spreadsheet that copies the tracker by hand. The report about the report.

That spreadsheet is the T-1000. It looks exactly like the real thing, it reshapes itself into whatever the meeting needs, and the moment it disagrees with the tracker, somebody gets hurt.

Process didn't get better. Our readers changed. For years we wrote things down for people who already knew, so writing them down felt pointless. Now the reader knows nothing, starts from zero every single time, and works faster than all of us.

The machine promised it would be back. It keeps its promise, every morning, with no memory of you. Leave it a note.