Getting Ready
for AI-Assisted
Coding.

You've used ChatGPT, maybe Claude or Gemini in a browser tab. You can ask a question and get an answer. That's the doorway. The room behind it is bigger than most people realize, and the people you're about to work with spend most of their day in that room.

This document gets you ready to walk in. It's not a tutorial — there's no software to install yet, no commands to memorize. It's the mental model: how these systems actually work, what makes prompts good, what changes when an AI can read your files and run commands on your behalf, and what care you owe the people whose data you might end up touching.

What you'll get out of this

• A working picture of what's happening inside when you send a prompt.
• The difference between chat assistants and agentic coding tools (and why that distinction matters).
• A simple framework for writing prompts that actually get useful results.
• A repeatable workflow — research, plan, build, review — that keeps you out of trouble.
• The non-negotiables: what never to paste into a model, and when to stop and ask.

How to read it

Linear is fine. The sections build on each other but each one stands on its own if you need to revisit it later. Plan on 25 minutes the first time through. The links at the end are where you go for depth — bookmark them, don't try to read them all today.

An LLM — large language model — is, at its core, a very good guesser of what word comes next. It was trained by reading an enormous amount of text and learning the statistical shape of language: which words tend to follow which, in which contexts, with which tone. When you send it a prompt, it generates a response one piece at a time, each piece chosen because it's a plausible continuation of everything that came before.

That's the whole trick. There's no database lookup, no live search of the internet (unless a tool gives it one), no understanding in the human sense. Just an extraordinarily well-calibrated next-word predictor, running fast enough that it feels like a conversation.

Three things that follow from this

• It remembers the conversation, not the world. Inside one chat, the model can see everything you've said. Across chats, it remembers nothing. Each new conversation is a stranger again.
• It can be confidently wrong. Because it's predicting what sounds right, it sometimes invents API names, citations, or function signatures that don't exist. This is called hallucinating. It's not lying — there's no intent — but the output looks identical to a correct answer. You verify; you don't trust.
• Better input produces better output. The more useful context you provide, the more accurate the prediction. Vague in, vague out. This is why prompting is a skill.

The most useful framing for working with AI isn't "the robot does my job." It's the suit makes Tony Stark faster. Tony brings the judgment, the relationships, the read on what matters. The suit handles execution at superhuman speed. Take Tony out and the suit is just metal. Take the suit away and Tony is still Tony.

What models are good at

• Drafting fast — first versions of code, docs, plans, emails.
• Translating between formats — bullet points to prose, design to code, log dump to summary.
• Pattern-matching against a vast amount of seen examples — "what's a normal way to structure this?"
• Following clear instructions exactly, tirelessly, without ego.

What models are bad at

• Judgment. Knowing what actually matters here, today, for this person. The model doesn't know which of three bugs is the one your CEO is breathing down your neck about.
• Context that isn't on the page. The history of why your codebase looks weird in one corner. The politics of who owns what. What the customer actually meant.
• Telling you when it's wrong. A model will hand you a confident answer about a function that doesn't exist with the same tone it uses for a correct one. You're the verification layer.
• Knowing when to stop. If you ask for "more," it will give you more, even when less was the right call.

The job isn't to get out of the way. The job is to direct. Decide what's worth building, frame the problem clearly, evaluate the result, and decide what's good enough to ship. None of that is going away.

Prompting is mostly an exercise in being specific on purpose. Most bad output from a model is a polite, confident response to a vague question. Five extra seconds spent describing what you actually want will save you twenty minutes of going around in circles.

CLEAR — five things every prompt benefits from

Bad vs. good, side by side

Refining isn't failing

Getting a draft that isn't quite right is the normal state. Think of ordering food: "Can I get it without croutons, dressing on the side?" That's not a complaint about the kitchen — it's the shape of the interaction. With models, "tighter, drop the second bullet, make the close more direct" is the same move. You're not starting over. You're steering.

ChatGPT in a browser tab is a conversation: you type, it types back, you copy something useful out. It can't see your code. It can't run anything. Whatever it suggests, you do the work of moving it into your project.

Claude Code and Cursor are a different shape. They sit inside your project. They can read your files, propose edits across multiple files at once, run commands, see the output, and react. The conversation isn't separated from the work — it is the work. People call this "agentic" because the model is acting in the world, not just talking about it.

What changes when the model can act

Claude Code, briefly

Claude Code is a command-line tool that lives in your terminal. You point it at a project, describe what you want, and it explores the code, makes a plan, proposes changes, and (with your approval) applies them. It's the default we'll have you reach for. It rewards clarity — the better you describe the goal and the constraints, the better the result.

Cursor, briefly

Cursor is an editor — a fork of VS Code with the agent built in. If you prefer working inside an IDE with files, tabs, and an integrated chat panel, Cursor will feel more familiar than a terminal. The underlying capabilities are similar; the surface is different.

The teams who get the most out of these tools don't sit down and start typing. They follow a loop. It's not a process you'll be tested on — it's the rhythm that keeps you from spiraling when things get complicated.

A small worked example

Say you want a tool that turns raw meeting notes into a clean summary with action items.

• Research. Ask the model: "What sections should a meeting summary include?" You get back something like attendees, agenda, decisions made, action items with owners and dates.
• Plan. You jot it down. You add: "input is messy text pasted from a Google Doc; output is a single block of markdown."
• Build. You hand the plan to Claude Code with the example input and ask for a small script. It writes one.
• Review. The output looks great except action items don't always have owners. You ask for a "missing owner" flag. Round two ships.

The loop is not always linear. Reviewing might tell you the plan was wrong; building might reveal a question your research didn't cover. Going backwards is not a sign you did it wrong — it's a sign you're paying attention.

These tools are powerful, which means they're also a way to make a fast, expensive mistake. The rules below aren't bureaucracy — they're the small number of habits that stand between "useful work" and "incident."

Four rules to internalize

A note on which model to use

Most agentic tools let you pick a model. As a default: Sonnet is fast, cost-effective, and capable enough for the large majority of tasks — drafting, refactoring, day-to-day code edits. Opus is the bigger, slower, more thoughtful model. Switch to it for high-stakes or genuinely tricky work: complex planning, architecture decisions, important written documents, anything where being wrong is expensive. You don't need to overthink this. Start with Sonnet; reach for Opus when the task earns it.

None of this is hard, and none of it costs you money. The whole setup is maybe ten minutes if you do it slowly. Before you download anything, there's one short conversation to have.

The whole journey, at a glance

Pick how you want to use Claude Code

Claude Code comes in a couple of flavors. They do the same thing under the hood — pick the one that matches how you like to work. You can switch later, and many people end up using both depending on the task.

Once you're signed in

• Try a tiny first task. Open a folder you're not afraid of and ask the model to look around. "What does this project do?" or "Summarize the structure" are perfect openers.
• You can't break anything by accident. The agent asks before it edits files, runs commands, or touches anything beyond reading. The first few times it asks, read the request slowly.
• If something looks wrong, ping the team. Setup quirks are normal and we've all seen them. You're not the first person to land on a confusing error message.

You don't need any of this to start. Bookmark the ones that sound interesting and come back when a question gets you curious. The first group is the strongest "read first" set.