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

Contents

I have spent more than a thousand hours working with Claude. Not using it now and then: working with it every day, in my business and in my code. And what has changed how I work is not what I do with it, it is what I have stopped doing.

These are fourteen 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. Start every conversation from scratch

A Project is a folder of conversations that share the same instructions and the same files. What you write in there once applies to everything you open afterwards, and that is the whole difference between repeating the same prompt a hundred times and never repeating it again.

Before I had them, every conversation started by explaining who I am, what I do, how I write, and re-uploading the same three files. Now I open the Project and type what I need straight away. The context is already in place before I type a word.

2. Give it generic instructions

“Write in a casual tone” means nothing. It is an instruction you cannot check: there is no way to look at the answer and say whether it followed it. And what cannot be checked does not get followed.

What does work are concrete rules: sentences under twenty words, a list of banned words, and three of my own texts as examples inside the Project. With that the output sounds like me. With “casual tone” it sounds like everybody else.

3. Wait for it to work me out

Some people drop hints and hope the model builds a picture over time. It is a waste of time: you tell it directly and that is that. “Remember I work in this, that I sell that, and that I write in European Spanish.”

Stored in memory or in the Project instructions, that goes into every new conversation on its own. Three sentences you write once and never write again, and they change every answer that comes after.

4. Let it agree with me unchecked

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. Let it write code without a plan first

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.

6. Believe anything without a file and a line

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.

7. Use it as a chat

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.

8. Draft replies to enquiries 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.

9. Write the meeting recaps

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.

10. Write the weekly reports

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.

11. Install a skill and forget it

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.

12. Give it permissions it does not need

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.

13. Use the same model for everything

Using the big model to classify emails is paying to think where you only need to read. And using the fast one to decide an architecture is far more expensive still, because you do not pay for that mistake in tokens: you pay for it in weeks.

The split I use: the big one to think, decide and write code; the fast one to summarise, classify, extract and sort. Most of what you ask for every day is the second kind, and that is where the saving is without losing anything.

14. Treat it as a tool

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.

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 five: ask for the plan before the code. It is the one that costs least and gives you the most time back from day one.