Month 1 — craft, prompts, and judgment

AWhy model-written design looks like that

These models learned from tutorial code and demo screenshots. Both optimise for a screenshot, not for a product.

1. 134Models inflate typography by default.Tutorial-scale headings and padding photograph beautifully and ship as an unusable page. Check font sizes and padding before you look at anything else.
2. 135Set explicit ceilings, or the sizes drift back.A stated maximum for headings, body text, and button padding is checkable in one pass. "Keep it reasonable" is not.
3. 136Padding accumulates through nested containers.Four wrappers each adding comfortable spacing produces hundreds of wasted pixels nobody chose. Audit the nesting, not the individual values.
4. 137Low-contrast gray text is the signature model design defect.It looks sophisticated in isolation and is unreadable in place. It appears in almost every generated interface.
5. 138Background decides text color. Taste does not.Start from the surface, then choose for contrast. "I like this gray" is how the defect gets in.
6. 139Hierarchy comes from size and weight, never from fading.Fading is what makes secondary text vanish for anyone over forty or on a dim screen.
7. 140Check every button in all its states.Default, hover, disabled. Invisible button text has been reported across many sessions and is almost always an undefined variable or a low-contrast disabled state.
8. 141A style variable used but never defined resolves to nothing.White text on a transparent background on a light page — invisible, with no error anywhere. Scan for used-but-undefined names after any variable change.
9. 142Read the existing variables before writing one line of new CSS.Otherwise the new feature arrives in invented colors and looks like it came from a different application.
10. 143Every color in the diff should trace to a value already in the file.A hex that appears nowhere else does not belong. This is checkable in seconds and catches the problem before it spreads.
11. 144Changing a root variable to fix one component breaks the page.Those values cascade everywhere. Fixing a hero background can silently restyle every heading and link.
12. 145One color family per page.Three competing accent colors read as unfinished. The fix is almost always to pick one and delete the others.
13. 146Accent color in structural text is noise; accent in structural detail is design.Colored breadcrumbs and footer links compete with content. A colored active-tab marker or focus ring is identity. Keep structural text neutral.
14. 147Buttons are sized by their label, never stretched to fill.Full-width buttons in a column read as a form nobody designed. Lay them out in a row that wraps.
15. 148Use inline vector icons, not text symbols, inside shapes.Symbol glyphs are positioned by font metrics that vary by system, so centering them is a moving target. One session lost two hours nudging three of them.
16. 149Generated pages drift into dozens of near-identical values.One measured project had three different button radii, four card paddings, and 153 unique hardcoded colors across 96 files. Nobody decided any of it.
17. 150Fix the drift by auditing values, not by adding a new standard.A new "consistent" rule that was never checked against existing ones produced a bug in 97 of 98 files, invisible because nobody opened them all.
18. 151Restraint is the credential.When everything is emphasised, nothing is heard. Over-decoration reads as novice work, especially on a page about design.
19. 152Never bold a number.Digits already stand out in a run of prose. Bolding them flattens the one thing that should have carried weight.
20. 153Every label must earn its row.Three stacked labels before the reader reaches the thing itself is decoration pretending to be structure. Let the live result carry the instruction.
21. 154The more often a control is used, the quieter it should be.Something clicked 200 times in a session should nearly disappear. Loud buttons everywhere is the trained-in default; resist it deliberately.
22. 155Importance earns reliability, not pixels.A critical action deserves a bigger hit area, a gesture, a keyboard shortcut. It does not automatically deserve to be the loudest thing on screen.
23. 156Sweep a setting before you give it a control.Some parameters have a real optimum; some just move the output without improving it. You cannot tell which by looking — only by testing across the range.
24. 157Never put a floor on a setting that has no optimum.With nothing to protect, a minimum is just one person's taste hard-coded as a limit — and it makes a whole class of output unreachable.

BLayout, mobile, and the fold

