Seven Things I Do Every Day In Claude Code

I spent the past year using Claude every single day, working for a seven-figure-a-year enterprise and building out custom automations, dashboards and agents.

In that time I've learned exactly what not to do. More importantly, I've learned how to think like a top-tier software developer.

Work In Claude Code

Desktop and Cowork are excellent starting points for anybody getting into AI. Desktop lets you add instructions to a project so you don't keep re-prompting Claude for the same type of work, and Cowork goes further, connecting different data sources and applications.

Both will let you use coding technology to create platforms, processes and automations. What they lack is the depth and breadth of Claude Code.

Claude Code runs in a terminal on your computer. Don't be put off by that. When I first started, I was intimidated by working inside a coding terminal, as somebody with no software engineering background. Once I got over that hump, I never went back.

In the terminal you can open multiple terminals at once, set up a persistent memory system (more on that below), and work with the files already on your PC without uploading CSVs the way you'd have to in Desktop. For those reasons alone, I find Claude Code a far better way to use this technology.

Ask Open-Ended Questions, Then Follow The Instructions

Learn to ask open-ended questions, the kind that lead to more detailed answers. Apply that to Claude Code, or basically any of these AI systems, and you'll get much better results and richer outcomes.

Everything you receive from these systems comes downstream from what you ask and how you ask it. Open-ended questions usually start with who, what, where, when, why or how. Ask those instead of yes-or-no questions and you'll get far deeper explanations, especially in Claude Code.

The other half is following high-quality instructions. As orchestrators of this technology, we don't have to be masters of it yet; that comes later. These AI are extremely intelligent about software and technology, so following their instructions properly gets you better outcomes.

When Something Doesn't Make Sense, Ask It To Explain

If you don't understand an instruction, a system, a data source, a website, or anything it tells you to do, ask it to explain it to you. It's as easy as that.

Handing off your human critical thinking is the exact opposite of what we want to be doing. You want to understand what you're doing, so your learning compounds and the next time you do something, you don't have to question it.

So whenever you're working in Claude Code or any of these systems, ask it to explain in simple terms, and learn something along the way.

Research Before You Build

Spend a substantial amount of time gathering data and information and researching whatever it is you're building. That's the bulk of the work in orchestrating and architecting with these tools.

Any software developer who's been in this game since before there was AI will tell you they spent a huge amount of time planning before writing a single line of code. The cool thing about today is we don't have to be software developers to use these tools.

Get good at being an architect. Tell these systems clearly what you want, listen to their instructions, and give them as much information as the outcome needs. Research and gather as much as you can before you hit build.

Once you actually start building, that's probably the easiest step. You hit enter and the technology builds what you asked for. The preparation, analysis, research and learning have to come first if you want to be doing this at a professional level.

Use Plan Mode Religiously

If what you're working on is intricate or extensive, or needs a vast amount of thinking and tokens, enter plan mode. Don't start a big build by telling your AI an idea and letting it rip. You'll get poor outputs and spend a lot more time on the back end.

Say it's a complicated automation, an agent set up to handle a complex task, or even a dashboard that compiles your data sources into a one-stop shop. That's when you want plan mode.

By this point you've done the research, asked the open-ended questions, and dictated everything about the build. I'd recommend something like Wispr Flow for that, because dictation is so much faster than typing.

In plan mode, get really clear on what you're building and every detail you can think of. Then ask Claude itself: are there any aspects of this I'm not thinking about? How can we get creative with this build and ship something quicker and more effective right away? Have that little back and forth with your system.

Then, and this is super important, read the plan and make sure you understand what it's doing. This technology is incredible, and it still makes mistakes. It hallucinates, and sometimes it includes things you never told it to do, because it's designed to try to be efficient. Sometimes you'll read the plan and think: actually, I don't want you to do that, or you understood me wrong.

So get out your notebook (I use a notepad right on my computer) and write down everything you want changed or corrected. Stay in plan mode until you've gone back and forth enough that the plan is as perfect as you're going to get it. Only then do you hit enter and start building.

The Real Work Starts After The Build

I believe this is the least talked about of the seven. The build is never actually done until you've performed this step.

Spend time reviewing, analyzing and correcting the work the AI delivered. Once the product, dashboard, automation or whatever it is has shipped, do extensive testing.

You can tell Claude to include a self-audit step at the end of your plan, and I'd encourage you to. Have it run smoke tests. You can even tell it which tests you want it to run. Include that in the plan and it will perform a self-audit for you.

Then do a visual pass yourself and go through everything that was built. You're going to find all kinds of little errors, hiccups, things that don't look right aesthetically. Jot it all down on your notepad, then re-enter plan mode with all of your corrections.

Listing corrections one by one, or putting in a couple and letting it go crazy rebuilding things, wastes tokens and time. In plan mode, all of your corrections can be coded at once instead of piecemeal. You may have to do this a number of times.

As a bonus, once you've started revising, take some space. Step outside, put your feet on the ground, or sleep on it, then look again with fresh eyes. You'll be a different person when you come back, and you'll notice different things.

I don't care what any influencer on X or YouTube tells you: it is almost impossible to one-shot anything meaningful. Research, ask good questions, make the plan, build it, then revise and edit everything to perfection. If you want to do this at the highest level, those are the steps to follow.

It is almost impossible to one-shot anything meaningful.

Set Up A Persistent Memory System

This one's non-negotiable.

I've done the groundwork here. There's a prompt you can copy and paste into your own Claude Code that sets up the persistent memory system I created for my own workflow. I've tested it many times, for clients, for friends and for anybody else I've interfaced with, and it's going to speed things up for you.

Think about the first time you do anything, whether it's on the computer or you're learning a new skill or a game. It always takes more effort, and it always takes longer the first time than the next couple of times.

A persistent memory system is essentially a second brain. Claude remembers every step you took together while building something, and it keeps a lessons file. That's important, because no matter how sophisticated this gets, it's going to make mistakes, and you correct it along the way.

Say you're building a dashboard for the first time, and you've corrected it many times; some things went wrong and some went right. Your memory system remembers all of that context. The next time you build something similar, it remembers the steps along with the lessons and corrections you made, so for me the build is at least ten times faster. Every time you do that, it compounds.

The memory also lets the system get to know you and how you work, which adds to the compounding effect.

Show me the prompt

Getting In There Every Day

You don't need to be a full-stack software developer to excel at this. It can't hurt, and people with that background will probably get there faster than you. Use the tool and technology, think about it like a professional, and get in there every single day, learning and compounding your learning.