Now we open it up.

Claude Code was never meant to stay contained in a terminal window. It’s built to connect -- to your files, your tools, your data, your workflows.

This post is where that happens.

CMOs as Builders is an 8-part series for technology marketing leaders who are ready to move from using AI to building with it. Each post builds on the last.

If this is useful, subscribe so you don’t miss what’s next.

The Series:

• Why CMOs Who Build Will Win

• Your First 30 Minutes with Claude Code

• How to Give Claude Code Its Orders

• Stop Losing Your Work: Sessions and Context

• Skills, Efficiency and Model Switching

• Beyond the Terminal: MCP, APIs, and the Tools That Connect Everything (you are here)

• From Terminal to Teammate (coming next)

• The CLAUDE.md Blueprint (coming soon)

What you’re about to understand. How Claude Code connects to the rest of your world:

You’ve been working in a terminal, building things locally. That’s real progress. But if Claude Code only works with what you type into it, you’re still doing a lot manually. The shift happens when Claude Code starts working with your actual files, calling your actual tools, and operating inside your actual workflows -- without you babysitting every step.

By the end of this post you’ll know:

• How to connect Claude Code to local files and folders -- and why this is the most immediately useful thing you can do

• The difference between CLI, API, and MCP connections -- and when each one is the right tool

• How to store API keys securely -- so you’re not leaving the door open to unexpected charges or worse

• When to add an orchestration layer like n8n -- and when you don’t need one

• What a fully connected Claude Code system actually looks like in practice

Why this matters for you as a CMO:

Right now, you probably switch between a dozen tools to get anything done. Claude Code connected to your stack collapses that. You stop moving data between systems manually. You stop rebuilding context every time you switch tabs. You start building workflows that run -- with you making the decisions, not doing the labor.

Time to read: 12 minutes

What you need: Posts 1--5, Claude Code installed, at least one API key from a tool you already use

Start Where You Already Are: Local Files and Folders

The most underrated capability in Claude Code has nothing to do with APIs or integrations. It’s simpler than that.

Claude Code can work with files sitting on your machine right now.

No API keys. No configuration. No middleware. You point it at a folder, and it reads, writes, edits, and organizes whatever is in there -- using the full power of the model you’ve been building with all series long.

What this looks like in practice:

Drop a folder of customer research documents into a directory. Tell Claude Code to synthesize them into an executive summary. It reads every file, pulls the signal, writes the output -- and saves it back to the same folder.

Drop a folder of competitor PDFs. Ask for a comparison matrix. Done.

Drop a month of sales call transcripts. Ask for a structured breakdown of objections by product line. Done.

I did exactly this with a Voice of Customer project - raw survey responses and support tickets in a folder, structured executive report out. No template. No manual tagging. No analyst hours. Claude Code read the inputs and built the output directly.

This also extends beyond documents. Claude Code can run scripts, execute processes, and trigger things that actually happen on your machine. You’re not just generating text. You’re running operations locally.

The mental shift: your working files are already the input. You don’t need to move anything anywhere. You just need to know how to point Claude Code at what already exists.

The CLI: The Terminal Is Where Serious Tools Live Now

CLI stands for command line interface. It’s the terminal you’ve been working in all series. One line of text, something happens.

You already know this. What you might not know is that the terminal is becoming the standard interface for serious tools, not just for developers anymore.

Case in point: Google just released their own CLI. You can now interact with Google’s AI tools, manage Google Cloud resources, and run operations across Google’s ecosystem -- all from the terminal. No browser required. No clicking through dashboards.

Claude Code operates here natively. It doesn’t just use the terminal, it lives in it. That means you can chain operations, trigger scripts, run processes, and call other CLI tools all from the same place you’ve been working.

What this means practically: you’re not just typing prompts. You’re operating your machine. Claude Code in the terminal can kick off a Python script, call a shell command, read the output, make a decision based on what it finds, and write the result to a file -- all in one session.

That’s not a chatbot. That’s a system operator.

The practical takeaway: get comfortable with the terminal as a place where things run, not just a place where you type. The more tools publish CLIs -- and they will -- the more valuable that comfort becomes.

API Connections: Claude Talking Directly to Other Software

An API is a door that software leaves open so other software can talk to it.

Every major tool you use has one. Slack. HubSpot. YouTube. Buzzsprout. Notion. Google. They all publish APIs because they want other software to be able to connect to them (and increasingly, they create MCP connections… see more in that section below).

Claude Code can walk through those doors directly. No workflow tool required. You write the call, you get the response, you do something with the output -- all from the terminal.

JSON: the language tools use to talk to each other

When Claude Code calls an API, it communicates in JSON. JSON stands for JavaScript Object Notation. Ignore the name. What it actually is: a standardized form that every system knows how to read.

Think of it like a shipping manifest. Every package, no matter where it’s going or where it came from, uses the same format. Sender, recipient, contents, weight. JSON is that format for data moving between software systems.

You don’t need to write JSON by hand. Claude Code handles it. But you should know it exists, because you’ll see it when things connect and when things break.

API keys: what they are and why security matters

To use an API, you need a key. An API key is a unique credential that tells the service: this request is authorized, and bill it to this account.

That last part matters. An exposed API key isn’t just a security problem. It’s an open billing account. Someone finds your Anthropic API key, they run a million tokens through it -- you pay for it. Same with OpenAI, Google, any service you’ve connected.

Never paste API keys into chat windows. Never commit them to a shared document. Never store them in plain text files inside a project folder.

How I handle it:

For general credentials, I use LastPass. You likely already have it or something like it. Use it for API keys the same way you use it for passwords.

For projects where multiple API keys need to be managed across a workflow or shared carefully with a team, I use Infisical. It’s purpose-built for secrets management. Think of it as LastPass specifically designed for developers and builders. You store keys in Infisical, your workflow pulls them securely at runtime, and they never sit exposed in a file.

The rule: treat every API key like a credit card number. Store it somewhere secure. Rotate it if you think it’s been exposed. And if you’re ever setting up a workflow that uses API keys -- build the secure storage step in from the start, not as an afterthought.

What you can connect:

From your terminal, with the right API keys stored securely, Claude Code can call:

• The Anthropic API directly -- useful for building tools that use Claude as the engine

• YouTube API -- upload, retrieve, manage video data

• Buzzsprout -- post audio, retrieve episode data

• HubSpot or Salesforce -- pull contact data, update records, trigger sequences

• Google APIs -- Drive, Calendar, Sheets, all of it

• Any tool that publishes an API -- which is most tools you already use

This is where the AI Tiers framework I’ve written about becomes concrete. Most CMOs spend their budget at Tier 1 and Tier 2, baked-in AI and platform add-ons. Real leverage lives at Tier 3 and Tier 4, orchestration and custom connections… and at a fraction of the cost of the point solutions trying to do the same thing.

API connections are your entry point into that territory.

MCP: The Native Connection Layer

MCP stands for Model Context Protocol. You don’t need to remember the acronym. What you need to understand is what it does.

MCP is a connector that lets Claude talk directly to your other tools -- not through a workflow, not through copy-paste, but natively. As if Claude is sitting inside those tools.

With the right MCP connections configured, Claude can:

• Read a page in your Notion workspace

• Update a task in Asana

• Pull contact data from your CRM

• Read files in your Google Drive

• Post a message to Slack

No switching tabs. No copy-paste. No manual handoff. Claude goes and gets what it needs, does the work, and puts the output where it belongs.

How MCP is different from an API connection

An API connection is something you build -- you write the call, you handle the response, you manage the integration. It’s powerful but it requires setup.

MCP is purpose-built for AI-to-tool connection. The protocol is standardized, which means tool providers are building MCP support directly into their products. You configure it once, and Claude has native access.

Think of the difference this way: an API connection is like building a bridge yourself. MCP is like a bridge that already exists -- you just need to know where the entrance is.

The context load warning -- this is important

Here’s something most people learn the hard way when they get excited about MCP.

Every MCP connection you load into Claude Code adds to the context window on every single conversation. Whether you’re using that connection or not.

Load ten MCP connections and you’re burning context, and money, before you’ve typed a word. The model is holding all of those connections in memory, waiting to use them, even when the task at hand has nothing to do with any of them.

The practical rule: only load the MCP connections you actually need for the work you’re doing right now. If you’re building a content workflow, load the content tools. If you’re doing research, load the research tools. Don’t connect everything because you can.

More connections does not equal more power. It equals more cost and slower, less focused sessions.

Be deliberate. Load what you need. Unload what you don’t.

MCP tools worth knowing about:

• Notion

• Asana

• Google Drive

• Slack

• HubSpot

• GitHub (more on this in Post 7)

The list is growing fast. Most major platforms are adding MCP support. When a tool you already use announces MCP support, it’s worth paying attention.

When You Add an Orchestration Layer

Everything in the previous three sections, local files, CLI, API, MCP, Claude Code can handle directly. You don’t need anything else for a lot of use cases.

But there’s a category of workflow where you want something more: visual structure, automatic scheduling, multi-system triggers, and human approval steps built in.

That’s where orchestration tools come in. n8n is what I use and recommend. Zapier and Make are alternatives, more familiar to most marketers, less flexible and more expensive at scale.

What n8n adds:

You see your workflow as a diagram. Each box is a step. Each arrow is data moving between steps. Claude sits at the decision points where intelligence is needed. Everything else is routing.

You can schedule it. You can trigger it from an event. You can build an approval step where a Slack message goes to you, you reply, and the workflow continues based on your response.

That last part -- the human-in-the-loop design -- is how I build everything. Automation doesn’t mean removing yourself from decisions. It means removing yourself from the parts that don’t require decisions.

When n8n is worth it:

When your workflow has multiple systems, runs on a schedule or trigger, and needs to keep running without you manually starting it every time.

LaunchPod is the clearest personal example I have. A completed podcast episode dropped into a Google Drive folder triggers the entire workflow: YouTube upload, Buzzsprout audio post, Webflow episode page built, eight content pieces generated by Claude, content queue populated, posts scheduled to LinkedIn, X, and Substack via Late.dev. Start to finish in about three minutes. I cancelled a part-time marketing hire because of it.

That complexity justifies the orchestration layer. You need the visual diagram. You need the scheduling. You need the error handling. n8n gives you all of it.

The LinkedIn Content Machine runs on three separate workflows. Workflow one pulls meeting transcripts from Google Drive and Google Calendar, extracts one content idea per day via Claude, and sends it to me via Slack with a suggested angle. Workflow two: I reply with my take, Claude writes the full post using my angle and my voice guidelines. Workflow three: I approve or edit in Slack, the post goes to Late.dev for scheduling. Human in the loop at every decision point. Fully automated everywhere else.

When you don’t need n8n:

Single-task automation. One-time builds. Anything Claude Code handles end-to-end in a terminal session. If you can describe the task in one sentence and it doesn’t need to run on a schedule, you probably don’t need an orchestration layer.

Start without it. Add it when the complexity earns it.

One more thing: n8n skills

If you want to go further with n8n, building workflows, connecting systems, setting up the orchestration layer for your own automations, Mighty & True has skills available for this. We’ve built the workflows. We know where the friction points are. Reach out if you want a faster path to getting it running.

What a Connected System Actually Looks Like

Let me walk you through the LinkedIn Content Machine end to end -- because it shows every layer working together.

The inputs:

• Google Calendar: what meetings happened this week

• Google Drive: transcripts from those meetings

The trigger: n8n workflow runs each morning, pulls the previous day’s activity

The intelligence: Claude reads the transcripts, identifies the strongest idea worth sharing, writes a suggested angle -- not a post, just a direction

The human step: I get a Slack DM. One idea. One angle. I reply with my take.

Back to Claude: it takes my reply, writes the full post in my voice, using my voice guidelines stored in the workflow

Another human step: I see the draft in Slack. I approve it or edit it and approve it.

The output: post goes to Late.dev, scheduled and queued

What this replaced: 45 minutes of thinking, drafting, and scheduling -- every day. Manually. Often skipped.

What it costs to run: a few cents in API calls per post.

No developer built this. I built it by understanding the layers -- local files, API connections, Claude as the brain, n8n as the visual structure, Slack as the human interface.

That’s the system. You can build one too.

A Note on Keeping It All Organized

As your connections multiply, your files multiply. Scripts, configurations, API call templates, workflow files, CLAUDE.md instructions, it adds up fast.

You need a way to keep all of it organized, versioned, and recoverable.

That’s what GitHub is for.

We’ll cover it properly in Post 7. For now, know it exists and know you’ll want it. GitHub is not a developer tool in the way you might be picturing it. It’s version control -- a system that tracks every change you make, lets you roll back to any previous version, and keeps your work safe even when something breaks.

As your system grows, GitHub becomes the backbone. We’ll build that in next.

How this Changes your Workflow

You started this series opening a terminal for the first time.

Now you’re looking at a system where Claude reads your Google Drive, writes a file locally, calls an API, routes the output through Slack for your approval, and publishes when you say go.

That’s not a chatbot you upgraded. That’s infrastructure you built.

Post 7: From Terminal to Teammate -- bringing other people and other systems into what you’ve built. GitHub, team workflows, and the next layer of scale.

If you’re building marketing systems and want a faster path -- or if you want help designing the architecture before you start building -- that’s what we do at Mighty & True. We work with marketing teams who are serious about moving from tool-buyers to builders.

Now I need to tell you about the day that system cost me $75. Not because the system failed. Because I was running it on the wrong settings.

This post is about the settings.

This is Part 5 of the CMOs as Builders series, where I use my experiment in AI code to teach B2B technology CMOs to build with AI instead of just chatting with it. If you are just finding this, start with Post 1 -- Why CMOs Who Build Will Win.

Subscribe to get every post in this series delivered free.

The full series:

1 -- Why CMOs Who Build Will Win

2 -- Your First 30 Minutes with Claude Code

3 -- How to Give Claude Code Its Orders

4 -- Stop Losing Your Work: Sessions and Context

5 -- Skills, Efficiency and Model Switching ← you are here

6 -- Beyond the Terminal: MCP, n8n, JSON and the Tools That Connect Everything

