Who Writes the Rules

The first push on any change is the heaviest one. Experienced developers have good reasons to keep their distance from AI, and those reasons deserve respect. They are also the strongest qualifications anyone could bring to the work ahead, because the people who care most about quality are the ones who should write the rules for how this tool gets used.

Every code base built by hand carries a fingerprint. You can read it in the way names get chosen, in the comments where the team argued with itself, and in which corners got cut and which ones nobody was allowed to touch. Spend enough years inside one and you can tell who built it without opening the log.

Now hand the people who built it a tool that writes clean, correct code on demand. Most of them will not say they are afraid; they will say they are worried about quality, and they will mean every word. Underneath that worry sits a harder question, one that rarely gets spoken: if the fingerprint goes, what happens to the person who left it?

I think it is a fair question, and I think it is the right place to start, because it is also a door.

The Door at Rest

Picture a door made of solid stone, set deep in its frame. Nobody stands guard over it, and it passes no judgment on whoever walks up to it. It is simply heavy. You lean on it and nothing happens, you push harder and nothing happens, and after a while the effort starts to feel foolish.

Anyone who tells you that door is light is selling something. The first push on any real change produces nothing you can point to, sometimes for a long stretch, and every instinct you have tells you to save your strength for work that shows.

Newton described the rest of it centuries ago. A body at rest stays at rest, and a body in motion stays in motion. Everything hard about the door lives in the first inch; once it moves, the same stone that fought you starts carrying its own weight forward. The door never gets lighter, but a moving door asks far less of you than one at rest.

A lot of experienced developers have already cracked this door open. They use AI for a quick lookup or a second opinion on a function, and then they close the tab. That is curiosity, and curiosity is safe precisely because it asks nothing of you. It cannot embarrass you, because you never handed it anything that mattered.

Leaning is a different thing. Leaning means giving the tool real work on a real system, with your name on the result, and being willing to be wrong where people can see it. That cost is exactly what moves the door, and it is also why so many of us stop short of paying it.

What You Are Actually Pushing Against

The objections we raise about AI are almost always technical. The weight underneath them almost never is, and the reasons for that weight are good ones that deserve more than a nod.

The first is identity. You spent years becoming the person who knows how it should be built. You learned the system by breaking it and fixing it, and you have carried it in your head through every release since. When a machine produces a working version in seconds, a question surfaces that nobody says out loud: if it can do this, then what am I for? That question weighs more than any technical objection, and because it rarely gets named, it rarely gets answered.

Right behind identity comes exposure. Every large code base has places nobody looked at twice, the function written at the end of a long week or the workaround that was only ever supposed to be temporary, and anyone who has built something large knows where a few of those live. A tool that reads every line without tiring will find them. The fear is that it will be right about something you missed, and that being right will look like proof you were never as good as your reputation said.

Then there is speed, the fear with the most history behind it. Leadership wants speed, and speed and quality have been at odds for as long as anyone has shipped anything. Speed shows up on this quarter’s report. Quality shows up two years later, when the system either carries the load or buckles under it, and by then nobody connects the failure to the shortcut that caused it. The developers who care most about the work have watched quality lose that fight before, and they are usually the ones who stayed late cleaning up after it.

And then there is the fingerprint. Generated code can be correct and still tell you nothing about the people who made it. A hand-built code base remembers its arguments; you can see where the team chose clarity over cleverness, and where somebody fought for a test nobody else wanted. When the code comes out smooth and uniform, that record thins out, and the next developer inherits a system that works without any sense of why it was built that way. Code nobody recognizes as their own is code nobody fights for.

I am not going to argue any of this away, because all of it is true. What I want to look at is what we do while carrying it.

Three Stages

None of this is new. Every generation of builders has stood at a door like this one, and there is an old line about how new ideas make their way through the world:

All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as self-evident.

We all walk these stages, with every tool that changes our work. Open source walked them, and so did the cloud; each had serious, capable people standing against it at the second stage, and each became so ordinary that nobody remembers the fight.

The first stage, ridicule, is usually polite. The tool is a toy, autocomplete with good manners, and it cannot possibly understand a real system. Some of that is true, which is what makes the stage so comfortable, since every bad answer the tool gives feels like confirmation.

The second stage, opposition, sounds like responsibility. The tool will lower the standard, and it will hand junior developers a loaded weapon. These are the objections of people who care, which is why this stage lasts the longest. The trouble is that while you oppose the tool, you are not learning it, and the people who are learning it will decide how it gets used. Opposition feels like protecting the craft, but more often than not it leaves the craft without a voice in what comes next.

