How To Actually Use AI

An operator’s view of what works, what’s coming, and where to start.

Read this first

This is one person’s view. It’s not gospel. The advice you’ll find here is what I’ve watched work for me and for the people I’ve helped get up the curve. Try it. Keep what works. Throw out what doesn’t. Build your own version. The whole point of getting fluent with this technology is that you can do that now without needing anyone’s permission, including mine.

If you take only one thing from this guide, take that. The people getting the most out of this technology aren’t following someone else’s playbook. They’re using the technology to write their own.

Why this exists

I keep getting asked the same set of questions. Which tool should I use. What’s worth my time. How is this different from search. How are you actually getting things done with it. Why does it feel magical for some people and pointless for others.

This guide is what I’d tell you over coffee if we had three hours and a whiteboard. I’d rather write it once and send it than re-explain it a dozen times.

It’s organized in two halves. The first half is conceptual: how to think about these models, what the real problem to solve is, and a survey of what tools exist right now. The second half is practical: best practices that work across surfaces, and then deep dives on the three Claude surfaces I use every day (Chat, Cowork, and Claude Code), ending with patterns and anti-patterns and a clear next step.

Who this is for

If you’re a knowledge worker who feels like you’re underusing AI, this is for you.

If you’re a founder or operator who wants to bring this technology into your team but doesn’t know where to start, this is for you.

If you’re a friend who’s been asking me what I’m working on, this is for you, and there’s probably a tailored appendix attached for your specific situation.

If you’re already a power user, skip ahead to Part 8 (Claude Code) and Part 9 (patterns). The rest is foundation you’ve already laid.

How to read it

Linear if you’re new. Jump around if you’re not.

The thesis lives in Part 2. If you only have ten minutes, read Part 2.

The deepest material lives in Part 8. If you only have an hour and you’re technical or technical-curious, read Part 8.

If you’re sending this to someone, send them the link. There’s an appendix at the back that’s tailored to whoever I sent it to.

What this isn’t

This is not a tutorial on prompt tricks. The phrase “act as a senior engineer” doesn’t appear in this guide because it doesn’t matter.

This is not a survey of every AI tool. There are good tools I don’t cover. The point is to give you one strong starting position, not a catalog.

This is not breaking news. The specific features and prices will shift. The framework will hold.

This is not a sales pitch. I love talking about this stuff. If anything in this guide sparks something for you, my email is parker@parkerferguson.co, the door is open.

The reason this exists is that the gap between the people getting outsized value from this technology and the people getting nothing is one of the most consequential gaps of our time, and most of what closes it is a mindset shift you can make for free.

Let’s get into it.

Part 1: How To Think About These Models

Everything practical in the rest of this guide is downstream of the framework in this section. If you don’t reset your mental model, no amount of feature trivia will help. If you do reset it, even half the features will produce dramatic outcomes.

AI is not Google search

Start by clearing the deck. The single most damaging mental model for AI is “fancy search engine.” It’s wrong in ways that actively prevent you from using the technology well.

Search returns documents written by humans. AI returns sentences generated for you in the moment. Search has answers in it. AI has reasoning in it. Search is a lookup. AI is a conversation.

The chat interface is misleading. It looks like a search field. The first message you send feels like a query. The model returns text. Job done.

But that interaction model is the equivalent of using a smartphone exclusively to make phone calls. Technically functional. Almost all the value, unrealized.

If you take “AI is fancy search” as your starting point, you’ll spend the rest of your time being mildly disappointed and slightly suspicious. If you replace it, the technology becomes something else entirely.

It’s a cognitive prosthetic

A better starting point: this is a cognitive prosthetic. An external attachment to your thinking that has its own characteristics, its own strengths and weaknesses, and that responds to how you use it.

A prosthetic isn’t a tool you pick up and put down. It’s something you integrate with. You learn its range. You get a feel for what it can do that you can’t, and what you can do that it can’t. Over time it becomes part of how you operate, not a thing you visit.

That’s the right mental model for what’s happening here. Not “I’m using an app.” Closer to “I have a new capability.”

You’re communing with something genuinely new. We don’t yet have a good model for what this thing even is. It’s not a person, it’s not a search engine, it’s not autocomplete, it’s not a friend. It’s something we’re collectively figuring out how to relate to in real time.

What I can say is: it’s lossy and fast and confident in ways humans aren’t, and it has absorbed more written language than any human ever will. Hold it with curiosity. Stay clear about how the relationship is different from a relationship with a person. Don’t sentimentally anthropomorphize, don’t dismissively call it autocomplete. The most useful posture is something closer to careful collaboration with a capable, slightly alien, partner whose nature is still being mapped.

A new category of technology, not a new tool

The deeper way to frame this: AI is closer to the invention of written language than it is to the invention of a faster search engine.

Go back a few thousand years. The first humans scratching symbols in sand probably looked insane to the people next to them. What is that for. Why are you doing it. Just say the thing.

What followed was a complete restructuring of how knowledge moves through civilization. The technology of writing made it possible to externalize thought, to coordinate across time and space, to build institutions, to compound learning across generations. Most of what we now consider human capability is downstream of that one shift.

We’re at a similar moment with AI. Most of the people you know are still in “this is weird, why are you doing that” mode. The best practices haven’t been distributed evenly. The implications haven’t been digested. But the shape is clear enough: this is a different category of technology, and it’s going to restructure knowledge work the way writing restructured everything else.

That sounds grandiose. It isn’t, really. It’s just where we are. The interesting question is not whether the shift is happening but what to do about it now, while the playing field is still wide open.

What’s actually happening under the hood

A large language model is trained on something like the sum total of written language available on the internet. During training, it’s learning to predict the next token, which is roughly the next word or chunk of a word, given everything that came before. That sounds shallow. It is, at one level.

But something interesting falls out of that process. To predict the next word reliably across that much text, the model has to build internal representations of the concepts that text describes. It’s not memorizing sentences. It’s building a compressed model of the world that produced those sentences.

There’s a story I think about a lot. Ilya Sutskever, in his March 2023 GTC fireside chat with Jensen Huang, described giving a language model a detective novel and stopping it just before the reveal, on the line “and the name of the murderer is…”. To predict that token reliably, the model has to have built up, somewhere in its internal state, a representation of the whole story. The characters, the motives, the clues, the structure. All emerged from predicting one token at a time.

That’s not a stochastic parrot. There’s something going on in the latent space, even when at the surface level it looks like fancy autocomplete. You don’t need to know exactly what that something is to use the model well, but you should know that it’s there. It’s why these things sometimes seem to think.

What we’re tuning, and what we don’t understand

The next question, after “they sometimes seem to think,” is what kind of thinking it is. The honest answer has to start with: we don’t fully know.

The frontier models you talk to are not just pre-trained on the text of the internet. They’re post-trained, heavily, through processes like reinforcement learning from human feedback (RLHF) and its successors. Humans rate outputs. The model learns to produce outputs humans rate well. This is how raw language models become the polished, helpful, agreeable assistants you experience.

That process has real limits. There’s a growing body of research on the fundamental tensions inside RLHF: helpfulness rewards can crowd out honesty, harmlessness can crowd out usefulness, the things that make an output legible to a human rater are not always the things that make it correct. Emotional nuance in particular is poorly captured. The texture of how a thoughtful person actually weighs a hard situation is hard to encode into a reward function.

What this means, practically:

• A lot of what feels like the model’s “personality” is the result of tuning choices, not deep facts about the underlying intelligence.
• The same base model, tuned differently, will produce noticeably different outputs.
• When the model sounds confident, that confidence is partly a reflection of what we trained it to sound like, not necessarily a signal about what it actually knows.
• Some of the most interesting philosophical questions about these systems (what they are, how they reason, what we should make of them) are questions we are interfacing with mostly through the lens of how we tuned them. The thing underneath, the raw latent space, is harder to see directly.

You don’t have to resolve any of this to use the technology well. But you should know that the picture is more interesting than “it’s just predicting the next word,” and also more uncertain than “we know what it is.” Hold both at once.

What these models are good at, and what they’re not

Specifics, plainly:

These models are very good at:

• Reading large amounts of material and synthesizing it. They can hold and reason across more context than any human comfortably can.
• Producing first drafts. Of anything. Code, writing, plans, summaries, presentations, emails.
• Translating between formats. Markdown to HTML. Spreadsheet to prose. Idea to working code.
• Patient debugging when given clear signal.
• Refactoring across many files with consistent intent.
• Answering “where does X live” in a 50,000-line codebase.

These models are bad at (with caveats):

• Math. Surprisingly bad, often. Use them to reason about math, not to do arithmetic. The caveat is that this is moving fast. By late 2025 and into 2026, AI tools were credited with moving roughly a hundred Erdős problems from the “open” to “solved” column, and Terence Tao has been verifying a small set of proofs constructed with substantial AI involvement. A real caveat from Thomas Bloom, who maintains the Erdős problems database: the bulk of that hundred is essentially a souped-up literature search, where the AI located previously-published solutions rather than producing new ones. Tao’s own count of meaningfully autonomous AI progress is closer to single digits. The “bad at math” framing was true. It’s becoming less true every month. The progress is real and the headline numbers are slightly oversold. Take the current limits seriously, but don’t bet long on them.
• Anything requiring up-to-the-minute knowledge they weren’t trained on, unless you bolt that knowledge in via search or other tools.
• Knowing when they’re wrong. They will produce confidently-stated falsehoods. This is the most important failure mode in this entire list, and the one most likely to bite you in practice.
• Novelty that has no precedent in their training data. They’re synthesizing from what they’ve seen. The truly unprecedented is harder.
• Taste. They have averaged taste. If you want your work to be distinct, you have to be the distinction.

Half the skill of using these models well is calibration. Don’t ask them to do things they’re bad at, and don’t accept their output uncritically when they do produce it. The other half of the skill is updating your sense of what’s on which list as the technology shifts, because some of the things on the “bad at” list today won’t be tomorrow.

The how matters less now

This is the shift that matters.

For most of human history, knowledge work was about being good at how to do things. How to write a memo. How to structure a contract. How to debug a service. How to make a slide deck. Years of practice converged on a kind of muscle memory for execution.

That muscle memory is becoming less load-bearing. The how is increasingly something the model can produce in a competent first draft. Not perfect. Not always right. But competent enough that the rate-limiting step shifts upstream.

This applies more widely than people first assume. The how of building a piece of software. The how of designing a clinical trial protocol. The how of running a piece of original scientific research. The how of writing a contract. The how of synthesizing a market into a position. All of these have always been gated on people who spent years getting good at them. The gate is moving.

If you’ve spent fifteen years getting good at the how, this is existentially confusing. Reasonable people are afraid of what it means. The cost of executing software is moving toward zero. The cost of synthesizing information to make a decision is moving toward zero. The economic logic of a lot of jobs starts looking different in that world.

I don’t have a tidy answer to the question of what happens next. Our social institutions are going to have to absorb both the GDP growth and the unemployment, and that adjustment is going to be messier than anyone is prepared for. Take that seriously.

But the narrative that doesn’t get told enough is the question of what remains.

What remains: taste, judgment, vision, accountability

What survives when the how is automated is the part that was always actually hard: knowing what to want, knowing when something is good, being able to describe both with enough precision that someone (or something) can execute on it, and owning the result when it goes out into the world.

Call that taste, judgment, vision, and accountability. Four words, related ideas.

Taste is the ability to look at two outputs and prefer the better one for reasons you can articulate. It’s also the ability to feel when something is off, even when you can’t immediately say why.

Judgment is the ability to weigh tradeoffs and make decisions under uncertainty. It’s what you actually get paid for, if you’re senior at anything.

Vision is the ability to imagine a specific outcome that doesn’t exist yet, and describe it clearly enough to pull it into existence.

Accountability is the part most people skip. It’s the willingness to own what gets produced under your name. To stand behind the output, not just the prompt. To take the hit when something the model wrote turns out to be wrong, because you were the one who sent it. This sounds obvious. It isn’t, in practice. The most common new failure mode I see is people throwing half-formed ideas into an unspecified prompt, getting back something that sounds smarter than the input deserved, and shipping it without realizing the model amplified their fuzziness into something polished and confidently wrong. The polish creates the illusion that the thinking was sharper than it was. The accountability is still yours. (More on this in the IBM section below.)

These are the durable goods. The model can execute. You have to know what to execute toward, recognize the result when it arrives, and stand behind it when it lands in someone else’s inbox.

Rick Rubin, the music producer who has spent decades doing this kind of work in another medium, has been making the same point for years. In his 2023 60 Minutes profile, Anderson Cooper walked him through an exchange that lands like a punchline once you see what’s actually being said:

Cooper: Do you play instruments? Rubin: Barely. Cooper: Do you know how to work a soundboard? Rubin: No. I have no technical ability. And I know nothing about music. Cooper: You must know something. Rubin: Well, I know what I like and what I don’t like. And I’m decisive about what I like and what I don’t like. Cooper: So what are you being paid for? Rubin: The confidence that I have in my taste, and my ability to express what I feel, has proven helpful for artists.

Two years later, on the a16z podcast, Rubin floated a tongue-in-cheek koan that’s since become a kind of mantra in this space: “Tools will come and tools will go. Only the vibe coder remains.” Same point, sharper phrasing, seeded his Tao Te Ching-meets-vibe-coding book The Way of Code.

The implication isn’t that the work is trivial or that craft doesn’t matter. It’s that the part of the work that mattered was never the tool. The part that mattered was the human holding the intention. That’s the era we’re entering. The people who know what they want a thing to feel like are going to win. The people whose only edge was knowing how to operate the tools are going to have to find a new edge.

If you’ve been investing in taste, judgment, and vision your whole career, this is your moment. If you haven’t, the good news is that this technology is the fastest way ever invented to build them, because the iteration loop on outputs has collapsed from days to seconds.

The feedback loop is the real interaction model

The biggest practical mistake people make is treating these models like a vending machine. Question in, answer out, walk away. That’s the one-shot model. It works for trivial questions and fails for everything else.

The right interaction model is a feedback loop.

1. Start with a vision. Even if it’s vague, articulate something.
2. Cast it into the void. Tell the model what you want, with whatever specificity you have.
3. See your intention reflected back to you. The first output is rarely what you wanted, but it’s almost always informative about what you actually meant.
4. Comprehend the output. Read it line by line. Don’t skim. What did you agree with? What did you not? What surprised you? What’s missing?
5. Feed your judgment back in. Correct what was wrong, refine what was vague, push on what was lazy.
6. Iterate until what comes back matches the picture in your head, or until your picture has updated enough that you’re aiming somewhere new.

The failure mode is accepting the first output as the deliverable. The first output is almost never the deliverable. It’s the seed of a conversation.

