The most common mistake I see in people starting out with automation is this: they get carried away by how easy it is today to build a flashy agent, and skip the question of whether that agent solves anyone's real problem at all. Building has stopped being the bottleneck. Correctly identifying the problem — and being able to put a number on what it's worth — is the whole game now.
I'll show you the whole road here, from zero to your first paid job. Two terms first, because they come back at every step. Claude Code is the tool where the Claude model does concrete work — it reads files, writes code, runs the next steps — operating in the terminal (the command window) or as a code-editor extension. It's not a chat where you only swap messages; it's a doer that actually builds things on your computer. An agent is exactly that kind of doer: it's given a goal and picks the steps itself, instead of waiting for each individual command.
The roadmap is simple. First the mindset and one exercise that sets up everything else. Then setting up the environment and the concepts you'll be frustrated without. Next you'll build two automations from start to finish. Then you'll get into the more powerful pieces — skills, teams of agents, connecting tools. And finally, what separates the craft from an income: how to price it, deliver it, and sell it. You read, you try, you come back to the harder bits. This is material for a few passes, not one afternoon.
Before you build anything: find the blockage
Let me start with an image I'll keep returning to. Picture a business as a pipe with water flowing through it — that is, work, jobs, money. Most companies try to pour as much water into that pipe as possible at once: they hire more people, throw AI at random problems. But if there's a blockage in the pipe, the water won't flow any faster no matter how endlessly you pour. Your real value is in finding that blockage first and clearing it — and only then increasing the flow.
That's why you don't start from the tool. You start by asking where, in a given business, the most time is wasted on repetitive work. A flashy agent built in isolation from such a blockage is a pretty toy no one will pay for. An agent that clears a specific, costly bottleneck is something the market really does pay for — and that's the whole difference.
There's one more habit that, in my view, decides how fast you'll master this: be genuinely curious. When you don't understand something the agent does, just ask it — "what did you do here?", "why that way?", "is there another way?". You don't have to know code. You have to want to understand what's happening. People who read what the agent does and ask follow-ups pick up everything else surprisingly fast. Those who click blindly stall at the first surprise.
To be honest: there's a lot of hype out there. You'll hear that systems like this "fix themselves forever" and that you just have to launch them once. That's not true. Maintenance still costs time, and a good system is built so that this time is as small as possible — not so as to pretend it doesn't exist.
Setting up the environment and ways of working
Now the specifics. You start by downloading a free code editor — the most popular is VS Code — and adding the Claude Code extension to it. On top of that you need a paid Claude subscription; without it the agent won't move. Once everything's in place, you see two things side by side: your project's files on one side, the conversation pane with the agent on the other. It's in that pane that you assign work in plain language.
A small decision worth making right away: which model. You usually have three to choose from — from the fastest and cheapest, through a middle one, to the most powerful (by name: Haiku, Sonnet, Opus). At first, leave the default or stick with the most powerful one to build a feel for quality. You'll switch to a weaker one later, deliberately — for instance when you're assigning simple, bulk work and want to economize.
A sensible longer-term strategy looks like this: the middle model for some 80% of the work, and you switch the most powerful one on only for hard design decisions or tangled bugs, then drop back to the cheaper one. You change the model on the fly with a short command — you type /model and pick. It's one of the many so-called slash commands (short commands starting with /); you'll see the full list by typing a question mark. You don't have to memorize them — you can always ask for the same thing in plain language.
There are also a few ways to run Claude Code, and each has a different trade-off. I'll list the four that are genuinely useful, so you choose for yourself rather than "because someone else does it that way."
Four options and their trade-offs
- In the terminal. Closest to the "raw" tool, the most control, the fewest distractions. The barrier to entry is a touch higher if the command window is new to you.
- In the desktop app. A convenient, standalone window; a good starting point when you don't want to work inside a code editor.
- As an editor extension (VS Code). My default choice for learning: you see the files and the conversation at once, making it easy to track what the agent is changing. This is the option I'll stick with here.
- In the browser. The task runs in the cloud, so it doesn't stop when you close your computer. Good for longer jobs meant to "run in the background."
There's no single right answer here. If you're just starting out, take the editor extension — the rest of this text assumes exactly that view.
Three concepts you'll be frustrated without
Before you start bigger builds, master three things. Skipping them is the most common reason people find "the agent doesn't work," when in reality it's the way of working that doesn't.
A token is a portion of text the model processes — roughly a piece of a word. Tokens cost money, because they're the unit of billing. The second thing is the context window — the model's working memory. Imagine Claude has a notepad and writes everything in it: your commands, the files you gave it, the entire conversation so far. That notepad has a finite capacity — usually on the order of two hundred thousand tokens. When it fills up, the model starts to lose the thread or has to "summarize itself" to make room. Quality drops then — and, as I said, it's usually not the model's fault but the fact that you let its memory get cluttered.
In practice you have two simple commands for this. You type /clear to wipe the conversation and start with a fresh head when you move to a new task. You type /compact when you want to keep the thread but trim it to the most important points — I usually do this when the context fills up to roughly 60%. Right at the start you don't have to live by this: the memory summarizes itself automatically anyway when it hits the limit. But it's worth understanding what's happening, because it's the key to keeping quality up over longer work.
The third concept is the most important: the CLAUDE.md file. It's the standing set of instructions the agent reads at the start of every conversation — something like a job description for a new hire. You keep in it whatever the model should always know: how the folders are laid out, what rules it follows, how it should behave. Without this file it's like an expert sat down to work with no induction at all. You set it up as the first thing in every new project — you can create an empty file named CLAUDE.md and let the agent fill it in itself by describing the project to it (there's even a short command for this, /init, but a plain request works just as well: "I've created a CLAUDE.md file for you, describe this project in it").
One habit around this file is priceless: keep it up to date. Whenever the agent discovers something new in your project — a pattern, a pitfall, a convention — or whenever you build a new skill, add it to CLAUDE.md. That way the file gets smarter over time and the agent stops making the same mistakes. You can ask outright: "write down what you've just learned about the project in CLAUDE.md."
It's also worth saying here something that recurs throughout this work: the quality of the instruction translates directly into the quality of the result. Underneath, it's still a language model — the more precisely you describe what you want, what result you're after, and what not to do, the better it hits the mark. A vague instruction gives a vague result. That's good news for a non-technical person: your main skill isn't code, it's clearly stating what you mean.
The framework that organizes all the work: workflow, agent, tools
In CLAUDE.md you usually also write down one simple framework that the rest rests on. The acronym is WAT, from three layers: workflow, agent, tools. A workflow is a process described in plain language, like a recipe: "gather data from five sources, analyze it, assemble a PDF report." Tools are the specific, predictable actions the agent uses along the way — for example a piece of code that always extracts data or assembles a file the same way. The agent is you in this lineup — or rather the model in the role of decision-maker: it reads the workflow, reaches for the tools, and handles the exceptions.
The point of this split is practical. Where a task is repetitive and can be worked out in advance, you hand the work to predictable code (tools). Where you have to think and make a decision, the model works (the agent). That way you don't have the model reinventing, every single time, things that should work the same — which is both cheaper and more reliable. You can copy the same chunk of instructions between projects; it's your standing starting point.
The first automation: competitor research with a branded PDF report
Time to build something end to end. The first example is an automation that researches the competition and finishes by assembling a polished, branded PDF report. Pay attention less to the output itself than to the way of working — because that's what carries over to every job that follows.
You start by opening an empty folder as a new project. Before you say anything about the specifics, you switch the agent into planning mode. This is an important setting: in planning mode the agent can think, read, and search the web, but it won't start building anything until you approve the plan. You have other permission modes too — from "ask before every change," through "edit files automatically," to a mode where the agent works without asking for approval. At first, stick with planning mode; it gives you a moment to check that the agent understood correctly before it starts acting.
Now you describe the goal in plain language: you want a system that, once a month, finds competitors on its own, checks their offering, and assembles it into an industry PDF report with concrete conclusions. The agent starts thinking, reads the project structure, and moves into the question phase — because a good plan requires decisions you didn't make for it in advance.
The question phase: the agent asks, you decide
This is a moment not worth skipping. The agent asks concrete questions — for example: how should competitors be found? You can supply a ready-made list, let it detect them on its own from a description of your business, or combine the two. It also asks about details of your business, the scope of the analysis, the output format, and how often it should run. You answer one by one, and it's from those answers that a sensible plan is born — not from guessing.
Once you've answered, the agent comes back with a finished plan — for example: "a monthly system that detects competitors on its own, researches their offering, and generates a branded PDF report with concrete conclusions." And here's the crux of planning mode: you read that plan and check it's exactly what you want before you click "go." Better to fix one sentence in the plan than to spin up a finished, badly conceived build.
How to inject the brand
The report itself should look like yours, not like a generic document. So you drag two things into the project: a logo and brand guidelines (colors, typography, tone). When the agent builds the document, it reaches for these materials and formats the output to be consistent with the brand. It's a small thing that makes a huge difference to how it's received — and at the same time it shows a general rule: if you want the output to look specific, give the agent something specific, not a generality.
Once the plan is approved, the agent moves to action. It builds itself a task list and checks it off before your eyes — you watch it find competitors one by one, gather data, assemble the document. Your role at this point is supervision: you read what it does and step in when something goes wrong. Since you're not writing code by hand, your job becomes clearly communicating the goal and watching over quality.
The second automation: a newsletter with an approval checkpoint
The second example adds an element that's crucial in client work: the moment a human comes back into play. You build a newsletter automation. You open a fresh, empty project and again start by describing the goal: you want to be able to give it a topic, and the agent will do the research, lay out the content, format it in HTML (the format in which web pages and emails display), keep the look consistent, and prepare the whole thing for sending.
Here too you drag a logo and brand guidelines into the project, so every issue looks the same and "feels" like yours. What's interesting is that you can point to the materials right in the instruction — you show the agent: use this logo, stick to these rules. The agent comes back with a plan, you read it and approve it.
The most important detail is at the end of the process. The newsletter doesn't go out into the world on its own: the workflow reaches a point where you approve the subject line and the whole thing before sending. This is deliberate. Everywhere reputation is on the line and a mistake is costly, you keep the last word for yourself. Automation is meant to take repetitive work off your plate, not to take away your control over what goes out under your name. You'll carry this principle — automate the boring steps, leave the heavyweight decisions to the human — over to practically every job.
What to do when something doesn't work (and when it works badly)
And here's an honest note, because it's inevitable: the first time, something will break. With a build like this it typically comes out that the test message arrived with broken formatting, or that the agent was given the wrong address for the spreadsheet it was supposed to write to and had no access to it. That's no reason to panic — it's a normal stage. You show the agent exactly what's wrong ("the message came through with a mangled background and layout, fix it"; "I gave you the wrong spreadsheet ID, here's the right one") and it fixes it. The more specifically you name the fault, the faster it clears it.
This is the practical face of an honest principle I live by: when the output is poor, it's usually not the model's fault but an underspecified instruction or missing access. Take some of the responsibility on yourself, fix the input — and the result jumps. This attitude separates the people who deliver working systems from those who give up at the first error.
The more powerful pieces: skills, sub-agents, and teams
Once you have two builds behind you, it's time for the pieces that take the work further than a single automation. You don't have to use them all at once — treat this as a toolbox you reach into for whatever the task happens to need.
A skill is a reusable recipe. Imagine you teach the agent once how to do something well — for example what your LinkedIn post should look like — and save it as a skill. From then on, whenever you ask for a post like that, the agent reaches for that recipe and does it just as well every time, without explaining from scratch. The first skill worth building is usually connecting the agent to a tool you actually use day to day — for example the system where you run your tasks or projects.
A sub-agent is a helper the main agent spins up for a separate piece of work. It has its own context window, so it doesn't clutter the main session's memory, and at the end it sends back the result. A step further are teams of agents: several doers working in parallel, each in their own area and — importantly — on their own files, so they don't overwrite each other's work. It's a powerful tool for tasks with several independent parts, but slower and more expensive; if you want to dig into it, I've written it up separately in the piece on teams of agents in Claude Code.
Connecting the world: tools, MCP, and RAG
Three concepts that let the agent reach beyond its own head. The first is browser automation — the agent can drive web pages, click, fill in fields, download. The second is MCP (the model context protocol), a standardized way for tools and data sources to plug into the model. The simplest way to think of it is as a set of ready-made actions a service exposes — the way an inbox exposes "send a message," "create a draft," "fetch a message." MCP is the shared standard that lets the agent use such actions instead of learning the controls from scratch every time.
The third concept is RAG (retrieval augmented generation). The model knows only as much as was in its training data. If you ask it about something that wasn't there — your internal documents, the latest decisions — it has to get it from somewhere. RAG is exactly the technique where the agent first reaches into the documents you've supplied and then answers on their basis, instead of guessing from memory. For client work this is very practical: it's how you build an assistant that knows the company's materials, not just general knowledge.
Working with code on GitHub and worktrees
Two concepts from the area of organizing the work, both manageable in plain language. Git is a version-control system — a tool that records every change in a project, so you can always roll back to an earlier state. GitHub is the place online where you keep such a project and sync it across devices or share it with others. Worktrees (parallel copies of the project) let you work on several things at once without breaking your main version. It sounds technical, but in practice you don't have to remember the commands: you describe to the agent in plain language what you want to achieve — "save this to GitHub," "set up a separate copy for an experiment" — and it does it. It's that same attitude again: be curious, ask, and the tool will help you.
How to make it run on its own
So far you've been running everything by hand. The next step is making the automation work without you. You have two typical ways. The first is a schedule — you set something to happen once a day, once a week, or every so many minutes (Claude Code even has built-in tasks that run while the app is open). The second is an event trigger (a web hook): something happens externally — a form comes in, a new record appears — and that itself kicks off your process. In either case you don't have to know the technical details; you describe the intent in plain language: "run this process every morning at eight" or "fire it when a new submission comes in."
Here the distinction you met during testing returns: what you put on a schedule or a trigger is the workflow and tools, not the agent from your editor. Those are what run in the background. The agent stays on your side, for building and fixing. Good to know before you promise a client "a system that runs itself."
Assembling it into an assistant
All these blocks can be tied together into one larger example — a personal executive assistant. You start with a solid CLAUDE.md that tells it about you and your goals. Then you "give it hands": you build the first skill — usually a connection to the tool where you actually run your tasks or projects — so it stops just thinking and starts doing something for you. You add more skills and sub-agents until the assistant can, for example, commission research on its own and then turn it into finished material. It's also worth glancing at the alternatives along the way, say at Google's command-line tool, just to have a comparison — but consistently remember: someone else's setup isn't your setup. A more powerful feature doesn't automatically mean better for what you happen to be doing.
Test and deploy before you hand it to the client
Before anything reaches a client, the system has to be tested — and this is a moment many beginners skip. Let me use the image of a railway track. Before you let trains onto a new track, you run different consist over it: light ones, heavy ones, on different wheels — to be sure the track holds up under each. You test an automation the same way: you feed it varied inputs, including hard and unusual ones, and check it copes with every case before you let it "into production," that is, into real work.
One distinction that saves misunderstandings: when you deploy a system like this, what you put into service is its workflow and tools, not the agent from your editor. It's the tools and the described process that go onto the server and work there. The agent — the model in Claude Code — stays on your side and serves to build and fix the system. It sounds like a technical detail, but it matters when you're talking to a client about what exactly will sit at their end.
How to actually test
In practice it looks like this: before you put the process on a schedule or trigger, you run a series of varied inputs through it — typical ones, but also extreme and unusual ones. An empty document, incomplete data, a strange format, two submissions at once. You watch whether each such case ends in a sensible result or a clear message, rather than a silent failure. When something breaks, you fix it — and run it through again. Only once the system has come through these hard cases do you have the right to say it's ready.
The reason all this makes sense today at all is mundane: the technology has finally matured. The models are predictable enough to use in real work, not just to play with in a chat. But "predictable enough" isn't "hands-off" — hence the emphasis on testing. A system that came through many different cases before it launched is a system you can look a client in the eye and tell: this works.
How to sell: don't show the tool, ask about the problem
Here the technical part ends and the money part begins — and this is the part most often skipped, the one that decides whether a skill turns into an income. The first rule: don't open the conversation with "I build automations in Claude Code." The client doesn't care. The hammer isn't what matters — the result is.
So in the meeting you don't start with "let me show you my workflow." You start with questions: where do you lose the most time in your business? which processes would you want to run themselves? The diagnosis always leads to a solution, and a solution can always be converted into measurable value for the business. Once you master this, you stop being "another automation person" and become someone who can look at a business, point out where time and money are leaking, and design something that fixes it. That's the shift from selling a tool to selling a solution.
There's one more trap here worth being honest about. Being able to have the agent build something is not the same as being able to judge whether what came out is any good. Someone who never understood what's happening underneath won't catch the moment the agent made a bad decision. This doesn't mean you have to be a programmer — it means the same attitude from the start returns here: be curious, read what the agent does, ask "why that way?". It's that curiosity, not knowing code, that lets you stand in front of a client and answer for the quality of what you deliver.
The most important change is in your head, and it's called value-based pricing. You don't count how many hours the build will take you — you count how much the automation is worth to the business. Let me use an image that captures it well: a glass of water has a different value to someone who's just run a few kilometers in the heat than to someone who's sat in an air-conditioned office all day. It's the same product — but a different value. You set the price not from the cost of making it, but from what the solution means to this particular client.
How to put a number on value with a concrete example
I'll show this with a typical situation, because abstraction isn't enough here. Picture a process where employees manually book meetings for the sales team. Assume an hour of such a person's work is worth around $40. If this process eats up enough time to cost the company roughly $800 a week, that comes to some $3,200 a month and, over a year, on the order of $38,000. And that's your reference point when pricing: not "how many hours I'll spend on the build," but "how much the company will stop losing once it's running." Treat the numbers as a way of calculating, not as a promise — in a real project you plug in the specific client's data.
The five pricing steps and where the relationship goes next
To take the randomness out of pricing, use a simple, five-step framework. It spells the word PRICE — fittingly. I'll go through all five letters, because each is a separate step in the conversation with the client.
- P — prepare. Before you even think about a number, set value-based pricing in your head. You don't count hours — you count the effect: time saved, money, fewer mistakes.
- R — research. This is the discovery stage. You talk, map the process, and establish where the blockage really is and what it costs. This is where the numbers for the price come from.
- I — implement and price. You design the solution and relate its price to the value you've calculated — for example to how much the company recovers in the first year.
- C — communicate. With a price in hand, you have to present it so it makes sense. You paint a picture of what the business will look like once the system is running. You explain what's in scope and how quality control works. A price without that picture is just a number.
- E — expand. The work doesn't end at deployment. You look for what's next: maintenance, monitoring, optimization, more automations, a second version, ongoing care. The best jobs often grow out of ones already done.
Trust comes before a retainer
Here's the second common mistake: people obsess too early over standing, monthly contracts and some dream "per-month" figure. Remember a simple rule: trust comes before a retainer. Asking someone for a monthly subscription before you've done anything for them is like asking for a recommendation before you've even started working together. First deliver one or two projects, solve a real problem, and show the value you brought. Then the conversation about ongoing care becomes natural — they'll ask for it themselves. The same logic applies to testimonials and referrals: you can't get them before delivering anything.
This ties to a natural growth path: from freelancer, through consultant, to a trusted partner the company relies on to improve how it operates. At the start, hourly billing can be fine — you're building trust and first results, and what you care about then is experience and proof, not the maximum rate. Later you shift toward an ongoing engagement billed by stages (milestones) rather than by the hour. Hours position you like a freelancer; milestones, like a partner. In practice the range of such jobs can be very wide: from small, low-budget work to large contracts on the order of tens of thousands — depending on how much value you actually bring and how deeply the company trusts you. There's no single correct billing model here; the market bears a fixed price for a specific outcome, packages of hours, and a subscription with a defined scope alike. At the start, gathering experience and proof matters more than squeezing out the maximum rate.
At the end of delivery there's one more step that builds trust more than anything else: show that it works. Once the system is deployed and you're only fine-tuning the details, record a short summary or walk the client through one or two full runs — from inputs, through the process, to the result — and show how the system handled real cases. This turns the abstract "we automated the process" into tangible proof they can see with their own eyes.
If I'm to leave you with one thought, let it be this: the value isn't in building a flashy agent, because building is easy today and easier with every passing month. It's in correctly identifying where the blockage is in a given business, putting a number on what it costs, and clearing it so the result shows. You'll get the tool in a week. The next step is a calm one: take one real, repetitive process — your own or a friend's company's — count how much time it eats up, and build one automation for it, start to finish. One pass down that road will teach you more than more hours of reading about it.