How I use AI as leverage, not autopilot

I use AI tools like Claude every working day. They read an unfamiliar codebase faster than I can, draft tests, sketch the first version of a feature, and turn a PDF into a structured draft in seconds. I would be slower without them, and I am not going to pretend otherwise.

What I have learned is that speed was never really the job. The job is software that still works, and still makes sense to the next person, months after it ships. So I try to use AI as leverage on my judgement, not as a replacement for it.

Where the line came from

Andrej Karpathy gave the industry the phrase vibe coding (opens in a new tab): giving in to the vibes, accepting what the model writes and not really reading the code. He was clear that it suits throwaway weekend projects. In his talk Software Is Changing (Again) (opens in a new tab) he describes the other end: keep the AI on a short leash, work in small steps, and make the loop between the model generating something and a person verifying it as fast as possible. That loop is most of how I work now.

Addy Osmani put a name to something I kept running into, the 70% problem (opens in a new tab). AI gets you most of the way very quickly, and the last stretch, the edge cases, security and code that someone can maintain, is where engineering knowledge decides the outcome. He also draws a firm line between vibe coding and AI-assisted engineering (opens in a new tab), and that line is the one I try to stay on.

Kent Beck calls his version augmented coding (opens in a new tab). The difference from vibe coding, in his telling, is simply whether you still care about the code: its tests, its structure, whether it will be easy to change. Simon Willison's notes on using LLMs for code (opens in a new tab) say the same thing from daily practice: give the model good context, and never hand over the job of checking that the code actually works.

And then there is taste. Emil Kowalski writes that taste can be developed (opens in a new tab), by making things yourself and paying attention to great work. When output becomes cheap, knowing what good looks like is the part that stays scarce.

What that looks like in my week

I write the rules down where the tools will read them. In my larger projects, each part of the codebase has a short file saying what it holds and what it must not do. People and AI read the same rules, so suggestions start from the same constraints instead of from a guess.

I keep changes small and I read every line. If I cannot explain a change in one sentence, it does not go in, whoever wrote the first draft.

I let automatic checks have the final word on the boring questions. Type checking, tests, linting and a check for unused code run on every change. The tool proposes; the checks and I decide.

I draft with AI and decide with people. In an internship project, AI turns technical PDFs into article drafts, but it can only pick products and industries from lists that already exist, and nothing goes live until an editor approves it.

And I keep practising the fundamentals: data modelling, system design, debugging. They are what let me notice when a confident suggestion is wrong. If I stopped practising them, I would stop noticing.

The engineers I want to learn from are not the ones who type the least. They are the ones who know what good looks like, check their work, and spend the time they save on the decisions that matter.

Where the line came from

What that looks like in my week

Further reading