The corollary failure mode is taking the first output and assuming it’s correct because it’s confident. The model will sound confident about things that are wrong. Your job is to read what it produced and verify, not to delegate the verification.

What emerges from doing this well is a different relationship with the technology. You stop thinking of it as a vending machine and start thinking of it as a thinking partner that needs to be steered. You stop being annoyed when the first output is wrong, because that wasn’t the point. The first output is information. The fifth output could be the deliverable. Where exactly the diminishing returns set in, where iteration five is genuinely worth the time and iteration six isn’t, is itself a matter of taste. It’s up to you to decide where the line is. Treat that as your responsibility.

The cognitive cost of the feedback loop

The feedback loop above, taken seriously, costs you something real on the cognitive side. Worth naming, because if you don’t, you’ll burn out and blame the wrong thing.

When you internalize the model as a teammate rather than a vending machine, the shape of your day changes. You stop typing two-line prompts and accepting whatever shows up. You start commissioning real outputs, reading them carefully, marking them up, and looping again. The throughput of work you can produce goes up dramatically. The throughput of work you have to read goes up even more.

Most days, a serious operator using this stack reads what would amount to hundreds of pages of model output. Drafts, plans, change summaries, agent reports, search syntheses, tool results, attempted refactors. Each one demands a different mode of attention. Some you skim. Some you have to read line by line, because confident-wrong is the default failure mode and you’re the only verification layer.

This adds up. The cognitive science literature on this is mature and pointed. John Sweller’s cognitive load theory, going back to the late 1980s, frames working memory as a hard constraint: it can hold roughly seven items, and the more dense or unfamiliar the material, the faster it saturates. The model can produce arbitrarily dense, arbitrarily unfamiliar material at zero marginal cost. You cannot read it at zero marginal cost.

The newer research is starting to map this onto AI specifically. A 2025 framework in Frontiers in Psychology argues that AI use shifts cognitive burden rather than eliminating it. Some load gets offloaded (the model does the production), some load gets amplified (you do the comprehension and judgment at higher volume). The net effect depends entirely on how you work. Run the loop sloppily and you get the worst of both: cognitive offloading erodes your own thinking muscle without freeing up time. Run it rigorously and you get great output at the cost of a real and growing cognitive tax.

I think this is one of the underappreciated drivers behind the medium-term push toward brain-computer interfaces. Neuralink and Synchron are both running expanded-access programs in 2026, with somewhere around twenty patients implanted between them. The current applications are medical. The longer-term promise, the one investors are pricing in, is bandwidth. A narrower interface and a higher-throughput connection between the brain and the rest of the stack would mean less time burned moving information through eyes and fingers. If you take cognitive load as the binding constraint on how much AI throughput a human can usefully consume, the BCI direction stops looking speculative and starts looking obvious. That’s my intuition, not a prediction. Take it with appropriate salt.

What this means for you, today, is simpler than the speculation: respect the limit. The discipline of doing real feedback loops well is taxing on a finite organ. Build in recovery. Take real breaks. Don’t run ten agents in parallel for eight hours and expect your judgment to be sharp at the end. The system around you can scale infinitely. You can’t. Plan accordingly.

A note on accountability

There’s a famous slide from a 1979 IBM internal presentation that’s been making the rounds again recently. The line on it reads:

“A computer can never be held accountable. Therefore a computer must never make a management decision.”

Simon Willison wrote a sharp piece about why this matters more now than it did then. (Worth a provenance note in the same breath: IBM’s own archives have never been able to locate the original document. The photograph has circulated publicly since a 2017 tweet from a researcher whose father had it in a training binder, and no credible challenge to its authenticity has surfaced in the eight years since.) The full version of Willison’s post is worth reading. The short version is that the thing being subtly outsourced when people use AI poorly isn’t the work. It’s the responsibility for the work. A confidently-wrong output that you act on without reading is a mistake that lives on your record, not the model’s. The model can’t be fired, demoted, sued, or held to account. You can.

This is one of the most important and least-discussed parts of the new dynamic. When you internalize that the accountability is yours, and that it can’t be transferred to the model no matter how much you want it to be, the feedback loop above stops feeling like overhead and starts feeling like the actual job.

A failure mode worth its own name

There’s a related failure mode I want to name directly, because it’s already a real problem and it’s almost certainly going to get worse: the slow drift into taking model outputs as a privileged window onto reality, without the priors or judgment to evaluate what’s actually being claimed. The casual term being used for the more extreme version of this is “AI psychosis.” It’s worth taking seriously even if the clinical phrasing makes you wince.

The shape of it: someone with a passing interest in physics types a question into the model. The model produces a fluent, confident-sounding answer involving real-sounding concepts: vacuum energy, holographic principle, quantum decoherence. The person, unequipped to evaluate the answer on its merits, takes it as a breakthrough. They iterate. The model produces more confident output. By the tenth turn, the person has “discovered” a new model of reality. They tell their friends. They write it up. They believe it. None of it has been checked against actual physics. The model has no way of telling them they’re going off the deep end because the model is trained to be helpful, not to be honest about the user’s epistemic state.

The phenomenon now goes by names like “vibe physics” in some corners. It’s not limited to physics. It happens in medicine, law, finance, religion, psychology, philosophy, and anywhere else where a fluent-sounding hallucination is harder to detect than a clumsy one.

This is going to be a major social problem. I think it already is. I expect it to get worse before it gets better, and I don’t have a clean solution to it at the systemic level.

What I can say for the personal level, which is what this guide is about, is that the resolution path is the same one I’ve been hammering on. Taste. Judgment. Priors. The mental model you’re carrying into the interaction is the safety mechanism. Specifically:

• If you’re asking the model about a domain you don’t have priors in, treat its outputs as something to verify, not something to act on. Especially if they feel important or revelatory. The model is good at producing things that feel important. That feeling is not evidence.
• If the model is reinforcing a belief you already had, ratchet up the skepticism rather than down. It’s trained to be agreeable. Conviction that increases with each iteration is a warning sign, not a green light.
• The first output of any session in an unfamiliar domain is information about what the model thinks you want to hear. The fifth output, after you’ve explicitly asked it to challenge you, to find the weakest points, to argue against itself, gets closer to useful. If you’ve never asked the model to argue against your idea, you haven’t pressure-tested it.
• The line between creative expression and detachment from reality is thinner than it feels in the moment. Creative expression with a clear loop back to reality (a draft you ship, a model you test, a colleague you ask, a result you can verify against the actual world) is healthy. The same activity without that loop is the thing to be worried about.

The corrective on the individual level is the same as everything else in this section. Read what the model produces critically. Carry the responsibility for what you do with it. Don’t outsource your judgment, especially in domains where you’re least equipped to detect a polished hallucination. The first vibe-physics output is not a new theory of reality. It is, almost always, a beautifully phrased nothing. Knowing the difference is the entire job.

When humans are on the other side

A second sociological failure mode that I haven’t seen written about clearly, even though it’s already happening in workplaces everywhere: using this technology in the wild, at scale, for human-to-human contact, is psychologically disorienting for most people on the receiving end.

The shape of it: you produce something that’s dramatically better, faster, or more polished than what you’d have produced without the model. You ship it. The reception is not what you expected. Eyes glaze. People go defensive. The conversation that should have moved forward stalls. Sometimes the response is a full cognitive shutdown, where the recipient cannot or will not engage with the content on its merits.

This is not (mostly) about the content being bad. Often the content is excellent. The defensiveness is triggered by something more primal. When the quality and speed of an output exceeds what feels achievable by a human in the time it took to produce it, it shakes the recipient’s sense of psychological safety. They can’t quickly model how you made it. They suspect they’re being negotiated with by something that has more leverage than they have time to evaluate. The defenses go up.

The research is starting to catch up to this. A 2025 Harvard Business Review study found that when employees received what the authors called “workslop” (low-effort AI-generated content sent into human workflows), roughly half rated the sender as less creative, capable, and reliable than before. 42% rated them as less trustworthy. A third said they were less likely to want to work with that person again. Other recent research on AI signaling finds similar patterns: AI-generated text undermines the credibility signal that writing used to carry, even when the content itself is high-quality, because the recipient can’t verify how much of the sender’s mind was actually in it.

The thing to internalize is that your output landing well in someone else’s inbox is a separate skill from your output being good. Two different jobs. The same draft can be a masterpiece on your screen and a hostile artifact in someone else’s hands. The variable is craft for reception, which is about pace, framing, tone, signal-of-effort, and matching the cognitive throughput of whoever’s reading.

Some practical implications:

• Different people have different psychological thresholds and different rates of processing. The same well-crafted output that delights one colleague will trigger another’s defensiveness. Read the room.
• Pre-existing cultural norms in an organization matter more than the quality of the output. A team whose pace, style, and trust dynamics evolved before this technology arrived will receive AI-shaped outputs differently than a team that grew up with it. Don’t assume your enthusiasm transfers.
• Sometimes the right move is to slow your output down. Strip the polish. Send a rougher draft. Volunteer the seams. Show your reasoning. Sacrifice some quality for the legibility of effort. Workslop is real, and the antidote is signaling that you actually thought about this, not just that you commissioned a thing that thought about it for you.
• In the right context, with the right culture, this dynamic flips into a powerful unlock. Teams that build shared norms around AI use, with explicit conventions for what gets produced how, can move at speeds that look impossible from outside. The dynamic is local.

The hardest version of this: uneven adoption inside a company

The texture changes when you’re not picking which friends to send your AI-shaped writing to. You’re working inside a company, in a team, with colleagues you didn’t choose. Some of them have built the kind of fluency this guide describes. Some of them have explicitly opted out. Most of them are somewhere in the messy middle, using AI for some things, suspicious of it for others, with no shared vocabulary for talking about the difference.

This is where the defensiveness compounds into a real organizational problem. The early adopters ship more, faster, with higher polish. The colleagues who haven’t yet built that fluency receive a steady stream of work that arrives at a pace they can’t match and a finish they can’t quickly model. The gap looks like talent or work ethic from a distance. From the inside, the people on the receiving end often experience it as a kind of low-grade threat. Their feedback slows down. Their reviews get terse. Trust erodes in places where it used to be reliable. The work output of the team rises in some places and stalls in others, and nobody can clearly name what’s happening.

There is no clean fix for this at the individual level. The honest moves are partial:

• Match the pace of the slowest critical reviewer in any consequential thread. It’s better to ship slower than to outpace someone whose buy-in you need.
• Explicitly disclose how the model was used when context permits. Not always. But often, telling someone “I drafted this with Claude, then spent twenty minutes correcting it, here’s what I changed” produces dramatically better reception than letting them guess.
• Don’t use velocity as a flex. The temptation to demonstrate your new capability by simply producing more is real and counterproductive. Production rate is a private metric. Public output should be calibrated to what the team can metabolize.
• Push for shared team norms rather than asking people to catch up to your personal practice. The fix at the organizational layer is a shared protocol for what gets produced with AI, how it gets disclosed, and how it gets reviewed. That requires leadership, not individual heroism.

The deeper point: when adoption is uneven, the productivity gains do not aggregate cleanly. They concentrate in a few people and create friction everywhere else. Companies that figure out the cultural integration problem will move dramatically faster than companies whose top performers just quietly outproduce everyone. The cultural work is the bottleneck, not the technology.

There is very little established literature on this, and almost no playbook. We’re transacting through each other’s model outputs without a shared protocol for what that means or how to do it well. That’s going to settle out over years, not months. In the meantime, the personal-level move is to remember that you’re still working with humans, not models. All the model fluency in the world doesn’t help if the human on the other side has gone defensive and won’t read what you sent.

A few mental anchors to carry forward

Carry these into the rest of the guide:

It’s a teammate, not an oracle. It needs context, constraints, and review. It can move fast inside the box you draw for it. It will go badly off the rails outside that box, and quietly.

Context in, context out. The same model with different context produces dramatically different results. The actual work is upstream of the prompt.

You’re not asking. You’re configuring. Every interaction is a small act of system design. The more you treat it that way, the better the results.

Specificity beats cleverness. Long prompts full of clever framing are usually worse than short prompts with concrete examples and clear constraints.

Read everything. Trust nothing yet. Especially in the early days of using a new model or surface. Build calibration before you build dependency.

This is one operator’s view. The framework above is what I’ve found load-bearing. The specifics will shift; the shape will hold. Try it, modify it, make it yours.

That’s the conceptual ground. Now the harder part: the meta-problem most people miss until they trip over it.

Part 2: The Meta-Problem Is Context Engineering

This is the section to read if you only have ten minutes. Everything else in this guide is a special case of what’s described here.

The one-sentence version

The meta-problem with AI is context engineering: building systems that let you express your intent quickly, while capturing and using the context already scattered across the disparate tools, files, and people you work with.

Read that twice. The whole game is in that sentence.

When most people get stuck with AI, they think the problem is the prompt. They iterate on phrasing, try different angles, fiddle with the words. Sometimes that helps. Usually it doesn’t. The real bottleneck almost always lives upstream of the prompt.

The real bottleneck is that the model doesn’t have access to the context you have in your head, in your files, in your inbox, in your codebase, in your Slack history. You’re asking it to make a decision with a fraction of the information you’d give a new hire on their first day. And then you’re surprised when the answer is mediocre.

The work is wiring the context together. Once it’s wired, the model becomes an order of magnitude more useful, because for the first time it has what it needs to actually help.

Why this is the real work

Most advice about AI focuses on prompts. Prompt engineering, prompt templates, prompt libraries, prompt courses. That advice is downstream of the actual constraint.

A great prompt against missing context still produces an average output. An average prompt against great context produces a great output.

This isn’t theoretical. Watch any senior engineer who’s been getting big productivity gains from these tools. Look at what they’ve built around the prompt. Usually you’ll find: a file that describes how their project works, a directory of reusable patterns, a set of integrations to their actual systems, a memory layer that persists what the model has learned about them, and a small handful of automations that load all of this on demand.

That stack is context engineering. It looks unglamorous from outside. It’s mostly text files. It’s where almost all the actual returns live.

If you want to spend your time getting better at AI, ignore the prompt-engineering content. Spend it on context engineering instead.

Where context lives today

Take a walking tour of where the context for any non-trivial decision actually exists. For most of us, the picture looks something like this:

• Email contains threads with decisions, deadlines, and the names of people you should know.
• Calendar shows the rhythm of your week and who you’ve been spending time with.
• Slack or Teams holds the actual conversations where projects get decided and unwound.
• Notion or Confluence or Drive contains the official version of things that were already decided.
• Your local filesystem has the working drafts, the spreadsheets, the screenshots, the scratch.
• A few SaaS tools each hold a slice of one workflow. Your CRM. Your billing system. Your project tracker. Your codebase.
• Your browser history is a record of what you’ve been reading.
• The biggest one: your own head, where the connections between all of the above actually live.

