Most writing about AI coding right now is aimed at someone else. The product manager opening Lovable for the first time. The marketer building an internal tool over the weekend. The founder testing an idea without waiting for a developer.
That advice is good. It is just not written to you.
You have written code for ten, twenty, maybe thirty years. You know what a race condition is. You have stood in a post-mortem at 3am. You have watched companies build their core business on code no one dares touch anymore. This is written from that position.
Because as it turns out, you are the one with the most to gain from understanding AI coding properly. And the most to lose from not doing so.
The traps are different. Not fewer.
For a vibe coder, the biggest risk is the app breaking and not restarting. Uncomfortable, but contained. For you, the risk is a silent rewrite that slips past code review and sits in production for three months before someone notices a financial calculation flipped sign on a specific branch of the logic. That is a different class of problem.
The shift is not that the tool is more dangerous for you. It is that your blast radius is larger. You integrate against systems that cost money to halt. You operate inside codebases where an N+1 query that runs fine in staging takes production down on first real load. You have consumers, contracts, SLAs.
That does not mean step away. It means the five basic disciplines of AI coding carry a different weight when you are an engineer. Not less. More.
Commit discipline is your review surface
Beginner advice says "use Git as save points." You already have Git. That is not the point.
The point is that an AI agent can touch fourteen files in a single iteration. When you do code review, it is not the final diff you are interested in — it is the reasoning steps between them. And the reasoning is gone if you let the agent work for hours and then commit a compact lump. The granularity of your commits determines how much information you have left to review.
The discipline that actually works: one commit per logical change, even if that means fifteen commits where you used to make one. Squash before merge if you must, but never let the agent collapse the work for you. When someone later asks why a specific handler looks the way it does, you want to point at a commit, not at a cloud.
The context window is a memory budget
You already treat memory inside applications as a resource that needs to be managed. Treat the context window the same way.
A running session is not an extension of your workday. It is a work block with a finite budget. When that budget is exhausted, output degrades gradually before it crashes. The model starts weighting earlier wrong attempts as heavily as your new instructions. It hallucinates variables that existed in a deleted file. It suggests API calls against a version you have already migrated away from.
The healthy reflex — staying in a degraded session to avoid repeating context — is wrong. Close it. Write a short executive summary of the current state, paste it into a fresh session with the relevant files referenced, continue. It is faster. The session is not owed loyalty.
Rule of thumb: when the model starts making changes you did not ask for, stop. It is not being clumsy. The context window is leaking.
CLAUDE.md is an interface, not a notebook
Standing instructions are not a document where you list your opinions. They are an interface to the agent.
That means the same quality bar applies as for a public API. Correct, concise, deterministic. Every rule in the file should be defensible, motivated, testable against. If you need to repeat an instruction in a session, that is a bug in CLAUDE.md, not in your prompt.
A few patterns that actually save time:
- Describe architecture in terms of what MUST change together, not in terms of what exists. Files change. Invariant relationships do not.
- Put hard "never do" rules ahead of "prefer." "Do not use raw SQL — always use our repository functions" prevents more debugging than "prefer type-safe queries."
- Include a short section the model treats as an external customer: "if you are about to alter the schema, stop and ask." That is not protection from the model. It is protection from your own future self pasting a broad prompt in a stressful moment.
CLAUDE.md is the onboarding document for a colleague who starts every session with zero memory. Write it accordingly.
Small bets, not because you are cautious
The standard objection to breaking work into smaller steps is that it kills momentum. That holds for a vibe coder who wants to see something move on screen. For you, it is the wrong diagnosis.
You have already internalised the principle in other contexts: trunk-based development, feature flags, progressive rollout. The reason is not caution. It is that blast radius is fundamentally cheaper to handle when it is small. Verifying five lines is trivial. Verifying 3,000 lines spread across fifteen files the agent created autonomously is not.
In practice: define the smallest meaningful unit before you prompt. One schema addition. One endpoint. One migration. Verify. Commit. Iterate. You spend twenty seconds on setup and save hours in debugging that never has to happen.
This is not new discipline for you. It is old discipline applied to a faster tool.
Adversarial review by default, not by exception
AI models are pathologically obedient. They build what you describe. They do not challenge your assumptions. They do not adjust the code for failure modes you did not mention.
For the beginner this is a discovery. For you it is already known — every junior you ever onboarded had to learn the same thing. The difference is that the model never learns from its own mistakes the same way. You therefore have to bake the review pass into the workflow, not hope it happens organically.
A simple routine that actually works: after every non-trivial feature, switch persona explicitly. "Review the code you just wrote as if a hostile customer is trying to break it. List every failure mode where input does not look like you assumed. List every resource leak that occurs when an upstream service dies. List every scaling assumption you made implicitly." The model knows the answers. It just needs to be told to look for them.
This is the same knowledge you already have as a senior. What is new is that you have to tell the model which hat to wear, every time.
The shift you are actually making
For the non-engineer, AI coding is a shift from not being able to build to being able to build. For you, it is a shift in what your work *is*.
Value moves from syntax and implementation detail to three things: architectural clarity, failure-mode reasoning, and depth of verification. Knowing which invariants must hold. Being able to articulate what should break before it breaks. Being able to say "this code is fit to trust in production" and stand behind it.
That is not less engineering. It is more.
What disappears is the typing time. What stays — and grows — is judgement. Which is also what senior engineers have always been paid for. The model just makes it more visible.