7 -- From Terminal to Teammate 8 -- The CLAUDE.md Blueprint

Skills, Efficiency and Model Switching

What you’re about to learn -- why working harder with AI costs you more than working smarter:

You have been running every task on the same model at the same settings. You probably did not even know there were settings. That is like running every marketing campaign on the same budget and timeline regardless of whether it is a product launch or a social post. The tool is not the problem. The defaults are.

By the end of this post you’ll:

Know which model to use for which task -- and switch between them in seconds inside Claude Code or Cursor

Understand effort levels, fast mode, and extended thinking -- three controls that affect speed, cost, and quality independently

Have a set of commands that let you monitor and manage context, tokens, and cost in real time -- no surprises, no runaway bills

Have a practical framework for preventing the $75 mistake I made -- so your first billing surprise is also your last

Why this matters for you as a CMO:

Model switching is not a technical skill. It is a resource allocation skill. The CMO who runs Opus on a bulk tagging job is burning budget the same way a CMO who puts senior strategists on data entry is burning headcount. This post gives you the judgment to match the right resource to the right task -- and the controls to enforce it.

Time to read: 14 minutes

What you need: Claude Code installed and running (Post 2), familiarity with sessions and context (Post 4)

The $75 Wake-Up Call

I need to tell you about the most expensive lesson I have learned with Claude Code.

Early on, I was building a messaging framework for a client -- what I call the Solutions Messaging OS. It is a system that takes competitive research, customer interviews, and product positioning and produces a structured messaging architecture. The kind of work that used to take a strategist two weeks.

I was running Claude Code and I had extended thinking turned on. Extended thinking is a mode where Claude shows its reasoning process before giving you an answer. It is powerful for complex strategy work. It is also expensive.

“I hit 22 million tokens in one session and spent $75 before I noticed. Then I built a Slack alert so it would never happen again. That is the whole point of this series in one sentence.”

I did not notice that my session had routed through the API instead of my Max subscription. I did not notice that extended thinking was burning through tokens at a rate I had never seen. I did not check /cost once during the session.

By the end of the day, I had hit 22 million tokens. The bill was over $75. For one session.

That number might not sound catastrophic. But it was not what I budgeted, it was not what I expected, and it happened because I did not understand three things: which model I was using, how that model was billing, and what controls were available to me.

This post exists so you never have that moment.

Meet the Models

Claude is not one model. It is a family of models, each built for different work at different price points. Think of it like a team, not a tool.

Haiku is your fast executor. It is the cheapest model in the family and the fastest. Use it for anything that runs in volume -- reformatting 50 blog posts for social, tagging hundreds of CRM records, cleaning up CSV files, simple data transforms. Haiku does not think deeply. It does not need to. It processes.

Sonnet is your reliable senior manager. This is the default model in Claude Code right now (Sonnet 4.6 as of this writing), and for good reason. It handles 80% of what a CMO needs. Campaign briefs. Content drafts. Data analysis. Code generation. It balances quality, speed, and cost better than any other option. I’m redesigning our style guide for Mighty & True right now in Sonnet. It works amazingly well. When in doubt, stay on Sonnet.

Opus is your strategist. This is the most capable model Anthropic makes. Use it when quality matters more than speed or cost. Competitive messaging frameworks. Complex multi-step analysis. Anything where a wrong answer costs you more than a slow answer. Opus 4.6, the current version, launched in February 2026 and introduced a 1 million token context window in beta -- enough to process an entire corporate document library in a single session.

Here is what this looks like in practice:

You do not need to memorize this. You need to internalize one question: How complex is this task, and how much does getting it wrong cost me?

“Model switching is not a technical skill. It is a resource allocation skill. The CMO who runs Opus on a bulk tagging job is burning budget the same way a CMO who puts senior strategists on data entry is burning headcount.”

Low complexity, low stakes = Haiku. Medium everything = Sonnet. High complexity or high stakes = Opus.

How to Switch Models

In Claude Code, type /model and press Enter. You will see a list of available models. Arrow keys to select. That is it. You are now running on a different model. The switch takes effect immediately in your current session. Here’s Anthropic’s handy guide on this.

In Cursor, model switching works differently. Cursor gives you access to models from multiple providers -- Claude, GPT, Gemini, and Cursor’s own models. You switch in the model dropdown at the top of the AI panel or in Settings.

This brings us to an important tradeoff.

The Cursor Question

If you followed Post 2 and set up Cursor as your IDE, here is what you need to know about how models work inside it.

Cursor has two AI systems running side by side. The first is Cursor’s own AI -- the tab completions, inline suggestions, and Composer features built into the editor. These use Cursor’s model pool. You pay for them through your Cursor subscription. You cannot route them through your Claude Max subscription.

The second is the Claude Code terminal. You can open Claude Code inside Cursor’s integrated terminal, and when you do, it runs on your Claude Max subscription. Full Claude Code. Full model switching. Full access to everything we have covered in Posts 2 through 4.

Here is the tradeoff:

What Cursor gives you that Claude Code alone does not:

Access to models from multiple providers. GPT. Gemini. Cursor’s own models. If Claude is down or rate-limited, you have alternatives.

Tab completions and inline suggestions. Cursor predicts your next edit as you type. This is genuinely useful for anyone writing code or structured files.

A visual IDE with a file browser, diff view, and familiar interface. If looking at a terminal makes you uncomfortable, Cursor softens the experience.

What you give up or pay extra for:

You are running two subscriptions. Cursor Pro ($20/month) plus Claude Max ($100 or $200/month). That cost adds up.

Cursor’s AI features and Claude Code’s terminal do not talk to each other. They are separate systems sharing a screen.

Claude Code running in Cursor’s terminal does not get Cursor’s inline diff view or visual feedback. You are still in the terminal.

My recommendation for CMOs: If you are using Cursor, run Claude Code from the integrated terminal for any serious building work. Use Cursor’s native AI for quick edits, tab completions, and small tasks where the visual feedback helps. Think of Cursor as your desk and Claude Code as the person sitting at it doing the real work.

If you are comfortable in the terminal and do not need the visual IDE, you can skip Cursor’s subscription entirely and run Claude Code directly. You will save $20/month and lose nothing in capability.

Effort Levels, Fast Mode, and Extended Thinking

Here is another important distinction that tripped me up early. Model selection is one control. But Claude Code has three more controls that affect your output speed, quality, and cost -- and they work independently of each other.

Effort Levels

When you run /model and select a model, look at the bottom of the screen. There is a slider you adjust with the left and right arrow keys. This is the effort level.

Effort controls how deeply the model thinks before responding. It has three settings: low, medium, and high. High is the default.

Low tells Claude to think less and respond faster. Good for simple tasks where you do not need deep reasoning -- renaming files, formatting text, quick lookups.

Medium is a balanced option. Solid quality without the full token cost of high. Good for routine coding work, standard content tasks, anything where you want decent output without waiting.

High is the default for a reason. This is where Claude does its best work. Complex analysis, strategy documents, anything where the quality of thinking matters.

Think of it like this. Low effort is a quick Slack reply. Medium effort is a thoughtful email. High effort is a board presentation. Same person, different investment of attention.

The practical move: drop to medium for routine work. Keep high for anything you would not want to redo.

Fast Mode

Fast mode is different from effort levels, and this is the part people confuse.

Effort controls how deeply Claude thinks. Fast mode controls how quickly Claude delivers the output. They are independent knobs.

Type /fast in Claude Code and press Tab. A lightning bolt icon appears next to your prompt. You are now getting the same model, the same intelligence, the same quality -- but the output arrives up to 2.5x faster. Anthropic prioritizes your request on their infrastructure.

The catch: fast mode costs more. At full price, it runs 6x the standard token rate. It also bills directly to extra usage, not against your subscription allowance.

When to use it: interactive sessions where you are iterating rapidly and every 30-second wait breaks your flow. Live debugging. Quick back-and-forth on a draft.

When to skip it: any task where you hit Enter and walk away. If you are not watching the screen, you will not notice the speed difference, and you will notice the bill.

Fast mode persists across sessions once enabled. Type /fast again to toggle it off. The lightning bolt disappears.

Extended Thinking

Extended thinking is the mode that cost me $75.

When extended thinking is on, Claude does not just give you an answer. It shows you its reasoning process -- the steps it takes to work through a problem before producing output. This is valuable for complex strategy work. When Claude is building a competitive messaging framework or analyzing a multi-layered dataset, seeing the reasoning lets you spot where it might be going wrong before it finishes.

Extended thinking is also expensive. Every token of reasoning counts toward your usage. A session that would use 50,000 tokens normally might use 500,000 with extended thinking on, because Claude is now producing its full chain of thought.

The current default: thinking is enabled automatically on Opus with adaptive thinking, meaning Claude decides when and how much to think based on the complexity of what you ask. On Sonnet, it works similarly. This is usually fine. The problem comes when you force high effort plus extended thinking on a task that does not need it.

My rule: I let adaptive thinking handle it for most sessions. I only explicitly push thinking depth (high or max effort on Opus) when I am doing genuine strategy work -- messaging frameworks, competitive analysis, anything where the reasoning process matters as much as the output. And when I do, I check /cost regularly.

The Decision Framework

Here is how these controls stack together:

The pattern: start with Sonnet at medium. Escalate deliberately. Every step up in model, effort, or speed costs more. Make those steps intentional.

The Commands That Keep You in Control

You have more visibility into what Claude Code is doing than you think. Here are the commands that matter.

/context -- Your Cockpit Dashboard

Type /context and Claude Code shows you exactly how your context window is being used. System prompt. Memory files. Skills. Messages. Free space. Autocompact buffer.

This is the command I wish I had known about from day one. When your free space gets low, Claude’s performance starts to degrade -- it has less room to reason. Check /context periodically during long sessions the way you check your phone battery.

/compact -- Controlled Compression

When your context is getting full, /compact tells Claude to summarize the conversation and free up space. But here is the key: you can give it specific instructions about what to keep.

/compact -- keep the campaign brief details and the file structure decisions. Drop everything about the debugging we did earlier.

This is dramatically better than letting auto-compact happen on its own. Auto-compact triggers when your context hits roughly 83% capacity. It happens mid-task. It summarizes everything generically. You lose precision on the details that matter.

Manual compacting at natural breakpoints -- after you finish a task, before you start a new one -- keeps you in control. Think of it like saving your game before a boss fight.

/clear -- The Fresh Start

/clear wipes the entire conversation. No summary. No holdover. Blank slate.

Use this when you are switching to a completely different task. If you just finished a campaign brief and now you need to debug a workflow, do not carry that campaign context forward. It wastes tokens and confuses the model. Clear and start fresh.

/cost and /stats -- Know What You Are Spending

/cost shows your token usage for the current session. If you are on API billing, this is your actual cost. If you are on a Max subscription, it shows what the session would cost at API rates -- useful for understanding your consumption patterns.

/stats shows your broader usage patterns for subscribers.

Get in the habit of checking /cost the way you check the clock during a meeting. Not obsessively. Just enough to know where you stand.

Auto-compact: What Happens When You Do Not Manage Context

If you never run /compact or /clear, Claude Code handles it for you. When your context window fills to roughly 83% capacity, auto-compact triggers automatically. Claude summarizes the conversation, frees up space, and continues.

The problem: it happens at the worst possible time. Mid-task. Mid-thought. The summary is generic because Claude does not know which details matter most to you. You lose the specific error message you were debugging. The exact phrasing you agreed on for a headline. The architectural decision you made forty minutes ago.

Auto-compact is a safety net, not a strategy. Manual compacting is the strategy.

Cost Control: Building Your Safety Net

Now that you understand models, effort levels, and context management, here is the practical infrastructure that keeps you from repeating my $75 mistake.

Subscription vs. API Billing

This is the single most important thing to understand about Claude Code billing.

Max subscription ($100 or $200/month): You pay a flat monthly fee. Claude Code usage is included. You get a generous but not unlimited token allowance per 5-hour session window. When you hit the limit, you wait. You do not get a surprise bill.

API billing (pay per token): You pay for every token, every session, no ceiling. This is how developers use Claude programmatically. It is also how you accidentally spend $75 in an afternoon if you do not know you are on it.

When you first set up Claude Code in Post 2, I told you to select “Use your Max subscription” at the login prompt. If you did that, you are on subscription billing. If you selected the API option, or if you are running Claude Code through an API key in your environment, you are on pay-per-token billing.

Check now. Type /cost in your next session. If it says something like “With your Claude Max subscription, no need to monitor cost,” you are on subscription billing. If it shows actual dollar amounts accumulating, you are on API billing.

Setting Spend Limits

If you are using API billing for any reason -- running automations, connecting external tools, or experimenting with programmatic access -- set spend limits in the Anthropic Console at console.anthropic.com.

Go to Settings. Go to Billing. Set a monthly spend limit that matches your budget. Set up email alerts at 50% and 80% of that limit.

This takes two minutes and it is the single highest-value safety measure you can put in place.

The Dashboard I Built to Watch Everything

After the $75 incident, I did what this series teaches you to do. I built something.

Using Claude Code, I created a monitoring dashboard and a Slack alert system that tracks spend by API key in real time. When any key crosses a threshold I set, I get a notification in Slack. I can see which projects are consuming what, which models are being used, and whether anything is running away.

I built this in one afternoon. It uses Python, the Anthropic API’s usage endpoints, and a Slack webhook. Three files. One afternoon. It has been running for months and has caught two potential overruns before they became problems.

This is the builder mindset in action. The skills you learned in Posts 2 through 4 -- writing directives, managing sessions, working with files -- let you build tools that manage the tool itself. That is the compounding effect.

For subscriber-only monitoring, the community has built tools like ccusage -- a command-line utility that parses your local Claude Code session data and shows you daily, monthly, and per-session token usage. It is useful if you want to understand your consumption patterns beyond what /cost shows.

Your Spend Prevention Checklist

Print this. Tape it next to your monitor. Follow it until it becomes habit.

Before every session:

1. Confirm your billing mode. Subscription or API. Know which one.