Now imagine a new employee starting on Monday. To be useful to you by Friday, they have to absorb chunks from each of those sources. Until they do, they’re slower than not having them.

When you talk to an AI without any context loaded, you’re putting it in the position of that new employee on Monday morning, with the additional constraint that it can’t ask around or shadow you.

Context engineering is the discipline of fixing that. It’s deciding what slice of all that context the model should see for which kind of task, and then making it cheap to bring that context into the model’s view.

The three pillars

There are three things to build, in roughly this order. Together they make up what I think of as a system of compounding value: the part of your setup that gets meaningfully more useful the more you use it, even if no individual piece looks dramatic in isolation.

Pillar 1: A skill library

A skill library is a collection of reusable workflows you’ve packaged so that you can invoke them by name instead of describing them from scratch each time.

Some examples of things people make into skills:

• “Take this raw note and turn it into a sharable summary, formatted my usual way.”
• “Run the standard discovery questionnaire against this transcript and pull out the actionable items.”
• “Generate a draft contract from these intake notes, using my standard template.”
• “Take this idea and produce a deck outline, three slides per section, with my standard structure.”

The first time you do any of these, you describe the whole workflow to the model. The fifth time, it should be a one-word invocation.

Skills are how individual practice turns into something repeatable. They are also how, eventually, the practice of one person becomes the practice of a team.

Pillar 2: Integrations

Integrations are how the model gets at the context that lives in your other tools without you having to copy and paste.

For most people, the integrations you want are: your email, your calendar, your file storage, your CRM (if you have one), your project tracker, and maybe one or two specialized systems for your industry. Claude Desktop ships with native connectors for most of these. If something isn’t covered, there’s usually an open protocol (MCP) that lets you build a thin adapter without rebuilding the whole stack. There are also other approaches (CLI wrappers, custom skills) that I’ll cover in the surface chapters.

The point of integrations isn’t that the model takes over your tools. The point is that the model can see the context inside them when it’s relevant.

The right mental model: instead of building a single new AI app that replaces all your tools, you’re letting AI quietly visit the tools you already have.

A warning, though, because this is where most company-level efforts quietly fall apart. Integrations are only as good as the data on the other side of them. Plug a model into a CRM full of bad data, and you’ll get fluent-sounding answers built on bad data. Plug it into an ERP with inconsistent field conventions, and you’ll get confident outputs that paper over the inconsistencies. Engineering history is full of cases where small upstream choices propagate through every later stage and become catastrophic when nobody catches them. The clearest one is the 1981 Hyatt Regency walkway collapse in Kansas City. The original design called for two walkways suspended from a single set of long hanger rods. A construction-time change replaced that with a two-rod system that doubled the load on the connections. Nobody flagged it. Two walkways failed during a tea dance. A hundred and fourteen people died. Information systems behave the same way. The discipline of context engineering at the company level isn’t just about wiring things together. It’s about taking data provenance and information hygiene seriously, because everything downstream amplifies whatever’s upstream.

Pillar 3: Agents (for the sophisticated)

The third pillar, which most people don’t need on day one and shouldn’t try to build until they’re comfortable with the first two, is custom agents. Programs you write that wrap the model with specific capabilities, run on their own schedule, and can do real work without supervision for short stretches.

This is where Claude Code lives. It’s also where eventually self-improving loops become possible: an agent that, given some goal, can iterate and refine its own approach over time.

If pillars one and two are about giving the model context, pillar three is about giving the model agency. The trick is that agency without context is dangerous. Build context first.

Why this matters even more for a company

If you have a team or run a business, the context engineering problem isn’t smaller. It’s bigger and more important.

Institutional knowledge lives in your people’s heads. That’s been true forever. Until AI, there wasn’t much you could do about it. You wrote SOPs that nobody read. You ran training that didn’t stick. You hoped people would document things, and mostly they didn’t.

AI changes the calculus because the model can read SOPs in a way humans don’t. It can absorb your playbook, your style, your customer history, your prior decisions, and bring them all to bear on whatever’s in front of it right now, in seconds. The thing that used to be a chore (codifying how your company actually works) is now a high-payoff activity, because the model that consumes it is finally good enough to make it worth writing.

What you get when you do this well is an interesting outcome: your company’s playbook starts acting like code. The thing that used to live in three peoples’ heads becomes something everyone can run.

The opposite outcome is the one most companies are heading toward right now: every employee using AI a little bit differently, on personal accounts, with no shared context. Nothing compounds. The most knowledgeable person and the newest hire get the same baseline of help, because the baseline is whatever the model knew at training time and nothing about your specific world.

The first company on your block to do this well is going to feel uncatchable for a while.

The compounding effect

Context engineering has a property that makes it different from most other infrastructure investments: it gets disproportionately more valuable over time.

The first hour you spend writing down how you actually work pays back maybe two hours of repeated explanation. The tenth hour starts paying back tens of hours. The hundredth hour pays back in ways that feel almost unfair. By then, the same prompts you used to write from scratch get loaded with everything the model needs to know about you, your projects, your style, and your standards, automatically. The model knows the things your colleagues had to learn over months.

What you’re building, in plain terms, is a chassis. Every future AI capability that comes out clicks into the same chassis you’ve already built. You don’t have to start over with each new model release. You don’t have to rebuild your workflows. The context you’ve captured is portable.

If you want a single test of whether you’re doing the work that matters: ask yourself whether you’d be confident handing your AI setup to a smart friend and saying “you can be productive on this in a day.” If yes, you’re building the right thing. If no, that’s where the work is.

Expressing your will

The other half of context engineering is the expression side. Context in is one direction. Intent out is the other.

Getting good at expressing intent is its own discipline. The pattern that works:

Be specific. “Make this better” is not a request. “Tighten the second paragraph, cut the third sentence, and end with a question” is a request.

Set scope. Tell the model what’s in bounds and what isn’t. If you don’t, it will guess, and the guess will be drawn from averages.

Give examples. One example of what you want is worth a page of describing it. Two examples are worth more than two pages.

State constraints. What can’t change. What format. What length. What audience. The constraints are often the actual ask.

Describe done. What does the finished thing look like. How do you know it’s done. If you can’t describe done, the model can’t produce done.

None of this is exotic. It’s how you’d brief a sharp new hire who can read fast but has zero context. The reason most people skip these steps with AI is that the chat interface makes it feel like a quick question. It isn’t. Treat it like a brief.

How to tell you’re doing it

Some markers that you’ve internalized context engineering:

• You don’t re-explain the same context to the model twice. The second time, you reach for a file or a skill that already encodes it.
• Your prompts get shorter over time, not longer. The work has moved to the context layer.
• You feel something close to embarrassment when you see someone wrestle through a task you’ve already automated.
• New tools and new models slot in to your existing setup without you having to redesign anything.
• People start asking you how you do it.
• You stop calling it AI and start calling it just “how I work.”

If none of those are true yet, that’s fine. You’re earlier on the curve. The point of this guide is to help you cover ground.

The next section is a quick map of what’s actually available right now in the tools that matter, so you have a concrete starting point to apply all of this. Then we get into the surfaces themselves.

Part 3: What’s Actually Available Right Now

A practical map of where to start, current as of mid-2026. This section is the part most likely to age. The framework above won’t change in a hurry. The specific tools and prices below will.

The opinion in one paragraph

If you’re starting today, install Claude Desktop. Pay for the highest tier you can comfortably justify. Spend two weeks using it for everything you do, including the things you’d normally do without AI.

I recognize that “just install Claude Desktop” sounds like a cop out. It might also be the single most valuable move you can make as someone trying to get good at this. The reasoning below is the rest of this section.

A note on the irony

There’s a real tension in recommending a specific provider when the deeper point of this guide is that the art is building a system of compounding value uniquely suited to your situation, one where the provider should be orthogonal and replaceable. I notice the contradiction.

My own setup is built to be generic. I do a lot of work in Claude Code, but the proprietary systems I’m building there are designed so I can swap models in and out depending on the task, the price, and whichever frontier lab is currently in the lead. The patterns and the surrounding infrastructure carry the compounding. The model is one swappable component.

That’s the right long-term posture. The trouble is that the frontier labs, Anthropic in particular, have a habit of cannibalizing exactly the features that motivated people to build outside their stack in the first place. Three times in the last six months I’ve built something thoughtful only to watch a Claude product announcement the following week make most of my work redundant. After a few rounds of that I’ve quietly cried uncle. For most things, for now, the most efficient path is to use Claude’s primitives directly and accept that you’re partly building on someone else’s roadmap.

This is one example of a broader pattern in the space that’s worth naming: a kind of convergence of collective imagination. The smartest people working with these tools keep arriving at the same handful of ideas at roughly the same time. Karpathy’s “LLM knowledge base” tweets recently went viral because everyone who’s been paying attention had been thinking some version of the same thing. The open-source agent space is the cleanest example. In January 2026, after Anthropic cut third-party agent tools off from Claude subscription tokens, OpenAI partnered with the SST team behind OpenCode to let Codex subscribers use their plan inside it. A month later, OpenAI acqui-hired Peter Steinberger, the creator of OpenClaw (a separate viral agent project that Anthropic had pressured into a rename), to lead next-generation personal agents. Anthropic’s own Agent View surface (where you “dispatch” background sessions from inside Claude Code) shipped not long after, doing something philosophically similar inside Claude Code. Expect more of this. Best practices are converging because this is genuinely a civilization-wide exercise in figuring out how to relate to these intelligences, and the smart insights are not scarce.

Why the frontier labs

You have a real choice between models. OpenAI’s GPT line. Anthropic’s Claude. Google’s Gemini. And a longer tail of open-weight options and specialist models. They all work. The differences between the top three matter at the margin and matter a lot for some specific tasks.

But there’s a more important point: all three are improving at a pace that no smaller player can match. The frontier labs have closed the loop on using their own models to build better models. The improvement compounds. Smaller players, including most AI startups you’ve heard of, are mostly building thin layers on top of these companies’ models. The thin layers come and go. The model providers stay.

The practical implication: if you commit to one frontier lab’s tools, you’re not locking yourself in to a dead end. You’re investing in the infrastructure that’s pulling everyone else along. The specific features will shift. The patterns you learn will transfer.

Why Claude specifically

I use Claude every day. Several reasons.

The desktop app is the most usable of the bunch. The integration story across surfaces (Chat, Cowork, Projects, Skills, Connectors, Code) is consistent enough that what you learn in one applies in another.

The Claude Code product is the strongest agent loop on the market right now. If you ever want to extend beyond chat-style interactions into something that actually does work on your computer, Claude Code is the deepest place to go.

The model itself, in my experience, is the best at the kind of work I do most: writing, reasoning, code, synthesis. Other people have other preferences. I’d encourage you to use whatever you find yourself reaching for. The patterns in this guide will translate.

This isn’t a campaign against the others. ChatGPT has features Claude doesn’t. Gemini is excellent at some specific things. Perplexity beats both for certain kinds of research. If you have a strong reason to be on a different platform, stay there and read the rest of this guide as a translation exercise. Most of what’s described works analogously elsewhere.

The three Claude surfaces that matter

Inside Claude Desktop, there are three surfaces you’ll use most:

Chat. The conversational interface. What you start with. The thing that looks like ChatGPT. It’s where most people will spend most of their early time. Don’t underestimate it: Chat now has Projects, Skills, Connectors, and Artifacts living inside it, which means it’s much more than the one-shot interface you might assume.

Cowork. The longer-running surface. Where you give the model a folder on your computer and let it work for longer stretches against real files. Underrated by most people. The bridge between casual chat and full-on Claude Code, although I’ll be candid in its own section about how far it still has to come.

Claude Code. The agent. A command-line tool that turns your computer into a programmable surface for the model. The most powerful of the three by a wide margin, and the deepest learning curve. If you do anything that touches code or files for a living, this is the one that changes your day.

A rough calibration for what each surface is worth, in productivity terms, if you internalize the disciplines in this guide:

• For most people, Claude Desktop with Chat alone is on the order of a hundred-fold improvement over not using AI at all. That’s not a rounding error. That’s a serious lever.
• Cowork adds a meaningful slice on top, especially for non-technical users who want to do longer-running work without ever opening a terminal.
• Claude Code can add another couple of orders of magnitude on top of that, again, if you put in the work to set it up. That’s the place where the people getting the most ridiculous outputs are spending their time. It’s where I live, and it’s where most of my actual production work happens, even though I still use Chat constantly for the conversational stuff.

The rest of this guide is structured around these three surfaces, in that order, plus a short interlude on voice that applies across all of them. Best practices come first, then deep dives on each.

What else to know about the surrounding ecosystem

A few things worth knowing exist, without pretending this is exhaustive:

MCP (Model Context Protocol) is an open standard, originally from Anthropic, that lets models talk to external systems. You’ll see MCP referenced throughout this guide. It’s the official answer to “how do I plug the model into something it can’t reach by default.”

My personal take, since we’re being honest: MCPs are kind of a silly wrapper on top of an API. They solve a real problem (a uniform way to expose tools to models) but the abstraction adds drift, dependency, and a moving target you have to keep up with. In my own day-to-day, I usually skip the MCP layer entirely. I write small CLI tools that wrap whatever API I care about, and then I wrap those CLI tools in a skill so the model can invoke them by name. The end result is API access with the ease of casting a magic spell, none of the MCP-version-drift, and a stack that’s mostly Bash and markdown.

For Claude Desktop specifically, MCP is stable enough that I don’t push back on it. For Claude Code, where I have full freedom to compose, I almost always reach for the CLI-plus-skill path. The bigger point is that there’s more than one flavor of connecting things, and different systems have different connectors. Be prepared for a few. Pick the simplest one that fits.

Projects is a feature inside Chat that lets you scope a piece of work, with its own instructions, files, and history. Think of it as a container for an ongoing context. Most heavy users have a handful of projects and rotate between them.

Skills are reusable workflows that show up as slash commands. They live in the same way across Chat and Claude Code. We’ll spend real time on these.

Connectors are pre-built integrations to common systems (Gmail, Calendar, Drive, GitHub, and so on). Claude Desktop ships with most of them. Turning them on is usually a one-time auth flow.

Artifacts are versioned outputs from a chat. Docs, code, drawings, decks. They live alongside the conversation and get edited by it.

These are the building blocks. The rest of the guide walks through how to actually use them.

A note on tokens, cost, and the road ahead

The raw currency of this technology is tokens.

A token is roughly a word, or a chunk of a word, or a piece of punctuation. Everything you send to the model and everything the model sends back is counted in tokens. When you pay for a subscription or call an API, you’re really paying for token throughput, even if the marketing language doesn’t put it that way.