1. 158Mobile and desktop are two layouts in one file.Two files means two brains, doubled fixes, and drift from week one. The split belongs in the breakpoints.
2. 159Base styles carry appearance only; layout lives inside its breakpoint.Colors, fonts and borders in the base. Every width, height and flow rule inside its own media query, so neither layout can leak into the other.
3. 160Serving different pages by sniffing the device is worse than a breakpoint.It is wrong on tablets, wrong on a resized window, wrong on rotation, and it caches the wrong answer.
4. 161Mobile is not the desktop layout with smaller numbers.Decide explicitly what collapses, what moves into a sheet, what drops entirely. Otherwise you get wrapped toolbars and stretched buttons.
5. 162Desktop passing says nothing about mobile.Walk the narrow widths yourself: no sideways scroll, nothing clipped at either edge, text wrapping, images contained.
6. 163Use the dynamic viewport unit, not the classic one.The old unit assumes the browser chrome is hidden, so a "full screen" layout spills the moment the address bar appears — on the device you care most about.
7. 164Calculate the height budget before writing layout code.Three consecutive attempts failed in one project because nobody added the zones up first. The arithmetic takes a minute and belongs in a comment.
8. 165A tool that needs a scrollbar to reach its own controls has failed.An article may charge the reader a scroll. A tool must not charge one to find the button.
9. 166"No scrollbar" means the content fits, never that the scrollbar is hidden.Hiding it while content still overflows leaves the user unable to reach the rest — strictly worse than the original problem.
10. 167Fix the component that overflows, not the wrapper around it.Capping a section's height silently clipped the buttons underneath a grid at many window sizes, and looked contained the whole time.
11. 168A container whose children come and go must keep a constant height.Otherwise the interface dances every time a status message arrives — and this is one of the most persistent bugs there is.
12. 169Reserve space for anything fixed to an edge.Fixed elements sit outside the normal flow, so the last item in a panel ends up behind the bar. One project had a section invisible for weeks before anyone noticed.
13. 170Panels that slide over content must never sit in the document flow.Put one inside a flex container and it steals space and crushes the layout — reliably, every time someone touches it.
14. 171Floating children need a stacking context on the parent.Sticky bars create their own. Without one on the parent, dropdowns and tooltips render into the wrong layer and get clipped behind the bar.
15. 172Wrap any third-party widget with its own stacking context.Map and editor libraries ship their own layering that leaks over your overlays. Contain it, and put your dialogs well above.
16. 173Use your own tooltips inside your wrapper, never the library's.The built-in one positions itself against the window and lands under your header.
17. 174Never rebuild a list's markup on every keystroke.Render once and toggle a hidden class. Rebuilding tears down thousands of nodes per second, flashes the page, and loses scroll position.
18. 175Reset scroll position on any reused panel before showing new content.Otherwise it opens halfway down where the last user left it, which reads as broken.
19. 176Put the transition on the active state, not the base state.On the base state, both the closing and opening panel animate at once and are briefly visible together.
20. 177Cancel timers when a view closes.Animation chains kept running for 38 seconds against a hidden panel and shifted the layout of whatever the user had moved to.
21. 178Show a skeleton, never a blank screen or the word "Loading".Blank reads as broken or empty. A shape that matches the final layout reads as "content is coming" at identical actual speed.
22. 179Derive card dimensions from the worst case in the real data.Find the longest title and the longest description in the actual dataset first, then size the card. Guessing produces clipping in production.
23. 180Content beats title for space.The title is a label, not a billboard. Give the reading content the room.
24. 181Empty space with no signal is the highest-attrition thing on a page.A screen that opens with nothing to see gives the reader no reason to scroll. Get to the content fast; hint at what is below.

CHow prompts really behave