2. Set your model deliberately. Default to Sonnet. Escalate to Opus only when the task demands it.

3. Check your effort level. Drop to medium for routine tasks.

During every session:

4. Check /context every 30 to 45 minutes. Know how much room you have.

5. Check /cost if you are on API billing. No surprises.

6. Run /compact at natural breakpoints. Do not wait for auto-compact.

Before using Opus or extended thinking:

7. Ask yourself: does this task actually need deep reasoning, or am I defaulting to the expensive option out of habit?

8. If it does need Opus, check /cost more frequently. Extended thinking burns tokens fast.

For any automated or programmatic usage:

9. Set spend limits in the Anthropic Console.

10. Set email alerts at 50% and 80% of your limit.

11. Build or install a monitoring system. The dashboard took me one afternoon.

What Just Happened

You now know something most Claude Code users take tens if not hundreds of sessions to learn: the tool has layers of control that dramatically affect what you spend and what you get.

Model switching is about judgment. The same judgment you use when you decide whether a project needs a senior strategist or a junior coordinator. The same judgment you use when you set a campaign budget.

Effort levels, fast mode, extended thinking, context management -- these are levers. You now know where they are and what they do. The CMO who learns to pull them deliberately will get better output at lower cost than the CMO who runs everything on default.

In Post 6, I am going to take you beyond the terminal entirely. We are going to talk about MCP, CLIs and APIs -- the connectors that let Claude talk directly to your other tools. And n8n -- the visual orchestration layer that lets you wire multiple systems together with Claude making decisions at each step. That is where individual efficiency becomes system-level automation.

But the cost controls you learned today apply to everything that comes next. Post 6 involves workflows that run automatically. Workflows that run automatically can run up bills automatically. The habits you build now are the habits that protect you later.

Kevin Kerner is the founder and CEO of Mighty & True, a B2B tech marketing agency that helps CMOs and their teams improve their growth programs while also building AI-powered marketing systems.

If you are a CMO or marketing leader not getting enough done while also trying to figure out where AI fits in your operation -- not just the tools, but the workflows, the automation, the systems that actually move the needle -- reach out. Speed to outcome, efficiency, and performance. That is what we build for.

You have the tool running. You know how to direct it. Now you need to know how to make sure your work survives when you close the terminal. That is what this post is about.

Subscribe to get every post in this series delivered to your inbox: kevinkerner.substack.com

The Series: CMOs as Builders

1. Why CMOs Who Build Will Win -- The case for moving from AI user to AI builder, and why stepping out of the chat window changes everything.

2. Your First 30 Minutes with Claude Code -- How to install Claude Code, get oriented, and build your first real output.

3. How to Give Claude Code Its Orders -- The three modes, the four-part directive, the commands that matter, and the session habits that make everything work.

4. Stop Losing Your Work: Sessions, Context, and Memory (You are here) -- How to build a memory system Claude can use across any project, any session, any task.

5. Skills, Efficiency and Model Switching -- When to use Sonnet, Opus, and Haiku, and how smart model selection changes your output quality and your bill.

6. Beyond the Terminal: MCP, n8n, JSON and the Tools That Connect Everything -- The layer above Claude Code and how it all connects.

7. From Terminal to Teammate -- How to manage Claude Code as a working member of your team, including GitHub as your filing system.

8. The CLAUDE.md Blueprint -- The master file that makes every session smarter from the first line.

Stop Losing Your Work: Sessions, Context, and Memory

CMOs as Builders | Post 4 of 8

What you’re about to understand -- why the way you manage context determines whether your work compounds or disappears:

You built something real in Post 3. A directive that worked. An output worth keeping. Then you closed the terminal and came back the next day. And Claude had no idea what you were working on. You started over. That is not a Claude problem. That is a context problem. And it is completely fixable.

By the end of this post you’ll:

• Understand how Claude Code’s memory actually works. There are now four distinct layers. Most people know none of them.

• Use /compact as a consistent session habit, not an emergency measure. I’ll show you exactly when and how I use it.

• Have a project folder structure set up that makes your work persist across every session, every day, every project.

• Know how to ask Claude to build its own memory as you go, so complex projects don’t start from scratch every time you open the terminal.

Why this matters for you as a CMO: Knowing how to run a session is table stakes. Knowing how to make your work carry forward — across sessions, across days, across projects — is what separates people who build real systems from people who keep rebuilding the same thing. This post gives you the memory operating model.

Time to read: 9 minutes

What you need: Post 3 complete. Claude Code running. Cursor open.

The amnesia problem

Here’s the scenario every new Claude Code user hits.

You sit down, open the terminal, and build something you really like. A competitor brief. A messaging framework. A content workflow. It goes well. You close the terminal feeling like you actually got somewhere.

You come back the next morning. Type claude. And Claude has no idea what you were building.

You start over.

This is not a bug. It’s just how Claude Code works by default. Each session starts with a clean slate. The good news: there’s a complete system for fixing this. And once you set it up, you stop thinking about it.

Two memory systems. Two separate tools.

Before we go further, I want to clear up something that confuses almost everyone who uses both Claude.ai and Claude Code.

Claude.ai memory is the memory system that lives inside the chat interface. If you’re on a Pro or Max subscription, Claude.ai can remember things from your past conversations and build up a picture of how you work over time. (I covered the difference between these two tools in Post 1 — worth reading if you haven’t.)

Claude Code memory is an entirely separate system. It lives in the terminal. It handles your project sessions. And it does not share anything with Claude.ai.

They don’t talk to each other. Claude Code doesn’t know what you discussed in a chat last week. Everything in Claude Code starts from what’s in that session and what you’ve deliberately set up. That’s what this post is about.

What just changed: auto-memory shipped February 26

This is worth calling out because it’s brand new.

On February 26, Anthropic shipped auto-memory for Claude Code. In plain language: Claude now watches your sessions and quietly takes its own notes. Preferences you’ve set. Decisions you’ve made. Patterns in how you work. At the start of your next session in the same project, it loads those notes back in automatically.

You don’t have to configure anything. If you’re on a Max or Pro subscription, it’s already running.

You can see what it’s saving and manage it with the /memory command. Type that in any session and you’ll see what Claude has recorded about your project so far.

I recommend checking /memory right now if you’ve had any Claude Code sessions before reading this. You may be surprised what it’s already captured.

That said, I still build deliberate memory systems on top of auto-memory. Auto-memory decides what to save based on what it thinks matters. The techniques below put you in control of what Claude remembers and how it’s framed. Both matter. Use both.

The four memory layers

Think of this as a stack. Each layer lasts longer than the one before it. I use all four on any project that runs more than a single session.

Layer 1: Session resume (same day)

Claude Code automatically saves your sessions. If you close the terminal and want to pick up where you left off, two commands bring you back:

claude --continue Opens your most recent session immediately.

claude --resume Shows you a list of recent sessions to choose from.

I use --continue constantly when I step away for a meeting and want to drop right back in. It’s fast, requires no setup, and works perfectly for same-day interruptions.

The limitation: session resume is not a substitute for real context management. On projects that span days or weeks, you need the layers below.

Layer 2: /compact (use it often, not just when things go wrong)

Claude Code has a working memory limit. Think of it like a whiteboard that can only hold so much before old notes start getting erased. The limit is large, roughly 150,000 words per session, but on complex projects you’ll hit it faster than you expect.

When that happens, Claude starts losing context from earlier in the session. Outputs get less focused. It misses details it had 30 minutes ago. You can feel it happening if you’re paying attention.

The fix is /compact. Type it at the prompt and Claude summarizes the session so far, clears the noise, and continues with the essential context loaded fresh. Think of it like sending your assistant the bullet-pointed meeting recap instead of making them re-read the full transcript.

Good news: compaction is now essentially instant. Claude runs a background summarization process throughout your session, so /compact just loads that pre-built summary into a clean context. You lose nothing important.

My practice: I compact often, not just when things slow down. After any major completed task, before starting the next one, I run /compact. It takes two seconds and keeps Claude sharp for whatever comes next.

One more habit: before you run /compact, type a one-line summary first. Something like: “Summary: built the competitor brief template, saved in /outputs, next step is adding ICP filters.” That line gets preserved through the compaction and helps Claude pick up the thread cleanly on the other side.

See Anthropic’s context management documentation if you want the full technical breakdown.

Layer 3: Session notes (end of every session)

The simplest habit. The one most people skip.

Before I close any meaningful session, I ask Claude to write a summary file:

“Create a file called session-notes.md that summarizes what we built today, the decisions we made, and what the next steps are.”

Takes Claude about 10 seconds. The file lives in the project folder. When I come back the next day, I read it (and have Claude read it) to re-orient myself or paste it back into a new session as starting context.

I recommend building this into your closing routine from day one. Do it every session until it’s automatic. On a multi-week project, the compounding effect is significant.

Layer 4: CLAUDE.md (permanent, loaded every session)

This is the one that matters most for ongoing work.

CLAUDE.md is a plain text file (markdown file) that lives in your project folder. Claude Code reads it automatically at the start of every session. No commands needed. No setup required beyond creating the file.

Think of it as the onboarding document you’d give a new contractor on Day 1 — except Claude reads it perfectly, every single time, before touching anything in that folder.

What I put in a basic CLAUDE.md to start:

• What this project is. One paragraph describing what you’re building and why.

• Brand voice rules. The specific language guidelines, tone, banned words, and style constraints that matter for this project.

• Preferred output format. How you want Claude to structure its outputs. Markdown or plain text. File names. Folder locations.

I’ll cover CLAUDE.md in full depth in Post 8, where we build the complete marketing blueprint. For now, create one and start simple. Even a basic CLAUDE.md changes the consistency of your outputs immediately.

One note: as your CLAUDE.md grows and your project gets more complex, you’ll want a way to track changes and roll back if something breaks. I’ll cover that in Post 7. For now, syncing your project folder to Google Drive is your safety net.

One more thing worth knowing now: there are two levels of CLAUDE.md. The one you create inside a project folder applies only to that project. But you can also create a global CLAUDE.md that applies to every Claude Code session on your machine, across every project.

Think of it as your standing rules for how Claude should always behave, regardless of what you're building. Things like "never commit files without asking me first" or "always default to Sonnet unless I say otherwise." The project-level file adds the specifics on top. We'll build both in Post 8. For now, just know the global one exists and is worth setting up early.

One more global rule worth adding immediately: tell Claude what it is never allowed to read. A file called .claudeignore works exactly like a spam filter for your project. You list the files and folders you want Claude to stay out of, and it won't touch them.

At minimum, add your .env files (where API keys and passwords live), any credentials files, and folders containing sensitive client data. A single bad prompt that accidentally exposes an API key is a recoverable problem. It's just easier to never have it happen. Add this to your global rules now, before you build anything connected to real systems.

Your folder is the system

Context management isn’t only about what Claude remembers. It’s also about where your files live.

When I start a Claude Code session, I cd (change directory) into a project folder first. That tells Claude Code to work from that specific folder. (If you’re not clear on the cd command, I covered terminal navigation basics in Post 2.)

Everything Claude builds in that session goes into that folder. The files persist when the session ends. That’s the difference between a chat that disappears and a tool that actually builds things.

Here’s the folder structure I use for most projects (that are outside of GitHub). You can borrow this directly:

/project-name

/inputs <- briefs, source docs, reference files

/outputs <- everything Claude builds

/prompts <- prompt templates that worked well

session-notes.md

CLAUDE.md

Simple, consistent, and easy to pick up from wherever you left off.

One more habit worth building immediately: instead of letting Claude read your entire project every session, point it at exactly what it needs. Type @filename in any prompt and Claude reads that specific file. So instead of asking Claude to “look at the brief,” you write @brief.md and it goes straight there. Keeps sessions lean, outputs focused, and your context budget used on what actually matters.

Important: put this folder somewhere that syncs automatically. Google Drive, Dropbox, iCloud — pick one. If anything happens to your local machine, your work survives.

Ask Claude to build its own memory

Beyond auto-memory, I recommend explicitly asking Claude to write memory notes as you work. This is a practice, not a feature.

At the end of any meaningful decision in a session, a positioning choice, a formatting preference, a workflow you’ve settled on, I type something like:

“Add a note to memory-notes.md that we decided to always write competitor briefs in this format: executive summary first, then evidence, then strategic implication.”

Over time, that file becomes a record of how you and Claude have worked together on this project. Preferences. Decisions. Things that didn’t work. At the start of any future session:

“Read memory-notes.md before we start today.”

Auto-memory handles some of this in the background, but building your own gives you control over what gets remembered and how it’s framed. I use both on any project that runs longer than a few sessions.

For a deeper look at how Claude’s memory architecture works, Anthropic’s memory documentation is worth reading.

Stop watching the terminal: notifications

Most people run Claude Code and sit there waiting for it to finish. You can certainly do that. But there’s a better way.

Claude Code can send you a desktop notification the moment it finishes a task or needs a decision from you. Your Mac or PC pings you. You go do something else in the meantime. This is how you stop babysitting the terminal and start treating Claude Code like the background worker it actually is.

This works through a feature called hooks, which are small automation rules that fire at specific points in Claude Code’s lifecycle. The notification hook is the simplest and most immediately useful one. When Claude finishes working and needs your input, you get a desktop alert instead of having to check the terminal every few minutes.

I’ll cover how to set up hooks in full in Post 6, when we connect Claude Code to your other tools. For now, the key thing to know is that this capability exists. You do not have to be tethered to the terminal while Claude works. Feel free to Google it for now, though. It’s super helpful.

The practical version right now: when you start a longer Claude Code task, minimize the terminal and go do something else. Check back in five minutes. You will find it either finished or waiting for a decision. Once you set up the notification hook, it will tap your shoulder for you.

Hooks: automation rules that run without you

While we’re on the topic, hooks are worth understanding even before you set them up.

A hook is a rule you define once that fires automatically at a specific point in every Claude Code session. Think of it as a standing instruction that doesn’t require you to remember to give it. Some examples that are directly useful for marketing work:

• Context re-injection after /compact. You can set up a hook that automatically reminds Claude of your project rules every time it compacts. So even after a long session with multiple compactions, Claude never loses your brand voice guidelines or output format preferences.

• Desktop notification when Claude needs you. Fire a system alert the moment Claude finishes a task or waits for a decision. Step away from the terminal without losing time.

• Auto-save session notes. A hook that writes a summary file every time you end a session, without you having to remember to ask.

Hooks are configured in a settings file inside your project folder. They’re not complicated once you see the format, but they do require editing a JSON file, which I’ll walk through in Post 6. For now, Anthropic’s hooks documentation is the reference if you want to get ahead of it.

The bigger idea behind hooks: Claude Code is probabilistic. It makes decisions based on context and may forget things. Hooks are deterministic. They run every time, no matter what. Used well, they’re the layer that makes your Claude Code sessions consistent even when the AI itself isn’t.

If you’re using Cursor: what it adds

I recommend Cursor throughout this series because it makes Claude Code more approachable for people who aren’t comfortable living in a raw terminal. (See Post 2 for the full setup.) But Cursor also has a few specific features that are worth knowing for context and memory management.

Checkpoints: the undo button

Cursor automatically snapshots your project as Claude makes changes. Every time Claude writes or edits a file, Cursor creates a checkpoint you can roll back to.

For a CMO who is building something new and uncertain, this is a confidence builder. Try something. See if it works. If it breaks something or goes in the wrong direction, click back to the previous checkpoint. You are not stuck with every decision Claude makes.

Cursor Rules: your project brief for the IDE

Cursor has its own version of CLAUDE.md called Cursor Rules. It’s a file that lives in your project and tells Cursor’s AI how to behave when it assists you inside the editor.

If you use both Cursor and Claude Code on the same project, I recommend keeping both files in sync. Same brand voice rules. Same output format preferences. Same project context. That way the AI assistance you get from Cursor’s inline suggestions and the work Claude Code builds in the terminal stay consistent with each other.

Export chat to Markdown

Cursor lets you export an entire conversation to a Markdown file. If you have a long session where you and Claude worked through a problem together, you can save that conversation as a reference document. That file becomes context you can load back into a future session or share with a team member. This is amazingly useful.

I use this when I’ve worked through something complex and want to preserve the reasoning, not just the output. The conversation itself is often as useful as what got built.

Claude Code runs inside Cursor

Worth saying clearly: Claude Code and Cursor are not competing tools. You run Claude Code in Cursor’s built-in terminal. Cursor gives you the visual interface, file browser, and inline AI suggestions. Claude Code runs in the terminal panel below and does the heavy building work. Both run simultaneously in the same window.

Most of the CMOs in our cohort end up using them together. Cursor for navigation and reviewing what Claude built. Claude Code for the actual building.

Scheduled tasks: what’s possible now

A question I get often: can Claude Code run on a schedule? Can it remind you to do things, or update files automatically without you triggering it?

The short answer: yes, but not fully inside Claude Code itself yet. Here’s how it actually works right now.

Cowork (Claude Desktop) does support scheduled tasks natively. You can set up a recurring task like “every Monday morning, pull this week’s calendar and summarize my priorities” and it runs automatically on a schedule. This is separate from Claude Code and lives in the Claude Desktop app, but it’s worth knowing exists for recurring, low-complexity tasks.

Claude Code itself doesn’t have built-in scheduling yet. What people do instead is use their computer’s built-in task scheduler (called cron on Mac and Linux) to trigger Claude Code commands at set times. This is more of a developer workflow right now. It’s doable but not something I’d tackle in early sessions.

The practical version I use now: I end sessions by asking Claude to write a “next session” note with exactly what we should do first when we pick this up again. That note sits in the project folder. When I come back, I read it before typing anything. It’s not automated, but it’s a 10-second habit that eliminates the 10-minute re-orientation that would otherwise happen.

Fully automated workflow scheduling is what Post 6 and Post 7 are about. That’s where n8n comes in and where things like my automated marketing projects live. The scheduling and triggering power is real. It just lives at a different layer than Claude Code itself.

What to do right now

Three actions. Do them before Post 5.

• Open Claude Code and type /memory. See what it’s already captured from your sessions. If you’re new, it may be empty. If you’ve been using Claude Code for a while, you may find it knows more about your projects than you expected.

• Create your project folder. Set up the /inputs, /outputs, /prompts structure. Put it in Google Drive or your cloud storage of choice. Create a blank CLAUDE.md with three sections: Project Overview, Voice and Tone Rules, Output Format. Fill in two or three lines under each one.

• End your next session with session notes. Ask Claude to create session-notes.md summarizing what you built, decisions made, and what’s next. Do it every session until it’s automatic.

In Post 5, we move into model switching and cost control. That includes the full story of my $75 API mistake and how to make sure it never happens to you. It’s the practical skill that turns Claude Code from an interesting experiment into something you can run responsibly at scale.

Working with Mighty & True

If this series is making you think about what’s possible inside your own marketing organization, that’s exactly the point.

At Mighty & True, we work with technology CMOs to automate their marketing workflows end to end. Not just their own daily work. Their team’s work too. We build the systems that connect strategy to execution, remove manual bottlenecks, and give marketing leaders real speed to outcome.

We run marketing campaigns. We augment marketing teams. And we build the automation infrastructure that makes both run faster. Our core metrics are the same ones that matter to you: speed to outcome, efficiency, and performance.

If you want to talk about what that looks like for your organization, reach out here.

About the author

Kevin Kerner is the founder and CEO of Mighty & True, a B2B tech marketing agency based in Austin. He has spent 30 years in technology marketing, leading teams, building agencies, and lately, building AI systems that run his business. He hosts the Tech Marketing Rewired podcast and writes about AI, marketing, and what’s actually working at the intersection of both.

He is not waiting for AI to get easier. He is building now. So can you.

Want the rest of the series?

All eight posts are coming. Each one builds on the last. By the end you will have gone from curious to actually building something real.

Subscribe at kevinkerner.substack.com and every post lands in your inbox the moment it drops. No algorithms. No feed. Just the guide, straight to you.

You have the tool running. Now you need to know how to actually run a session. That is what this post is about.

Subscribe to get every post in this series delivered to your inbox: kevinkerner.substack.com

The Series: CMOs as Builders

1. Why CMOs Who Build Will Win -- The case for moving from AI user to AI builder, and why stepping out of the chat window changes everything.

2. Your First 30 Minutes with Claude Code -- How to install Claude Code, get oriented, and build your first real output.

3. How to Give Claude Code Its Orders (You are here) -- The three modes, the four-part directive, the commands that matter, and the session habits that make everything work.

4. Stop Losing Your Work: Sessions and Context -- How to build a memory system Claude can use across any project, any session, any task.

5. Skills, Efficiency and Model Switching -- When to use Sonnet, Opus, and Haiku, and how smart model selection changes your output quality and your bill.

6. Beyond the Terminal -- MCP, n8n, JSON and the Tools That Connect Everything -- The layer above Claude Code and how it all connects.

7. From Terminal to Teammate -- How to manage Claude Code as a working member of your team, including GitHub as your filing system.

8. The CLAUDE.md Blueprint -- The master file that makes every session smarter from the first line.

What you’re about to learn — why the way you communicate with Claude Code determines everything it builds for you:

You got Claude Code running in Post 2. You typed something, it produced something. But maybe the output wasn’t quite right. Maybe you weren’t sure what to say next. Maybe you got a great result once and couldn’t repeat it. That’s not a Claude problem. That’s a communication problem. And it’s completely fixable.

By the end of this post you’ll:

• Know the three modes Claude Code operates in. Plan, Build, and Review. You’ll know exactly when to use each one so you stop getting half-finished outputs.

• Have a repeatable four-part structure for every directive you write. One that produces consistent, usable output on the first pass.

• Know the most important commands in Claude Code. The ones that control memory, context, sessions, and cost, and what each one actually does.

• Understand how to set up your project before you write a single directive. Folder structure, Markdown files, and the scaffolding that makes everything run cleaner.

Why this matters for you as a CMO: Knowing how to use the tool is table stakes. Knowing how to run a session, setting it up, directing it through phases, managing context as you go, is what separates people who get real output from people who get interesting demos. This post gives you the operating model.

Time to read: 14 minutes

What you need: Claude Code installed and running (Post 2). Cursor open.

My mental model for Claude Code includes 3 modes, and most people only use one

Before you type a single directive, understand that Claude Code is not a single-speed tool. It has distinct operating modes with specific behaviors in each one. Using the wrong mode at the wrong time is why people get messy output, unexpected file changes, or results that don’t match what they asked for.

Plan, Build, and Review is how I think about the three phases of any session. But each phase maps to a specific mode inside the tool with its own mechanics. Here is exactly what each one does and how to use it.

Plan Mode: think before you build

Inside Claude Code, I think of the first stage as Plan Mode (I think of it as Architect Mode). You activate it by pressing Shift+Tab twice (or simply ask it for Plan mode).

When you enter Architect Mode, Claude becomes read-only. It cannot change any files. It cannot write any code. It can only research your project and think.

What you do in this mode: you give Claude your directive and ask it to write a plan. The output is a file called plan.md (or it’s named your_project-name.md) that maps out every change it intends to make before it makes a single one.

What plan.md contains: which files will be created or modified, what will be written in each one, what decisions will be made along the way, and what order the steps will happen in.

Pro tip: press Ctrl+G while you are in Plan Mode to open the plan.md file instantly in your editor so you can read the full plan before approving anything.

Why Architect Mode is critical: Claude is acting as an architect, not a contractor. It is drawing the blueprints before anyone picks up a tool. You read the plan, you correct anything that is wrong, and only then do you move to the next mode. This catches misalignment before it costs you tokens or time. Before Claude writes 200 lines of code or a 1,500-word document, you see its interpretation of your directive. If the interpretation is wrong, you fix the plan, not the output.

When to use it: every new task. Every time you are about to ask Claude to create or modify multiple files. Any time the task is complex enough that a wrong assumption would waste 10 or more minutes.

A word about the model: Opus 4 does a great job creating plans… but Sonnet also does. You’ll burn more tokens with Opus … but try both models to get the best plan.

Build Mode: execute the plan

Once you have reviewed and approved the plan, you switch to execution. Press Shift+Tab once to enter Interactive Mode (I think about it as “build mode”), which is the default. If you want Claude to run through the steps without stopping to ask questions at each one, you can switch to Auto-Accept Mode instead.

In Interactive Mode Claude executes each step and pauses for your input before moving to the next one. You stay in the loop at every decision point. This is where I spend most of my time when I am building something new or complex.

In Auto-Accept Mode Claude runs all the steps in sequence without stopping. This is faster but requires more trust in the plan you approved. I use this for simpler, well-defined tasks where the plan is tight and the risk of a wrong turn is low.

What Build Mode actually produces: this is the part most people underestimate. Build Mode does not just produce documents. It builds working applications, API integrations, automations, and full workflow logic. I built LaunchPod, my podcast post-production automation, entirely in Build Mode. I use it to build all of my n8n workflows. When Claude Code builds an n8n workflow it is producing working integration logic that connects real tools, moves real data, and runs on its own. That is the ceiling of what this mode can produce. The document examples in this post are the entry point, not the limit.

One important thing to understand about tokens: Claude uses tokens the entire time you are in a session, across every mode. Build Mode is where you can burn through them fastest, especially when you are building something complex or running the wrong model for the task. A long Build Mode session with Opus running when Sonnet would have done the job is how you end up with a surprising bill.

Post 5 covers model selection in full because it matters enough to deserve its own post. For now, know that Sonnet handles most Build Mode tasks well, and check /cost regularly so you always know where you stand.

Review Mode: verify before you move on

Review is your checkpoint. After Build Mode produces output, you stop and verify before doing anything else.

Claude Code gives you two tools for this.

The first is the Rewind Menu. If a build step produces something wrong or breaks something that was working, press Escape twice to open the Rewind Menu. This lets you go back to a previous state before the bad step happened. Think of it as an undo button for your build session. Use it immediately when something goes sideways. Do not try to fix a bad build by building more on top of it.

The second is the /review command. This is a custom command you can run to ask Claude to check its own work against the original plan. It reads what was built and compares it against what plan.md said should happen. Gaps and mismatches get flagged before you move forward.

How to run it:

/review

What it produces: a comparison of the plan against the output, with any gaps or inconsistencies called out in plain language.

When to use Review Mode: before you hand anything off. Before you move to the next phase of a multi-step project. Any time a build step felt uncertain or produced output that surprised you.

The workflow that works for me:

Enter Architect Mode. Write the plan. Press Ctrl+G to review plan.md. Approve or correct it. Switch to Interactive Mode. Build step by step. Run /review when the build is complete. Use the Rewind Menu if anything goes wrong. Move to the next phase clean.

Running this loop once produces better output than running Build Mode five times and hoping something sticks.

Using Claude as a thought partner during any mode

One of the most valuable habits I have built working in Claude Code has nothing to do with directives or commands. It is something I do across all three modes whenever something feels off or when I want to pressure-test a direction before I commit to it.

I stop and ask.

“Am I thinking about this the right way?”

“How would you approach this differently?”

“What are you seeing that I might be missing here?”

“Is there a better structure for what I’m trying to build?”

Claude will give you a real answer. Sometimes it confirms you are on the right track. Sometimes it surfaces an approach you had not considered. Sometimes it identifies a problem with your current plan before you have spent an hour building in the wrong direction.

This is where a lot of my best ideas come from. Not from the directive. Not from the output. From the conversation around the work.

The moment I stopped treating Claude as a task executor and started treating it as a thinking partner, the quality of what I was building jumped significantly.

One important caveat: Claude will offer suggestions confidently whether they are right for your specific situation or not. You have to use your own judgment. Claude knows the technical landscape. You know your business, your team, your constraints, and what actually needs to happen. Use it as a thought partner, not a decision-maker. Ask the question, weigh the answer, and decide for yourself.

This is not a separate mode. It is a habit you layer on top of whatever mode you are already in. Get comfortable asking the question. It changes how you work.

