Skip to content
Portrait of Guglielmo Vaccaro
Back to the blog
AI

AI makes you build faster, not decide better

I use Cursor and Claude every day and they save me real hours. But speed and direction are two different things, and confusing them is the most expensive way to use these tools.

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.

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 quality of the code I write working alone is higher 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.

Frequently asked questions

Which AI tools do you use?

Cursor for code and Claude for the rest, every day. They are part of the nine tools I use on every project, listed in my stack for shipping a product.

Has AI made your products better?

It has made my code better, because it made maintenance affordable. Better products, no: those depend on what I decide to build, and that part has not changed.

Do you have AI write your articles?

The first pass on the structure yes, the final text no. A generated article is recognisable, and the value of what I write is in the things I actually did, which a model cannot know.

Is it not risky to depend on these tools?

The risk is not depending on them for the mechanical part: I could do that work before and I still can, just more slowly. The risk is using them where you cannot judge the answer, and there the dependency turns into blind trust.

Newsletter

An email now and then on AI, tools, and founder life. No hype, just things I actually use.

By subscribing you accept the Privacy Policy. No spam, unsubscribe whenever you want.