AI Coding Isn’t About Writing Code Faster - It’s About Thinking Differently

Don’t touch the code. Of all the rules in the brief I gave the AI agents rewriting 180 of my old blog posts, that one mattered most, and it was the one I wasn’t willing to take on trust. That project changed how I think about AI coding, and speed had little to do with it.

Speed is what people notice first about AI coding. It’s also the least interesting part. Code that arrives faster is only worth having if you can say precisely what you wanted and prove you got it. That’s a different job from the one most of us trained for, and it moves the developer up a level: from typing to writing briefs, defining checks and making decisions.

I see it as three shifts.

Shift one: from writing code to writing the brief

My blog has more than 220 older posts, mostly short WordPress, WooCommerce, ACF and PHP snippets. During this year’s site rebuild, 180 of them still had almost no explanation around the code, so AI writing agents rewrote the text from a strict brief.

The brief did the job that code used to do. It’s where the constraints lived and where “done” was defined. Write it vaguely and you get vague output at scale. Write it precisely and the output becomes predictable.

I now think of a brief the way I think of a function signature with good documentation:

• Constraints. What must stay true no matter what, like “the code blocks are untouchable”.
• Examples. One good output teaches more than a paragraph of adjectives.
• A definition of done. Something you can check, not “make it better”.

Assume the agent will follow what the brief says and guess at whatever it only implies. Every guess is a place for the output to drift, so leave as few as you can.

Shift two: the check is the real prompt

A brief says what should happen. A check proves whether it did. Every draft went through a validator before it was accepted, and after saving, every code block was compared byte-for-byte with the original.

That second check earned its keep. A script that saved posts through wp_update_post() was quietly damaging code, because WordPress strips slashes from the data it’s given before saving. In PHP snippets that’s destructive: \n becomes a plain n. Read the post and it looks fine. Compare the bytes and four posts fail. The bug was the agent’s own, and so was the fix, once the check exposed it:

// wp_update_post() unslashes its input, so slash it first.
wp_update_post( wp_slash( [
	'ID'           => $post_id,
	'post_content' => $content,
] ) );

I wouldn’t have caught that by reading. The check caught it because the check existed. That’s why I’ve stopped treating tests and validators as cleanup after the prompt. They’re the most precise part of it, the part an agent can’t talk its way around. If you ever save content programmatically, the wp_slash() reference is worth five minutes.

The brief had one more rule I’d now copy into every future one: if the old code has a problem, flag it, don’t fix it. The agents flagged 136 posts, for deprecated functions, missing escaping and a few snippets that wouldn’t run on PHP 8, such as a nested ternary without parentheses. A silent fix would have looked helpful and broken the one guarantee that mattered. A flag turned each problem into a list item a human can work through deliberately.

Shift three: from one answer to a comparison

Ask an agent how to fix something and you get one fix, delivered with confidence. Ask what your options are and what each one costs, and you get something more useful: a decision you can actually make.

A small example. A drag-and-drop ordering plugin on my site squeezed the admin list’s Title column to about 50 pixels. The cause was a genuine bug: it copied column widths from the first row’s <td> cells, but WordPress renders the title cell as a <th>, so that column never got its width. There were three reasonable ways out: drop the plugin, edit its files, or correct the widths from outside it. I kept the plugin and fixed it with a small admin script. Dropping it would have thrown away a tool that otherwise worked, and editing its files would be undone by the next update.

Those reasons are the kind an agent can list but can’t weigh for you. It doesn’t know how much you trust a plugin, how often you update, or who else maintains the site. You do. Asking for trade-offs instead of answers keeps that judgment with the person who has the context.

In AI coding, reading diffs is the job now

All three shifts end in the same place: reading. When an agent does most of the typing, your main contribution is attention, and most of it goes into the diff.

It’s a different kind of reading from reviewing a colleague’s pull request. You’re watching for changes to files you never mentioned, a fix that treats the symptom, a helper that duplicates something WordPress already has, a confident comment describing code that does something else. It’s slower than skimming, and it’s the part that decides whether the project is any good. The theme build itself is written up in I built a WordPress theme with AI, and the recurring failure modes are in what AI still gets wrong when building real websites.

What AI coding means for juniors and seniors

For juniors, the risk is obvious. If an agent writes the code, where does the learning come from? From staying the one who reads. Ask the agent to explain before it edits. Break its code on purpose and fix it yourself. Write the check before you look at the output. The skill you’re building is judgment, and judgment only grows from checking things.

For seniors, the risk is quieter. Experience made us fast at writing code, and that edge is shrinking. What isn’t shrinking is knowing where WordPress will surprise you, what a client actually meant, and which of three working solutions will still be pleasant to live with in two years. That knowledge now goes into briefs and checks instead of keystrokes. Whether that leaves developers with a job at all is a fair question, and I take it on in are developers still relevant in the AI era.

If I had to fit it on a sticky note:

• Write briefs like APIs: constraints, examples, a definition of done.
• Build the check before you trust the output. Byte-for-byte beats eyeballing.
• Tell agents to flag problems, not silently fix them.
• Ask for options and their costs, then decide yourself.
• Treat reading diffs as the work, not the overhead.

Faster code was never the point. Knowing exactly what you want, and being able to prove you got it, always was. AI just made that impossible to skip.