Claude Code is an AI agent that works in your computer's terminal. You describe what you want in plain language, and it reads your project's files, suggests changes and runs commands. To get started you need a computer running Windows, macOS or Linux, a few basic tools such as Node.js and Git, and the habit of checking every result yourself.
This post explains what that means in practice, how a working session with the agent goes and how you can tell whether the result is any good.
What is Claude Code, and how is it different from a chat?
In an ordinary AI chat you get text back. You copy it, paste it somewhere and hope it fits. An agent like Claude Code works directly in your project folder instead. It sees which files exist, reads the existing code and changes it.
The terminal is simply the text window where you type commands. It feels unfamiliar at first because there are no buttons. You type a line, press Enter and read the response. That is all there is to it.
This leads to the most important point for beginners: the agent changes real files. That is useful, because you make quick progress. It also means you need to keep track of what changed and when. Codex plays a similar role. The way of working described here applies to both tools.
What do you need before you start?
Before you call the agent for the first time, your environment should be ready. This list covers the basics:
- A laptop or desktop running Windows, macOS or Linux. A tablet is not enough, because you need to install programs and work in the terminal.
- Permission to install programs. On company devices this is often blocked. Check with your IT department beforehand.
- Node.js version 20 or later. Many web projects need it to run the app locally and to run tests.
- Git. It lets you save checkpoints and see which files the agent has changed.
- Your own access to Claude Code or Codex. The conditions that apply are listed on each provider's official pages.
- Some patience with English. Code and many tool messages are in English, even if you write your tasks in German or another language.
For the installation, it is best to follow the provider's official instructions. Afterwards, check in the terminal that everything is recognised: Node.js, Git and the agent should each display their version. If you would like step-by-step help, the freely available Mission 0 on setting up the tools (in German) is a good starting point.
What does a workflow with Claude Code look like?
A typical working round is short and repeats itself. The smaller the round, the easier it is to find a mistake when something goes wrong.
- Open the project folder. You start the terminal in the folder where your app lives.
- Save a checkpoint. With Git you record what the project looked like before the change.
- Write the task. You describe a single, clearly defined change.
- Read the proposal. Before you approve anything, you look at which files the agent wants to touch and why.
- Start the app and try it out. You click through the new feature yourself.
- Run the tests. If your project has tests, they show you whether something else has broken.
- Save and take notes. You save the new state and briefly write down what the AI contributed and what you adjusted yourself.
The last step may seem pedantic, but it pays off. Otherwise, after a week you will no longer know why a particular line is in the code.
How do you give the agent a clear task?
The most common beginner's mistake is a task that is too big and too vague. "Build me a contact manager" leaves countless decisions open. The agent then makes them itself, and afterwards you do not understand what has been built.
It is better to break a task into steps you can check, and for each step to say how you will know it is done. These checks are called acceptance cases. They usually follow the pattern: when I do this, then that happens.
An example from a contact app
Suppose your app already shows a contact list. Now every contact should get a status. A clear task could look like this:
Add a Status field to every contact with the values "new", "contacted" and "closed". New contacts start as "new". I can change the status in the detail view. Do not change anything about the design of the list.
Acceptance cases: When I create a new contact, its status is "new". When I set the status to "contacted" in the detail view and reload the page, it stays "contacted".
The agent now knows what to do, where to do it and what to leave alone. And you know how to check the result.
What belongs in a good task
- Goal: What should the person using the app be able to do afterwards?
- Location: Which view or part of the app is affected?
- Limits: What must not be changed?
- Acceptance cases: Two or three sentences you can play through yourself.
- Error cases: What should happen if an input is empty or invalid?
How do you check what the agent has built?
An agent often phrases its answers as if everything were done. That does not mean it is true. Checking is therefore not a sign of mistrust, it is part of the work. This checklist helps after every round:
- Does the app still start? It sounds trivial, but it is the most common surprise.
- Are the acceptance cases met? Play them through yourself rather than relying on the agent's summary.
- What happens in error cases? Create a contact without a name, enter an incomplete email address, set a follow-up to a nonsensical date.
- How does the app handle an interface? If data comes from outside, test an empty response, an error message and a long wait. With a simulated interface you can do this safely.
- Are there secrets in the code? Access keys and passwords do not belong in files you share.
- Were unrelated files changed? Git shows you which files have changed since the last checkpoint. Does that match the task?
- Can you explain the change? If you can say in two sentences what is new and why, you have stayed in control.
If something goes wrong, roll back to the last saved checkpoint and narrow the task. That is often quicker than letting the agent patch things over several rounds.
What are the common pitfalls the first time?
Some problems come up for almost every beginner. Knowing them saves you frustration.
Error messages in English. You can hand a message to the agent and ask for an explanation. Still read it yourself, because the cause is often in the first or last line.
Several changes at once. If you ask for filters, status changes and an export in a single task, it becomes almost impossible to trace an error back to its cause. One change per round is the simplest rule.
Tests get changed instead of the code. An agent may rewrite a failing test so that it passes. So pay attention when test files change even though you only wanted to fix a feature.
Real data in a learning project. Sample data is enough for your first attempts. An app that stores data in the browser is not meant for real customer data.
How does the Vibe Coding Foundation course fit your first steps?
The Vibe Coding Foundation course from BUILT IN CLASS practises exactly this workflow on one continuous project: a contact and follow-up app for a small company, using sample data. You work with Claude Code or Codex and need your own access, the cost of which comes on top of the course price. The course is taught in German.
The missions build on each other. After setting up, you turn an idea into a clear task, build the contact list and detail view, add input validation, status changes and filters, and connect the app to a simulated interface that returns empty responses, errors and delays. You then narrow down prepared bugs, check basic access cases and document your project so that others can run it. In the transfer mission you export overdue follow-ups as a CSV file. You will find all missions with planned times in the course overview (in German).
Each mission has criteria in the form of tests that you check on your computer with a single command, plus hints at three levels. The AI log that appears in this post as the last step of each round is something you keep throughout the course. The planned time is around 30 hours, for example six weeks at about five hours a week. The page on the exam (in German) describes how the written project exam works. If you pass, you receive a private academy certificate, not a state-recognised qualification. Price and what is included are listed under Price.