AI Coding Assistant

Help from the side

The most visible feature is suggesting the next line. Type a few characters and the rest appears in gray, ready to accept if it looks right. The more standard the shape of the code, the better it guesses.

Second is filling in repeated patterns. In spots where a similar shape repeats twenty times, or where you're just reformatting and retyping, the time saved is large — that kind of work is tedious and easy to slip up on.

Third is time spent looking things up. Where you once searched for usage and copied an example, now you describe what you're trying to do and the shape appears on the spot. Not breaking your flow turns out to matter more than it sounds.

Used more for reading than writing

Run into unfamiliar code and ask "explain in one paragraph what this does," and the time it takes to skim drops sharply — especially when you're picking up something someone else built.

Pasting in an error message and asking what it means or where to look first is another big use. The message itself reads like something a machine wrote, baffling at first glance, but put into plain language it gives you somewhere to start.

You can also ask what's risky before you even run it — missing edge cases, spots that break on an empty value, what happens when a number gets very large. Asking gets you something like a second review.

Why checking is essential

A suggestion is built to look convincing first. It sometimes uses a feature that doesn't actually exist as if it did, or reaches for an outdated approach. It looks natural enough on the surface that it's easy to just accept.

Running without errors doesn't mean it's correct, either. Code that works fine on ordinary input and breaks on an empty or very large value is common. People make this mistake too, but accepting a lot of code quickly means more of these spots pile up.

How much you're sending out matters as well. Whether it's fine to paste in company code or something containing user data varies by tool and by company policy.

How to use it well

Ask for small pieces at a time. Request the whole thing in one go and it gets hard to find where it went wrong. Take one piece, run it, and only then move to the next.

It's also worth building the habit of asking why it did something this way before accepting it. If the explanation falls apart, the code usually has a problem too. Pasting in code you don't understand is the riskiest habit there is.

If you're still learning, flip the order: write it yourself first, get stuck, then ask, and compare the answer against your own. Taking dictation from the start doesn't grow your ability to read and judge code.

Asking it to write a quick test alongside the code is a good habit too. A short check for which cases the code should handle correctly means you know exactly what broke the next time you go back to fix something.