1. 182Constrain output at the API, not in the prose."Respond with only the code" is a request the model can ignore. Starting its reply for it is a guarantee it physically cannot write a preamble.
2. 183Validate the shape before you display or save.A check that looks for an opening tag will happily accept an essay that mentions one. Require real structure: element counts, almost no loose prose.
3. 184The model's raw words never reach the screen.Not in results, not in debug output, not in errors. One failure printed a model's entire internal planning essay onto a user's page.
4. 185User-facing errors are a whitelist, not a passthrough.Only sentences a human wrote may render. Everything else collapses to one clean line. Mark the human-written ones explicitly.
5. 186You should be able to list every possible outcome of a generation.The result, or one of a small set of named failures. If you cannot enumerate them, there is a leak somewhere.
6. 187Client and server must run the same validation.If they drift, you get output that displays but never saves, or garbage that saves but never displayed.
7. 188After a bad incident, sweep the data you already stored.A fixed check protects the future. The past is still sitting in your database looking exactly like good data.
8. 189Any word in a prompt may come back in the output.Naming a word in an instruction makes it likely in the answer. Describe the feeling you want, never the word you expect.
9. 190Some words drag output to its most generic version.Stock abstractions with strong canonical meanings pull everything toward the median. One project maintains a banned list of fifty and enforces it at zero occurrences.
10. 191Ban them in your code and your own speech too.Variable names, file names, endpoints, and how you describe the task. What you name it shapes what gets written next.
11. 192Watch for the substitution trap.Ban a tired word and the model reaches for an equally tired synonym. Re-check the frequency list after any ban, not just once.
12. 193Ban the vocabulary, not the subject.A constraint on language is craft. A constraint on theme is you overriding the brief you were given.
13. 194Constraints go at the end, marked as never-output.Rules buried in the body get quoted back verbatim as if they were the answer. Position matters: the end gets the most attention.
14. 195Long prompts bury the middle.Anything sitting between the opening and the final block gets the least weight, so the settings a user actually chose can be overwritten by rules read later.
15. 196Soft conditionals do not work. Build two prompts and choose in code."Apply this only when X" gets routed around with synonyms and partial compliance. Decide before the model sees anything.
16. 197One prompt for every situation is a design failure.Universal prompts accumulate instructions that only apply sometimes. Separate prompt families, each carrying only its own constraints, beat one prompt carrying all of them.
17. 198Sameness is not fixed by adding more rules.More instructions become the new mould. Generate each item in its own call with one small concrete ask — less structure produces more variety, not less.
18. 199Examples teach; instructions describe.A model learns style from a real example, not from adjectives about the style. Generic guidance produces generic output no matter how carefully it is worded.
19. 200Two good examples beat twelve.Two set the floor. More crowds the context and starts producing averages of the examples rather than work in their spirit.
20. 201Bad examples do more damage than missing ones.Whatever you show gets matched, including the flaws. Curate what goes in the prompt as carefully as what comes out.
21. 202Ask for the answer first, then the problem around it.For anything with a correct solution, deciding the answer first and constructing backwards took one pipeline from 70% correct to nearly always correct.
22. 203Do not suppress reasoning when accuracy matters."Only output JSON" removes the working-out that produced the right answer. Let it reason, then extract.
23. 204Ask for a self-check as an explicit step."Verify each constraint against your answer" catches a real share of errors before the output ever reaches you.
24. 205State the obvious counts explicitly.If there are five slots there must be five items. Left unstated, the model assumes they can differ, and sometimes they do.
25. 206"Understand the source first" is an instruction for a human, not a model.Anything loaded as understanding sits in context and leaks into everything downstream. The output paraphrases the source instead of abstracting from it.
26. 207To get output independent of a source, never show it the source.Not the text, not a summary of it. Either extract mechanically or generate from a structural description alone.
27. 208"Recall" and "generate" produce different things.Asked to generate, a model invents plausible material. Asked to recall, it draws on what it has actually seen. If you want real examples, the verb matters.
28. 209Fixing the prompt does not fix the rows already stored.The improved version serves fresh output while the old broken records still surface in search and library views.
29. 210Never use a model for a job a script does exactly.Keyword intersection, matching, sorting, counting. A script runs in a second, costs nothing, and never hangs. Reserve the model for judgment.

DContent the model writes