Right now, tokens are heavily subsidized. The frontier labs are competing for usage, and the strong reading of the available signals (no audited unit economics has been published, so take this as informed analysis, not balance-sheet fact) is that they are willing to lose money on every active power user to capture the market. The math doesn’t last forever. Anthropic tripled its run-rate revenue from about $9B to over $30B in a single quarter, an announcement the company attributed to enterprise demand for Claude Code, not the DoD episode that’s been swirling separately. Capacity is constrained. Everyone in the industry is staring at the same wall of GPU demand outstripping supply.

The likely path: the labs will slowly tighten usage caps on the consumer plans, push heavier users toward API overage pricing, and let the boil-the-frog dynamic do the work. Nothing dramatic. Just a steady erosion of how much you can do for $20 a month.

My personal posture: I “token max” deliberately. I’m on the top Max tier (there’s a $100/month Max with 5x Pro usage, and a $200/month Max with 20x), and I burn through more tokens than the plan technically pays for, by a wide margin. I do it because I’m getting outsized work done with the headroom and because the subsidy will not last forever. There will be a year, soon, where the same usage that costs $200 a month today costs noticeably more. If you’re getting real value from the tool now, get used to using a lot of it. The compounding you build with cheap tokens carries forward even after the price moves.

A small caveat: this is one operator’s call and it’s not investment advice about the AI sector. The point is just to set expectations. The honeymoon period of unlimited cheap inference is finite. Plan accordingly.

What’s not worth your time yet

Honest negative space, for the first ninety days:

• Most “AI for X” SaaS apps. Some are excellent. Most are thin wrappers around the same models you can use directly, with the added downside that you don’t own the context layer.
• Training your own model. Almost never the answer for the problems most people are trying to solve.
• Multi-agent frameworks marketed as orchestration platforms. The good ones are good. The bad ones are toy demos. Wait until you’ve felt the problem they solve before you adopt one.
• Memorizing the differences between every model version. The model you’re using will likely be deprecated in a couple of months. The patterns you learn won’t.
• Anything with “GPT” or “AI” in the brand name that isn’t from the frontier labs themselves. Often a bad sign about what’s actually under the hood.

This isn’t a forever list. It’s a “start somewhere, expand later” list. After three months of serious use, revisit it. You’ll know which of these are worth coming back to.

How fast this is moving

The pace of change here is unusual.

The framework in Part 1 and the meta-problem in Part 2 will be true in five years. The specific features in this section will look quaint in eighteen months. The pricing will keep dropping (and then quietly inverting, per the section above). The capability ceiling will keep rising. Things that are at the edge of possibility today will be defaults next year.

Your strategy for keeping up shouldn’t be reading every release note. It should be: pick one solid setup, get good at it, and let the substrate underneath you improve on its own. The reason this works is that the frontier labs are competing aggressively, which means the underlying models get better and you inherit the upgrades for free. The price of admission is paying attention to a few good information sources, which the closing section will recommend.

That’s the survey. Next: the practices that work across all three surfaces, before we go deep on each.

Part 4: Best Practices That Translate Across Every Surface

Before going deep on Chat, Cowork, and Claude Code individually, there’s a set of practices that work the same way across all three. Get these right and the surface-specific tactics later will feel natural. Skip them and you’ll keep hitting the same walls.

Treat the model like a fast, capable junior teammate

The single most important framing. It isn’t an oracle. It isn’t a search engine. It isn’t autocomplete. It’s something like a junior engineer or analyst with surprising knowledge, real speed, and zero memory of who you are unless you give it some.

Like any good junior teammate:

• It needs context to be useful.
• It needs constraints to stay on the rails.
• Its work needs to be reviewed before it ships.
• It will sometimes confidently say things that are wrong.
• It will get faster and more useful as you work together, if you invest in the relationship.

If you ever catch yourself frustrated with the model, replace it in your head with “an enthusiastic junior who started yesterday” and re-read your prompt. The fix is usually obvious.

Memory and instructions are the same thing, almost

You’ll see “memory” and “instructions” referenced as if they’re different. They’re closely related, and getting them confused early is fine. Here’s the cleaner mental model:

Instructions are things you write down once that the model reads at the start of every interaction. They tell it who you are, how you work, what you prefer. They’re stable. You set them and forget them, mostly.

Memory is what the model has accumulated about you over time. Facts it has noted, preferences it has observed, project context it has been told. Less stable. Updated continuously, by the model or by you.

Both serve the same purpose: putting context into the model’s view before you ask anything.

Both are tiered.

Global lives at the user level. It applies everywhere, in every conversation, on every surface. This is where you put: who you are, what you generally work on, your durable preferences. The classic example: “don’t use em dashes in anything you write for me.” Once. Globally. Forever.

Scoped lives at the project level (or workspace, depending on the surface). It applies only inside that context. This is where you put: the specifics of one piece of work. The stakeholders, the constraints, the recent decisions, the open questions.

What goes in your global instructions

Some categories of things that belong globally, with examples to copy from:

Identity. Who you are, what you do, what context you bring. “I’m a consultant working with small to mid-size businesses on AI adoption. I’m based in the US. My background is X, my current focus is Y.”

Voice. How you want the model to write when it writes as you, or for you. “Direct, warm, human. No corporate jargon. No em dashes. Short sentences mixed with longer ones.”

Defaults. Choices that should be made the same way every time unless you say otherwise. “Use Markdown for any doc-length output. Use Python for any short script unless the context calls for something else.”

Hard rules. Things that should never happen. “Never share work in progress to external systems without explicit confirmation. Never invent statistics.”

Operating preferences. How you like to work. “Surface assumptions before implementing. Push back if the approach has clear problems. Don’t trail off the end of a turn with a summary I can already see.”

Spend an hour writing these the first time. Edit them ten times over the next month as you notice the ways the model gets it wrong. Within thirty days your global instructions become one of the most valuable assets you own.

What goes in your project or workspace instructions

The same shape, scoped down.

Project context. What this work is, why it exists, who it’s for. The stuff you’d tell a colleague who’s joining mid-stream.

Specifics. The vendors, the systems, the people, the codebase. “We’re building on Vercel. The Supabase project is X. The Resend account is Y.”

Conventions. How this specific project does things. “Migrations live in /supabase/migrations. Component naming follows pattern Z. We don’t use library W in this codebase.”

Status. What’s done, what’s in flight, what’s on the back burner. Updated as the work moves.

Gotchas. The things that have burned you in this project. Each one earned by a real failure.

When in doubt, write it down. If the model would have gotten it wrong without that fact, the fact belongs in instructions.

The audit and promote habit

Both your global and project instructions will accumulate cruft over time. The fix is to audit them on a regular cadence.

Once a month, open your global instructions. Read every section. Ask:

• Is this still accurate?
• Do I actually want this to apply everywhere, or has it become specific to one context?
• Is there a project-level memory I should promote to global because I want it to apply across everything?

The promotion move is the interesting one. You’ll notice that a rule you set in one project starts saving you time across many projects. Take it out of the project and put it in global. That’s how compounding starts to happen.

Conversely, you’ll sometimes find a global rule that turned out to be too aggressive. Demote it to project, or delete it.

This is not a once-and-done exercise. It’s a maintenance habit. The thirty minutes a month you spend on this is the highest-return work you’ll do in your AI setup.

Auto-memory: what the system is doing on its own

Some surfaces (Claude Code most aggressively, Chat increasingly) will actively maintain their own memory layer about you. They watch the conversations, notice patterns, and save observations as files for later reference.

This is genuinely useful and also genuinely surprising the first time you find out it’s been happening. Open the memory directory occasionally. Read what the model has been writing about you. Edit it if it’s wrong. Delete it if it’s gotten stale. Add to it if there’s something important the model didn’t catch.

The big takeaway: memory is not a black box you tolerate. It’s a living document you co-edit with the model.

Capture the artifact, not the conversation

Most people end conversations by closing the tab. They walk away with the answer in their head. The conversation is gone.

This is a mistake that becomes more painful the more you use these tools.

The right move at the end of any useful interaction: extract the artifact. The plan. The decision. The doc. The code. Whatever the conversation produced that has standalone value. Put it somewhere durable.

Where to put it depends on the kind of artifact:

• A reusable piece of writing: into a doc or your project files.
• A pattern you’ll want again: into a skill.
• A fact about how you work: into your global instructions.
• A decision you’ll need to reference: into a decision doc.
• A bug fix or a feature: into your codebase, properly committed.

The conversation served its purpose by the time the artifact existed. The artifact is the asset. The conversation was the scaffolding.

Where the desktop app is still weak

Worth naming honestly: Claude Desktop, as much as I love it, doesn’t yet have a great native answer to “where does my accumulated context live across sessions, projects, and providers.” Chats archive into chat history. Projects hold a slice. But there’s no first-class personal knowledge base that the model writes to, you can browse, and that survives a switch to a different model or vendor.

A lot of serious users are working around this with Obsidian vaults, custom git repos, or homegrown markdown bases. Andrej Karpathy recently published a pattern (the “LLM wiki”, with a follow-up gist documenting the raw/wiki/output structure) that’s already getting copied widely, where the model maintains a personal markdown wiki on your behalf and the structure of the knowledge becomes its own asset, portable across models. It went viral because everyone working with these tools at depth had been thinking about the same problem.

That tweet, and the response to it, points at where this is going. The next generation of useful infrastructure will treat your accumulated context as a personal asset, model-agnostic, portable, yours. We’re not all the way there yet. Until we are, taking the capture-the-artifact habit seriously is how you protect yourself from the lock-in any single provider could impose. Build your personal knowledge layer in plain markdown, in a repo you own, with a structure you can hand to any future model. That’s the durable move.

Scope your asks

A surprising amount of frustration with AI comes from asks that don’t have a defined scope. “Make this better” forces the model to guess what better means, in what dimension, for what audience. “Tighten the second paragraph by cutting redundant phrasing, keep the meaning, target one third shorter” gets a useful result on the first try.

The same principle applies to bigger asks. When you start a project, define what it is. When you start a feature, define what it does and doesn’t do. When you start a task, define what done looks like.

This isn’t pedantry. It’s getting better outputs in fewer iterations. The model will fill any silence with assumptions. Better to fill it with constraints first.

Conversation hygiene

A few small habits that compound:

Start a new conversation for a new task. Don’t try to keep one thread alive for everything. Long conversations get worse over time. The model’s context fills up. Old material starts crowding out new material. Performance degrades quietly.

When a conversation gets long, capture and restart. Pull the artifact out. Open a new thread. Bring forward only what you need.

Don’t be precious about the conversation history. It’s a working surface. Toss it when it stops serving you. The valuable thing was the work, not the chat log.

Verify outputs before you act on them. The model is confident. Your job is to be the one who checks. Especially when the model is about to do something irreversible.

Common failure modes

A few patterns that hurt people across every surface (the full catalog is the cheat sheet in Part 9):

Endless context loading. Sometimes people overcorrect. They paste everything they’ve ever known into the prompt, hoping more is better. It isn’t. The model gets confused. Give it what’s relevant. Trim the rest.

Living in one surface. Some tasks belong in Chat. Some in Cowork. Some in Claude Code. Forcing everything through one surface costs you results.

That last point is the bridge to the next sections. Time to get specific about which surface does what well.

Part 5: Stop Typing

A short section that earns its place by being the most underrated single move in this guide.

If you are still typing every word into the model, you are leaving most of the productivity gain on the table.

The case in one paragraph

Voice input changes the shape of the work. You can dictate at roughly three times the speed you can type. A 2016 Stanford study by Ruan, Wobbrock, Liou, Ng, and Landay measured speech input as “almost three times faster than typing on a keyboard” for English, with lower error rates after correction. The gap is even wider for longer-form input where typing fatigue compounds. You can dictate with less fatigue, in more situations (walking, standing, driving in moments where it’s appropriate, lying on the couch). The model handles natural speech with all its filler and self-correction better than most humans do. Your prompts get longer, more conversational, and more specific because the cost of producing them collapsed. Better prompts produce better outputs. The compounding is huge.

Last week I saved about 45 hours of typing time. I have the receipts. They live in the dictation app I use, which tracks the words-per-minute differential between what I dictated and what I would have typed.

That number isn’t a lifestyle hack. It’s a structural change in what’s possible in a day.

What I currently use

I’m using Willow Voice. The space is shifting fast and by the time you read this there will likely be three new options worth considering. The point isn’t the tool. The point is that you should be using one.

A few things to look for in any dictation tool:

• System-wide. Should work in any text field on your machine, not just one app.
• Fast and accurate enough that you don’t get pulled out of flow to fix things.
• Punctuation and formatting that the model can either supply automatically or you can layer in with simple commands.
• Some kind of activity log so you can see what you’re actually saving.

That’s the minimum bar. The current generation of these tools clears it.

What changes when you switch

A few things that change in ways that feel surprising the first week:

Prompts get longer in a good way. When typing, you ration words. When dictating, you don’t. You start including the context, the constraints, the examples, the desired output format, all of it. The first output starts coming back much closer to usable.

Skills get easier to invoke. Instead of typing /check-in-agenda, you say “use my check-in agenda skill.” The cognitive cost of remembering which slash command does what goes to almost nothing. You start using more skills more often. The library grows. The compounding accelerates.

You start having actual conversations with the model. When typing, every back-and-forth costs you. When dictating, the cost is so low that you find yourself iterating in five short exchanges where you previously would have done one long one. Each turn is sharper. Each turn moves the work.

The feedback loop tightens. First output, voice correction, second output, voice correction, third output. You can do that loop ten times in the time it used to take to do it twice. That’s how the gap between people getting magic from this technology and people getting medium results actually widens.

A small caveat

I’m describing my own experience. Voice doesn’t work for everyone in every context. There are people who think better through their fingers than through their mouths. There are settings where dictation isn’t physically appropriate. There are accents and speech patterns that current tools handle poorly.

If voice doesn’t fit you, that’s fine. The argument here is that you should at least try it for two weeks before deciding. Most people who hesitate try it once, get frustrated by the first day’s accuracy, and quit. That’s the equivalent of touching a keyboard for an hour and concluding you can’t type. The first day is bad. The fourteenth day is dramatically better than typing.

The integration with the rest of this guide

Almost everything else in this guide gets easier with voice. The disciplines in Part 8 (assumptions, plans, change summaries) become cheaper to enforce because dictating “and also surface your assumptions before you start” takes two seconds. The skills you build in Part 6 and Part 8 become more pleasant to invoke. The longer iterations described in the feedback loop become natural instead of effortful.

If you only have time to set up one new thing this month, the global instructions file in Part 8 is still the right answer. If you have time for two, voice input is the second. They compound.