Set up your project before you write your first directive

Most people open Claude Code and immediately start typing what they want. This is like handing a contractor your wish list before they have seen the building. A few minutes of setup at the start saves hours of confusion across the life of a project.

Create your folder structure first

Ask Claude to build it for you. This is one of the most underused Claude Code capabilities and one of the most satisfying things to watch it do.

Here is the directive:

“Create a folder structure for a content marketing project. I need folders for: briefs, drafts, final, research, and assets. Inside briefs, create a template file called brief-template.md with placeholder sections for: objective, audience, key message, format, and deadline.”

Claude creates the entire structure in one pass. You now have an organized project before a single piece of work exists. The whole thing takes about eight seconds.

Create a context file before you start working

A context file is a short Markdown document that gives Claude everything it needs to know before it starts working on a project. Not just brand voice or audience. Anything that shapes what good output looks like for this specific project.

That could be technical constraints for a software build. Business rules for a reporting system. Competitive positioning for a messaging project. Workflow logic for an automation you are building. Data sources and definitions for an analytics tool. The context file is not a template with fixed fields. It is a briefing document, and its contents depend entirely on what you are building.

The best way to figure out what belongs in yours: ask Claude.

“I am building [describe your project in two or three sentences]. What should I include in a context.md file to give you the best possible briefing before we start? Give me a recommended structure with placeholder text in each section.”

Claude will ask the right questions for the type of project you are describing. A content workflow gets different context sections than an API integration or a client dashboard. Let Claude help you design the file before you fill it in.

Save it as context.md in your project folder. Then in every future directive, add this line at the top: “Read context.md before you start.”

That one line replaces five minutes of re-explanation at the start of every session.

The other thing that makes this powerful: you do not have to maintain it manually. At the end of any session where something important changed, just ask Claude to update it.

“Update context.md to reflect any new decisions, constraints, or information from today’s session.”

Claude reads what happened in the session, identifies what is new or different, and updates the file. Your briefing document stays current without you having to think about it.

Managing context and memory across sessions

One thing to remember in AI coding… Every new session starts with a blank slate. Claude does not remember what you built yesterday, what decisions you made last week, or what your project even is. You have to tell it every time.

That sounds like a problem. It becomes one only if you have no system for it. Here is the system I use.

The three files that replace your memory:

There are three files that do different jobs in a well-run project.

context.md is your project briefing (mentioned above). It tells Claude what you are building, what constraints apply, what good output looks like, and anything else Claude needs to know before it starts work on this project. You reference it at the start of every session. Claude reads it and starts from a fully briefed position instead of a blank one.

README.md is your project status file. It tells Claude where the project stands right now. What has been completed, what decisions have been made, what the next step is. You update it at the end of every session. At the start of the next session, Claude reads it and knows exactly where it left off.

CLAUDE.md is something more powerful and something I will cover in full in Post 8. Think of it as the master file that Claude Code is specifically designed to read automatically at the start of every session. It is where you put the things that should never change across a project: your build and test commands, your folder structure, your hard rules and negative constraints, the things Claude should never do regardless of what you ask. Post 8 is dedicated entirely to building this file correctly. For now, know it exists and know it is coming.

The session workflow I use on every project:

Start of session:

“Read context.md and README.md. Tell me where we left off and what we are doing today.”

This is how every session starts. Claude reads the two files that contain everything it needs to know about who you are and where the project stands. You do not re-explain anything. You confirm the starting point and go.

During a long session when output starts softening:

/compact — We are building [project name]. Completed: [what is done]. Current task: [what we are working on now]. Do not lose this thread.

Run this before the whiteboard fills completely. Waiting until output quality has fully degraded means you have already lost some of the thread. Run it when you notice the first signs.

End of every session. This is non-negotiable:

“Update README.md to reflect what was completed today, what decisions were made, and what the next step is. Keep it under 200 words. Date the entry.”

“Update context.md to reflect any new decisions, constraints, or information from today’s session.”

Claude reads what happened, identifies what changed, and updates both files. Your briefing document and your status file stay current without you having to think about it.

A note on where all of this is heading: Right now you have two files doing most of the memory work. In Post 8, I will show you how CLAUDE.md ties everything together into a single master briefing that Claude Code reads automatically every time you open a project. No manual referencing. No re-explaining. Claude just knows. That is the system we are building toward. These two files are the foundation.

And in Post 7, I will show you how I store all of it in GitHub so nothing ever gets lost and every change is tracked. That is further down the road. For now, your project folder and these files are all you need.

The anatomy of a strong directive

A mistake people make often is treating Claude Code like a search engine. They type a vague request and hope for the best. What you actually want is something closer to a creative brief crossed with a technical spec. You have written creative briefs. You know what a clear scope of work looks like. The skill transfers directly. You are just writing the brief for an AI that can build things, not just write them.

In my work, strong directives have four elements. They work the same whether you are building a document, a script, an automation, or a full application. I will show you each one two ways: first for a content task you will recognize, then for a build task that might be new territory. The structure is identical. Only the subject changes.

Element 1: Role

Tell Claude what job it is doing right now.

For a content task: “You are a B2B content strategist working on messaging for a mid-market SaaS security product.”

For a build task: “You are a senior Python developer building a lightweight automation script. You write clean, well-commented code with error handling built in.”

Python is a programming language. Well-commented means Claude will add plain-language notes inside the code explaining what each part does. Error handling means Claude will write the code so that if something goes wrong, it fails gracefully with a useful message instead of just breaking silently.

You do not need to know how to write Python to give this directive. You just need to know that telling Claude it is a careful, experienced developer produces better code than not telling it anything at all. The role shapes every judgment call Claude makes when the directive does not spell out every detail.

Element 2: Task

State what you need clearly and lead with the end in mind. That might be a specific deliverable, a problem you need solved, or a plan you need formed before you build anything. All three are valid tasks. The key is that Claude knows what success looks like before it starts.

When you know exactly what you want built:

State the deliverable directly.

For a content task: “Create a one-page competitive positioning brief.”

For a build task: “Build a script that reads all the spreadsheet files in a folder, merges them into a single file, removes any duplicate rows, and saves the result as a new file called merged-output.csv.”

A .csv file is a spreadsheet file that any program can read, including Excel and Google Sheets. Think of this directive as asking Claude to do something you might otherwise do manually in Excel, except Claude does it automatically on any number of files in seconds.

When you have a problem but not a solution:

Describe the problem and the outcome you want. Let Claude figure out the approach.

“I have 12 monthly reports sitting in a folder as separate files. I need them combined into one document with a summary table at the top showing key metrics from each month. I do not care how you do it as long as the output is clean and I can open it in Google Docs.”

This is a perfectly good task. You are not telling Claude what to build. You are telling Claude what problem you have and what done looks like. Claude will propose an approach. You approve it or redirect it. This is also where the thought partner habit from earlier kicks in. Ask Claude: “What is the best way to solve this given what you know about my setup?” You might get an approach you would not have thought of.

When you are not sure where to start:

Ask Claude to help you form the plan before you commit to anything.

“I want to automate the process of pulling our weekly sales data from Google Sheets, formatting it into a summary report, and emailing it to our leadership team every Monday morning. I do not know the best way to build this. Help me think through the options and write a plan before we build anything.”

This is not a vague request. It is a specific ask for a plan as the deliverable. Claude will walk through the options, explain the tradeoffs in plain language, and produce a plan you can review before a single line of code gets written. This is Plan Mode working exactly as it should.

The mistake is not having a topic instead of a task. The mistake is leaving Claude without a clear picture of what done looks like. A deliverable, a problem with an outcome, and a request for a plan all give Claude that picture. “Help me with my spreadsheets” does not.

Element 3: Context

Give Claude what it needs to do the job well. For content work, reference your context.md file or paste in relevant background. For build work, describe what already exists, what tools are in play, and any constraints on how the solution should work.

For a build task: “The folder already exists and contains files exported from three different systems. The column headers are slightly different in each file. Use the column structure in schema.md as the standard and normalize everything to match it.”

Schema is just a fancy word for the agreed-upon structure of a spreadsheet or database. Normalize means make everything consistent. You are telling Claude: here is the mess, here is what clean looks like, make it match.

Context is what separates a directive that produces something immediately usable from one that produces something technically correct but wrong for your actual situation. Claude can build exactly what you asked for and still miss what you needed if it does not have enough context.

Element 4: Output spec

Tell Claude exactly what the finished product should look like. This is where most people leave money on the table. They write a great directive and then forget to describe what done actually looks like. Claude fills in the blanks on its own and produces something that needs reformatting, renaming, or restructuring before anyone can use it.

The output spec answers four questions: What should the file be called? What format should it be in? How should it be structured? And what should not be in it?

For a content task: “Output as positioning-brief.md. Use H2 headers for each section. Under 800 words. No bullet points.”

For a build task, you do not need to know the technical details. You just need to describe what you want to see when it is done.

“Save it as a file called merge-data.py. I want to be able to read through it and understand what each part does, so add a plain-English explanation above each step. When it finishes running, show me a message confirming it worked and how many rows ended up in the final file. Keep it simple. Do not use anything that would require extra installation steps on my computer.”

You are not writing code. You are describing the experience of using the thing Claude is about to build. What does it look like when you open the file? What happens when you run it? What do you want to see? What do you not want to deal with?

The same principle applies whether Claude is building a report, a workflow, an automation, or an application. Describe the finished experience, not the technical method. Claude handles the method. You define what good looks like.

Without an output spec, Claude guesses. And it will guess based on what is technically correct, not what is right for your situation. Thirty seconds of output spec saves ten minutes of cleanup every time.

The most common directive mistakes:

Asking instead of directing: “Can you help me think through a content strategy?” produces a conversation. “Build a 90-day content strategy framework for a B2B SaaS company targeting IT buyers. Output as a Markdown file with monthly phases, weekly themes, and format recommendations per channel.” produces a file. “Can you help me with my data?” produces questions. “Read the files in this folder, merge them into one spreadsheet, and remove any duplicate rows. Save the result as clean-data.csv.” produces a finished file you can actually use. Know which one you want before you type.

No output spec: Claude will produce something. It just will not be in the format you wanted, at the length you needed, or structured the way your team uses. This is the most common mistake and the easiest to fix. Add the output spec before you submit the directive, not after you get something back that needs reformatting.

One giant directive: Break complex tasks into stages. The first directive produces the structure or framework. The second populates it. The third refines. This is true for documents and for code. You would not hand a new hire a 40-item project list on day one. Same principle applies here.

Over-explaining the reasoning: Claude does not need to know why you want something. It needs to know what to produce. Cut the backstory. Lead with the task.

The commands you actually need to know

Claude Code has a command layer. These are specific instructions that control how it operates, not just what it produces. Knowing these puts you in control of context, cost, and session quality in a way that changes how you work.

/context — shows you what Claude is currently holding in memory

What it does: Displays everything currently in Claude’s context window. The conversation history, the files it has read, the instructions it has received in this session.

Why it matters: Context has a limit. Think of it as a whiteboard. During long sessions the whiteboard fills up and Claude starts erasing the oldest content to make room for the new. When that happens you will notice it. Claude starts ignoring earlier instructions or produces output that contradicts something you established two steps ago. Running /context shows you how full the whiteboard is before things go sideways.

When to use it: Any time a session has been running for 30 or more minutes. Any time Claude starts producing output that feels like it has forgotten something.

/clear — clears the current context and starts fresh

What it does: Wipes the slate completely. Claude no longer remembers anything from this session.

Why it matters: Starting fresh with a full context window is faster and cheaper than trying to work around a full one.

When to use it: When switching to a completely different task. When output quality starts degrading mid-session. When you have finished one phase and want to start the next cleanly.

One important thing to know: after /clear, Claude does not remember your context file either. It does not remember anything. Always re-reference context.md in your first directive after clearing.

/compact — compresses context while preserving what matters

This is the command I use most and the one most people have never heard of.

What it does: Summarizes and compresses the current session history to free up context window space. Unlike /clear, it keeps the thread. Claude still knows the shape of the project. It just holds it more efficiently.

Why I use it instead of /clear: Most of my sessions run long. I am building across multiple tasks in the same project. I do not want to start over because I would lose the continuity. /compact gives me breathing room without losing the thread.

The critical thing about /compact: always add a specific instruction when you run it. Tell Claude what to preserve in the summary before it compresses.

Here is what that looks like:

/compact — Remember: we are building the LinkedIn content workflow. We have completed the folder structure and the context file. Next step is the draft directive for post generation. Hold that context.

Without that instruction, /compact decides what matters. With it, you decide. Always run it with an instruction.

/cost — shows the token cost of the current session

What it does: Displays how many tokens have been used and the approximate dollar cost.

Why it matters: This is how you avoid the $75 mistake I walked through in Post 2. Check it during sessions, not at the end when there is nothing you can do about it.

When to use it: Every 20 to 30 minutes during active sessions. Before starting a complex multi-step task to establish your baseline cost so you know what the session is running you.

/model — switches the model mid-session

What it does: Changes which Claude model is running without starting a new session. Post 5 covers model switching in full because it matters enough to deserve its own post. The short version for now: Sonnet is your default for most tasks. Opus is for complex reasoning where quality matters more than speed. Haiku is for high-volume simple tasks where cost matters most. Knowing when to switch is one of the most important skills in this entire workflow.

/help — lists all available commands

Use this when you want to explore. It is the full menu and worth reading once so you know what is available.

Keyboard shortcuts worth knowing in Cursor:

Escape: Interrupts Claude mid-build. Use it immediately when something is going in the wrong direction. Do not let a bad build run to completion. The moment you see output heading somewhere wrong, hit Escape.

Up arrow in terminal: Cycles through your previous commands. You do not have to retype a directive you have already used. For directives you run regularly, this saves significant time.

Shift+Tab: Toggles Plan Mode on and off. Version-dependent in Cursor, but worth checking.

Security review: a habit worth building now

Most CMOs building with Claude Code are not thinking about security. That is understandable. You are focused on output, not infrastructure. But the habit of reviewing what you build is the same habit that keeps you out of trouble when your systems start connecting to real data, real APIs, and real workflows.