1. 211Ask for one entry per unique item, explicitly.Models work token by token, so "list every X" returns one entry per occurrence. A word appearing three times gets three identical rows.
2. 212Deduplicate at the source, not in the display layer.Hiding duplicates on screen leaves them in the data for everything downstream to trip over.
3. 213A question with two defensible answers is broken.Fix the question, not the options. If an expert could argue for a second choice, it fails regardless of how the answer key reads.
4. 214Every option must belong to the same family.If one is a phrase and the others are single words, the reader picks by shape instead of by understanding — and learns nothing.
5. 215Wrong options must be genuinely tempting.A wrong answer that is absurd is not a distractor, it is padding. It should sit in the same conceptual space as the right one.
6. 216A question must stand alone.One that only makes sense if you just read the surrounding page is unusable anywhere else, and confusing where it is.
7. 217Feedback teaches or it is filler."Correct!" and "Look again" both teach nothing. Name the specific confusion, then resolve it.
8. 218Honour the mistake that was actually made.Generic feedback after a specific wrong answer reads as indifference. The response should address the choice the person made.
9. 219Never ship a hardcoded fallback that reads as real content.One template fired the same hint for every question of its type — including on a sentence where the hint was nonsense. Missing data should disable the feature, not fabricate.
10. 220Never let a default carry content from the first case you built.One viewer was built for a single word and silently served that word's data for every word after it. Defaults must be empty, and access must be generic.
11. 221Set an explicit length rule and keep the awkward middle empty.Prose that barely overflows its container produces broken-looking scroll indicators. Short or long, never just-over.
12. 222Cap paragraph length for anything read on a phone.A 145-word paragraph is about twelve unbroken lines on a narrow screen. The voice is lost regardless of how well the sentences are written.
13. 223Ask for plain English and get plain English back.Models reward information density because other models score it highly. A human reader gets respect without understanding.
14. 224A hard word needs a plain-word handshake before it appears.Introduce the idea in ordinary language, then name it. The depth is unchanged; the door is wider. Every unexplained term is a gate.
15. 225If the reader could have guessed it, nothing was written.Every section should contain at least one moment of "I never framed it that way." Otherwise you produced words, not content.
16. 226Specificity is what makes writing land.A named, concrete situation carries further than the general principle it illustrates. The general version is a poster; the specific one is true.
17. 227Show the mechanism, not just the claim.Naming a feeling is validation. Explaining why it happens is the reason anyone stays past the first paragraph.
18. 228Missing sections beat wrong content.A gap is visible and fixable. Confidently wrong material gets read, trusted, and repeated.

EData, schemas, and identity

1. 229Identity is a unique ID, never a name.Names collide. Keying anything — ratings, links, lookups — by name eventually returns the wrong record with total confidence.
2. 230Know which store is authoritative for each field.A value copied into two places will disagree, and the stale copy is usually the one being read. One project had a rating column that had been wrong for months.
3. 231Define your identifiers before you build around them.User, device, session. Which one owns which data, and what happens on migration. Retrofitting this loses people's data.
4. 232Namespace IDs at import, not in the source files.The same local ID pattern repeats across sources. Prefixing on the way in keeps each file readable and the combined set unique.
5. 233Split a dataset by shape, keyed on the same ID.Metadata, geometry and text in one giant record becomes unworkable past a certain size. Parallel files, checked programmatically for alignment.
6. 234Add the verification into the generator itself.Minimum counts, required fields, cross-references present. A record that fails should never reach the file.
7. 235Verify that referenced text actually appears where it claims to.When one field quotes another, near-matches fail silently and the feature is simply dead in the browser with no error.
8. 236A missing field should disable a feature loudly, not fail quietly.Silent absence looks identical to a rendering bug and gets diagnosed as one, days later.
9. 237Cache shared results on the server, never per user.One lookup should serve every future request for the same thing. Per-client caching pays for the same answer over and over.
10. 238Pre-compute the common cases; let the long tail fill itself.A cheap warm-start covers most real traffic, and the rest accumulates at near-zero marginal cost.
11. 239Move to a real database before the JSON file hurts.Loading a large file into memory for every query stops working at a size you will reach sooner than you think.
12. 240Search by meaning, not by name matching.Abstract terms have no literal match, so name search silently returns generic results. This one wastes half an hour every time because keyword search feels like the obvious approach.

FJudgment

