What nobody tells you before your first AI coding session

Everyone is talking about AI coding agents. Claude Code, Cursor, Lovable, Replit, Bolt: the demos look extraordinary. People are shipping entire products in a weekend, or at least that is what the tweets say. You install one of these tools, open it up, and then sit there wondering what to actually type.

This post uses Claude Code as the example because it is the tool I use daily. Most of the principles apply regardless of which agent you choose.

That gap between "this looks powerful" and "I know how to use this" is real, and almost nobody talks about it. The tool is genuinely capable, but it does not come with a manual for people who are not already software engineers. It is not magic that turns prompts into money. It might help you save time, move faster, or build something you could not have built alone, but it does not know what to build or why. That part is still on you. It is a tool. A powerful one, but a tool.

This post is about the mental model, the habits, and the workflow that make the difference between productive and stuck.

Pick a tool and get it installed. I use Claude Code, so the examples below reflect it, but the principles transfer. If you are going with Claude Code, the official documentation walks through setup in a few minutes. Otherwise, your tool of choice will have its own. You can also ask any AI assistant to help you get started. The installation is not the hard part. What comes after is.

Start with something you can judge

If you already have a project, open it. If you do not, that is fine too. Many people come to Claude Code with a fresh idea and no codebase. Both starting points work, but they need different approaches.

If you have an existing project: open it in Claude Code and start with a small, bounded task. Not "refactor the authentication system." Something like "add a loading spinner to the submit button" or "rename the utils directory to lib and update all imports." Small tasks let you verify the output in 30 seconds and build a feel for how Claude works.

A useful first prompt for an existing project might be: "I want to change the colour of the header on the homepage from blue to dark grey. Can you find where that is set and update it?"

If you are starting from scratch: resist the urge to type "build me a SaaS." Start by describing what you want to build and why, and let Claude help you think through the structure before writing any code. The conversation matters more than the first commit. What problem are you solving? Who is it for? What is the simplest version that would be useful? Claude can help you think through these questions, but it cannot answer them for you.

A useful first prompt for a fresh idea might be: "I want to build a simple booking page for my physiotherapy practice where clients can see available slots and request an appointment. Help me think through the simplest version that would be useful. Do not write any code yet."

Either way, the principle is the same: start with something where you can tell whether the output is good or not.

Claude can tackle big things, but context determines the quality

With Claude Code you can attempt surprisingly ambitious tasks. It can refactor entire modules, build features across multiple files, write test suites from scratch. The scope is not the limiting factor. The context is.

When Claude has good context (an existing codebase with clear patterns, a well-described problem, specific constraints) the results can be remarkably good. When the context is thin (no codebase, vague instructions, no constraints) the results look plausible but miss in ways you might not catch until much later.

Your context does not have to be perfect from the start. It can emerge through the conversation. Ask Claude questions. Let Claude ask you questions. Do not rush the back-and-forth. The people who get the best results are the ones who treat it like a conversation with a capable colleague who has never seen their project before, not a text box that produces code.

Being specific helps. "Fix the contact form" is weaker than "the contact form submits but never shows a confirmation message, so users keep clicking send and I get duplicate emails." But sometimes explaining the problem or a behaviour is more useful than prescribing the solution. Claude can often figure out the right approach if you describe what is going wrong.

Build your CLAUDE.md with Claude, not from scratch

After a few sessions, you will notice yourself correcting Claude on the same things. Maybe it keeps putting files in the wrong folder. Maybe it uses a tone in your copy that does not match your brand. Maybe it suggests a different way of doing something when you have already decided how you want it done.

This is when you need a CLAUDE.md file. It lives in your project root and is loaded automatically at the start of every session. Think of it as the briefing you would give a new team member on their first day: here is how we do things, here are the things that are not obvious from the code, here are the things you must not do.

The good news: you do not have to write it alone. Ask Claude to help you create it. After a productive session, try something like: "Based on what you have seen in this codebase and the corrections I have made, help me draft a CLAUDE.md that captures our conventions and constraints." Claude will produce a solid first draft because it has already seen the patterns.

