Things I would NEVER do after using Claude for 1000+ hours

Contents

This can genuinely change the way you work.

Here are eighteen things I no longer do. Each one took me time to learn, and I was getting almost all of them wrong for months without noticing.

1. Repeating who I am in every new chat

A Project is a folder where you keep your instructions and your files. Every conversation you open inside uses them. You write it once and it is set for good.

I used to start every chat explaining who I am, what I do and how I write, and uploading the same files again. Now I open the Project and go straight to what I need.

And tell it explicitly, do not drop hints and hope it picks them up. “Remember I work in this, that I sell that, and that I write in European Spanish.” Three sentences inside the instructions that you write once so you never write them again.

2. Asking it to write “in a casual tone”

“Write in a casual tone” is useless. Read it like this: look at the answer it gives you and try to decide whether it followed that order. You cannot. Well, neither can it.

What does work are orders you can check: “sentences under twenty words”, “never use these fifteen words” and three of my own texts as examples inside the Project. With that it writes like me. With “casual tone” it writes like everybody else.

3. Closing the laptop without it noting what we learnt

I have a file called rules that is the project's memory: how I write, what I never want to see, how it is put together inside, which decisions were already taken and why, and the mistakes it already made once.

And the point is not having it: it is updating it. Before closing each session I tell it to update the file with what we learnt that day. Not what we did, which is already in the code: what we learnt. The correction I had to make twice, the decision we took and the reason, the thing it assumed that was not true.

The next day it starts already knowing. Without that step, every session repeats the same three mistakes and you repeat the same three corrections forever. With it, the file grows on its own and within a few weeks there is barely anything left to explain.

4. Asking if my plan is good and believing it

These models tend to agree with you, and that makes them useless exactly when you need them most: when you have to decide something. If you tell it your plan, it will tell you it is a good plan.

What I do is open four separate conversations with the same case, each with a different role: the one watching the money, the one watching the risk, the one watching the user, and the one whose job is to argue against me. Without them seeing each other. Then a fifth, blank, with the four answers pasted in so it can decide. That is where the holes I could not see show up.

5. Trusting what a single agent says

A model reviewing its own work agrees with itself. It is the same problem as the previous point, but inside the code: you ask it to review what it just wrote and it tells you it is fine.

What I do is put two of them talking. Claude Code writes the plan or the code, and I hand it to Codex to review without having seen the conversation. Then I take what Codex said back to Claude and ask it to respond: where it is right, where it is not and why. And if they do not agree, another round.

It works because they are different models, trained differently, and they do not share the same blind spots. What one misses, the other sees. I read both versions and decide, which is still my job, but I decide with two opinions that actually contradicted each other rather than with one that is agreeing with me.

6. Asking for the code straight away

The most expensive mistake is asking for the code straight away. It writes it, and it writes it fast, and it writes the whole thing in the wrong direction. By the time you notice there are four hundred lines written and fixing them costs more than throwing them away.

I ask for the plan first and tell it explicitly not to touch anything. Ten lines explaining what it is going to do, in which files and in what order. I fix that plan in a minute, and from there the code goes where I want it. It is the change that has saved me the most time of all.

And the other half, which I missed for months: make it ask before it starts. I tell it that if anything about the job is ambiguous it should not decide for me, it should ask whatever it needs first. Three questions at the start save two hundred lines written against what I had in my head, and they almost always show me I explained the job worse than I thought.

7. Believing a fact without opening the file

It is wrong with exactly the same confidence it is right, and that is the problem. There is no change in tone to warn you that what you just read was made up on the spot.

So the rule is fixed: if it tells me something works a certain way, it tells me in which file and on which line it saw that, and I open it. And I tell it from the start that “I do not know” is a perfectly valid answer. When you give it permission not to know, it stops filling gaps.

8. Repeating by hand what it could repeat for me

A loop is this: you measure where you are, you change one thing, you measure again and you keep the change only if the number improved. Then another round. It sounds obvious and almost nobody does it: the normal thing is to ask, read the answer and decide by eye.

These are my three best. Each one is a prompt you launch and leave going round until there is nothing left to fix.

📚 Documentation always up to date. The least glamorous one and the one that saves the most grief, because out-of-date documentation misleads you more than no documentation at all.

Review all the code and check that the documentation reflects the current implementation. Update whatever is out of date, verify the changes and open a pull request.

🧪 Full product audit. This is the one that actually finds things: it walks the app as a real user, documents every bug with the steps to reproduce it and starts over until a whole pass comes back clean.

Create safe, realistic local data. Go through every feature, role, route, button, form, modal, state and flow as a real user would.

Define acceptance criteria, test edge cases and document every bug with the steps to reproduce it.

Find root causes, fix the problems, add tests and repeat the whole audit until you get a clean pass.

Ask for permission before touching production, sensitive data or destructive actions.

🔎 SEO and GEO audit. It orders the problems by impact and fixes the heaviest one first, rather than the list of a hundred minor things these tools usually hand back.

Review crawling, indexing, search intent, titles, internal links, structured data, sources and content ready to answer directly.

Order the problems by impact, fix the most important one first and repeat the audit and the reference searches.

Keep going until there are no critical errors left and no priority search without a clear, optimised page.

These and a few more are in the Forward Future loop library, which is where I got the idea of setting them up this way.

It is the same thing I was talking about in the article on why this moment is like BTC in 2012: what has changed is not that AI gets things right more often, it is that you can try and discard far faster. Whoever iterates ten times while you iterate once, wins.

