You are the engineer and the model is a pair. You ask for a function, a test, a regular expression, an explanation of a stack trace or of a library you have not used, and you decide what to keep. You still write most of the code. The model writes pieces of it when you ask.
It is unglamorous, it gets less attention than the categories around it, and it is still the most common way professionals work with these tools. It is also the baseline the rest of this rung assumes. If this mode is not reliable for you, the ones that hand over more will not be either.
What it is for
- Writing the routine parts faster: boilerplate, a test case, a data transformation, a query you can describe but would otherwise look up.
- Understanding code you did not write, by asking what it does and why.
- Getting unstuck on an error, by giving the model the exact message and the code around it.
- A second opinion on an approach before you commit to it.
Who it suits
Professional developers on any codebase, including the ones where nothing more autonomous is allowed. Engineers who want the speed without changing how they work. People early in their careers too, on one condition: the habit of being able to explain every line you keep, which is exactly the habit this mode makes easy to skip.
How to tell this is your category
- You type most of the code. Whatever the model contributes, you asked for by name.
- The unit of work is a question or a function, not a task.
- You read each answer before it goes in, because it is short enough to read.
- If you are asking for whole features across several files and reviewing the result afterwards, you have moved to an AI IDE or a terminal agent.
What it costs you later
The layer page covers what every category on this rung shares: every line you accept is yours, the context tax and drift. In this mode those costs arrive in small pieces, which is what makes them easy to miss.
- Small answers skip review because they are small. A twenty-line function that handles the common case and misses the race condition looks finished. The edge case shows up only if you know to look for it, and a short answer invites a short look. The bugs this mode ships live in code that seemed too small to check.
- Plausible calls that do not exist. A model works from what it was trained on. It can suggest a function a library removed two versions ago, or one it never had, in code that reads as confidently as the rest. Check unfamiliar calls against the library's current documentation, and pin the version you checked against.
- Answers fitted to the question, not the codebase. The model sees what you paste. Ask without the surrounding code and you get an answer that is right in general and wrong for your project: a pattern your team dropped, an error style nobody else uses, a dependency you do not have. Each one is small. Together they make a codebase that no longer agrees with itself.
- Understanding you did not build. Keeping an answer you could not have written is borrowing. Once is fine. As a habit, it leaves you owning code you cannot debug, and reviewing a model's output well takes exactly the understanding the habit skipped. You can outsource the typing. You cannot outsource the understanding.
- What you paste leaves your machine. A question goes to a provider with everything in it. A pasted configuration file can carry a key, and a pasted log can carry a customer's email address. Strip secrets and personal data before you ask, and know what your organisation allows to be sent where.
Getting more from it
- Say what finished looks like: the inputs, the edge cases, the error behaviour and the libraries allowed.
- Paste the code around the change, and one example of the pattern you want matched.
- For anything beyond a few lines, ask for a short plan before the code, and correct the plan.
- When it fails, give the exact error rather than a summary, and iterate.
Prompt engineering for developers covers each of these with examples.