AI Principles — The Parts You Still Own

Agents write most of our code now. That’s not a complaint — it’s the best leverage I’ve seen in my career. But it’s created a quiet failure mode: people start treating the agent as the engineer, and themselves as the person who pressed go. The output got faster; the responsibility didn’t move anywhere.

These are the four principles I keep coming back to with the team. None of them are about prompting. They’re about the parts of the job that stayed yours when the typing got delegated.

You still have to think

The agent will produce an answer to almost anything you ask. That’s the trap. A plausible, well-structured, confidently-worded answer is not the same as the right one, and the better the model gets, the more convincing the wrong answers look.

Your job didn’t become “ask and accept.” It became “ask, then judge.” You’re still the one deciding whether the approach is sound, whether the edge case got handled, whether this is even the right problem to solve. If you’ve stopped doing that work — if you’re skimming diffs and trusting vibes because it’s fast — you haven’t delegated the thinking, you’ve just stopped doing it. Those are very different things, and only one of them is fine.

It’s never the AI’s fault

When something breaks, “the agent wrote it” is not an explanation. A human chose the task, chose the approach, reviewed the output, and shipped it. The accountability lives with that human and that process — it does not live with the tool. You can’t point at the model the way you’d never point at your compiler or your text editor.

But — and this matters just as much — accountability is not blame. We stay a blameless culture. When the agent shipped a bug, the question is never “who do we punish.” It’s “what in our process let this through”: the review that rubber-stamped it, the missing test, the context the agent never had, the spec that was too loose. The agent is part of the system now, so it’s part of the post-mortem — but the root cause is always a human decision or a process gap, and the fix is always to the process, not the person. Don’t scapegoat the AI. Don’t scapegoat the engineer either. Fix the system that let it happen.

Understand what you’re building — and what the options were

The most dangerous thing an agent does well is hand you the first reasonable approach as if it were the only one. Accept it without looking, and you’ve made an architectural decision you didn’t know you were making.

So the bar is: you should understand what you’re building and why this shape over the alternatives. If you genuinely don’t know the option space — new domain, unfamiliar system, a call with real consequences — that’s not a moment to let the agent decide for you. It’s a moment to go find the options. Ask another engineer. Ask the agent to lay out three approaches with trade-offs instead of one with confidence. Spin up a second agent to argue the other side. The tools are great at surfacing alternatives when you ask for them — the failure is never asking, and quietly inheriting the first thing that compiled.

Make the “how we decided” visible

Here’s the part that breaks teams quietly. All the real work — the options you weighed, the trade-offs, the reason you went this way and not that way — happens in a chat transcript nobody else will ever see. Then a PR shows up with the answer. The reviewer sees clean code and no idea how it got there.

The exploration being invisible is a much bigger problem with agents than it was before, because so much more of the reasoning now lives outside the diff. So write it down. The PR description should say what you were solving, what approaches you considered, and why you picked this one. A real decision gets a short design doc or an ADR. Commit messages carry the why, not the what — the diff already shows the what.

A good test: could a reviewer who wasn’t in the room reconstruct your decision from what you wrote, and push back on it? If all they can do is check that the code runs, you’ve shipped a conclusion with the argument deleted. The argument is the valuable part.

Closing thoughts

Notice what these have in common. The agent took over the production of code. It did not take over thinking, owning the outcome, understanding the system, or explaining the decision. Those four things are arguably more of the job now than they were when you were also the one typing — because the typing used to force you to slow down and engage with all four, and now nothing forces you. You have to choose to.

That’s the whole shift, really. The leverage is enormous and I wouldn’t go back. But leverage cuts both ways: it amplifies good judgment and bad judgment equally, and it does it faster. The principles are how you make sure it’s amplifying the right one.

Written with an agent, reviewed line by line, and — per the fourth principle — here’s the how: these started as four rough notes, the agent drafted around them, and I cut and reshaped until the argument was mine. Low risk, fully reviewable. That’s the framework in action.