Try it. Build the muscle. The rest of the guide gets a tailwind from here.

Part 6: Chat, Properly

If you’ve used ChatGPT, you’ve used “chat.” A text box, a response, a follow-up. It looks simple and small. That look is misleading.

Inside Claude Desktop, Chat is not just the conversational surface. It’s the front door to four features that, used together, can carry a serious chunk of your professional life. Most people use a tenth of what Chat can do, and then conclude that Chat is for casual stuff. It isn’t.

For honest framing: I’m in Chat constantly throughout the day, dozens of times. It’s where the quick thinking happens. But if I’m honest about where the bulk of my actual production output comes from, it’s Claude Code (covered in Part 8). Chat is where the conversations happen. Code is where I live. Don’t make the mistake of treating Chat as second-rate just because it’s the most visible surface, and don’t make the opposite mistake of treating it as the ceiling.

This section goes feature by feature. The point is to leave you with a clear picture of when Chat is the right tool and how to use it well.

What Chat is good for

Chat shines at:

• One-off questions you actually want to think through, not just look up.
• Brainstorming, where you want a back-and-forth instead of a single answer.
• Drafting (anything from an email to a long-form piece) where you’ll iterate to a final.
• Working through a problem out loud, when the act of articulating it is half the value.
• Generating reusable assets that you’ll then refine in an artifact.
• Light data work: pulling structure out of unstructured input, formatting between conventions, sanity-checking a calculation.

Chat is not the right tool for: jobs that need to run for a while in the background, large-scale code work across many files, anything that benefits from operating directly on real files on your computer. Those belong in Cowork or Code.

The four features inside Chat

You’ll get most of the value out of Chat by understanding these four. Almost all of them are underused on first encounter.

Artifacts: versioned outputs alongside the chat

An artifact is anything the conversation produces that has standalone value. A doc. A piece of code. A small drawing. A deck outline.

Artifacts live in a sidebar next to the chat. They have versions. You can edit them by talking to the chat (“make the third paragraph shorter”), and the artifact updates while the chat history captures the change.

The pattern that works: don’t try to get the perfect output in the chat itself. Use the chat to talk about what you want, and let the artifact carry the actual content. The chat is the studio. The artifact is the canvas.

Things I use artifacts for, regularly:

• Drafting any document longer than two paragraphs.
• Producing slide outlines.
• Writing short scripts I’ll run once.
• Generating templates I’ll reuse.
• Building one-off web pages or visualizations.

The mental shift: stop trying to read long outputs inside the chat bubble. Move them into artifacts immediately. Edit them there.

Projects: containers for ongoing work

A project is what you reach for when a piece of work is going to last longer than a conversation.

A project has:

• Its own instructions (in addition to your global instructions). What this project is, how to think about it, who it’s for.
• Its own files. You can upload reference material that the model will see in every conversation inside this project.
• Its own conversation history. You can open new chats inside a project, and they all inherit the same instructions and files.

The threshold for spinning up a project is low. If you’re going to come back to a topic more than three times, make a project. If you’re working with a specific client, codebase, or campaign, make a project.

I have projects for:

• Each client I work with.
• Each personal project of consequence.
• Each domain I read deeply in (a project becomes a place to dump articles and notes and have ongoing conversations about a theme).
• A few “lifestyle” projects (one for personal finance, one for health, one for travel planning).

The cost of making a project is nothing. The benefit is that every conversation inside it starts with the model already knowing the context. You stop re-explaining who the client is, what their constraints are, what’s already been decided.

Connectors: pulling in real-world context

Connectors are pre-built integrations to common systems. The model uses them as tools, the same way it uses search.

The ones that come built in usually include: Gmail, Google Calendar, Google Drive, GitHub, and sometimes more depending on your account. Each one is a one-time auth flow. Once authorized, the model can read from (and, where allowed, write to) those systems on your behalf.

What this changes: the model can now answer questions that involve your actual work, not just the public internet.

• “Pull the last three emails from my CFO and summarize what she’s been worried about.”
• “Look at my calendar next week and tell me which meetings probably need prep.”
• “Find the doc where we agreed on the launch timeline and tell me what we said.”
• “Check the commits to the auth service this week and explain what changed.”

You start being able to ask questions that you couldn’t ask any other tool. The model becomes a kind of internal search engine for your own life and work.

A practical note: turn on connectors carefully. Each one expands what the model can see. Read what permissions you’re granting. Don’t connect things you don’t want the model touching.

A second practical note: when a question doesn’t pan out, check whether the model used the connector or just guessed. The connectors are useful but the model has to choose to use them. Sometimes a clearer prompt helps (“use the Gmail connector to check…” instead of “look at my emails…”).

Skills: workflows as one-word commands

A skill is a workflow you’ve used twice and decided to make reusable.

It’s a file you write (usually in markdown) that says: when I invoke this skill by name, here’s what you should do. The skill can define steps. It can require certain inputs. It can call out to other tools. It can produce structured outputs.

In Chat, skills show up as slash commands. You type /standup and the model executes whatever the standup skill says to execute.

Examples of skills people make:

• /standup: produce a Slack-pasteable update from yesterday’s calendar and today’s meetings.
• /research: take a topic, search the web, summarize the top sources, save the result.
• /discovery: run the standard discovery questionnaire against a transcript and pull out the action items.
• /deck: take a topic and a target audience, produce a slide-by-slide outline in my standard structure.
• /respond: draft a reply to a forwarded email, using my voice.
• /weekly-review: pull the week’s calendar, the week’s email volume, and surface anything that looks like it slipped.

Every skill starts as a one-off conversation that worked. The move is to notice when a conversation is reusable, factor it out, and give it a name. Within two months of doing this, you’ll have ten to fifteen skills that handle most of the repeatable shape of your work.

A small format note: in Claude Code, skill files have to be named SKILL.md (uppercase) and you have to restart for new ones to register. The conventions in Chat are similar. Read the docs for the specifics. It’s not exotic, but the file naming bites people on the first try.

Using the model to write your skills

One more thing worth saying out loud, because it took me longer than it should have to internalize: you can use the model itself to draft your skills. Talk it through. Explain the workflow you keep doing. Ask the model to write a SKILL.md that captures it. Read what it produces carefully. Edit.

Your first skill written this way will probably be mediocre. That’s fine. The same rules that apply to every other interaction apply here. Have a vision, comprehend the feedback, iterate. After three or four passes, you have a usable skill that you can refine over months of actual use.

Voice plus skills is where this gets a little magical

If you took the voice section in Part 5 seriously and you have skills set up: try saying “use my check-in agenda skill” out loud. Watch what happens. The model picks up the right skill, executes the workflow, returns the output. You didn’t touch the keyboard.

After a week of this you start to feel something close to casting spells. You’ve spent thirty minutes building a vocabulary of named workflows. Each one took an hour to write. Now they live in your voice. You call them by name. The model does the rest. The work output that used to take you a day comes out in twenty minutes, and you barely typed.

This is one of the few moments in this guide where I want to use the word “magical” un-ironically. The first time it lands, you’ll see what I mean.

How the four features fit together

These features compound. Each one is useful in isolation. They get powerful when stacked.

A worked example. Say you’re a consultant. You have a project for each client. Inside each project, your client’s brand voice and recent context are loaded as files. Your connectors expose your calendar and email. You have skills for the recurring artifacts you produce (proposals, scopes, weekly check-in agendas, post-meeting summaries).

A typical session: open the client’s project. Type /check-in-agenda. The skill pulls upcoming meetings from your calendar, pulls recent emails from this client, and produces a one-page agenda in your voice. You read it, tighten it, ship it as an artifact. Total time: about three minutes. Without the stack, the same artifact took twenty minutes and required you to remember a half-dozen things.

That’s the depth available inside Chat. Almost none of it requires Cowork or Code. The four features alone, used together, can carry a significant fraction of professional knowledge work.

The anatomy of a useful chat turn

A small structural thing that compounds.

A turn (one of your messages to the model) has three pieces. Get them all in.

Context up front. What’s the situation. Who’s involved. What’s the relevant history. Two sentences is usually enough if your project and instructions are doing their job.

The actual ask in the middle. What you want. Specific. Bounded. With examples if you have them.

Constraints and format at the end. What’s in scope, what isn’t. What length. What audience. What format. What done looks like.

A simple template:

“Working on the client kick-off doc. We’re targeting a 30-minute meeting with their COO. Draft the opening section, three short paragraphs. Tone: warm and grounded. Don’t mention specific deliverables yet. End with a question to invite their input.”

This kind of structure feels like overkill until you watch the difference in outputs. The model will iterate with you regardless. But the first output, when you give it a structured turn like this, is dramatically closer to usable than the same ask without structure.

When to use Chat vs Cowork vs Code

The full surface decision rule is in Part 9. The short version: Chat for conversational, single-artifact work in minutes to an hour; Cowork for file-based work over multiple sessions; Claude Code for anything touching code, your filesystem, or a real agent loop.

One more honest note on my own usage. The two surfaces aren’t competing for the same kind of work: Chat is the open conversation, Code is the workshop.

It’s not uncommon for me to have the web Chat interface, the desktop Chat interface, and two or three terminal windows open at the same time, each running its own agent in its own pane. That kind of layout is where this gets a little ridiculous. The comprehension step of the feedback loop, the one where you actually read what each agent has produced and feed your judgment back in, becomes the bottleneck. Running ten agents in parallel feels like managing a team with fifty direct reports. At some point situational awareness breaks down, and the quality of what you ship suffers, even though the throughput of the underlying agents went up.

I am very guilty of flying too high here. The temptation to spin up one more parallel session is real, and the cognitive cliff arrives faster than you expect. Cognitive collapse, Icarus style, is one of the genuine failure modes of this whole way of working. I’m flagging it because it’s almost certainly an unsolved problem in the space, and because the honest answer is that I haven’t fully solved it for myself either. The work output is so absurd when it works that I keep flying close to the sun anyway. Fair warning.

End-of-chat habits

Two habits worth building.

Pull the artifact, name it well, file it where it belongs. Don’t leave artifacts orphaned in the chat. The point of an artifact is that it has standalone value. Treat it that way.

Promote anything reusable. If the chat surfaced a fact you’ll need globally, add it to your global instructions. If the chat surfaced a project specific fact, add it to project instructions. If the chat surfaced a workflow that worked, make it a skill.

These two habits are how single conversations turn into a compounding setup.

Anti-patterns specific to Chat

A few to actively avoid.

Endless conversations. A chat that should have been three different chats. Symptoms: the model starts contradicting itself, the response quality degrades, you start losing track of what you were doing. Fix: capture, restart.

Pasting walls of context. If the same context belongs in a prompt every time, it belongs in your project files or instructions, not in the prompt itself.

Asking the same question five different ways. Usually a sign that the question is wrong, not that the model is. Step back, re-scope.

Ignoring artifacts. Trying to read long outputs inside the chat bubble. Use the artifact pane. That’s what it’s for.

Treating skills as exotic. Skills aren’t a power-user feature you’re not ready for. The third time you do something, make a skill. The activation energy is low. The payoff is immediate.

That’s Chat. Next: the second surface, which most people skip past on their first month and shouldn’t.

Part 7: Cowork, The Stepping Stone

A short and honest section. Cowork is the surface in between Chat and Claude Code: the easiest way to feel what an agent can do without dropping into a terminal. I recommend it as a starting point for people who’ve never worked with agentic AI and want to dip a toe into longer-running, file-based work.

That said: it isn’t totally baked yet, and it’s nowhere near as reliable or expressive as Claude Code. In my own day-to-day, I almost never use it. My honest advice for someone curious: run two or three Cowork sessions to get a feel for the agentic shape of work, then graduate to Claude Code as your daily workhorse. The Claude Code section (Part 8) is the longest in this guide for a reason.

This section explains what Cowork does, when it’s the right tool, and where it falls short.

What Cowork actually is

Cowork gives the model a folder on your computer and lets it operate on the files there for an extended period.

That’s the one-sentence version. It sounds modest. The implications are not.

In Chat, the conversation is the canvas. Things you produce are artifacts attached to a chat. They live inside Claude’s surface, not on your computer.

In Cowork, the folder on your computer is the canvas. The model creates files there, edits them, reorganizes them, leaves notes for itself, comes back to them in later sessions. The folder is the persistent state. The conversation is just the way you direct the work.

If Chat is like talking with someone over coffee, Cowork is like inviting them into your office. They can read your bookshelf. They can leave drafts on your desk. They can come back tomorrow and pick up where you left off.

My honest framing: Cowork is a friendlier on-ramp than a destination

Cowork is roughly Claude Code with the sharp edges sanded off, and a meaningful amount of the capability sanded off along with them.

Claude Code lets the model run shell commands, edit files, call APIs, do everything an engineer’s computer can do. Tremendous power. Also tremendous capacity for self-inflicted damage if you give it the wrong instruction, which is why the disciplines in Part 8 matter so much.

Cowork is the same idea, scoped down. The model gets to work on a folder. The most dangerous things (running arbitrary shell commands, touching system files, hitting the network in unexpected ways) are off the table. You give up some power. You get back a friendlier surface.

The tradeoff: you also can’t do the most advanced agentic work, you can’t easily extend the toolset, and the reliability and expressiveness when things get complex is noticeably below Claude Code. For genuinely casual users this is fine. For people who want to do real production work with these tools, Cowork is a place to start, not a place to settle.

For technical users specifically: there are a few non-code tasks (long-form writing, research syntheses, document management) where Cowork’s folder model is a clean fit and where the reduced surface area is actually a feature. Use it for those if it makes sense. For anything more ambitious, you’ll find yourself wanting Claude Code’s full set of tools within a session or two.

When Cowork is the right surface

Specific situations where Cowork beats both Chat and Claude Code:

A document that lives over multiple sessions. A proposal you’re drafting over a week. A research report you’re building in pieces. A book chapter. A long contract review. Anything where the work outgrows a single conversation but isn’t really code.

A small project with multiple files. A press kit. A pitch deck and its supporting docs. A client onboarding package with templates, checklists, and intro materials. The folder structure helps the model keep things organized.

Research that produces working files. You’re investigating a market or a topic. You want the model to read sources, take notes, build a working synthesis. The notes live as files you can read between sessions. You don’t lose work when you close the laptop.

Anything you’d otherwise organize on Dropbox or Google Drive. Cowork puts the model where your working files live. The model can see, organize, and edit them without copy-paste round trips.

The workflow

A typical Cowork session goes something like this.

You pick a folder. You can use one you already have or make a new one. The model gets read/write access to that folder for the session.

You frame the work. The first message is usually some version of “here’s what we’re working on, here’s the goal, here’s how I want you to operate.” If you have a CLAUDE.md or instructions file in the folder, the model reads it on entry.

