The Line Doesn't Defend Itself

A while back I wrote about the decisions I won't hand to AI — the one-way doors, the choices too expensive to reverse. Module boundaries, the data model, failure semantics. The decisions I keep for myself.

Reading it back, I noticed the thing the post assumed without saying: that I'm the one standing at the door.

On my own repo, fine. I am the door. I see the shape of the system. I know which seams matter. I know which shortcuts are harmless and which ones quietly change the architecture.

But that's not where I spend most of my days.

I lead a team of ten, and the honest truth is I'm not in the room when most of the code gets written. The line I drew so carefully in that post doesn't travel with me. It stays in my head.

And a line in one person's head is not a line.

It's a hope.

Your system was a person

AI didn't make the team less disciplined. It made visible that our discipline had been centralized in one person.

That is the uncomfortable part.

What we often call "our architecture" is really one senior engineer being quietly consistent. The boundaries hold because that person reviews enough pull requests to catch the drift. The vocabulary stays coherent because they happen to remember what we decided to call things. The failure semantics stay intact because someone has a sense, built over years, of what belongs where.

It was never really a system.

It was a habit.

And for a while, that was enough. The pace was slow enough for the habit to work. A questionable abstraction took days to appear. A bad boundary had to be typed by hand, discussed, fought with, reshaped. There was friction in the work, and that friction gave the team time to notice when something felt wrong.

AI changes that.

Not because it writes bad code. Most of the time it doesn't. It writes plausible code. Clean code. Tested-looking code. Code that fits the local request.

And that is exactly the problem.

The line gets crossed locally

Here's how the line actually gets crossed.

Not by one obviously bad decision. Not by one person deciding to ignore the architecture. Not by some dramatic moment I can point to later and say, "there, that's when we lost it."

It gets crossed by ten people, each making a call that is locally reasonable.

One reaches past a module boundary because the import was right there and the ticket was due. Another introduces a second name for a concept because the first one wasn't written anywhere obvious. Someone asks AI to generate a small helper, and the helper quietly duplicates logic that already had a home. Someone else accepts a refactor that makes one screen cleaner while making the system shape harder to see.

None of them did anything wrong.

Each diff is clean. Each choice makes sense in the small. Each pull request can be reviewed and approved without anyone feeling negligent.

And the architecture drifts anyway.

One sensible commit at a time, the shape you meant to protect disappears. By the time you notice, nobody can point to the moment it left.

That used to be a slow problem.

It isn't anymore.

Speed removed the friction that saved you

The thing that used to protect a team wasn't discipline.

It was friction.

Building the wrong thing was slow. A bad boundary took time to work its way into the codebase. There was enough hesitation, enough back-and-forth, enough "why is this so hard?" that somebody usually noticed on the way in.

The cost of the wrong decision was paid slowly enough to interrupt it.

AI removes that delay.

Now the wrong boundary can land in an afternoon — clean, tested, reviewed-looking, and wrong in exactly the way that doesn't show up in a diff. Everyone on the team is moving faster, sometimes much faster, which means every decision arrives faster too.

Including the decisions that should never have been made.

The drift didn't get worse because people got worse.

It got worse because the brakes came off.

The line has to leave your head

So the job I described in that first post — deciding where the lines are — turns out to be only half of it.

Drawing the line is the part I enjoy.

The part that actually matters on a team is making the line exist somewhere other than my own skull.

This is the shift I resisted for a while, because it sounds like bureaucracy. Write more docs. Add more process. Make more checklists. Turn architecture into paperwork.

But that isn't the answer.

A wiki page nobody opens is not the line leaving your head. It's your head, transcribed, and then ignored.

The line leaves your head only when it appears at the moment the decision is being made.

In the pull request. Against the actual code. While the choice is still cheap to change.

A rule about module boundaries that lives in a document is easy to forget. The same rule, surfaced on the exact import that crosses the boundary, becomes real. A naming convention buried in onboarding material is a preference. The same convention appearing when someone introduces a second word for the same concept becomes a guardrail.

That distinction matters.

The point is not to document everything. The point is to move the load-bearing decisions to the seam where they are made.

Not after the fact. Not in a quarterly architecture review. Not when the damage has already spread.

At the seam.

Every time.

Automatically enough that nobody has to remember the rule exists.

Because a standard you can only enforce when you are personally watching is not a team standard. It is your availability disguised as architecture.

AI is a mirror

This is what took me longest to admit.

The bottleneck was never really AI quality.

AI can write fine code. It can follow patterns. It can generate tests. It can move quickly through implementation details that used to take hours. That part is not the hard problem anymore.

The bottleneck is whether your team's standards exist outside one person's head.

And for many teams, mine included, they often don't.

AI is a mirror held up to that arrangement. It moves fast enough to expose that your "system" was a person. The moment that person can't be in every review — because there are now more changes, more branches, more generated code, more small decisions landing in parallel — the consistency starts to evaporate.

Not because the team stopped caring.

Because the structure was never actually externalized.

The architecture was held together by memory, taste, and attention.

Those are powerful things. They are also fragile.

They don't scale with speed.

When is a line worth drawing?

You can't write everything down.

You shouldn't try.

Most of a codebase genuinely should be left to judgment — human judgment, AI-assisted judgment, team judgment. Not every choice needs a rule. Not every inconsistency matters. Not every pattern deserves to become policy.

So the real skill is not documenting more.

It is knowing which lines are load-bearing.

Three questions help me decide whether a standard deserves to become part of the system.

First: if two people answer this differently, does the code break later?

If divergence is harmless, leave it to taste. If divergence compounds — two names for one concept, two ways across one boundary, two places where the same rule lives — it is load-bearing.

Second: would I catch this in review if I happened to see the pull request?

If the answer is yes, then the rule currently lives in my head and nowhere else. That means it disappears the moment I'm not looking. Those are the first rules worth moving into the system.

Third: is it cheap now and expensive later?

The lines worth defending are the ones that cost almost nothing to get right at the start and a weekend to fix once they spread. The import that should not exist. The concept named the wrong way. The state placed in the wrong layer. The shortcut that feels harmless until five more features depend on it.

Everything that fails all three questions, I try to let go of.

The team — and the AI — should move at full speed inside the rest.

The line doesn't defend itself

The first post was about the doors I keep for myself.

This one is the part I got wrong by leaving it unsaid: a door I'm the only one guarding isn't guarded.

It's just closed until someone leans on it.

The work didn't move up the stack from writing code to drawing lines. It moved one step further than that.

From drawing the line to making it hold without me standing on it.