AI makes you build faster, not decide better

I use AI every day to write code, for the first pass on text and to look inside data. It saves me real hours, and I have no intention of stopping.

But the leverage it gives is on one dimension only: how fast you produce. It does not touch the other one, which is whether what you produce is the right thing. And since the cost of going in the wrong direction grows with speed, a tool that makes you faster without improving your direction can make the outcome worse.

The rule I use: only where I can already recognise a wrong answer

I use AI where I have enough competence to notice when it hands me something wrong. Where I do not, I do not use it to decide: at most I use it to sketch a map that I then verify elsewhere.

The reason is that these tools produce plausible answers with the same confidence whether they are right or wrong. The filter cannot be the tone of the answer, because the tone is identical. The filter has to be you.

This inverts the common intuition. AI looks most useful where you know least, and that is exactly where it is most dangerous, because you have no way to check it. Where you know a lot it saves time at no risk. Where you know little it makes you run in the dark.

Where it gives real leverage

Understanding code I did not write. The best use case by far. Having a chunk of unfamiliar code explained is faster than reading it, and verifying the explanation is immediate: I open the file and check.

Repetitive changes. Renaming, fixing types, writing migrations, generating test data. Work that has to happen, that nobody sees, and that used to eat entire afternoons. Verification here is trivial: either it compiles and the tests pass, or it does not.

The first pass on text, never the last. I draft the structure, have it rewritten, then keep the structure and rewrite the sentences myself. Generated text is obvious when published, and my problem was never grammar anyway: it is saying something I actually believe.

Asking me questions about data. Pasting an export and asking what stands out. Not because it finds answers I could not find, but because it asks the questions in twenty seconds instead of half an hour. I then check the answers against the real data myself.

The common thread: in all four cases verification costs less than production. That is the condition that makes AI worth it, not the difficulty of the task.

I barely write any code by hand

Everyone can take whatever approach suits them here, and I have no interest in telling anybody how to work. Personally, I write almost nothing by hand any more.

What has not changed is the review. I read the code, I understand it and I correct it, because that is the one place where the rule above still has to hold: if you cannot recognise a wrong answer, delegating the writing just means stacking up problems you will find later.

The further you get into the tool, the more you can build systems that review themselves, with checking loops that go back over what they have just produced. And the models are improving fast: the code they produce now is more precise and more reliable than what they produced before. In a year this section will probably need rewriting, which is a good sign.

The first eighty per cent arrives fast, the last twenty is the work

The speed AI gives you is not spread evenly across a project. The first part gets built very quickly: the structure, the screens, the main path. Within a few days you have something that looks finished.

It is not. What is missing is the twenty per cent that decides whether the product actually gets used: the edge cases, the empty states, what happens if somebody goes back halfway through, the error message written so it makes sense, the flow with no gaps in it. Taken one at a time they are small things. Put together they cost more time than the eighty per cent before them.

The problem is not technical, it is one of expectations. Treat the project as finished at eighty per cent and you promise a date you will miss, stopping exactly where the product stops being a demo. The early speed is real, but it is speed on the part that was already the easy one.

Where it stops working

It stops working the moment the problem is no longer "write this" but "decide what is worth writing".

Which problem to solve, for whom, what to leave out of the first version, when to shut down: these are all questions with no correct answer to retrieve. They depend on what you saw talking to people and how much risk you are willing to take. A model can give you the arguments for any option, which is the opposite of being helped to choose.

It is also where I paid the highest price in the past, long before using tools like these. Two years on a market I never verified was not a speed problem: I was building plenty. If I had had AI back then, I would have built the wrong thing in one year instead of two, and the lesson would have arrived earlier only by accident.

What actually changes: maintenance, not creativity

The real gain is not in ideas, it is in the boring part. Renaming things, fixing types, rewriting a function so it reads better, writing the comment nobody ever writes.

That has a side effect worth more than the time saved: it makes doing things properly affordable. I used to postpone refactoring because it cost an afternoon. Now it costs twenty minutes, so I do it. The code in the projects I run working alone is cleaner today than when I worked in a team, and not because I got better.

How I use it in practice

1. I define the problem in writing before opening any tool. If I cannot put it in three lines, AI amplifies the confusion instead of resolving it.
2. I ask for the mechanical part, never the direction. "Rewrite this function with this signature" yes. "What should I build" no.
3. I always verify, and verification has to be cheap. If checking the answer costs as much as writing it, I have gained nothing.
4. I rewrite the final text. Always.
5. Product decisions get made by talking to people, not to a model.