A memorable line leaves work to do
Short lines travel well because they leave conditions unstated. Treating one as a universal instruction can turn a warning about maintenance into a contest over line counts. Each card below adds the missing context: meaning, problem, conditions, and a next action.
Maintenance cost: speed leaves responsibility behind
Maintaining code is not cheap
Meaning here: producing an implementation still leaves someone responsible for its upkeep.
— Matt Pocock
Ask who will change the feature, investigate a failure, and update duplicated behavior. Cheap generation does not remove any of those jobs.
Problem
Estimating cost from generation speed while ignoring later changes.
Conditions
You are deciding whether a feature or implementation deserves to stay.
Next action
Find one unused feature or duplicate implementation and specify evidence for removing it safely.
Code as a liability: prove the simplification
All code is debt.
Meaning here: an implementation brings possible future obligations.
— Matt Pocock
A useful validation, a clear name, or a necessary abstraction also takes code. Return to core ideas and consider the cost of changing behavior alongside the amount of implementation.
Problem
Keeping every generated addition without assessing its value.
Conditions
Expected behavior is known and you can compare results before and after a change.
Next action
Simplify one duplicate branch and check both valid and exceptional paths.
Growing skill: practice judgment
Your skill level acts as a ceiling for the agent
Meaning here: your ability to judge the work affects what you can reliably achieve with an agent.
— Matt Pocock
Read this as a personal judgment. It is not an experimental law or a verdict on anyone's potential. Ask a more useful question: can you read the change, investigate the failure, explain the states, and identify review risks?
Problem
Accepting completion claims you cannot evaluate.
Conditions
You need to judge whether an implementation and its evidence deserve confidence.
Next action
Choose reading, debugging, modeling, or review practice from the learning paths.
Exercise: where did the complexity go?
Imagine checkout code compressing membership, expiry, and refund eligibility into one nested expression. It has half as many lines, but a failure no longer tells the reader which condition mattered. Write a review response before opening the suggested answer.
Ask for evidence of a simplification
- Task: identify which of the three lines could most easily be misused to justify the compression.
- Deliverable: recommend keeping or changing it, with one readability reason and one behavior check.
- Check: can another reader locate the refund branch for an expired membership?
Suggested approach
Treating code as a liability does not prove that compression helps. Name the relevant conditions and verify refund behavior for expired and active memberships. Compare understanding and change costs before deciding.
Try a second counterexample: clear error messages add code but make a failure easier to investigate. Explain why that addition earns its place. If a slogan cannot settle the question, supply the missing context and tradeoff.
What counts as done?
Your answer addresses readability, behavior, and maintenance cost. It also identifies a judgment the quotation cannot make for you. A shorter implementation alone does not explain how someone will maintain it.
Quick reference
Maintenance cost
Delivery leaves future changes and investigations.
Code liability
Establish the benefit before reducing implementation.
Growing skill
Practice the part of the work you cannot yet verify.
Sources
Independent, unofficial, noncommercial study notes. This site has no affiliation with or endorsement from Matt Pocock. Referenced works belong to their authors; MIT reuse carries separate copyright and license notices.