How to Use AI as a Companion, Not a Crutch

Two ways this goes wrong

The first is refusing to use these tools, usually on the grounds that they make you worse. There is a real concern buried in that, but the practical result is doing by hand what your colleagues finish in an afternoon.

The second is more common and more damaging: accepting output you cannot evaluate. Code arrives, it looks plausible, it runs on the happy path, and you ship it. You have not learned anything and you have added something to the codebase that nobody, including you, understands.

The useful position is between those, and it comes down to one rule that everything else follows from.

The rule

Use it for work you could do yourself but would rather not, and for work you are actively trying to understand. Do not use it for work you cannot evaluate.

That line is the whole thing. If you can read the output and tell whether it is right, the tool is making you faster. If you cannot, you are not delegating, you are gambling, and the debt comes due when it breaks in production and you are the person expected to fix it.

Where it is genuinely excellent

The boring middle of a task. Boilerplate, configuration, a test suite for a function whose behaviour you already know, converting data from one shape to another, a regular expression you would otherwise assemble by trial and error. This is work with a known correct answer and no learning value, and handing it over is a straightforward win.

Explaining unfamiliar code. Paste in a function from a codebase you have just joined and ask what it does. This is one of the highest value uses and one of the least discussed, because reading unfamiliar code is most of what a new job consists of.

Being a rubber duck that answers. Describing a problem out loud is a debugging technique that predates all of this. Describing it to something that responds with clarifying questions is better, and it works even when the answer it gives is wrong, because the act of articulating the problem is where you usually find the bug.

First drafts of writing. Design documents, pull request descriptions, incident summaries. Not to publish, to get past the empty page. The draft will be flat and generic and you will rewrite most of it, which is far easier than starting from nothing.

Learning a new language or library. Show it code you understand in a language you know and ask for the idiomatic equivalent. The comparison teaches faster than documentation.

Where it will quietly hurt you

Architecture and design decisions. It will produce a confident answer to what your service boundaries should be. That answer is a plausible average of things it has seen, and it knows nothing about your team, your deadline, your existing systems or your data. Design decisions are the ones you live with for years, and they are exactly the ones to make yourself.

Anything security related. Authentication, authorisation, cryptography, input handling. Generated code here is frequently subtly wrong in ways that pass review, and the failure mode is not a broken feature.

Debugging you have not attempted. Reaching for it in the first thirty seconds skips the part where you build a model of the system. Debugging is how you learn how things actually work, and outsourcing it means you never develop the instinct for where problems live.

Learning a fundamental you have been avoiding. If you do not understand recursion and it writes your recursive function, you still do not understand recursion, and you have removed the discomfort that would eventually have made you learn it.

The habit that keeps you sharp

Try first, then ask. Give the problem an honest attempt, even a failed one, before requesting help. The attempt is what makes the answer stick, because you now have a specific question rather than a general request.

This is the same reason it is worth struggling with a practice problem before opening the solution. Recognition is not recall. Reading a correct answer to a problem you never attempted produces the strong feeling of understanding and almost none of the substance.

Prompting, briefly, for engineers

Most prompting advice is written for people using a chat window casually. For engineering work, four things matter far more than any clever phrasing:

Give it the context it cannot see. Your file, the surrounding code, the versions, the constraints, what you already tried. Most disappointing output is a context problem rather than a capability problem.

Ask for the shape you want. If you need JSON, say so and give the schema. If you want three options with trade offs rather than one confident answer, ask for that, and it is usually the better request.

Let it reason before it answers. Asking it to work through the problem before producing code measurably improves the result on anything non trivial.

Iterate rather than restarting. Tell it what was wrong with the last answer. A conversation converges; repeatedly rewriting the opening request does not.

The thing about verification

Every one of these tools will state something false with exactly the same confidence it states something true. There is no tone shift, no hedging, no signal. This is not a flaw that is about to be fixed and you should structure your habits around it permanently.

Which means: run the code. Check the API actually exists. Read the generated test and confirm it would fail if the behaviour were wrong, because a test that passes against any implementation is worse than no test. Treat a cited fact as a lead, not a source.

The engineers who get the most out of these tools are not the ones with the best prompts. They are the ones with the strongest habit of verification, which is a slightly boring answer and the correct one.

What this means for your career

There is a widespread fear that using these tools will hollow out your skills. It is a reasonable fear and it is conditional rather than automatic.

It hollows you out if you use it to avoid understanding. It sharpens you if you use it to understand faster, because you can now ask unlimited questions of something that never gets impatient, and that is an enormous advantage over learning alone.

What is actually changing is which skills pay. Producing code from a clear specification is becoming cheap. Knowing what to build, telling whether an answer is right, and explaining a decision to other people are becoming more valuable, and none of them are things you can generate your way around.

So use the tools, heavily. Just make sure that at the end of every week you understand more than you did at the start, and not less.