The time to build the habit is before the systems get complex. Not after.

What a security review is in this context:

It is a structured prompt that asks Claude to look at what it just built and flag anything that could create a problem. Data exposure. Hard-coded credentials. Insecure connections. Permissions that are broader than they need to be. Claude explains every issue in plain language. You do not need to understand the technical details to understand whether something needs attention.

The /security-review skill:

Claude Code has a built-in skill called /security-review. Run it after any build session where Claude has created code, scripts, or workflow logic.

How to run it:

/security-review

What it does: Claude reviews the files created in the session and flags potential security issues with plain-language explanations. It will note things like an API key pasted directly into a file instead of stored as an environment variable, a script that writes to a public folder, or a connection that does not verify credentials before passing data.

What you do with the output: You do not need to understand every technical detail. You need to understand the severity. Claude will tell you what is low risk, what needs attention before you share the output with anyone, and what needs to be fixed before you deploy anything to a live system.

[SCREENSHOT PLACEHOLDER — Terminal showing /security-review output with a flagged issue highlighted and Claude’s plain-language explanation below. Annotate: “You do not need to be a developer to read this. Claude tells you what it found and why it matters.”]

My rule: I run /security-review at the end of any session where I have built something that connects to an external service. It takes two minutes. It has caught real problems, including an API key I pasted directly into a config file instead of storing it properly as an environment variable. That is the kind of mistake that is embarrassing at best and expensive at worst.

Build the habit now. Your future self will be glad you did.

Updating your Markdown files at the end of every session

This is a small habit with a large return. Before you close Claude Code, you do three things. Every session. No exceptions.

1. Update your README

“Update README.md with what was completed today, what decisions were made, and what the next step is. Date the entry.”

2. Update your context file if anything changed

Did you add a new product line? Change your target audience? Decide on a new output format standard? Update context.md to reflect it.

“Update context.md to add [new information] to the [relevant section].”

3. Create or update your session log

For larger projects I maintain a session-log.md file that captures a one-paragraph summary of each work session. It is not a substitute for the README. It is a running record that lets me see the full arc of a project when I come back to it after a week away.

“Update session-log.md with a one-paragraph entry for today’s session. Include what was built, what was decided, and any open questions. Date the entry.”

Memory is the hidden cost of building with AI. Every time you re-explain a project to Claude from scratch you are burning tokens and time. These three files, context.md, README.md, and session-log.md, are your memory system. They cost almost nothing to maintain and return that investment every single session.

The directive I use every week

I want to show you what all of this looks like in a real directive. Not a hypothetical. Something that runs in my workflow every day.

LinkedIn Content Machine:

Every day my n8n workflow drops a meeting transcript into a Google Drive folder and sends me a Slack message letting me know it is there. The Claude Code piece is the directive that turns that transcript into a LinkedIn post draft.

Here is the structure:

Role: You are my content strategist. Your job is to find the single most interesting professional insight from this meeting and turn it into ideas for a LinkedIn post.

Context: Read context.md before you start. My voice is direct, no jargon. I write like I talk.

Task: Read the transcript file in the /transcripts folder dated today. Identify one insight. Not a summary. One idea worth saying. Write a LinkedIn post from my perspective using that insight.

Output spec: Create a file called linkedin-draft-[date].md. Hook line first, no question hooks. Three short paragraphs. One closing observation. No hashtags. Under 250 words.

What makes this directive work: it is specific about what good looks like at every level. It has a role. It references the context file so Claude already knows my voice before it starts. The output spec has a file name format, a word count, and explicit restrictions.

This runs every day. The consistent output quality comes directly from the directive quality. A vague prompt produces a generic post. A specific directive produces something that sounds like me. That is not magic. That is a well-written brief.

The full session from open to close

Here is everything in this post assembled into a single workflow you can follow from the first directive to the last file update.

Start of session: “Read context.md and README.md. Tell me where we left off and what we are doing today.”

Plan Mode: “Think step by step. I need you to [task]. Show me your plan before you build anything.”

Approve or correct the plan: “Change step 3 to [adjustment]. Otherwise go ahead.”

Build: “Good. Build it.”

Thought partner check-in (use this any time, in any mode): “Am I thinking about this the right way? What would you approach differently?”

Mid-session context management when output starts softening: /compact — We are building [project name]. Completed today: [summary]. Current task: [next step]. Hold this thread.

Review: “Review what you just created against the output spec. What is missing or off?”

Security review (if you built anything connected to external services): /security-review

End of session: “Update README.md with what was completed today, decisions made, and next step. Date the entry.” “Update context.md if anything changed today.” “Update session-log.md with a one-paragraph entry for today’s session.”

Check /cost. Note what the session actually cost. It will probably be less than you expect.

Run this loop once. You will not go back to opening Claude Code and just typing.

What comes next

You just learned how Claude Code actually operates. Not just what to type, but how to run a session from the first directive to the final file update. Three modes. Four-part directives. Session commands. Context management with /compact. Security review. End-of-session file discipline. And the thought partner habit that is harder to teach but worth more than any command.

Most people who use Claude Code never figure out this layer. They get inconsistent output and assume the tool is unpredictable. The tool is not unpredictable. Sessions without structure are unpredictable. Now you have the structure.

In Post 4, I go deeper on context. How to build a standing briefing system that Claude can use across any project, any session, any task. The files you are creating now are the foundation. The system in Post 4 is what makes them permanent.

And in Post 7, I will show you how I store all of it in GitHub so nothing ever gets lost and every change is tracked. That is further down the road. For now, your project folder and your three Markdown files are all you need.

If you are finding this series useful, share it with another CMO who is still on the chat side of the line. The gap between where they are and where this series takes you is closing fast.

Interested in building these systems with hands-on guidance? I am running a founding cohort for a small group of senior marketing leaders who want to go from reading about this to actually doing it.

Reply to or comment on this post with your name and I’ll be in touch.

Kevin Kerner is CEO and CMO of Mighty & True, a B2B technology marketing agency in Austin that helps tech brands grow faster through modern strategies that use AI and automation to their advantage. He also hosts the Tech Marketing Rewired podcast.

This post is where we get our hands dirty. No more theory. Today you install Claude Code, get oriented inside it, and build your first real output. Thirty minutes. No engineering background. No help from IT.

You can do this. Let’s go.

Subscribe to get every post in this series delivered to your inbox: kevinkerner.substack.com

The Series: CMOs as Builders

1. Why CMOs Who Build Will Win -- The case for moving from AI user to AI builder, and why stepping out of the chat window changes everything.

2. Your First 30 Minutes with Claude Code (You are here) -- How to install Claude Code, get oriented, and build your first real output.

3. How to Give Claude Code Its Orders -- The difference between a prompt and a directive, and how to communicate so Claude builds what you actually want.

4. Stop Losing Your Work: Sessions and Context -- Why Claude forgets everything when you close a session, and the simple habits that make your work carry forward.

5. Skills, Efficiency and Model Switching -- Haiku, Sonnet, Opus: what each model is for, when to use which one, and how the wrong choice cost me $75 in a single session.

6. Beyond the Terminal: MCP, n8n, JSON and the Tools That Connect Everything -- The infrastructure layer that turns Claude from a smart assistant into the brain of an automated system.

7. From Terminal to Teammate -- How to bring your team into the systems you’ve built without losing control of what you’ve created.

8. The CLAUDE.md Blueprint -- The one document that ties everything together: your operating manual for building with AI at scale.

What you’re about to do -- open a terminal for the first time and build something real.

You’ve been using Claude.ai in a browser tab. It answers questions, helps you think, drafts things on demand. Every session starts from zero, every output disappears when you close the window, and nothing connects to anything else in your stack. Today that changes. Claude Code runs on your computer. It creates files. It builds things. And getting it running takes about 30 minutes.

By the end of this post you’ll:

• Have Claude Code installed and running inside Cursor, a purpose-built environment that gives you full visibility into what Claude is doing -- no technical background required.

• Understand what you’re looking at: the terminal, the file system, what Markdown files are, and how Claude Code actually works differently from Claude.ai.

• Know the billing mistake I made in my first week -- one wrong choice at setup that cost me $75 in a single afternoon.

• Have given Claude Code its first real instruction and watched it produce a file on your computer that wasn’t there 60 seconds earlier.

Why this matters for you as a CMO: Every system in this series starts here. Content workflows, research pipelines, competitive trackers, reporting tools -- all of it begins with this setup. Walking through it once makes everything that follows possible. You don’t need to hand this to IT. You can do it yourself in the time it takes to eat lunch.

Time to read: 20 minutes

What you need: A Mac or Windows computer. A Claude.ai Max subscription ($100/month). 30 minutes without interruption.

You can get by on a smaller Claude subscription (or use ChatGPT or Gemini), but you’ll want more. Don’t worry, you can get a full day’s work done on Max.

Also, don’t use Anthropic developer tokens in this building work. Use it in production… but not in building. Tokens are much more expensive. Lean into the subscription. You will pay less and won’t hit the cap very often.

Before we install anything

In Post 1, I drew a line between chat AI and building with AI. Here’s the practical version of that line.

Claude.ai in your browser is a conversation. You type, it responds, you copy the output somewhere useful. That’s the whole loop. When you close the tab, the conversation ends. Nothing was saved. Nothing was created. You start over next time.

Claude Code is different in ways that matter.

It runs on your computer, not in a browser. It creates real files in real folders on your hard drive. It can read documents you already have. It builds things that exist after you close the window. When you come back tomorrow, the work is still there.

The name throws people off. You do not need to write code to use it. I give instructions in plain English and Claude writes whatever code is needed to carry them out. My job is directing. Claude does the building.

Here is the clearest way I can draw the line.

Claude.ai is a conversation with a very capable person. Claude Code is that same person sitting at your desk with access to your computer, your files, and the ability to actually build things.

Same intelligence. Completely different capability.

That is what you are setting up today.

What you need before you start

A Mac or Windows computer. This guide uses Mac examples. Windows works nearly identically and I’ll flag the one spot where the commands differ.

A Claude.ai Max subscription. This is $100 per month. You can start on the $20 Pro plan but you will hit usage limits fast and it will kill your momentum. Think about it practically: if Claude Code saves you three hours a month, the subscription has already paid for itself. It will save you far more than three hours.

30 minutes without interruption. You do this once. You never have to do it again.

Step 1: Why Cursor, and how to get it running

Your Mac or Windows computer already has a terminal built in. On a Mac it’s called Terminal. On Windows it’s called Command Prompt. You could run Claude Code directly in either one. I don’t recommend it, especially when you’re starting out.

Here’s why.

The built-in terminal is a black window with a blinking cursor and nothing else. No file browser. No way to see what Claude is creating. No way to open and read the documents it builds. You type instructions and get text back, but you’re operating blind. You can’t see the folder you’re working in, you can’t preview files, and when something goes wrong -- and occasionally it will -- you have no visual context to help you figure out what happened.

Cursor fixes all of that. It’s a workspace designed for exactly this kind of work. You get a file browser on the left so you can see every file Claude creates the moment it creates it. You get an editor in the center so you can open and read those files immediately. You get a terminal at the bottom where Claude Code runs. Everything is visible at once. You’re not operating blind -- you’re watching the work happen in real time.

Cursor also has AI built directly into it. We’ll use that later in the series. For now, the reason you want it is simple: when you can see what you’re doing, you learn faster and make fewer mistakes.

One more thing. Cursor is free to start. You don’t need to pay for anything to follow this series.

To install Cursor:

1. Go to cursor.com

2. Click the Download button -- it will automatically detect your operating system

3. Open the downloaded file. On a Mac it will be a .dmg file -- double-click it and drag Cursor into your Applications folder. On Windows it will be an .exe -- double-click and follow the prompts

4. Open Cursor from your Applications folder (Mac) or Start menu (Windows)

When Cursor opens for the first time, it will ask if you want to import settings from VS Code or start fresh. Choose “Start Fresh.” It may also offer you a quick tour -- feel free to skip it. We’ll cover everything you need.

Opening the terminal inside Cursor:

This is the step that trips people up most. The terminal doesn’t open automatically. Here’s exactly where to find it.

Look at the top menu bar. Click “View.” In the dropdown menu, select “Terminal.” A panel will appear at the bottom of your screen. That panel is the terminal. That is where Claude Code will run.

Alternatively, press Control and the backtick key at the same time. The backtick is the key in the top-left corner of your keyboard, directly above Tab, to the left of the number 1. That keyboard shortcut opens and closes the terminal panel instantly.

You now have Cursor open, your terminal panel visible, and a working environment ready to go.

Step 2: Get oriented inside Cursor

Before you install anything, take 60 seconds to understand what you’re looking at. Cursor has four areas and you’ll use all of them.

The right sidebar is your file browser. All the files in your working folder appear here. Click any file to open it. Think of it as Finder, but inside your workspace. When Claude creates a file, you’ll see it appear here in real time.

The center panel is your editor. Files open here when you click them in the sidebar. This is where you read and review everything Claude builds.

The bottom panel is the terminal. This is where Claude Code runs. You opened it in the previous step. This is where you will type every instruction in this series.

The LEFT sidebar is Cursor’s built-in AI chat. This is not Claude Code. Do not confuse these two. The right sidebar is a quick chat interface that uses various AI models for questions and lookups. Claude Code runs in the terminal at the bottom. They are different tools with different purposes. Ignore the right sidebar for now.

Step 3: Create a home base folder

Before you install Claude Code, you need a folder for it to work inside.

This is the concept that trips people up most. Claude Code works with files that live on your actual computer, not in the cloud.

When you work in Google Docs, your documents live on Google’s servers. You access them through a browser. You don’t see them as files on your hard drive because they are not on your hard drive. Claude Code doesn’t work that way. It works with actual files in actual folders on your machine -- the kind that show up in Finder on a Mac or File Explorer on Windows.

Claude needs a home. A folder it works inside. Everything it creates, reads, and modifies lives there.