Two rules to make the loop worth anything. First: always measure the same way, because if you change the criterion between rounds you are not comparing anything. Second: touch one thing at a time, because if you touch three you will not know which one worked.

9. Leaving it unplugged from my tools

An MCP is a standard plug. The tool says what it can do and the model uses it directly, without you copying and pasting anything in between. It is the difference between it telling you what it would do and it doing it.

The two I use most: NotebookLM, which gives it access to my notebooks and the sources I keep there, so it answers with my documents and not with whatever it remembers from the internet. And Canva, which lets it create and edit real designs rather than describing them for me to make by hand afterwards.

And there is one for almost everything: your database, GitHub, Figma, your task manager. Every one you plug in is one more thing you stop doing as the middleman. That is where it stops being a clever chat and starts being something that works.

10. Using it by copying and pasting

As long as you use it copying and pasting, you have a search engine with better conversation. The jump is in connectors: you give it permission to read your email, your calendar and your files, and it starts working with your real data instead of with what you tell it.

Always start with the read-only ones, where it cannot break anything. Permission to send or to write gets granted once you have spent a week reading what it drafts and you trust it. That order is not caution: it is that during the first week you are going to be correcting it.

11. Answering client emails by hand

A scheduled task checks the inbox every hour, finds what looks like a client enquiry, reads the whole thread and drafts the reply in my writing voice. It leaves it in drafts.

I read it, change whatever needs changing and hit send. Thirty seconds per enquiry instead of twenty minutes. And notice what is not automated: the send button. That stays with me, and I think it stays with me for good.

12. Writing every meeting recap by hand

The transcript goes in, the one any video call app already gives you, and out comes a summary with the same shape every time: what was decided, which task belongs to whom, and the follow-up email already drafted.

Two minutes instead of twenty. But what really matters is not the time: it is that the output is identical every week. A summary with a different shape each time is one nobody reads, and then we are back where we started.

And to be honest: if this is your problem every single day, there are tools that already do it better than a prompt you put together yourself. Granola is the one I like most, and Fathom and Circleback are after the same thing: they join the meeting, take the notes and hand you the summary without you lifting a finger. I stick with my version because I take it into my own format, but if you only want the summary, start there.

13. Writing the Monday report by hand

On Monday morning, a scheduled task pulls the numbers from the spreadsheet, the inbox and the calendar, writes the report with the same structure as always, saves it in the client's folder and leaves the email drafted with the report linked.

It is done before I open the laptop. I read it, change two sentences and send it. This is what separates using AI from having AI working: the difference between asking for something and finding it done.

14. Installing a skill and never touching it again

A skill is what turns a generalist model into one that works like you: interface design with your judgement, documents with your template, decks with your structure, your way of writing and your way of reviewing.

And they do not get installed and forgotten. Every time something comes out wrong, instead of sighing, I add the line that was missing. Three weeks later the skill knows what I know about that, and you do not get there by writing a perfect prompt on day one.

15. Giving it access to production

It can read the repository, propose changes, write on a branch that is not the main one and run the tests. It does not touch production, it does not touch the real database and it does not run anything I cannot undo.

The question before granting a permission is always the same: if this goes wrong, can I go back in a minute? If the answer is no, that permission does not get granted. And this holds the same for an agent as for an intern, with the difference that the agent moves much faster.

16. Using the expensive model for everything

There are four and they are not interchangeable. From most to least expensive: Fable 5, Opus 5, Sonnet 5 and Haiku 4.5. Between the first and the last there is a tenfold difference in what each answer costs.

My split: Sonnet 5 by default, which is where ninety per cent of my work happens and is more than enough for writing code. Haiku 4.5 for the mechanical stuff: summarising, classifying, extracting, sorting. And I go up to Opus 5 or Fable 5 only when the problem is genuinely hard: an architecture decision, a bug I have not found in two hours, something long the agent has to hold together over many steps.

Using Fable to classify emails is paying to think where you only needed to read. And the other way round is worse: using Haiku to decide an architecture is enormously expensive, because you do not pay for that mistake in tokens, you pay for it in weeks of work in the wrong direction.

17. Keeping it switched off until I need it

This is what sums up everything above. A tool you open when you need it, you ask it for something and you close it. Infrastructure is running whether you look at it or not.

When you have the Projects with your instructions, the skills with your judgement, the connectors with your data and the scheduled tasks running in the morning, you are no longer using a tool: you have a system that works while you do something else. That is the real change, and it is the one almost nobody makes.

18. Typing the prompts instead of dictating them

This is the one that looks least important and the one that has changed my day the most. I no longer write my prompts: I dictate them. I use Typeless, and WisprFlow does the same thing. You hit a key, you talk, and it appears written wherever your cursor is.

The difference is not typing speed, it is how much you tell it. Typing, you put four lines because typing is tiring, and then the result is not what you wanted because half the context was missing. Talking, you give it a whole paragraph with the why, what you already tried and what you do not want it to do, in the time it used to take you to write the title.

The bottleneck was never the model: it was how little you told it. And you told it little because writing it out felt like a chore. That chore disappears and the answers change on the spot, without touching anything else.

Where to start tomorrow

If you take one thing from this, make it point one: set up a Project with your instructions and your files. It is half an hour and it is what makes everything else possible.

And if you take two, make the second point seven: ask for the plan before the code, and make it ask you whatever it is not sure about. It is the one that costs least and gives you the most time back from day one.