What to do after you install Claude Code

You installed Claude Code, signed in, and now you’re looking at an empty window with a blinking cursor. It is alien, it is confusing, and the part where you actually do something with it is not obvious.

This article is not a tutorial. It will not make Claude Code less weird, and it will not turn you into a programmer. What it does is give you a reason to stay in the chair long enough for the weirdness to fade and the work to start.

Most guides stop where this one starts. They walk you through install and auth, list the slash commands, point at CLAUDE.md, and then leave you holding a tool with no shape for the first thing to do with it. If you have ever closed the window here and concluded the tool “isn’t for you,” you are not the problem. The guide ended one chapter early.

This article is that chapter.

The job has changed

Before you type anything, change the picture in your head of what you are about to do.

The old picture: a programmer types code, line by line, in a language only programmers read, and at the end there is software. To do this work you need to learn the language, then the framework, then the platform, then the tools, and somewhere down that long road you ship something.

That picture is out of date. The bottleneck in software work has moved. The coding activity, the part that used to take years to get fluent in, is now the part the machine is best at. What the machine cannot do is decide what to build, describe what “right” looks like, and notice when something is off. That work, the architecting and defining work, is now the job, not typing the code.

You are not behind because you are not a programmer. You are early because you have the part the machine still needs: domain expertise, taste, a clear sense of what the thing is for. The skill to build is not syntax. The skill to build is specification (saying what you want with enough precision that the machine can act on it) and validation (knowing whether what came back is right).

On this site, I argue that work is code. Using an AI code tool like Claude Code is one of the fastest validations of that idea. You define what you want, how it is delivered, what a working product looks like, and the output is code that you can deploy and use. Claude Code looks at EVERYTHING as code, so if you want a piece of software, a spreadsheet, an email, a PowerPoint presentation, or a video of cats with subtitles, Claude will see it the same way… code.

Pick something you actually want

The single biggest mistake at this stage is picking a “learning project.” A todo app. A tutorial clone. Something you do not care about, chosen because it seems like the sort of thing a beginner ought to build.

Skip it. Pick something you actually want to exist.

Two shapes work well for a first build.

The first is a small personal tool. A script that takes the messy CSV your bookkeeper sends and reformats it the way you actually need it. A weekly digest that emails you the three things you care about, pulled from wherever they live. The tedious spreadsheet step you keep doing by hand, automated.

The second is a one-page site for something real. A landing page for a side project. The resources you keep sending to clients, indexed in one place. A page that explains, in your words, what you do.

Both shapes share the thing that matters: you already know what “right” looks like, because you are the user. Validation is free. You will recognize a bad answer the moment you see it, because you have been doing this work by hand and you know what it should feel like.

Avoid the inverse: building a thing for a domain you do not understand, where you cannot tell whether the output is good. That is the hardest possible mode to learn in. If you have a great idea, you can come back to it when you know more. It won’t take long.

Describe it well

Before you ask Claude Code for anything, work the idea out somewhere familiar. ChatGPT, Claude on the web, Gemini, whichever AI you already talk to comfortably. You are not asking it to build the thing. You are asking it to interview you about the thing, and to write the brief that Claude Code will read.

A starting prompt that works:

I want to build [a one-line description]. Interview me about it. Ask me one question at a time. When we’re done, write a clear, complete prompt I can paste into Claude Code to start building it.

Answer the questions in your own words. The conversational AI is good at this part. It will surface assumptions you didn’t know you had, ask about edge cases, and notice when “what good looks like” is fuzzy. Spend ten or fifteen minutes here. The brief that comes out the other side is the spec.

Now you need a folder where the project will live, and Claude Code running inside it. Fastest path: open the starter kit and hit “Use this template” to get your own copy. Then open that folder the same way you opened things when you installed Claude Code. VSCode users: File → Open Folder. CLI users: cd into the folder and run claude. JetBrains users: open it as a project. Claude Code will pick up the CLAUDE.md and STATE.md the kit gave you. If a term in any of those files is unfamiliar (allowlist, dotfile, hook), the kit’s GLOSSARY.md explains them in plain English, and the AI Vocabulary page on this site covers the broader practitioner terms.

Paste the brief in. Ask Claude Code to flag anything still ambiguous and propose a first slice small enough to finish in one sitting.

This approach will save you time. You are not asking for software yet. You are working with the machine to sharpen the specification until you agree on what is being built. Most beginners skip this and go straight to “build me X.” The output is then exactly as vague as the request, and the iteration loop is long and frustrating. The fifteen minutes you spend on the spec save an hour later.

Watch it work, and check

When the first slice comes back, two things matter.

One: read what it did. You do not need to understand every line. You do need to understand the shape. What files exist now. What does each one do, in one sentence. Ask Claude to walk you through it at whatever level of detail you need. There is no wrong question here.

Two: run it and see if it does the thing. If it does, say so, and ask for the next slice. If it doesn’t, describe what happened, what you expected, and what you saw instead. “It crashed” is a weak report. “I clicked Submit and the page went blank, and the terminal printed a red message starting with TypeError” is a useful one. You are practicing validation. The more specifically you can describe the gap between what you wanted and what you got, the faster the loop closes.

Failure modes, named in advance

Three things will happen. They are normal. They are not signs the tool is broken.

Hallucination. The model will sometimes confidently say something that is not true: a function that does not exist, a file in a place it is not, an API shape that is wrong. The fix: when something doesn’t work, say so plainly and ask it to verify against the actual code or docs.

Context loss. In a long session the model forgets things you established earlier. The fix: restate the important constraint when you notice drift, or start a fresh session and paste the spec back in.

Stuck in a loop. It tries the same fix three times in slightly different forms. The fix: stop it, say “step back, what are we actually trying to do here,” and let it re-plan from the goal instead of grinding on the symptom.

If you know these in advance, none of them feel like the tool failing.

Learning as you go

You will hit moments where a word goes by, git, dependency, environment, runtime, and you realize you do not know what it means. You have two good options. Ask Claude to explain it in the context of what you are doing right now (this is better than a generic explanation, because it grounds the concept in your actual work). Or read the official docs for the piece in question.

You do not need to learn computer science to ship the first thing. You need to learn the next concept on the path to the next thing you want to build.

Start a real project with the starter-kit. The kit is set up to give you a working skeleton for a first project so you spend your energy on the specification, not the scaffolding. The starter kit.
The why behind this approach. If the framing in this article (specification and validation as the real skills) clicked, the longer argument lives in AI-Native Engineering.
Tool mechanics. Anthropic’s Claude Code 101 course and the Quickstart cover install, auth, slash commands, and CLAUDE.md. Look things up there when you need them; don’t try to read it all up front.
Operating moves. Once you have shipped the first thing and want sharper habits for working in Claude Code day to day, Power Using Claude Code is the reference.

Your knowledge and experience are what makes any of this work. The tool is good at coding. It is not good at knowing what you want.