The third stage arrives whether you take part or not. One day the thing is simply how work gets done, and the only question left is who shaped it on the way there.

The door moves somewhere between the second stage and the third. Nobody argues their way through it; we lean our way through it, one real task at a time, until the objections we raised turn into the standards we enforce.

I say often that you miss every shot you don’t take, and technology has never worked any other way. Nobody is asking you to bet everything. A calculated bet is enough: pick one real task, give it your full attention, see what you learn, and then do it again. Write down where the tool helped and where it let you down, because that record is the first draft of your rules. The door does not need a hero. It needs someone willing to lean a little longer than last week.

The Chainsaw

Leaning does not mean lowering your guard. The danger is real, and the clearest picture I know of how to handle it comes from the woods.

Before the chainsaw, a forester felled trees with a crosscut saw and an axe, and the work was slow and brutal. When the chainsaw arrived, anyone with sense looked at it and saw danger, and they were right. In careless hands it was more dangerous than anything that had come before it.

It was also progress. It did in minutes what had taken hours, and with training and the right gear it became safer than the work it replaced. That safety did not come from the engine. It came from chain brakes and protective chaps, from training on kickback, and from felling methods written down by people who already knew how a tree falls. The machine made the work faster; the people who knew the woods made it survivable.

AI without guardrails is dangerous, and you are right to say so. It is also a tool, and guardrails come out of standards, and standards come from the people who know the craft. Someone who has never chased a race condition at two in the morning has no idea where generated code will hurt a team. You do. Your fear of lower quality is your credential, because the person most worried about the standard is the person most qualified to set it.

The Suit

That still leaves the fingerprint, and the worry that anything the tool touches comes out generic. For that one, I think about a good tailor.

Off the rack, a suit is cut for an average man who does not exist, so it fits everyone a little and no one well. A good tailor takes that same suit and changes the shoulders, the sleeves, the break of the trouser, and the taper at the waist. Done well, the result can stand next to a bespoke suit at a fraction of the cost and time. The tailor’s value lives in the fitting. He knows where this particular body departs from the pattern, which changes matter, and which ones would ruin the line, and years at the bench taught him things no pattern can.

AI-generated code is off the rack. It is correct and clean, and it was made for nobody in particular. Leadership gets the speed of the rack, and you supply the tailoring: the naming that fits this team, the structure that fits this system, and the judgment about where the generic answer would fail. The fingerprint does not disappear. It moves into the alterations.

That is where speed and quality finally stop fighting, because the rack is fast and the tailoring is where quality lives. Some pieces will still deserve a bespoke build by hand, usually the core that everything else depends on, where a subtle mistake costs the most. Somebody has to decide which pieces those are. That decision is the new craft, and it belongs to the person who knows the difference.

The Window

Right now, almost nobody has made those decisions in writing. Early in any shift the standards do not exist yet; there is no agreed way to review generated code, no shared sense of when to trust it, and no clear line between what gets built by hand and what does not. Those rules will exist within a few years, and they will be written either by the people who care most about the work or by whoever showed up first and cared most about speed.

There is an idea from Japanese martial arts and the tea ceremony that explains why the senior developer is the right person for this work. It is called shuhari, and it describes three stages of mastery. In shu, you follow the form exactly as it was taught to you. In ha, you understand the form well enough to bend it and break it. In ri, you leave the form behind, and the rules come from you.

Most experienced developers reached ri in their craft years ago, and that is part of why this tool stings; it puts a master back at shu, following someone else’s form with an unfamiliar instrument. That is uncomfortable, and it is also temporary. A beginner has to climb all three stages from the bottom. You already know the way up, and you will reach ri with this tool faster than anyone who has never reached it with anything. The world moves a new idea through its three stages slowly. You can move through your own much faster, once you start leaning.

The rules themselves are practical. They decide which parts of the system stay handwritten, what every piece of generated code must pass before it merges, how the team’s conventions get handed to the tool so its output starts closer to the fit, and when a reviewer sends output back instead of patching it. Each of those is a judgment call, and each one carries the fingerprint of whoever makes it.

Windows like this do not stay open long. Once a practice settles, the people who shaped it become its authorities, and everyone else inherits their choices. Today it is a blue ocean with almost no one in it, and the senior developer who learns this tool well enough to set its terms becomes the one a team, and eventually a field, looks to for how it ought to be done.

The craft has always survived the same way, through the people who carry it deciding how it moves into what comes next.

The door has already moved an inch. Lean, and it keeps moving.