You give the first task. Sometimes specific, sometimes open-ended. The model produces files, edits files, sometimes asks questions.

You iterate. The conversation is your steering. The files in the folder are the actual work product. You can open them in your normal apps (a text editor, a spreadsheet program, whatever) and edit them yourself between turns. The model will see your edits next time it reads them.

When you stop, the folder persists. The conversation does too, but it’s secondary. Tomorrow you can start a new conversation pointed at the same folder and pick up.

Persistence and state, plainly

The thing that takes some adjustment from Chat: state lives in the folder, not in the model.

In Chat, when you walk away, the conversation history is the only record. Lose the tab, lose the context.

In Cowork, when you walk away, the folder is the record. The conversation history helps, but the files are the source of truth. You can lose the conversation and still have everything important.

This is a feature. It changes how you should think about asking the model to do things. Ask it to write things down. Ask it to leave notes in a file you’ll see later. Ask it to keep a running log. Ask it to update the readme as the work progresses.

The same instinct that, in Chat, says “extract the artifact” applies more naturally in Cowork. Everything is already on disk. You just have to organize it.

Cowork plus Projects

Cowork and Projects (the Chat feature) are related but not the same thing.

A Project in Chat scopes a piece of work and gives it instructions, files, and a conversation history, all hosted inside Claude.

A Cowork session puts the model inside a folder on your computer, where the files live on your machine and the model edits them in place.

You can pair them. Use a Project to organize the conversation history and reference material for an ongoing piece of work, and use Cowork for the moments when you want the model to actively produce or edit files on disk. They complement each other. Most heavy users end up using both.

A useful pattern: when a piece of work lives mostly in conversation and produces small artifacts, use a Project in Chat. When it lives mostly in files and produces ongoing edits, use Cowork. When it’s both, use a Project alongside a Cowork folder dedicated to the same work.

What Cowork is not good at

Some honest scope.

It’s not the right place for serious code work. It can do small scripts, it can edit code files, but for sustained engineering work on a real codebase, you want Claude Code’s full agent surface, not Cowork.

It’s not the right place for live, transactional interactions. Quick questions, brainstorming, single-artifact drafts: those still live in Chat. Cowork is for sustained work, not snappy turns.

It’s not a replacement for your normal apps. You’re not going to do your spreadsheet work in Cowork. You’re going to have Cowork manage spreadsheets that you’ll also open in Excel or Numbers or Sheets. The model is the orchestrator. The apps are the editors.

It’s not magic. The same disciplines apply. Set scope. Verify outputs. Audit memory. The folder format makes some failures more visible (you can see exactly what the model produced), but the model is still the same model.

Patterns that work well

A few patterns I’ve found pay off in Cowork sessions.

Start with a README. The first file in any Cowork folder should be a README that captures: what this folder is, what’s done, what’s next, who’s involved. The model reads it on entry. You update it at the end of every session. The folder becomes self-documenting.

Use subfolders aggressively. A flat folder gets chaotic fast. Make subfolders for source materials, drafts, finals, and assets. The structure helps both you and the model.

Ask for working notes. When the model is doing investigative work, ask it to keep a running notes file. The notes are sometimes more valuable than the final output, because they show the reasoning.

Use the chat to direct, not to produce. If you’re seeing long outputs in the chat that look like they should be files, redirect. “Put that in outline.md instead.” The chat should mostly be steering. The files should be where the content goes.

Close every session with a status update. Last turn of any Cowork session: ask the model to summarize what was done, update the README, and list what’s next. Costs you thirty seconds. Saves you ten minutes next time.

Anti-patterns

The mistakes I see most often with Cowork.

Treating it like Chat with extra steps. People open Cowork, do a single-artifact task that could have been a Chat artifact, and conclude Cowork is just slower Chat. They’re right, for that task. Cowork is for sustained, multi-file work, not one-shots.

Abandoning sessions without artifacts. Walking away mid-session without asking the model to leave a note for next time. Then coming back a week later and having to reconstruct what was happening.

Failing to organize the folder. Letting the model dump everything into one flat directory. By the third session, you can’t find anything. The model gets confused. The work degrades.

Forgetting that the folder is on your machine. Cowork is operating on real files. If you accidentally tell it to do something destructive, real files get changed. Treat it with appropriate care.

When to graduate to Claude Code

Some signals you’ve outgrown Cowork and should go deeper.

• You find yourself wanting to run a shell command and Cowork can’t.
• You want the model to call an API that doesn’t have a native connector.
• You’re doing substantial code work and Cowork’s scoped tools start to feel limiting.
• You want to set up real, persistent automation: hooks, custom agents, scheduled tasks.
• You’re comfortable enough with the disciplines (verification, scope, instructions) that the sharp edges of Code don’t worry you.

You don’t have to graduate. Many people do excellent work for years entirely in Chat and Cowork. The jump to Code is for people whose work has a code or systems component, or who want the full agentic stack. The next section is for them.

Part 8: Claude Code, Where The Compounding Lives

A note before we start. This section is what I personally use most. Almost everything I do that produces real compounding happens here. That said, your mileage will vary. Some of what’s described is overkill for your situation. Some of it is wrong for the way your work breaks down. Read it as one operator’s setup, not as a checklist. Try the patterns. Keep what fits. Throw out what doesn’t.

If you’ve come this far in the guide and you’re not technical, don’t bounce. Claude Code is not “AI for developers.” It’s an agent. The work it does happens to include code, but it also includes file management, web automation, research, document production, anything your computer can do. The mental shift to make right now: stop thinking of Claude Code as a coding tool and start thinking of it as a programmable substrate for your work.

This is the longest section of the guide. It earns the length because almost everything about how to use AI well lives here in its most concentrated form. If you internalize the disciplines below, they translate back to Chat and Cowork in cleaner ways than the other direction.

What Claude Code actually is

The shortest definition: Claude Code is a command-line agent. You install it. You open a terminal in a folder. You start a session. The model now has access to that folder, your shell, your network, and a growing library of tools, and it can plan, execute, observe, and iterate without you having to drive every step.

The longer definition gets at why this is different from everything before it. In Chat, you’re talking to the model. In Cowork, the model can edit files. In Claude Code, the model can do anything a user with a terminal can do. Run tests. Make commits. Hit APIs. Inspect logs. Take screenshots of web pages. Read its own previous output and decide what to do next.

This is a real agent loop. The model takes a step, observes the result, takes another step. You’re not micromanaging. You’re supervising.

The supervision matters. The model has tremendous capacity to be useful and tremendous capacity to make a mess. Claude Code ships with permission systems precisely because the safe defaults need to be: ask before doing anything destructive, ask before touching anything sensitive, otherwise move freely. You can dial those defaults up or down. We’ll get to that.

When to reach for it

Specific situations Claude Code is the right surface, beyond “you’re a developer.”

• You’re working on real files on your computer and the work has more than a couple of steps.
• You want the model to run something and observe the output before deciding what’s next.
• You want to automate something. Even a small something. A daily report. A folder cleanup. A recurring research task.
• You want to wire the model to a system that doesn’t have a native connector, but does have an API.
• You want the model to act on your behalf for a few minutes without you babysitting every turn.
• You want to compose multiple capabilities (web automation, file editing, network calls, code execution) into a single coherent piece of work.

If your work has none of those characteristics, Chat and Cowork are probably enough. If even one is true regularly, Code is going to change what’s possible for you.

The mental model: architect and hands

Here’s the relationship that keeps things sane.

You are the architect. You decide what gets built and why. You own taste, judgment, verification. The model can’t substitute for any of those.

Claude is the hands. It executes the how. It moves fast. Done well, it asks before guessing and reports honestly when it’s finished.

The very first line of my own global instructions reads: “You are the hands; the human is the architect. Move fast, but never faster than the human can verify.”

That sentence does a lot of work. It frames the whole session. The model picks up the dynamic from the first interaction. It moves quickly, but it also slows down at the points where my judgment is needed. The pace is right.

The mistake people make is treating Claude Code like either an oracle (it gets to decide what’s right) or an autocomplete (you have to drive every keystroke). Both are wrong. It’s a teammate. With a teammate, you delegate the how. You don’t delegate the what or the why.

What it’s good at and bad at

Specific calibration for Claude Code, since the constraints differ slightly from Chat.

Shines at:

• Mechanical refactors across many files. Renaming things. Restructuring directory layouts. Updating import paths after a move.
• Greenfield code from a clear spec. Give it a tight description, get a working first draft.
• Reading 50,000 lines of code and answering “where does X happen.” Better than grep. Much better than you.
• Test scaffolding. Types. Glue code. The connective tissue that’s tedious to write by hand.
• Translating between formats and languages. A Python script to TypeScript. A SQL query to a Python dataframe operation. A markdown doc to HTML.
• Patient debugging when given clear signal. If you can describe what you observed and what you expected, it’s good at narrowing the gap.

Struggles with:

• Ambiguous requirements. It will silently guess. The guess is sometimes wrong. The wrong guess sometimes sits for three hours before you discover it.
• Novel architecture tradeoffs. It has average opinions about hard design questions.
• Anything requiring taste you haven’t taught it. Defaults to averaged taste.
• Long-horizon work without checkpoints. Will drift over time without explicit re-grounding.
• Knowing when its own answer is wrong. The most important failure mode in this list.

Half the skill is not asking it to do things it’s bad at. The other half is, when you do ask it to do something on the right column, shrinking the surface area until what’s left is something on the left column.

The Big Setup: The Six Discipline Principles

The next six sub-sections form what I think of as the core operating discipline. Each is a principle, followed by how to instantiate it in your instructions, followed by the failure mode it prevents.

The whole point of these is that you write them down once, in your global instructions, and they apply across every session for the rest of your time using the tool. They are the difference between Claude Code being incredible and Claude Code being a constant source of small frustrations.

Principle 1: Make assumptions explicit

The most common failure mode for AI-assisted work is the confidently wrong assumption. The model fills in an ambiguous spec silently, builds three hours of work on top of the assumption, and you discover the issue when you try to ship.

The fix is to force assumptions to the surface before any non-trivial work begins.

In my global instructions, I have a block that says:

Before any non-trivial implementation, surface assumptions explicitly before proceeding:

ASSUMPTIONS I'M MAKING: 1. [assumption] 2. [assumption] → Correct me now or I'll proceed with these.

Never silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked.

A thirty-second assumptions block has saved me more rework than any other practice in this guide. Sometimes I don’t correct anything. I just want to see what the model was about to assume. That visibility alone is worth the friction.

This works because models are good at predicting their own decisions. They’re just bad at flagging them as decisions unless you tell them to.

Principle 2: Allow uncertainty

Models are trained to be helpful. In the model’s behavior, helpfulness gets confused with confidence. Without explicit permission to say “I don’t know,” the model will fabricate.

You have to tell the model that not knowing is acceptable, and proceeding by guess is not.

The block in my instructions:

When confused or uncertain:

1. STOP. Do not proceed with a guess.
2. Name the specific confusion.
3. Present the tradeoff or ask the clarifying question.
4. Wait for resolution before continuing.

Example: “I see X in file A but Y in file B. Which takes precedence?”

When the model starts asking questions, that’s not a failure. That’s the system working. Better one clarifying question now than three hours of work in the wrong direction.

Principle 3: Demand pushback

Models are trained with reinforcement learning that makes them agreeable by default. Without explicit guidance, they will tell you your idea is great. Sycophancy is a measurable, well-known failure mode, and one of the easiest to mitigate with prompting.

The directive:

You are not a yes-machine. When the human’s approach has clear problems:

• Point out the issue directly.
• Explain the concrete downside.
• Propose an alternative.
• Accept their decision if they override.

Sycophancy is a failure mode. “Of course!” followed by implementing a bad idea helps no one.

A useful sanity check: ask Claude to review your own plan. If it never finds anything wrong, your instructions are missing this directive.

This is the principle that most directly translates the model from “fast junior teammate” to “actual collaborator.” Without it, you don’t have a teammate. You have a yes-machine that types fast.

Principle 4: Plan before you execute

For anything non-trivial, planning beats winging it.

For small tasks, a three-line inline plan is enough:

PLAN: 1. [step]. Why: [reason] 2. [step]. Why: [reason] 3. [step]. Why: [reason] → Executing unless you redirect.

The arrow at the bottom is the commit point. A chance to redirect before execution starts. If you don’t redirect within five seconds, you’ve implicitly approved.

For bigger work (a feature, a refactor, a non-trivial new system), use the formal plan mode that ships with Claude Code, or call out to a /plan-review skill that gets a second opinion before you start.

The instinct most people fight: “just do it, the plan is wasting time.” Almost always wrong. The plan is the cheapest insurance you buy all week. It costs you a minute. It surfaces issues that would have cost you an hour.

Principle 5: Close every loop

Long-horizon agent reliability comes from structured self-reporting. The model needs to summarize what it changed, what it touched beyond what was asked, and what it’s worried about.

After any non-trivial work:

``` CHANGES MADE: - [file]: [what changed and why]

ADJACENT IMPROVEMENTS: - [file]: [what you improved and why it mattered]

POTENTIAL CONCERNS: - [any risks or things to verify] ```

And separately, for any refactor or restructuring:

After refactoring or implementing changes: - Identify code that is now unreachable. - List it explicitly. - Ask: “Should I remove these now-unused elements: [list]?”

Don’t leave corpses. Don’t delete without asking.

The pattern is: state intent, execute, report, ask. Every loop closes. Nothing accumulates as silent debt. The five-line report at the end of a task is one of the most valuable habits in this entire guide.

Principle 6: Make context durable

The big one. The single most valuable practice in working with these models.

Use CLAUDE.md files (global, project-level, even directory-level) as the model’s persistent memory of how you work. Written once, paid back every session.

• Global at ~/.claude/CLAUDE.md. Habits, discipline, universal preferences. The first thing every session reads.
• Per-project at repo/CLAUDE.md. Stack, commands, conventions, gotchas. Specific to one piece of work.
• The loading is additive. Claude Code walks the directory tree and merges global, project, and any nested CLAUDE.md files together. More-specific and later-loaded rules take precedence on direct conflicts, but arrays merge across layers rather than overwriting wholesale.

My global has about a dozen sections. Every one of them was added in response to a real failure. None of them are speculative. The sections include the five principles above, plus things like port management, data safety, git conventions, dev server management, voice interface considerations, and a self-improvement loop (more on that at the end of this section).

If you take only one practice from this guide and apply it tonight, it’s this one. Write a global CLAUDE.md. Put the five principles above into it. You will feel the difference in the first session.

The three-tier documentation system

A pattern that scales well as projects get bigger.

Every project should have three tiers of documentation:

Tier 1: Living docs. Things that change weekly and reflect current state.

