Coding with Claude

Start with one small task, not a whole app

Coding with Claude works best when the task is small enough to describe in a paragraph. Ask for one function, one page, or one bug fix, and check the result before moving on. When you ask for an entire application in one message, the result is harder to review, harder to test, and harder to fix when something is wrong. Break the work into steps: first the data shape, then the function, then the tests, then the wiring that connects them.

Give Claude the facts it needs in the first message. State the programming language, the framework if there is one, what the code should do, and what it should not do. Paste the relevant code rather than describing it from memory. If the code depends on another file, say so, and include the function signatures or the important parts of that file. The more concrete the starting point, the less guessing the answer contains.

Explain code before you change it

If you inherit code you did not write, ask Claude to explain it before you ask for changes. A good explanation names what each part does, what data flows through it, and where the risky assumptions sit. Read that explanation against the code itself. This step often reveals that a function does something different from what its name suggests, or that a piece of logic only works for one special case.

Ask follow-up questions about anything unclear. Why does this function take that argument? What happens when the input is empty? Where would this break if the data grew ten times larger? These questions turn a passive explanation into a real review, and they often surface the bug you were actually looking for.

Debug by showing the error, not just the symptom

When something breaks, paste the exact error message, the code that produced it, and a short example of the input. Also state what you expected to happen. That combination lets Claude reason about the cause instead of guessing at common problems. If the error only appears sometimes, say what is different on the failing runs.

Work through fixes one at a time. Apply one change, run the code, and report the new result before trying the next idea. If a fix does not work, that result is useful information, so include it in your next message. Jumping between three untested fixes at once makes it hard to know which one mattered.

Write a Python function called parse_price that takes a string like "$1,299.50" and returns 1299.50 as a number. It should return None for an empty string and raise a clear error for text that is not a price. Then write five short tests: a normal price, a price without cents, an empty string, a price with commas, and an invalid input.

Refactor in small, verifiable steps

Refactoring means changing the structure of code without changing what it does, and Claude is useful for exactly that kind of careful rewrite. Ask it to split a long function into smaller ones, rename variables so their purpose is clear, or remove duplicated logic. After each change, run your tests. If you have no tests, write a few before refactoring, so you have a way to prove nothing broke.

Be explicit about what must stay the same. Say which inputs, outputs, and edge cases matter, and ask Claude to list the behaviour it preserved. If the refactor touches code that handles money, dates, or user data, review that part yourself line by line, even if the rest looks fine.

Chat, artifacts, and Claude Code

In the chat app, Claude can write and explain code, and artifacts give you a place to see a working page or document built from that code. That is enough for learning, for prototypes, and for one-off scripts. For work inside a real codebase, Claude Code runs in your terminal and works directly with the files in your project, so it can read the surrounding code and make changes across several files in one session.

The rule stays the same in both settings: you are responsible for the code that ships. Run it, test it, and read anything that touches security, payments, or personal data. Check current plans and features in the app before you rely on a particular capability, because offerings change over time.

A practical workflow

1. Describe one task and paste the relevant code.
2. Ask for the change, plus a short explanation of what changed and why.
3. Run the code and its tests yourself.
4. Report errors back with the exact message and move on to the next small task.

Used this way, Claude becomes a steady coding partner: it drafts, explains, and reviews, while you decide what ships. That division of labour is what keeps the speed without giving up control of the codebase.

Frequently asked questions