# How I use AI as leverage, not autopilot

*2026-11-12 · Fariz Wibisono*

AI writes a lot of my first drafts now, in code and in content. This is where I draw the line between what the tool does and what stays my job, and the writing that shaped how I think about it.

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](https://x.com/karpathy/status/1886192184808149383): 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)](https://www.youtube.com/watch?v=LCEmiRjPEtQ) 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](https://addyo.substack.com/p/the-70-problem-hard-truths-about). 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](https://addyo.substack.com/p/vibe-coding-is-not-the-same-as-ai), and that line is the one I try to stay on.

Kent Beck calls his version [augmented coding](https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes). 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](https://simonwillison.net/2025/Mar/11/using-llms-for-code/) 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](https://emilkowal.ski/ui/developing-taste), 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](/projects/content-pipeline), 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.

> **If I had to put it in one line.** Use AI to go faster on what you understand and to learn what you don't. Never use it to skip the understanding.

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.

## Further reading

- Andrej Karpathy, [Software Is Changing (Again)](https://www.youtube.com/watch?v=LCEmiRjPEtQ), talk at Y Combinator AI Startup School.
- Andrej Karpathy, [the post that named "vibe coding"](https://x.com/karpathy/status/1886192184808149383).
- Addy Osmani, [The 70% problem: Hard truths about AI-assisted coding](https://addyo.substack.com/p/the-70-problem-hard-truths-about).
- Addy Osmani, [Vibe coding is not the same as AI-assisted engineering](https://addyo.substack.com/p/vibe-coding-is-not-the-same-as-ai).
- Kent Beck, [Augmented Coding: Beyond the Vibes](https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes).
- Simon Willison, [Here's how I use LLMs to help me write code](https://simonwillison.net/2025/Mar/11/using-llms-for-code/).
- Birgitta Böckeler and colleagues, [Exploring Generative AI](https://martinfowler.com/articles/exploring-gen-ai.html), on martinfowler.com.
- Emil Kowalski, [Developing taste](https://emilkowal.ski/ui/developing-taste).