Sign in to keep reading
“Design” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueNEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
NEW: ML Mock & Coaching with a 20+ year experience coach. Save $20 on sessions for Premium.ML Mock & Coaching now available
Holding a code-review standard the model will not hold for you — minimal diffs, fitting the codebase you were given, and refusing plausible-looking code that is worse than what was already there.
“Design” is free with an account. Your progress and bookmarks follow you across devices.
Sign in to continueWould You Approve It?
Could you answer these today? Tick what you already know.
Design Drills
Drill 1 — Review your own generations. For a week, before accepting anything over twenty lines, read it as a pull request and write one comment you would leave. Notice how often you have one.
Drill 2 — The minimal-diff challenge. Next bug you fix with AI help, set an explicit constraint: change as few lines as possible. Compare against what the model first proposed.
Drill 3 — Find the helper. Before generating any utility, spend sixty seconds searching the codebase for it. Track how often it already existed.
Drill 4 — Justify the complexity. For each abstraction in your result, name the requirement forcing it. Anything you cannot tie to a requirement is speculative — remove it and see if anything breaks.
Design asks the question that survives the interview: is the thing you shipped any good?
Not whether it passes. Whether a colleague opening this diff on Monday would approve it. Models are extremely good at producing code that passes and only adequate at producing code that is good, and the gap between those two is where this dimension lives.
A model optimizes for a plausible, generally-good answer. It does not know that your team decided against that abstraction last quarter, that this module deliberately avoids inheritance, or that the interface it is rewriting has four callers.
That produces a recognizable set of design failures:
| How Generated Code Goes Wrong | ||
|---|---|---|
| Failure | What it looks like | What it costs you |
| Rewrite instead of fix | A bug in one function comes back as a restructured class | You now own a large diff you did not design, on a problem that needed three lines |
| Speculative generality | Config objects, strategy patterns, and hooks for requirements nobody stated | Reads as pattern-matching rather than judgment |
| Pattern mismatch | Correct code written in a style the surrounding module does not use | Signals you never read the codebase you were changing |
| Silent dependency | A new import to do something the standard library already does | In an interview, an unexplained dependency is a question you will have to answer |
| Rebuilt helpers | Reimplements a utility that already exists two files over | Direct evidence that orientation was skipped |
The last one is worth dwelling on. Asking the model to build something the repository already has is one of the clearest signals that you never looked. It is also completely avoidable with the orientation pass from the fluency lesson.