Architecture Decisions Don't Survive AI Speed

Six months in, someone asks why the app runs on Postgres instead of the obvious alternative. You know there was a reason. You remember caring about it quite a lot at the time. You cannot remember what it was.

Now your assistant asks the same question. Except it does not ask. It picks something reasonable and rewrites the thing.

Code records what. It has never recorded why.

The reasoning always lived somewhere else. A conversation. A scratch document. Your head. That was survivable when a codebase moved at human speed and the person who made the call was still in the room to be asked.

AI took away both of those cushions. An assistant can touch twenty files before you have finished reading the first diff, and it carries no memory of the call you made in week two. It will produce something plausible, working, and quietly at odds with a decision you already made, faster than you can review it. The code will look fine, which is exactly what makes it expensive to find later.

The instinct behind ADRs is right

Plenty of teams reached for architecture decision records for exactly this reason. Write the decision down with its context and the alternatives, and the reasoning outlives the person who had it. That instinct is correct, and it is why the practice spread.

Where it comes apart is the lifecycle.

An ADR gets written once, at the moment of peak optimism, and then it sits. The project moves. Evidence turns up that would have changed the call. Nobody reopens the file, because reopening it is a chore that belongs to nobody. Six months on, the document describes a decision that is still technically in force and no longer true.

A decision nobody revisits stops being a record and starts being a fossil.

What a decision looks like when it stays alive

PAPI tracks decisions as things that keep moving. Each one holds its reasoning, a confidence level, and the evidence that has piled up for or against it since it was made. When a build contradicts a decision, that surfaces rather than sinking. Every five cycles a strategy review pulls the decisions back into the light and asks the blunt question: is this still right, and what has changed since.

A decision can be validated, challenged, or superseded, and the trail stays behind it. So the next person, or the next session, sees more than the verdict. They see how sure anyone was, and what happened afterwards.

Your assistant needs this more than you do

You can hold a fuzzy version of the why in your head and get by. Your assistant cannot. It starts every session with whatever it is handed.

Hand it the code, and it will infer intent from the code. It will look at a deliberate choice that reads like a mistake from the outside, and it will helpfully correct it. Then you will spend an afternoon working out why a thing that used to work does not.

Hand it the decisions instead, with the reasoning attached, and it stops relitigating questions you already settled. It builds inside the constraints you actually chose, because it can see them.

The part that compounds

Decisions are the piece of a project with the longest half-life. Code gets rewritten. Features get cut. The reasons you chose one shape over another are still shaping the work years later, whether or not anyone can still name them.

We build PAPI with PAPI, and the decisions we made in cycle 1 are still steering cycle 330. We do not have unusually good memories. We stopped relying on them.

The why stays with the what. See how PAPI tracks decisions.