1. 241Do not compress an open universe into a neat number.Proposing "the 500 templates" for something the world has been producing for centuries is the model's context limit dressed up as a taxonomy.
2. 242Closed sets can be listed. Open ones need a method.File formats can be enumerated. Metaphors, registers and narrative shapes cannot. For those, build the generator, not the list.
3. 243Check whether it already exists before proposing to build it.Offering to build five hundred of something the user already has twenty thousand of is worse than useless.
4. 244Estimate at machine speed, not human speed.Estimates in one project were wrong by 30 to 100 times, repeatedly — three files edited in parallel plus one test run is seconds, not the half hour that gets quoted.
5. 245Describe scope instead of duration.What is in it, what is reused, what is new, what is uncertain. Time ranges without that decomposition look arbitrary and anchor the decision anyway.
6. 246When something is unreliable, fix it — do not wrap it in a check.A health ping, a retry, a fallback message: all treat the symptom. The guard then becomes permanent and the real problem becomes invisible.
7. 247Two failed attempts at the same visual mean the concept is wrong.Do not keep adjusting the geometry. Pick a different image that carries the same meaning; it usually works in one pass.
8. 248An unintended reading is a reason to pivot immediately.If it reads as something you did not intend, the shape combination is the problem. Softening it will not remove the reading.
9. 249Study the good examples before proposing how to make more.Two full generation rounds failed in one project because the pipeline was designed from category names instead of from the actual best work.
10. 250Use the curated library you already paid for.Reaching for a generic symbol when a semantically-matched one already exists in your own database is homework not done.
11. 251Never scale after a failure without diagnosing it first.A second failed batch straight after the first, with only a guess in between, wastes the money and the goodwill together.
12. 252Match model to task, and test the cheap one first.Measured on one job: the smaller models could not do it at all, while the capable one at minimum reasoning was eleven times cheaper and six times faster than at default with no quality loss.
13. 253Some tasks are simply outside a model's ability. Find out early.Three of four models tested could not interpret vector graphics at all. Three test items would have shown it before the pipeline was built around it.
14. 254Four locks before any large run: a written contract, a validator, an approved small batch, a cost audit.All four. Three is how a large run produces a large amount of unusable output.
15. 255Do not confuse the review tool with the product.Building polished experience into a checking tool wastes effort and makes people evaluate the wrong thing. Lock the content first.
16. 256Reuse only when it genuinely fits the subject.Reaching for an existing pattern because it is cheap produces something that works and means nothing. Ask what the material actually asks the reader to do.
17. 257Keep the mechanism out of the interface.If the labels describe your method, anyone reading the page learns your method. The user controls the outcome; the system keeps the how.
18. 258Users see purpose, never your schema.Internal codes, band names and stage numbers leaking into visible text is the most common polish failure, and it is a single audit pass to fix.

GMaking any of this stick

1. 259A recorded lesson is not an enforced one.An archive changes nothing next session. Only rules that load automatically every time actually alter behaviour.
2. 260Record the story and enforce the rule — two separate moves.The incident, the quotes and the nuance go in the archive. The one-line law goes where it loads every session. Doing only the first is why the same lesson gets paid for twice.
3. 261Knowing a rule and following it under pressure are different things.A model can recite every rule here and break three of them in the same session. Better models do not fix this; competence just makes skipping the check feel safer.
4. 262The strongest enforcement is a tool that refuses.Safety as the default behaviour of the tool costs nothing to remember. Safety as something to opt into gets skipped exactly when the pressure is on.
5. 263Put the referee outside the player.A check that blocks the action holds across every session and every model, with nothing to remember. Prose rules erode; a gate does not.
6. 264Name honestly what cannot be enforced.Nothing can force a model to talk during a long task. Knowing which rules rest on discipline alone tells you which ones to check yourself.
7. 265Write rules for a person, not for a machine.Shorthand written for a model is not understood by the model either. If someone walking in cold cannot follow it in one pass, it will not be applied.
8. 266A longer plain document beats a dense one.These files get opened at the worst possible moment — when something is broken. That is not when anyone should be decoding notation.
9. 267Keep the always-loaded set small.Everything cannot be top priority. A bloated standing file is skimmed, and then the three rules that mattered are skimmed too.
10. 268Keep the log append-only.Superseded entries stay visible so the reasoning is readable later. Deleting them hides why the rule changed, which is usually the useful part.
11. 269Update the record before declaring the work done.Afterwards means never. The detail that made it worth recording is already gone by the next session.
12. 270Every rule here was paid for once. That is the only reason to keep it.Not one of these is theory. Each came from a specific session where something broke, and each is written so nobody has to buy that lesson twice.