Assistance That Works Beside You

One common form of AI help sits in the editor while you work. It offers suggestions you can inspect before accepting them.

That is the half of the field worth understanding first: its small suggestions give you a manageable place to practice reading and checking code.

Finishing what you started

Completion watches what you are writing and offers the rest. Sometimes a few words, sometimes a whole function.

The interesting part is how much context it now uses. Give a function a clear name and a line describing what it should do, and a good completion will often produce a reasonable body, because the name and the comment told it what you meant. Write vague names and you get vague suggestions, which is a small daily reminder that naming things carefully was always doing more work than it looked like.

With suggestion-only completion, you accept or ignore each one. Accepting adds the code; it does not establish that the code is correct. Tools that also run commands or make wider changes need the permissions and review discussed in the next lesson.

Changing a piece of code you point at

Select some code, describe the change, and the tool rewrites that selection. “Handle the case where the file is missing.” “Turn this into a function that takes the folder as an argument.” “Make this work for a list of files instead of one.”

This is a useful way to keep the work focused: small enough to inspect as one change, specific enough that you already know what you were asking for.

Asking about code that already exists

This one changed my working life more than any other, and it is the one I would push hardest on a beginner.

You can point a conversation at real code and ask what it does. Not a textbook example: the actual file in front of you, with its odd names and its history. You can ask why a line is there, what breaks if you delete it, what a piece of unfamiliar syntax means, or what the author was probably worried about.

For someone learning, that can make an unfamiliar file much more approachable. The explanation can still be wrong. Ask the tool to point to the lines that support its explanation, then compare what it says with the code and what happens when you run it.

Explaining what went wrong

Share an error message after removing passwords, private data, or other details the tool should not receive. Ask what it means and what to check next. A suggested cause is something to investigate, not a diagnosis you have to accept.

An error report can be difficult to read before you know its terms. Having something explain it on demand can help you find a next step instead of changing code at random.

Drafting the parts nobody enjoys

Tests, documentation, commit messages, example data, the conversion between one shape of data and another. AI can draft these quickly. Reviewing them still means checking their claims: a test is a check that compares what a program does with what you expect, and it can check the wrong expectation.

What this half has in common

These forms of help can work in small units you can inspect: one suggestion, one selection, one answer. That makes checking more manageable, but a mistake can still be hard to spot, even in one line.

For learning, that is a useful starting point. Read the suggestion, ask about what you do not recognize, and compare its behavior with a result you can work out yourself. Seeing the code is an opportunity to check it, not proof that you have caught every mistake.

The other half of the field does not work that way. There you hand over a goal, the tool works for a while on its own, and you review the result rather than the keystrokes. That changes what your judgment is for, which is next.