AI Explained · Guide

How to write code with AI

The people who get great code out of AI are not using a secret model. They have a method. Here is the practical version, with two hands-on exercises built in.

Start with the right mental model

A coding model is not a genie and not a search engine. The frame that works, borrowed from people who use it daily, is an over-confident assistant who types extremely fast, has read most of the internet, and has almost no judgement about whether its own answer is correct. It will hand you working code and broken code with the same easy confidence. Your job is not to trust it. It is to direct it and check it.

Because a model predicts likely text rather than knowing facts, it sometimes hallucinates: it invents a library, a function, or an option that sounds plausible and simply does not exist. That is not a reason to give up on it. It is a known failure mode you design around, the same way you work around any tool’s limits. The rest of this guide is how.

Mind the training cutoff

Every model has a training cutoff, the date its knowledge stops. Ask about a library version released after that date and it will answer anyway, often inventing methods that fit the older version it remembers. Two habits fix most of this. First, prefer stable, popular libraries: the model has seen thousands of correct examples, so it guesses far less. Second, for anything newer than the model, paste a few lines of the current documentation straight into your prompt. You are not expected to memorize cutoff dates; you just need to recognize the symptom (confident code using an API that does not exist) and reach for fresh docs.

Hands-on: spot the hallucination

A model was asked to total an API response. Which line is invented?

import requests

resp = requests.get(api_url)
items = resp.json()
total = requests.sum_results(items)

Context is the whole game

Most of the skill in working with a model comes down to managing its context window, the text it can see at once. A model knows only what is in front of it: the current conversation, plus anything you paste in. Start a fresh chat and it remembers nothing. Use that on purpose. Seed a new conversation by dumping the relevant code or a working example, then ask for the change. The system prompt is your standing brief at the top of every reply, the place for rules like “cite file paths” and “never invent APIs.” If you want to see exactly what fills the window, the Context Window Visualizer lays it out.

Plan first, then dictate

Real work has two phases, and the model is good at both if you switch modes deliberately. In the planning phase it is a fast research assistant: ask “what are my options for X, with the tradeoffs and a tiny runnable example of each.” Once you have chosen an approach, stop asking and start telling. Give the exact function signature, the types, the error handling, and the constraints. Writing that brief in English, with a few small gaps for the model to fill, is genuinely faster than writing the code yourself, and what comes back needs far less repair. The AI Coding Prompt Builder assembles both kinds of prompt for you.

You have to test what it writes

This is the one step you cannot hand to the machine. Reading code is not the same as watching it run. Ask the model to write the tests alongside the code, then actually run them, and run the thing yourself on a real input. A model will happily produce code that looks right and fails on the first edge case. Manual checking was always part of the job; with AI in the loop it is the part that keeps you out of trouble.

Treat it as a conversation

The first answer is a draft, not a verdict. The fastest path to good code is a short back-and-forth: “break that repetitive block into a function,” “use string methods instead of a regex here,” or simply pasting the error message back with “this failed, here is the trace.” The model never tires of revising, so nudge it toward what you actually wanted instead of accepting the first thing it typed.

Let tools run the code

The biggest jump in usefulness comes from tools that can run code in a sandbox and read the result, closing the loop: write, run, see the error, fix, repeat. A coding agent like Claude Code, Cursor, or Aider does this across your real files: it edits, runs the tests, reads the failure, and tries again. That is powerful and worth using. It does not remove your two jobs, which are still to direct it clearly and to test the result.

Vibe-code to learn, then tighten up

Vibe coding, accepting changes without reading every line, is a fantastic way to learn what a model can and cannot do, and perfect for throwaway weekend projects. It is a poor fit for code you will have to maintain or that touches anything important. Use the loose mode to explore and build intuition; switch to the precise, tested mode the moment the code needs to last.

Know when to take over

Sometimes it is simply faster to write the line yourself than to explain it. The model amplifies your expertise; it does not replace it. The more clearly you understand the problem, the better you can brief the model and the faster you catch its mistakes, which is why experienced developers often get the most out of these tools. Treat AI as a way to ship things you would not otherwise have had time for, not as a reason to stop learning how the code works.

Put it into practice