Here is what I recommend. Put that folder inside a cloud storage app you already use. Dropbox, Google Drive, iCloud Drive, or OneDrive all work. These apps create a folder on your computer that automatically syncs to the cloud. Your files live locally, which is what Claude needs. They’re also backed up automatically, which is what you need.

If you already have one of these desktop apps installed, you’re set. Open Finder or File Explorer, navigate into your Dropbox or Google Drive folder, and create a new subfolder. Name it something clear. “Claude Agent” works. “AI Work” works. Whatever you’ll actually remember.

If you don’t use any cloud storage desktop apps, create the folder anywhere on your computer. Just know those files won’t back up on their own. I call my file folder “automations” but you can name anything you like.

Now open that folder in Cursor:

Go back to Cursor. In the top menu, click “File” and then “Open Folder.” Navigate to the folder you just created and select it. That folder is now open in Cursor. You’ll see it appear in the left sidebar.

The mental model worth holding onto: Cursor is a window into a folder on your computer. Whatever is in that folder shows up in the sidebar. If Claude creates a file, you see it appear there in real time. If you add a file in Finder, it shows up in Cursor automatically. Same files, two different views of them.

Step 4: Install Claude Code

Now you install Claude Code itself. You’ll do this by typing a command into the terminal panel at the bottom of Cursor.

Click anywhere inside the terminal panel to make sure it’s active. You’ll see a blinking cursor waiting for input.

On a Mac, copy and paste this command exactly as written:

curl -fsSL https://claude.ai/install.sh | bash

Hit Enter. A stream of text will run down the screen. That’s the installer working. Don’t close the terminal. Wait until the text stops and a clean blinking cursor comes back.

On Windows, use this instead:

irm https://claude.ai/install.ps1 | iex

Same process. Paste it in, hit Enter, wait for it to finish.

When the installer finishes, confirm it worked by typing this:

claude --version

If you see a version number in response -- something like 1.0.23 -- Claude Code is installed and ready.

If you see an error message instead, close the terminal panel completely (there’s usually a trash can icon next to the terminal tab), open a new terminal panel using View and then Terminal, and try the version check again. That resolves it most of the time.

IMPORTANT - If for ANY REASON you have are having technical problems, start a chat in Claude and paste in what you are seeing.

You will need to build up the reflex to ask the LLM when you are stuck on pretty much anything. You can ask in Claude chat now (or any LLM chat), but in a few minutes you can ask Claude Code.

Step 5: The $75 mistake -- read this before you log in

This is the most important thing in this post. I’m putting it before the login step on purpose.

Claude Code can authenticate two completely different ways. If you don’t understand the difference before you log in, you can end up on the expensive path without knowing it.

Path one is your Claude.ai subscription. You’re paying $100 a month for Max. Claude Code can run entirely inside that subscription. Everything you do counts against your monthly usage allowance. Not against a separate running meter. More on that here.

Path two is the Anthropic API. The API is how developers build products on top of Claude. It bills by the token. Every word Claude reads or writes costs a small amount. There is no monthly cap. It runs like a taxi meter.

Here is what happened to me. I was building a messaging framework in my first week and using Claude’s extended thinking mode -- a deep reasoning feature I’ll cover in Post 5. I had set up an API key during installation instead of logging in with my subscription account. One afternoon session generated over $75 in charges before I noticed.

The work felt productive. The bill did not feel small.

When Claude Code first launches, it will ask how you want to authenticate. You will see two options. One is to log in with your Claude.ai account. The other is to enter an API key.

Log in with your Claude.ai account. Do not enter an API key.

API keys have legitimate uses and we’ll cover them in Post 5 when we get into model switching and cost controls. For your own personal use right now, your subscription is what you want. Make this choice correctly one time and you never have to think about it again.

Step 6: Start Claude Code and log in

In the terminal panel inside Cursor, type:

claude

Hit Enter.

Claude Code will launch and walk you through login. It will open a browser window where you confirm your Claude.ai account. After you confirm in the browser, come back to the terminal. You’ll see a confirmation that you’re logged in. Then the Claude Code interface appears, waiting for your first instruction.

One thing worth knowing before you move on. Claude Code does not start automatically every time you open Cursor. Each time you open a new terminal session, type claude to start it. It runs when you call it, not in the background.

Step 7: Two things that will save you confusion later

Before you type your first real instruction, two concepts worth understanding now. Both will come up constantly throughout this series.

Markdown files

As you use Claude Code, it will create files with a .md extension. These are Markdown files.

Markdown is a plain text format with simple symbols for structure. A # before a line makes it a heading. Putting ** around a word makes it bold. A - at the start of a line makes a bullet point. That covers most of what you’ll ever see.

Claude works in Markdown because it’s transparent. Word documents and Google Docs have invisible formatting underneath the text -- hidden codes controlling fonts, spacing, and layout. Claude can’t see those hidden layers. Markdown has no hidden layer. What you see is exactly what Claude sees. That makes it the cleanest format for AI work.

You don’t need to learn Markdown syntax. Cursor has a Preview mode that shows you the formatted version of any .md file. Headings look like headings. Bold looks bold. Lists look like lists.

To open Preview mode in Cursor, right-click any .md file in the left sidebar and select “Open Preview.”

Bash commands

When Claude Code does things on your computer -- creates a file, reads a document, reorganizes a folder -- it runs commands in the terminal. You’ll see lines appear that look like this:

ls "/Users/yourname/Documents/Claude Agent"
cat "/Users/yourname/Documents/Claude Agent/notes.md"
mv "/Users/yourname/Documents/Claude Agent/draft.md" "/Users/yourname/Documents/Claude Agent/final.md"

These are bash commands. Bash is the language your computer’s terminal speaks natively. ls lists the files in a folder. cat reads and prints the contents of a file. mv moves a file. cp copies one. Those four cover the vast majority of what you’ll ever see Claude run.

Claude shows you each command as it runs and explains what it’s doing. If you ever see something you don’t recognize, just ask:

What did that last command do and why?

It will explain in plain English every time.

One practical step worth doing right after you get Claude running. Claude Code will ask your permission before running certain commands. You can pre-approve the common safe ones so it doesn’t stop and check every time. After you start your first Claude Code session, paste this in:

Help me pre-allow these safe commands so you don't need 
to ask permission each time: ls, cd, mv, cp, cat, and open. 
Walk me through how to do this with /permissions.

Claude will handle the setup from there.

Step 8: Give it something real to do

You’re in. The > prompt is waiting.

Before you type anything, hold this line clearly in your head. It matters for everything in this series.

If you want to think something through, ask a question, or brainstorm an idea, use Claude.ai in your browser. That’s what it’s built for. Claude Code is for when you want to build something. A file. A template. A structured output that lives on your computer after you close the window.

That’s the distinction. Keep it close.

Now paste this into the terminal:

Create a Markdown file called "martech-eval.md" in my 
working folder. Build a structured evaluation framework 
for assessing a new marketing technology before approving 
budget. Include three sections: Strategic Fit, 
Implementation Reality, and Measuring ROI. Under each 
section, write five specific questions a CMO should be 
able to answer before signing off. Format it as a working 
document my team can actually fill out.

Hit Enter.

Claude will think for a moment. Then you’ll see it working -- creating the file, writing the content, confirming what it did. In about 20 seconds, martech-eval.md will appear in your file browser on the left side of Cursor.

Click it. Right-click and open Preview. Read what’s there.

That file did not exist two minutes ago. It’s on your computer right now. You can open it tomorrow. You can share it with your team. You can ask Claude to revise it in a future session. It’s not a chat response you have to copy somewhere. It’s a document.

That’s the moment things click for most people. Everything else in this series builds from exactly that.

10 prompts to try before Post 3

Spend 20 minutes here before you move on.

These are all builder prompts. Tasks that produce real files, folders, and structured outputs that live on your computer. Every one of them shows you something Claude Code does that Claude.ai simply cannot do.

Remember the line: questions and brainstorming belong in Claude.ai in your browser. Plan mode is great, but I’ve found that initial thoughts can happen just as well, or better in chat.

Building belongs here.

1. Build a reusable campaign debrief template

Create a Markdown file called "campaign-debrief-template.md" 
in my working folder. Build a post-campaign debrief template 
for a B2B tech marketing team. Include sections for: original 
goals vs. actual results, channel-level performance breakdown, 
what to repeat next time, what to stop doing, and a 
three-sentence summary written for a CEO who does not want 
details. Format it so my team can fill it out after every 
campaign without additional instruction.

The file lives in your folder. Your team can use it next week. It doesn’t disappear when you close a browser tab.

2. Drop in a real document and get a structured output

Find any PDF, Word doc, or text file on your computer. A recent agency brief, a competitor’s press release, a research report -- anything. Drag it directly into the terminal panel in Cursor. Then paste this:

Read the file I just dropped in. Create a new Markdown 
file called "doc-summary.md" with: a three-sentence 
plain-English summary, the five most important claims or 
data points, and three questions this document leaves 
unanswered that I should be thinking about.

You fed Claude a real file from your computer. It read the document and produced a structured output. That output is now saved.

3. Build a personal prompt library

Create a folder called "prompt-library" inside my working 
directory. Inside that folder, create five individual 
Markdown files -- one for each of these recurring tasks: 
analyst briefing prep, campaign brief, agency RFP scoring, 
board presentation narrative, and competitive positioning 
review. Each file should contain a reusable prompt template 
with clear placeholder brackets showing me where to fill 
in the specifics for each use.

Claude just built you a folder containing five working files. Open Finder. They’re all there.

4. Create a living competitive tracker

Create a Markdown file called "competitive-tracker.md" in 
my working folder. Build a structured template I can update 
monthly to track up to five competitors. Include fields for: 
current positioning statement, recent product announcements, 
pricing signals, dominant content themes, and one thing they 
are doing better than us right now. Add a "Last Updated" 
date field at the top.

A document you maintain over time. It lives in your folder, you update it monthly, and Claude can read and revise it in any future session.

5. Reorganize a messy folder

Find a folder on your computer with disorganized files. Downloaded PDFs, old documents, whatever you’ve got sitting around. List the file names, then paste this:

I have a folder with these files: [paste your list of 
file names here]. Propose a logical subfolder structure 
to organize them by type and purpose. Create the subfolders. 
Tell me which file belongs in each one. Then move them.

Claude is interacting with your actual file system. It’s not describing what you should do. It’s doing it.

6. Build a working agency scorecard

Create a Markdown file called "agency-scorecard.md" in my 
working folder. Build a scoring rubric for evaluating a 
marketing agency pitch. Include ten criteria relevant to 
B2B tech marketing, a 1 to 5 scale for each criterion with 
a one-sentence description of what each score level looks 
like, a weighted total calculation where strategic fit 
counts double everything else, and a notes field after 
each criterion. Format it so I can fill it out during 
a live pitch meeting.

A formatted working document ready to use at your next agency review. Not a description of what one could look like.

7. Turn raw meeting notes into a structured brief

After your next internal planning meeting, paste your raw notes directly into the Claude Code terminal. Messy is fine. Then paste this:

I am pasting in raw notes from a marketing planning meeting. 
Create a Markdown file called "meeting-output.md" with these 
four sections: a three-sentence summary of what was actually 
decided, a numbered list of action items with owner names 
where they were mentioned, a list of open questions that 
were raised but not resolved, and a suggested agenda for 
the follow-up meeting based on what is still open.

A formatted file you can share with your team the same day. Not a response you have to clean up and reformat yourself.

8. Build a weekly priorities system

Create two Markdown files in my working folder. First, 
a reusable template called "weekly-priorities-template.md" 
with fields for: three non-negotiable priorities for the 
week, one thing I have been avoiding that needs to happen 
anyway, the key meetings this week that require real 
preparation, and a definition of what winning looks like 
by Friday. Second, an active file called 
"week-of-feb-24.md" using that exact template, pre-filled 
with placeholder text that shows me how to use each field.

Two files created. A template and a working instance of it. A system you return to every Monday, not a one-time answer.

9. Read multiple files and synthesize across all of them

Drop two or three related documents into your Claude Agent folder. A campaign brief, a results report, an agency recap. Then paste this:

I have added three files to my working folder: 
[list the exact file names here]. Read all three. 
Create a new Markdown file called "campaign-synthesis.md" 
that identifies specifically where the original goals and 
actual results diverged, summarizes the explanation for 
the gap, and gives me three concrete things I should do 
differently when briefing the next campaign.

Claude read three separate real documents and synthesized across all of them. The output is grounded in your actual work, not a generic framework.

10. Scaffold an entire new project from scratch

I am starting an initiative to audit our marketing 
technology stack. Create a project folder called 
"martech-audit" inside my working directory. Inside it, 
create four subfolders: research, vendor-evaluations, 
stakeholder-interviews, and final-recommendation. In each 
subfolder, create a starter Markdown file that describes 
what belongs in that folder and provides a template for 
the first document I will need to produce there.

Open Finder when this finishes. Four subfolders exist. Eight files are in them. Claude built an entire project structure in under a minute.

Run two or three of these before you move to Post 3. Pay attention to what feels different from your Claude.ai experience. The files are real. They’re in your folder right now. They’ll be there when you open your computer tomorrow morning.

That persistence is the whole point. Once you feel it, you can’t unfeel it. Plus, these files will be come the working, persistent instructions for your apps and workflows as we get farther into this series.

What you’ve got set up

Take a moment here. This is further than most CMOs ever get. And you did it without asking anyone for help.

A working environment. Cursor is installed with your working folder open and connected to cloud storage. Files back up automatically. You can see everything Claude creates in real time.

Claude Code running cleanly. Authenticated with your Claude.ai subscription, not the API. No billing surprises. You know how to start a session by typing claude and you know it waits for you to call it.

Your first real output. A file that didn’t exist 30 minutes ago, sitting in a folder on your computer, built from a plain English instruction. No code written by you.

The foundation. You know what Markdown is and why Claude uses it. You know what bash commands are and how to read them. You understand the difference between Claude.ai and Claude Code, and why that difference is the entire premise of this series.