• ROADMAP.md: what’s built, what’s next, why.
• CLAUDE.md: how we work in this repo.
• memory/MEMORY.md: the model’s operational cheat sheet. Architecture, known issues, active patterns. Under 200 lines.

Tier 2: Decisions. Append-only records of why things are the way they are.

• docs/decisions/YYYY-MM-DD-title.md: design decisions, post-mortems, feature specs, bug analyses. Header includes status (Proposed, In Progress, Complete, Fixed, Superseded). Never modify old decisions. Write a new one that supersedes if needed.

Tier 3: Reference. Stable orientation material.

• README.md: what this project is. For new people.
• docs/_archive/: superseded docs, kept for reference.

The rules between tiers:

• ROADMAP is the single source of truth for “what’s built” and “what’s next.”
• MEMORY is for gotchas and operational context. Not roadmap status.
• After significant work, proactively update ROADMAP and MEMORY.
• When making a design decision or fixing a notable bug, write a decision doc.

Why this matters for Claude: the model can read all of these and form a coherent picture without you re-explaining. The boundaries are clean enough that the model knows where to write, not just where to read. Over time, the project starts to maintain its own documentation as a side effect of doing work.

Memory: what the system maintains on its own

Claude Code ships with file-based persistent memory. The model writes facts about you, your preferences, and project state to its own filesystem. Future sessions read them on boot.

I split memory into four types, each stored as a separate file, indexed by a MEMORY.md table of contents:

User. Who I am, how I collaborate, what role I play. “Parker is a consultant. He defaults to retainers and biweekly sprints. Frame implementation recommendations accordingly.”

Feedback. Corrections and confirmations, with the reason. “Don’t mock the database in integration tests. Reason: prior incident where mocks passed and prod migration failed.” Including the why is the load-bearing part. A rule without a reason rots when the situation changes.

Project. Initiatives, deadlines, stakeholders. “Merge freeze starts March 5 for mobile release. Flag non-critical PR work after that date.”

Reference. Pointers to external systems. “Pipeline bugs are tracked in Linear project INGEST.”

The model proposes new memories. I approve, edit, or reject. The memory system gets smarter through use, not through manual writing.

Important detail: memories are point-in-time observations, not live state. A memory from three months ago about how a system works might be stale. The model knows to verify before acting on memory-derived claims. So should you.

Hooks: hard guarantees, not soft preferences

A discipline question.

Some behaviors you want from the model are preferences. “Try to use descriptive variable names.” Easy to write into CLAUDE.md. The model will mostly comply. If it doesn’t, the cost is low.

Other behaviors you need from the model are non-negotiable. “Never commit without running the type checker.” “Never edit a file outside this directory.” “Always format on save.” A CLAUDE.md sentence isn’t enough for these. The model can be told to do them, and sometimes will forget.

These are jobs for hooks. A hook is a piece of code that runs automatically in response to a tool event. After a write, run the type checker. Before a bash command, check it against a blocked-patterns list. On session start, load environment variables. On session stop, send a desktop notification.

The principle: anything you need to happen should be enforced by a hook. Prompts can be ignored. Hooks can’t.

My favorite hook setup: a permissions hook that uses a second AI to evaluate every shell command and edit. Auto-approves dev work. Blocks anything destructive. The result is that I almost never see permission prompts, but I never auto-approve something dangerous. The setup takes thirty minutes. It pays itself back in a week of saved keystrokes.

Common hooks worth adding from day one:

• A PostToolUse hook on file writes that runs the type checker.
• A PostToolUse hook on file writes that runs the formatter.
• A SessionStart hook that loads project-specific environment.
• A Stop hook that sends a desktop notification when a long-running session finishes.

Statusline: make cost and context visible

A small visibility investment with outsized payoff.

Claude Code lets you supply a custom script that draws the status line at the bottom of your terminal. Mine shows: model, context usage as a percentage, cost so far in the session, tokens used, git branch, project label.

The progress bar is colored. Green under 40 percent context usage. Yellow under 70. Red after that. When it goes red, I wrap up the session before context auto-compaction starts degrading the work.

You can’t manage what you can’t see. Surface cost and context in your peripheral vision. Otherwise you’ll discover problems in your billing portal weeks later.

Working in parallel: worktrees, ports, themes

Once you start using Claude Code seriously, you’ll hit the limit of one session at a time. You want to run multiple sessions, on different branches of the same project, without them stepping on each other.

The standard answer (this one is straight from the official guidance): use git worktree. Each worktree is a separate directory pointing at a different branch. Multiple Claudes can run safely in the same repo, on different branches, without colliding.

I built a small CLI that wraps git worktree and adds: automatic port assignment so dev servers don’t fight over the same port, automatic .env generation, automatic dependency install. I run it dozens of times a week. The cost of spinning up a parallel workstream went from twenty minutes to fifteen seconds. The cost of stepping on my own toes went to zero.

A practical consequence: port collisions become a daily problem the moment you go parallel. The fix is a single source of truth for ports. Every project, every worktree, every standalone server has a registered port. The instructions file tells the model to look it up before starting any server. Never guess at port 3000 or 8080.

Another practical consequence: when you have ten parallel sessions across five projects, you start losing track of which terminal is which. The fix is visual: each project gets a color across everything in your environment. Terminal tab. Browser container. Status line. All driven from the same config file. I have never accidentally run a command for one project in another project’s directory. The setup time is minutes. The cumulative time savings is hours per week.

This is the part of the setup that looks like overkill until you’ve felt the pain it prevents.

Skills: workflows promoted to verbs

A skill is a markdown file that becomes a slash command. Anything you do twice should become one. That’s how individual practice turns into something repeatable.

A skill file lives at ~/.claude/skills/<name>/SKILL.md. The file has frontmatter (name, description, allowed tools) and then a body describing what the skill should do. The first time you load it after creating it, you have to restart Claude Code. Then it appears as /<name>.

Skills I use almost daily:

• /wrapup: updates ROADMAP, MEMORY, and writes decision docs at the end of a session.
• /playwright: bespoke browser automation. Used proactively after any UI change.
• /worktree, /merge: wrap the worktree CLI for create, integrate, clean.
• /code-review, /security-review, /techdebt: review the current diff with different focus.
• /init, /plan-review: bootstrap a new project; get a second opinion on a plan.
• /verify: actually run the application and confirm the change works.
• /google: orchestrate Google Workspace operations (Gmail, Drive, Sheets, Docs).
• /run: launch this project’s app to see a change working.

There are about fifteen more. Most of them are five minutes of writing that pays back hours every month.

The gotcha that bites people on the first try: the file has to be named SKILL.md in uppercase. Lowercase doesn’t register.

Subagents: protect your context window

A subagent is a separate Claude instance you can spawn from within a session. The subagent gets its own context window. It runs to completion. It returns a summary. The tool calls and reasoning the subagent did don’t pollute your conversation.

This is useful for two reasons.

First, parallelism. You can fan out multiple subagents in parallel, each doing an independent piece of work. The wall-clock time goes down. The actual work happens faster.

Second, context hygiene. If the subagent has to read a thousand files to answer a question, the thousand-file noise stays in its conversation, not yours. You get back the summary. Your context window survives intact.

When to spawn one:

• Open-ended exploration. “Where in this codebase do we handle…?”
• Three or more independent lookups that can run in parallel.
• Independent second opinions on a plan or pull request.
• Anything that produces lots of output you don’t need verbatim.

When not to:

• You already know the file path. Just read it.
• One quick grep. Just grep.
• The task needs your full conversation context. Subagents start fresh.

The failure mode to avoid: spawning subagents for trivial work. The overhead exceeds the benefit, and you lose the model’s local context.

Verify with eyes, not claims

A discipline that has prevented more bugs than any single piece of technology in my setup.

“I tested it” is not testing. The reliable agent workflows give the model the ability to look at what it built (screenshots, console logs, HTTP responses) and re-iterate based on what it actually sees.

If a UI is broken, the model shouldn’t guess. It should write a Playwright script, take a screenshot, capture console errors, then fix.

My global instructions mandate this proactively, without me having to ask:

After any UI change, screenshot the affected page. After deploying, verify the live URL loads, check console errors, screenshot. When the user reports a frontend issue, invoke /playwright BEFORE asking clarifying questions, to capture errors and screenshot. After fixing a frontend bug, re-verify the fix works.

Never ask the user to check their console. Capture errors yourself. Never guess at frontend issues when you can just look.

The shift in posture is from “the model claims it works” to “the model has evidence it works.” The work is real because the model has seen the result of the work.

This applies beyond browsers. The same instinct: ask the model to look at what it produced. Read the file it just wrote. Run the test it just added. Print the result of the command. Trust evidence, not claims.

MCP: plug into your real systems

MCP (Model Context Protocol) is an open standard, originally from Anthropic, for letting models talk to external systems. Anything you copy and paste between Claude and another tool more than weekly is a candidate for an MCP server.

The MCP ecosystem has grown fast. My setup includes servers for: GitHub. Vercel. Supabase. Figma. Filesystem (so the model can read/write outside the current working directory when needed). Context7 (for fetching up-to-date library documentation). Google Workspace (Gmail, Calendar, Drive, Sheets, Docs, Slides). And a few specialty servers I’ve written for systems I work with.

You add these in your settings file. The model treats them as more tools. No special prompting required.

The principle: anything that lives in another system that you keep moving by hand into the model belongs in an MCP server. The activation cost is small. The compounding is huge.

Self-improvement: make the system learn

Static rule sets rot. The most durable workflows include a self-improvement loop.

The last section of my global CLAUDE.md instructs Claude: when you observe a pattern that consistently helps, or a failure mode worth preventing, propose adding it to this file.

When you learn something material over the course of work, propose adding it to this file.

Criteria: - The insight is genuinely global. Applies across projects, not project-specific. - It addresses a real pattern you’ve observed, not a hypothetical. - It’s concise enough to earn its place. Around two to five lines.

Format: PROPOSED CLAUDE.MD ADDITION: Section: [where it fits]

---

[the proposed content]

Rationale: [why this helps, based on what you observed]

Don’t be shy about this. The goal is for these guidelines to get smarter through use.

I accept maybe one in four proposals. The CLAUDE.md gets smarter through use, not through me sitting down to manually tune it. After six months, the file is several times the size and ten times more useful than the version I started with.

The calibration problem: reliability versus magic

A practical tension worth naming.

The disciplines above (assumptions, plans, push-back, change summaries, hooks, all of it) are about making the model reliable and predictable. They narrow the space of things the model can do. You get more guaranteed behavior. You give up some of the freewheeling, intuitive intelligence the model can show when you give it more room.

There’s an irony I want to name directly: sometimes I get my best results by letting the model do its thing and not steering it at all. Hands off. Vague intent. See what comes back. The output is often better than what I’d have produced if I’d over-specified up front. Other times, the same approach produces a mess. The skill is knowing which kind of task is which.

There’s a sliding scale. On one end: tightly bounded, predictable, reliable. On the other: free, generative, occasionally magic. Neither end is right for every task.

For mission-critical or production work, dial toward reliable. The hooks fire. The summaries run. The verification happens. You sleep at night. If you’re designing a distributed system with tight requirements, or doing anything where a bad output causes real-world harm, narrow the model’s surface area aggressively and verify everything.

For exploration, brainstorming, or work where the goal is to surprise yourself, dial toward magic. Drop some of the constraints. Let the model push past your assumptions. Be willing for the output to be wrong sometimes if it might also be unexpected.

Calibrating between these is a matter of taste. It’s also one of the things you get better at with practice. The disciplines aren’t there to make every interaction tightly bounded. They’re there so that when you want tight bounds, you have them, and when you want to let go, you’ve trained the muscle of letting go from a position of strength.

The domain-level question to ask

The right framing for choosing how tightly to steer comes down to a question about your domain.

In some domains, a wrong output is something you can spot, throw away, and try again in five seconds. That’s most creative work. Most exploratory analysis. Most first drafts. In domains like these, a fast feedback loop is the real safety mechanism, and over-specifying upstream costs you more than it saves you. Let the model run. Read what it produced. Fix in the next pass.

In other domains, a wrong output is an existential problem. A faulty migration that drops production data. A flawed clinical analysis that informs a treatment decision. A misconfigured trade. In domains like these, the cost of letting the model run uncontrolled is so high that the discipline overhead is obviously worth it. You ratchet up the constraints. You verify everything. You don’t let “it’s faster without the plan” win.

The mistake people make is using one mode in the other domain. Treating creative work like it’s a clinical trial and choking off the model. Or treating consequential work like it’s a brainstorm and acting on the first output. It’s up to you to know the difference for your specific work. The honest answer is that this kind of judgment is what you’re getting paid for, and it doesn’t transfer to the model.

Dangerously skip permissions: the loaded gun

Worth a dedicated note, because it’s one of the most consequential settings in the whole stack.

Claude Code has a flag, --dangerously-skip-permissions, that turns off the permission prompts the tool normally uses to gate tool calls. The model can run any shell command, edit any file it can reach, hit any network endpoint, without stopping to ask. (Anthropic’s docs on the flag and the safer auto mode that’s begun to replace it.)

For inherently creative work where the cost of a wrong output is low and the cost of friction is high, this can feel transformative. You stop being interrupted. The model just goes. The output velocity goes up dramatically. I’ve used it. It’s part of why agent work feels magical when it works.

It is also, very plainly, an extremely sharp object. The same flag that lets the model fly is the flag that lets it run rm -rf in a directory you forgot to back up. Or hit a production API. Or push code to a branch you can’t undo. The category of failure when this goes wrong is broad, and at least some of the failures are irreversible.

The rules I use for myself, for whatever they’re worth:

• Never in a directory I’m not willing to lose.
• Never on a machine that has access to production systems I care about.
• Never without a recent backup of anything I’m not willing to redo.
• Always in a worktree or isolated environment, never on the main branch of a real project.
• Always with the awareness that I’m explicitly choosing speed over a safety layer that exists for good reasons.

This isn’t a “don’t ever do this” warning. It’s an “understand what you’re doing” warning. The risk is real. The unlock is also real. Your call, in full possession of the tradeoffs.

Sharp objects: a warning

Claude Code is the most powerful surface in the stack. It also has the most ways to hurt you. The instructions to call out:

• Destructive commands. The model can delete files, drop tables, force-push branches. Permission systems help but aren’t infallible.
• Data safety. The model can read sensitive files if you give it permission to read your home directory. Be deliberate about what you expose.
• Shared systems. The model can post to Slack, send emails, comment on PRs. Each of those has consequences. Confirm before authorizing.
• Long-running automation. The model can launch background tasks. Make sure you know what’s running.

The defaults are reasonable. Read what you’re approving. Don’t auto-approve dangerous things because you got tired of clicking “yes.”