The one that matters most is your project-level CLAUDE.md. It lives in your project folder, and it is where you put conventions, decisions, and rules specific to this project. "We use Tailwind for styling." "Never delete the database migration files." "The admin pages are password-protected." Start here.

There are other places Claude reads context from (global instructions that apply across all your projects, and memory that persists across sessions), but you do not need to worry about those yet. Start with the project-level file and expand later when you need to.

All of this can be developed organically. You do not need to read documentation or copy someone else's template. Start with the corrections you have already made, and let it grow from there. Ask Claude to help you write the CLAUDE.md based on what it has observed in your project so far.

Develop a workflow, do not just follow rules

You might come across advice telling you to commit after every change, never skip hooks, always read every diff line by line. Some of that can be useful depending on what you are building, but the real goal is to develop a workflow that works for you and your project, not to memorise a checklist someone else wrote.

Here is what actually matters:

Understand enough to stay confident. You do not need to read every line of code Claude writes, but you do need to understand what it is doing and why. Ask Claude to explain how the pieces fit together: how the pages connect to the database, where the user's data flows, what happens when someone clicks a button. Try to build a mental picture of the architecture, even a rough one. The right level of scrutiny depends on the stakes. A cosmetic change needs less review than something that handles user data. You can also ask Claude whether what it has built is working well from a user experience, speed, security, or reliability point of view. It will often flag things you had not thought to check. More on each of these in future posts.

Learn how developers work, then adapt. Version control, testing, deployment pipelines: these exist because they solve real problems. You do not need to learn all of them at once. Pick them up bit by bit as your project grows. Understanding why developers use them helps you decide which ones matter for your project right now, especially if your product is going to be used by other people. Do not over-engineer your process early on, but do not skip the basics either. More on each of these in future posts.

Set up safety nets early. Claude operates fast, and mistakes happen before you notice them. Automated checks catch the obvious errors without slowing you down: linters flag style issues and common bugs, type checkers verify your code is internally consistent, and pre-commit hooks run these checks automatically before any change is saved to version control. You can ask Claude to help you set these up.

When things go wrong, they go wrong fast

AI coding agents move fast, and that speed means you might not notice a problem until after it has happened. A command could expose credentials in the terminal. A database change could drop data you needed. A "fix" could pass the tests by changing the tests instead of fixing the underlying bug.

These are the kinds of things that can catch you off guard, especially early on. You do not know what you do not know. The models are getting better at catching issues themselves, and they will often warn you about risky operations. But they are not perfect, and safeguards reduce risk without eliminating it.

The good news is that you can ask AI to help. Ask it to check whether what it just did is safe. Ask it to set up automated guardrails (linters, pre-commit hooks, redaction patterns that strip sensitive data from output) that catch the obvious mistakes without relying on you to spot them manually. The faster you move, the more valuable these automated safety nets become.

The more you use it, the more you learn

There is no shortcut to this. You will develop your own patterns, your own prompts that work, your own sense of when to trust Claude and when to push back. That intuition comes from hours of use, not from reading about it.

A few things that help the learning compound:

Watch what others are doing. Follow people who share their AI coding workflows. But always question what you see. What works for a senior engineer with 20 years of context is different from what works for someone building their first production app. There are often multiple ways to achieve the same thing. Apply the approaches you understand, and skip the ones that feel like cargo-culting someone else's setup.

Ask Claude for opinions. "What would be a better way to structure this?" or "What am I missing?" or "What could go wrong with this approach?" Claude is not always right, but it will often surface things you had not considered. Question the answers, but ask the questions.

Let the direction emerge through your questions. You do not need a perfect plan before you start. The best sessions often start with a problem and end somewhere unexpected, because the conversation surfaced options you did not know existed. Direct it with your questions. The questions shape the work more than the commands do.

That said, do not confuse fast iteration with finished work. Claude will help you get to a working prototype faster than you have ever built one before. Making that prototype into something real users can actually rely on is a different job entirely, and it is what the rest of this series is about.