{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"when-not-to-reach-for-it","title":"When to put the tool down","url":"https://addaly.com/learn/how-software-changed/when-not-to-reach-for-it","position":46,"of":87,"minutes":8,"answer":"Generation serves output and undermines understanding, so name which one you are after before you start, and schedule unassisted practice deliberately.","keyIdea":"Generation serves output and undermines understanding, so name which one you are after before you start, and schedule unassisted practice deliberately, because the fast review judgement everything now depends on is built only by having written the code yourself."},"body":{"format":"markdown","text":"## A short list, worth being explicit about\n\nMost 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.\n\n## When you are learning\n\nIf 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.\n\nThis 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.\n\nThe 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.\n\n## When you do not yet understand the problem\n\nA 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.\n\nSpend the twenty minutes. Write the ambiguity audit. Then ask.\n\n## When you are tired\n\nThe 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.\n\nThis 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.\n\n## When the stakes are asymmetric\n\nMoney, 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.\n\nThe 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.\n\n## When the feedback loop is long\n\nThe 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.\n\n## When you need to own it for four years\n\nArchitecture, 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.\n\n## Deliberate practice, and why to schedule it\n\nOne more, which is not a prohibition but a discipline.\n\nSet 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.\n\nThe 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.\n\nA 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.\n\n## The one-line test\n\nBefore reaching for it, ask: **is my goal output, or understanding?**\n\nBoth 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."},"check":{"question":"An engineer argues that unassisted practice is nostalgia, since the tools are not going away and time spent hand-writing code is time wasted. What is the strongest mechanical counter-argument?","options":[{"text":"The tools may become unavailable or unaffordable, so retaining the ability to work without them is basic risk management.","correct":false,"tempting":"A prudent contingency, but it defends the skill as a backup rather than as something currently load-bearing."},{"text":"Reviewing generated code quickly depends on a model of correctness built by writing code, which decays without use.","correct":true},{"text":"Hand-written code is of higher quality on average, so a proportion of unassisted work raises the codebase's overall standard.","correct":false,"tempting":"Asserts a quality difference that is not established, and would be an argument about output rather than about capability."},{"text":"Interviews still test unassisted coding, so practice is necessary to remain employable regardless of day-to-day method.","correct":false,"tempting":"A real career pressure, but it makes the practice about passing a filter rather than about the judgement the job requires."}]},"prev":{"slug":"unfamiliar-language","title":"Shipping in a language you do not know","url":"https://addaly.com/learn/how-software-changed/unfamiliar-language"},"next":{"slug":"restarting-the-conversation","title":"Knowing when to start again","url":"https://addaly.com/learn/how-software-changed/restarting-the-conversation"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'When to put the tool down', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/when-not-to-reach-for-it (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"When to put the tool down","courseTitle":"How Software Development Changed","module":{"index":5,"slug":"the-working-loop","title":"The working loop"},"answer":null,"keyIdea":"Generation serves output and undermines understanding, so name which one you are after before you start, and schedule unassisted practice deliberately, because the fast review judgement everything now depends on is built only by having written the code yourself.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"a-short-list-worth-being-explicit-about","runs":[{"text":"A short list, worth being explicit about"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"when-you-are-learning","runs":[{"text":"When you are learning"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"when-you-do-not-yet-understand-the-problem","runs":[{"text":"When you do not yet understand the problem"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Spend the twenty minutes. Write the ambiguity audit. Then ask."}]},{"t":"h2","id":"when-you-are-tired","runs":[{"text":"When you are tired"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"when-the-stakes-are-asymmetric","runs":[{"text":"When the stakes are asymmetric"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"when-the-feedback-loop-is-long","runs":[{"text":"When the feedback loop is long"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"when-you-need-to-own-it-for-four-years","runs":[{"text":"When you need to own it for four years"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"deliberate-practice-and-why-to-schedule-it","runs":[{"text":"Deliberate practice, and why to schedule it"}]},{"t":"p","runs":[{"text":"One more, which is not a prohibition but a discipline."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-one-line-test","runs":[{"text":"The one-line test"}]},{"t":"p","runs":[{"text":"Before reaching for it, ask: "},{"text":"is my goal output, or understanding?","b":true}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"An engineer argues that unassisted practice is nostalgia, since the tools are not going away and time spent hand-writing code is time wasted. What is the strongest mechanical counter-argument?"}],"options":[{"text":[{"text":"The tools may become unavailable or unaffordable, so retaining the ability to work without them is basic risk management."}],"correct":false,"tempting":[{"text":"A prudent contingency, but it defends the skill as a backup rather than as something currently load-bearing."}]},{"text":[{"text":"Reviewing generated code quickly depends on a model of correctness built by writing code, which decays without use."}],"correct":true,"tempting":null},{"text":[{"text":"Hand-written code is of higher quality on average, so a proportion of unassisted work raises the codebase’s overall standard."}],"correct":false,"tempting":[{"text":"Asserts a quality difference that is not established, and would be an argument about output rather than about capability."}]},{"text":[{"text":"Interviews still test unassisted coding, so practice is necessary to remain employable regardless of day-to-day method."}],"correct":false,"tempting":[{"text":"A real career pressure, but it makes the practice about passing a filter rather than about the judgement the job requires."}]}],"order":[3,1,0,2],"why":null},"prev":{"slug":"unfamiliar-language","title":"Shipping in a language you do not know","minutes":9},"next":{"slug":"restarting-the-conversation","title":"Knowing when to start again","minutes":8}}}