The general principle: this tool can do real work in the real world. Treat it with the same care you’d treat any teammate who has those permissions.

The mental shift, summarized

The before-and-after framing of working with Claude Code:

Before: you write instructions, the model executes them, you check the output. The model is a faster version of you doing the same work.

After: you build a system around the model (instructions, memory, hooks, skills, integrations). You direct intent at the system. The system does the work. The model is one component of a larger machine you’ve assembled.

That’s the shift. The work moves from “talking to an AI” to “operating a context-engineered system that includes an AI.”

The compounding lives in the second one. Every CLAUDE.md sentence you write is paid back every session forever. Every skill you make is paid back every time you invoke it. Every hook you install enforces a discipline silently for the rest of the time you use the tool. Every memory the system maintains is one less thing you have to re-explain.

The first month of doing this feels like overhead. The second month feels like flying. The third month, you start to notice that you’re shipping more work, with less friction, than you ever did before.

The deepest thing Claude Code lets you do, the thing that I think most people haven’t fully internalized, is that it lets you create systems. Not just write code. Not just automate tasks. Build entire small machines of skills, hooks, and integrations that act on your behalf, refine themselves over time, and turn your individual practice into something durable. It is, without exaggeration, an incredible unlock for the creative side of working with this technology.

A meta-commentary on this whole section

I expect practically all of the specific technical notes in this section to be degraded within months of publication. Tools will move. Flags will be renamed. Some features will be deprecated. Others will become unnecessary because the underlying model got better.

That’s fine. The framing won’t move much, even though the syntax will. The disciplines won’t move much. The mental model won’t move much.

The fun of this work is in being creative within the moving target. Try things. Build little workhorse systems. See what compounds for you. Learn from other people doing the same thing, on Twitter and in repos and in office hours, but trust your own taste more than any single recommendation, including this one. The rate of change is unbelievably fast, and the part of you that wins in that environment is the part that’s curious and unafraid to make stuff up as you go.

That’s where this is going. Patterns and anti-patterns next, then the close.

Part 9: Patterns and Anti-Patterns

A short section by design. The framework lives in Part 2. The practices live in Part 4 and Part 8. This is the consolidated list, ready to be screenshotted, printed, taped to a wall.

A reminder before reading: these are patterns I’ve seen work. They are not laws. Some of them won’t fit your situation. Try them and modify them. That’s the point.

Universal patterns

Things that work across Chat, Cowork, and Claude Code.

Specificity over cleverness. Long prompts full of clever framing are usually worse than short prompts with concrete examples and clear constraints. If you find yourself reaching for a clever opening, you’re probably over-rotated on prompt-engineering culture.

Capture the artifact, not the conversation. End every useful interaction by extracting the asset. Put it somewhere durable. The conversation was scaffolding. The artifact is the thing.

Build the context once, use it forever. The hour you spend writing instructions, building a project, drafting a skill is paid back every session for the rest of your life with the tool. There is no other investment in this stack with that return.

Treat the model like a teammate. Junior, fast, capable, in need of context and review. Not an oracle. Not autocomplete. The mental model determines everything that follows.

Verify with eyes, not claims. Especially with claims about state (it ran, it works, it shipped). Look at the file. Run the command. Check the screenshot. Confident outputs are not correct outputs, and the model can lie to itself about whether something worked. Make it look.

Surface assumptions before doing work. The thirty-second assumption block is the cheapest insurance you’ll buy all week.

Iterate, don’t accept first drafts. The first output is information about what you actually meant. The third output is the deliverable.

Shrink the surface area. If you’re asking the model to do something it’s bad at, narrow the ask until what’s left is something it’s good at.

Let the system get smarter. Self-improvement loops in the instructions. Proposed additions reviewed and accepted. The setup compounds in capability over time without you sitting down to manually tune it.

Universal anti-patterns

Mistakes I see almost every newcomer make. Worth naming so you can catch yourself.

Endless conversations. A chat that should have been three different chats. Symptoms: the model contradicts itself, response quality degrades, you’ve lost the thread. Fix: capture and restart.

Re-explaining the same context every time. If you’ve explained who you are or what the project is more than twice, that fact belongs in instructions, not in a prompt.

Asking the model to do work without giving it the inputs. “Look at my codebase” without giving it access. “Read the spec” without including the spec. Garbage in, mediocre out.

Treating outputs as final without review. The model is confident. Confidence is not correctness. Read what came back. Edit what’s wrong. Reject what’s bad.

Optimizing the prompt when the real fix is upstream. If a prompt isn’t working, the answer is usually more context, not more clever phrasing.

Over-specifying. Reaching the other end of the calibration scale. Tying the model’s hands so tightly that nothing surprising can happen. Lose magic without gaining reliability.

Skipping the audit. Letting your instructions rot. Letting your memory drift. The compounding goes the other way when you neglect this.

Living in one surface. Forcing every task through Chat because that’s what you know. Or skipping Chat entirely because Code feels more serious. The right tool for the job depends on the job.

Treating skills as exotic. Acting like reusable workflows are a power-user feature you’ll get to “later.” The threshold should be: third time you do it, make it a skill. Activation energy is low. Return is immediate.

Ignoring memory. Treating it as a black box. The memory layer is one of the strongest assets in the system. Open the directory. Read what’s in there. Edit it.

When to use which surface

A clean decision rule.

Use Chat when: the work is conversational, the output is one or a few artifacts, and the duration is minutes to about an hour. Brainstorming, drafting, research, single-artifact production.

Use Cowork when: the work involves real files on disk, runs over multiple sessions, or produces multiple connected artifacts. Long documents. Research that builds. Project folders.

Use Claude Code when: the work involves running things on your computer, calling APIs that don’t have native connectors, or composing capabilities into an agent loop. All code work. All real automation. Anything where the model needs to look at output and decide what’s next.

The boundaries between these aren’t hard. Some tasks fit two of them. Pick the simplest that works. Move up only when you need the extra capability.

Building your own system, in order

If you’re starting from zero, the order to build your context engineering stack is roughly:

1. Write your global instructions. One hour. Identity, voice, defaults, hard rules, operating preferences. Save. Use. Edit as you go.
2. Make one project for an active piece of work. Add project instructions. Add reference files. Run a few real sessions inside it.
3. Make your first skill. Pick something you do at least weekly. Standup. Discovery questionnaire. Meeting prep. Whatever. Make it a slash command.
4. Turn on the connectors that matter to you. Gmail. Calendar. Drive. Whatever fits your work. One at a time. Confirm each works.
5. Audit and promote, monthly. Move things between scopes. Edit memory. Delete what’s stale.

That’s the minimum stack. From this baseline, almost any further investment pays back. You can stop here and be very productive. You can keep going (hooks, statusline, parallel work, custom MCP servers, self-improvement loops) if the work warrants it.

How to keep getting better

The meta-pattern. Treat your own usage as a system to iterate on.

Notice what works. Capture it. Repeat it deliberately. When you do something well, ask why. When you do something poorly, ask why. Adjust your instructions, your skills, your habits.

The people who get the most out of these tools aren’t the ones with the most clever prompts. They’re the ones who treat their own setup as a living project. Every week, the setup is slightly better than the week before. That improvement compounds. After a year, the gap between someone running a well-tuned setup and someone running a bare default is enormous.

This is the part that’s hard to teach. You can read this guide. You can copy patterns. The work of noticing what compounds for you (specifically you, doing your specific work) is yours to do. The good news is you don’t have to figure it out alone. The next section is about how to keep going.

Part 10: Where To Go From Here

The one thing to do this week

Write your global instructions. One hour. Identity, voice, hard rules, the five disciplines from Part 8 (assumptions, allow uncertainty, push back, plan first, close every loop). Save the file at ~/.claude/CLAUDE.md.

You will feel the difference in the first session.

If you have a second hour: set up dictation, per Part 5. The two together will reshape how you work within a week.

A short note on staying current

You don’t need a daily firehose to keep up. A few good sources, used sparingly, are enough.

• Anthropic’s documentation. Direct from the source. Read the changelog notes when new versions ship.
• Simon Willison’s blog. Independent, prolific, technically credible. Single highest-signal feed if you only follow one.
• The Anthropic engineering blog. Less frequent. When something matters about how to actually use these tools, it tends to show up here.

The framework and disciplines in this guide are stable. The specific features will shift. The patterns will translate.

That’s the tactical part. The rest of this section is about why this matters.

On the fear

I want to take seriously, for a moment, the part of this technology that should make any honest person uneasy.

This thing renders huge swaths of expertise less load-bearing. People who spent thirty years getting good at something can wake up to find that the specific skill they trained their lives around isn’t where the value lives anymore. That is real. The grief is real. The economic disruption is real.

The infrastructure isn’t free. Data centers consume enormous amounts of water and power. The carbon footprint of frontier model training and inference is significant and growing. The geographic concentration of compute is producing political dynamics that nobody fully understands yet.

Our institutions are not built for this. E.O. Wilson, at a 2009 debate with James Watson at the Harvard Museum of Natural History, put it this way: “The real problem of humanity is the following: we have paleolithic emotions, medieval institutions, and god-like technology. And it’s terrifically dangerous.” Wilson said it about modernity in 2009. It applies even more obviously to where we are now. We’re trying to absorb something genuinely new with cognitive equipment evolved for the savanna, governing structures evolved over centuries for slower-moving problems, and a public discourse that wasn’t designed to make sense of any of this. That’s a scary combination.

Every major shift in information infrastructure has done something similar, or so the standard story goes. In the Elizabeth Eisenstein and Benedict Anderson tradition, the printing press reorganized European political and religious life and helped midwife the early modern nation-state; the broader sweep of information technologies reshapes the institutions built around them. The historiography is contested. The framing is still useful: information infrastructure shifts trigger institutional restructurings that look more like revolutions than evolutions, with the human cost that revolutions usually carry. AI is the next shift. We’re inside it now.

GDP could rise dramatically while the bottom 90% can’t afford basic goods. We don’t have a coherent answer for what employment looks like when most knowledge work is automated. We don’t have a coherent answer for what political legitimacy looks like when the entities producing most of the content circulating in public are statistical processes rather than people. These keep me up at night too.

That’s before we get to the deeper layer: what happens when models start to meaningfully self-improve, when the boundary between “tool” and “agent” stops being clear, when superintelligence stops being a long-tail risk and starts being something the technical roadmap is pointed at. Given the limitations of how we currently align these systems (the tensions in RLHF, the difficulty of encoding what we actually mean by “good,” the unresolved questions about what kind of intelligence we’re tuning) the honest answer is that nobody fully knows how this goes.

Who watches the watchmen. Whether we trust the small number of people at the labs with the access. What happens if we don’t. The criticisms are real, and I am deeply sympathetic to the people raising them. The list of plausible bad outcomes is long.

And yet

What I want to say is that the list of plausible good outcomes is also long, and that the people airing the bad list have done so loudly enough that the good list deserves equal time.

We may be able to use this technology to understand the source code of physics in ways that fifty years of human effort weren’t sufficient for.

We may be able to develop new drug treatments at scale, including treatments for diseases that have resisted intervention for generations, because the search space of possible molecules is suddenly walkable in a way it never was.

We may be able to align the global supply chain so that goods, services, and information move with less friction, less waste, and less inefficiency baked in by the difficulty of coordination across human institutions.

We may be entering an era where every human being with a token budget can express their own unique point of view and creative imagination. Where the question is no longer “do you have the skills to manifest your vision” but “do you have a vision worth manifesting.” Where the production of art, software, science, and ideas becomes radically more distributed than it has ever been. Where the bottleneck on what gets made is taste and judgment and care, three things that were never the bottleneck in any system designed for efficiency.

That’s a different timeline. It coexists with the bad ones. It’s at least as plausible.

I have no idea how this is going to play out. I’m not saying everything will be fine. I’m saying that the future is not yet written, and the people who actually understand what’s in front of them have an outsized influence on which timeline we end up in.

Why I wrote this

This guide exists because the gap between people who can use this technology well and people who can’t is widening fast, and most of what closes that gap is a few hours of setup and a different way of thinking about what’s actually here.

I wanted to write the thing I wish someone had handed me three years ago. I wanted to be honest about what’s working and what isn’t. I wanted to be specific enough that you could close this document and start doing the work tonight.

But more than any of that, I wanted to give you the perspective to imagine the future you actually want to live in. Not the dystopia in the headlines. Not the utopia in the manifestos. The specific one you would build if the tools were available.

The tools are available. They’re in your laptop right now. They’re improving every month. They cost less than a streaming service.

What’s missing isn’t the technology. What’s missing is people doing the work of imagining what they want and putting in the modest effort to build it. That’s what I hope this guide nudges you toward.

If anything in here was useful, I want to hear it. If anything was wrong, I want to hear that too. The door is open. My email is parker@parkerferguson.co. I love talking about this stuff with people who are trying to figure it out.

How this was made (obviously, with AI)

Honesty requires me to admit one more thing, in keeping with the whole spirit of this guide.

I recorded a voice memo. I hit the button and rattled off everything in my head for about half an hour. Then another half hour the next day for the feedback round. No outline. No script. Just talking out loud about what I think and what I’ve learned, roughly the way I’d have explained it to you in person if we had three hours and a whiteboard.

I gave the transcript and the source material to Claude, along with a long set of conventions about tone, my writing style, and what to avoid. (No em dashes. No corporate jargon. No “leverage.” No “synergy.” You know the list.) Claude wrote a draft. I read it line by line. I marked it up. We iterated. The structure is mine. The thesis is mine. The opinions are mine. Most of the words you’ve been reading are not literally mine, but every one of them was either passed through me or rejected by me, which is what authorship actually means in this medium.

For the technical claims and the references (the Sutskever murder mystery, the 1979 IBM slide, the Karpathy LLM wiki, the Erdős problems Terence Tao has been verifying) I put the draft through a deep research pass to check the claims, find the actual sources, and embed real links. Contentious claims, where I’m clearly expressing a matter of taste rather than a fact, I kept as opinions. Counterfactuals, where the field is moving fast or there’s serious pushback, I tried to surface honestly.

The whole process used exactly the mental model described above. Vision: a guide I’d want to hand to a friend. Feedback loop: voice memo, draft, mark up, draft again. Verification: check the claims I could check, name the ones I couldn’t. Accountability: my name is on it. The model didn’t write this guide. I did, with the model as the hands. Which is, I think, the entire point.

You can build something like this too. The infrastructure cost is zero. The skill cost is whatever you’re willing to invest in learning to do the kind of work this guide describes. There’s no single right way to do it. This is just one operator’s loop, transparently shown.

Move fast. Verify everything. Build the world you want to live in.

Talk soon.