You haven’t written a single line of code. You’ve started acting like a builder.

What’s next

Post 3 -- How to Give Claude Code Its Orders

The difference between a weak Claude Code prompt and a strong one has nothing to do with vocabulary. It’s structure. When you’re asking Claude to build something real, there’s a specific way to frame the instruction that changes the quality of everything you get back. Post 3 covers role, context, constraints, and output format. Real examples from systems I use every day.

Post 4 -- Stop Losing Your Work: Sessions and Context

Claude Code has no memory between sessions. Every time you type claude and start fresh, it starts completely fresh. Post 4 covers how to manage that. Project files, context documents, and the methods I use to make sure Claude always knows what we’re building and where we left off. We’ll also plant the flag for GitHub -- a more durable way to protect your work that gets its full treatment in Post 7.

Post 5 -- Skills, Efficiency and Model Switching

The $75 billing lesson in full. When to use Haiku for bulk processing, Sonnet for most marketing work, and Opus for complex reasoning. When extended thinking mode is worth turning on and when it’s spending money for no reason. Cost controls that matter before you start building anything serious.

Post 6 -- Beyond the Terminal: MCP, n8n, JSON and the Tools That Connect Everything

Where Claude Code stops being a solo tool and starts connecting to your existing stack. Google Drive, Slack, your CRM, your publishing tools. This is where systems like LaunchPod and the LinkedIn Content Machine come from, and where the real operational leverage lives.

Post 7 -- From Terminal to Teammate

How to build systems that keep a human in the loop at every real decision point. How to work alongside others on what you’ve built. And a full introduction to GitHub -- not framed as a developer requirement but as the professional standard for protecting work that actually matters to your business.

Post 8 -- The CLAUDE.md Blueprint

The file that makes Claude work specifically for your business from the first line of every session. Your brand voice, your context, your systems -- all baked in before you type a single instruction. The thing that turns a capable general-purpose tool into something that genuinely knows who you are and what you’re building.

Every post builds on the one before it. Do the work in each one and by Post 8 you’ll have real infrastructure running. Not a proof of concept. Not a one-off experiment. Systems that save you meaningful time every single week.

Post 3 is next.

About the author

Kevin Kerner is the founder and CEO of Mighty & True, a B2B tech marketing agency based in Austin. He has spent 35+ years in technology marketing, leading teams, building agencies, and lately, building AI systems that run his business. He hosts the Tech Marketing Rewired podcast and writes about AI, marketing, and what’s actually working at the intersection of both.

He is not waiting for AI to get easier. He is building now. So can you.

Want the rest of the series?

All eight posts are coming. Each one builds on the last. By the end you’ll have gone from curious to actually building something real.

Subscribe at kevinkerner.substack.com and every post lands in your inbox the moment it drops. No algorithms. No feed. Just the guide, straight to you.

Most CMOs I know are smart, curious, and already using AI every day. But there’s a gap between using AI and building with it, and that gap is where your next real competitive advantage lives. This series is a step-by-step primer for technology CMOs who are ready to cross it. No computer science degree required. No prior coding experience assumed. Just a willingness to learn a new way of working that most of your peers haven’t found yet.

You can do this. Let’s go.

Subscribe to get every post in this series delivered to your inbox: kevinkerner.substack.com

The Series: CMOs as Builders

1. Why CMOs Who Build Will Win (You are here) The case for moving from AI user to AI builder, and why stepping out of the chat window changes everything.

2. Your First 10 Minutes with Claude Code How to open the terminal, run Claude Code for the first time, and understand what you’re actually looking at.

3. How to Give Claude Code Its Orders The difference between a prompt and a directive, and how to communicate with Claude Code so it builds what you actually want.

4. Stop Losing Your Work: Sessions and Context Why Claude forgets everything when you close a session, and the simple habits that make your work carry forward.

5. Skills, Efficiency and Model Switching Haiku, Sonnet, Opus: what each model is for, when to use which one, and how the wrong choice cost me $75 in a single session.

6. Beyond the Terminal: MCP, n8n, JSON and the Tools That Connect Everything The infrastructure layer that turns Claude from a smart assistant into the brain of an automated system.

7. From Terminal to Teammate How to bring your team into the systems you’ve built without losing control of what you’ve created.

8. The CLAUDE.md Blueprint The one document that ties everything together: your operating manual for building with AI at scale.

What you’re about to understand: why the gap between chatting with AI and building with it is bigger than you think, and why that gap is yours to close.

You’re already using AI. Probably every day. And if you’re honest, you’re pretty good at it. You know how to prompt. You get useful output. Maybe you’ve even built a GPT or a Gem for your team. That’s real progress. But there’s a whole other level underneath the chat window that most CMOs have never seen, and the people who find it are doing things that simply aren’t possible from a chat interface. Not harder things. Different things entirely.

By the end of this post you’ll:

• Know exactly what Claude Code can do that chat AI cannot. The difference is not incremental. It is categorical.

• Know why stepping out of the chat window makes you a better marketing leader. Not just a faster one.

• See what “building” actually looks like in practice. Real systems, real outputs, real time saved.

• Feel confident that this is something you can do. Because it is, and I’m going to show you how.

Why this matters for you as a CMO:

The leaders who understand what these tools actually do, not just what they can generate in a chat window, will make better decisions, push their teams further, and build advantages that compound over time. You don’t need to become a developer. You need to understand what’s possible. That alone puts you ahead of most people in your seat.

Time to read: 8 minutes

What you need: Nothing. This is the starting point.

Let me guess where you are right now

You use ChatGPT or Claude daily. You’ve gotten real value out of it. Meeting summaries, briefs, research, copy, evals. It’s made you faster and you know it.

But somewhere in the back of your mind, there’s a quiet doubt. You’ve heard about Claude Code. You’ve seen people talking about building things with AI, not just chatting with it. And part of you is curious. Part of you wonders if it’s real or just hype. And maybe, if you’re being completely honest, part of you thinks that stuff is for developers, not for you.

I’m here to tell you that last part is wrong. And this series is going to prove it.

I’m not a developer. I’m a marketer and a CEO. I built my career on messaging, positioning, demand generation, and leading marketing teams. I did not grow up writing code. And I am now building sophisticated automated systems that run my business. Systems that save real hours, eliminate real costs, and do things I genuinely could not do before.

If I can do it, you can do it. Full stop.

Why I’m the one writing this

I’m not a developer by trade. I know a bit of code and have built repos before, but I’ve never studied it formally. I started my career in tech marketing in 1990, back when marketing meant print ads and maybe emails. I spent the next 25 years doing what most of you have done: leading marketing teams, running agencies, building strategies, and managing the relentless pressure of doing more with less in B2B tech. I know a bit of code. Have built repos before. But really, I’m a noob.

In 2014 I founded Mighty & True, a B2B tech marketing agency based in Austin. I am the CEO and, functionally, the CMO. I run the strategy, the team, the client work, and increasingly, the systems that hold it all together. I also host Tech Marketing Rewired, a podcast where I talk to some of the best marketing leaders in B2B tech about what’s actually working right now.

About three years ago I started moving our business deeper into systems building, automation and now AI (after the great books eMyth and Traction). Not just using it in a chat window, but actually building with it. We built a platform called FlowOS that uses AI and automation to improve the work between our team and our customers.

All along, I taught myself. I made mistakes. Just this month, I ran up a $75 API bill in a single session because I had the wrong model selected. I built systems that didn’t work and rebuilt them until they did. And I came out the other side running a materially different business than the one I had before.

I’m building every day. LaunchPod, my podcast automation system. LinkedIn Content Machines. Solutions Messaging Strategy Automation. SEO, AEO and User Flow analysis. Dashboards for clients managing dozens of brands. Real systems, built by a marketer, running in production today.

I’m writing this series because I genuinely believe any CMO can do what I did. You don’t need a technical background. You need curiosity and a willingness to sit with something uncomfortable for a few hours. The payoff is real. I’ve lived it.

That’s why I’m the one writing this.

Chat AI is a conversation. Claude Code is a construction site.

Here’s the most important thing I can tell you in this first post.

When you use Claude.ai or ChatGPT in a browser, you are having a conversation. You type something, AI responds, you type something else. It’s powerful. It’s useful. And it has a ceiling.

“Chat AI is a conversation. Claude Code is a construction site. One has a ceiling. The other doesn’t.”

That ceiling is real. In a chat window, you can generate content. You can summarize documents. You can think through problems. What you cannot do is build something that runs on its own. You cannot connect your tools together and have them fire automatically. You cannot turn a flat document into a live application. You cannot create a workflow that wakes up every Monday morning, pulls data from three different sources, and delivers a finished report to your inbox before you’ve had your coffee.

For that, you need to step out of the chat window and into the terminal.

The terminal sounds scary. It isn’t. It’s just a different interface, a text-based window where you give your computer direct instructions. Claude Code runs there. And once you’re in it, a completely different class of work becomes possible.

Here’s the simplest way I can put it: the chat window is a conversation with a very smart person. Claude Code in the terminal is that same smart person sitting next to you at a workbench, with access to every tool in the shop, able to actually build things alongside you.

What becomes possible when you step out of the chat window

Let me be specific, because this is where it gets real.

You can connect your tools together. In a chat window, AI can talk to you. In the terminal with Claude Code, AI can talk to your other tools: your Google Drive, your CRM, your project management system, your publishing platforms. It can pull data from one place, process it, and push output somewhere else. Automatically.

You can build workflows that run without you. As mentioned above, I have a system called LaunchPod. When I finish recording a podcast episode, I drop the audio file into a Google Drive folder. That single action triggers a workflow that uploads to YouTube, publishes to Buzzsprout, builds a page in Webflow, generates eight pieces of content via Claude, and schedules everything to post across LinkedIn, X, and Substack through Late.dev. Start to finish, without me touching anything. I cancelled a part-time marketing hire because of it.

That is not possible from a chat window.

You can turn flat documents into applications. Raw survey data becomes a structured executive report. A spreadsheet of brand metrics becomes an interactive dashboard your whole leadership team can use. A list of customer support tickets becomes a synthesized voice-of-customer analysis with themes, quotes, and recommendations. These aren’t just better outputs. They’re different kinds of outputs entirely.

You can sequence and time things. Chat AI responds when you ask it something. Claude Code can be set to run on a schedule: every morning, every Monday, every time a file lands in a folder. Your reporting doesn’t have to wait for someone to remember to run it.

You can create shared infrastructure your whole team uses. This is one I don’t hear talked about enough. When you build in Claude Code, you create files that live in a project folder. Files your whole team can access, update, and build on top of. A CLAUDE.md file (we’ll cover this in depth in Post 8) is essentially an operating manual for how Claude should work within your organization. It’s persistent, collaborative, and updateable. A ChatGPT custom GPT or a Gemini Gem lives in a walled garden. Your team’s Claude Code project files live in infrastructure you own and control. That’s a meaningful difference for any CMO trying to systematize how their team works.

A word on the hype, and why this still matters

I know some of you are skeptical. And honestly, fair enough. There is a lot of hype around AI right now and not all of it is earned.

Here’s my honest take. Claude Code, and agentic AI building in general, is real and it works. I use it every day and it has materially changed how my business operates. Is it perfect? No. Is every use case worth the effort? No. Are there things that are harder than the demos make them look? Yes.

I also think we’re in an intermediary moment. The tools will keep evolving. At some point, the line between chat AI, coding AI, and agents will probably blur in ways that make some of this easier. But that future isn’t here yet. And waiting for it means falling behind the people who are learning now.

The CMOs who understand these tools today, who have actually sat in the terminal and built something, will be the ones who lead their teams most effectively when the next wave hits. You don’t have to build everything yourself. But you do have to understand what’s possible. That understanding is the advantage.

What this series is going to do

Over the next eight posts, I’m going to take you from curious and maybe a little skeptical, to someone who has actually built something. Not a toy. A real system that does real work.

Here’s the path:

• Post 2: Claude Code basics. What it is, how to open it, how to actually use it for the first time.

• Post 3: How to direct it well. The quality of what you build is directly tied to the quality of how you communicate what you want. We fix that early.

• Post 4: Sessions and memory. How to not lose your work when Claude forgets everything at the end of a session.

• Post 5: Model selection. Haiku, Sonnet, Opus: each one has a job. Using the wrong model at the wrong time costs real money. One session running the wrong model cost me $75.

• Post 6: The connectors. MCP, n8n, JSON: the infrastructure that makes your systems talk to each other.

• Post 7: Bringing your team in. How to hand off what you’ve built without losing control of it.

• Post 8: CLAUDE.md. The document that becomes the operating manual for everything you build.

By the end, you’ll have the foundation to build systems like LaunchPod. Systems that eliminate real labor costs, move faster than any team, and give you a compounding advantage that most of your competitors aren’t building yet.

You can do this

I want to close this first post with something direct.

The thing holding most CMOs back from this is not intelligence. It is not technical ability. It is the belief that this is someone else’s job, that building is for developers and your job is to direct the people who build.

That belief made sense three years ago. It does not make sense today.

The tools have changed. The barrier to entry has dropped dramatically. And the leaders who cross that barrier, who actually sit down, open the terminal, and build something, come out the other side with a clarity about what AI can do that you simply cannot get from reading about it or watching someone else do it.

You are curious enough to be reading this. That’s the only qualification you need.

Let’s go build something.

Next: Post 2: Your First 10 Minutes with Claude Code. We open the terminal, run the tool, and you see what it actually does.

About the author

Kevin Kerner is the founder and CEO of Mighty & True, a B2B tech marketing agency based in Austin. He has spent 35+ years in technology marketing, leading teams, building agencies, and lately, building AI systems that run his business. He hosts the Tech Marketing Rewired podcast and writes about AI, marketing, and what’s actually working at the intersection of both.

He is not waiting for AI to get easier. He is building now. So can you.

Want the rest of the series?

All eight posts are coming. Each one builds on the last. By the end you will have gone from curious to actually building something real.

Subscribe at kevinkerner.substack.com and every post lands in your inbox the moment it drops. No algorithms. No feed. Just the guide, straight to you.