When to put the tool down

A short list, worth being explicit about

Most writing on this subject is about how to use these tools. The complementary list is shorter and does more work, because each item is a specific situation where reaching for the tool makes the outcome worse.

When you are learning

If the point is that you understand something afterwards, generating it defeats the point entirely. The understanding came from the struggle; that is not sentiment, it is how memory works. Retrieval and effortful construction produce durable knowledge and reading a correct answer does not.

This applies to a student learning to program and equally to a senior engineer learning a new domain. When your goal is capability rather than output, the tool is in the way.

The practical form: decide before you start which mode you are in. “I am learning how the scheduler works” and “I need this fixed by four” are different activities with different correct methods, and the failure is drifting from the first into the second without noticing.

When you do not yet understand the problem

A confident answer to a question you have not finished asking is worse than no answer, because it terminates the thinking. You will accept the framing embedded in the response, and that framing was chosen by pattern-matching rather than by anybody who understands your situation.

Spend the twenty minutes. Write the ambiguity audit. Then ask.

When you are tired

The judgement required to review a generated change is higher than the judgement required to write the same change yourself, because writing constructs understanding as a side effect and reviewing does not. At the end of a long day, that gap is exactly where the plausible-and-wrong change gets accepted.

This is a real and underrated operational risk. Late in the day, in an incident, at the end of a long session: those are the moments to type it yourself or to stop.

When the stakes are asymmetric

Money, authentication, authorisation, deletion, anything that writes to another company’s system, anything that sends a message to a human, anything a regulator reads. In these places, insist on understanding every line or do not ship it.

The rule is not that generation is forbidden. It is that the review standard is line-by-line comprehension rather than plausibility, which means the time saving is close to zero, and if the time saving is zero, the tool is not doing anything for you except adding a step.

When the feedback loop is long

The payoff depends on verification being cheap. Where verification is expensive (a hardware deployment, a monthly batch job, a data migration that runs once, an embedded system in the field) the arithmetic reverses. Slow, careful, hand-written, reviewed twice.

When you need to own it for four years

Architecture, data models, the shape of a public API. These are bets on what changes next, and that is a judgement about your business rather than about code. Delegating it produces a design you did not choose and cannot defend when it needs to change.

Deliberate practice, and why to schedule it

One more, which is not a prohibition but a discipline.

Set aside a couple of hours a week and work with no assistance at all. Write the parser. Implement the retry logic. Do the binary search. Read the standard library source. You are not being efficient and that is the point.

The argument is mechanical rather than nostalgic. Your ability to review a hundred lines in ninety seconds, which is the skill that now determines your value, comes from having built those lines yourself enough times that wrongness produces a feeling before it produces an argument. That feeling is a compressed model built by practice, it decays without use, and there is no other way to acquire it.

A pianist practising scales is not trying to produce music. The scales are what make the music possible later, and nobody thinks the metronome is a productivity tool.

The one-line test

Before reaching for it, ask: is my goal output, or understanding?

Both are legitimate. They are served by opposite methods, and almost every bad outcome in this lesson comes from wanting the second while using the method for the first.