Week 1 — the habits that decide whether the work holds

AReading, and what "I read it" hides

Roughly half of everything that goes wrong traces back to the model producing where it should have been reading.

1. 46Make it prove the read: the file list and a rough token count.A verifiable list turns "I understand" into something you can check in three seconds.
2. 47"Read all N files" means N literal reads in this conversation.Not a search, not a sample, not a script that opens them. One project lost two days to seven separate promises to read that were each quietly dodged.
3. 48A subagent report is not a read.It returns a synthesis that looks like a read. Worse, when the context compacts, the fake read freezes into the summary as though it were real.
4. 49A file too big to read at once gets split, never skipped.Read it in offset chunks. "I got the pattern, I can infer the rest" is where the specific bugs hide — the ones only found by reading actual code.
5. 50Read the whole reference file, not its first eighty lines.Skimming the top gives you the variables. Reading it all gives you the design decisions. One build invented a worse interaction model three times because the core of the file was never opened.
6. 51"Read everything" is worse than "read these three."Attention thins as context fills. Fifty files dilute the three that matter. Curate before the deep read.
7. 52But when you do say read it all, enforce it.A half-read foundation means hours of patching on sand. Reading is the cheap part of the job.
8. 53Never let it search your whole drive.On a large tree that crawl runs for an hour and blocks everything. Name the folder — or just tell it where the thing lives.
9. 54Re-reading the same file twice in a session is a reflex, not a need.Make it state what it already knows first. If it can state it, it does not need to read it again.
10. 55Read the consumer before writing the producer.Five minutes reading the thing that eats your output saves a failed run, a wasted API call, and a debugging session.
11. 56Read every generator in the folder, not the first two you find.One project had 35 generation scripts recording an evolution. The good output came from a specific one; two failed batches happened because nobody found out which.
12. 57When told "copy from X", it must quote X back.The simplest possible check. If it cannot show the path and quote the first lines, it is generating and calling it copying.

BBatches, parallelism, and APIs

This is where the money is, and where the silent failures live.

1. 58A loop that awaits each call is not parallel.A concurrency limiter caps parallelism, it never creates it. You need the gather-style dispatch as well.
2. 59Any script past five API calls runs in parallel.One sequential build turned a 15-minute job into three hours. If you wanted to wait hours you would have used the discount batch endpoint at half the price.
3. 60Stagger the submissions rather than firing them all at once.A tight submit loop is a thundering herd. You rate-limit yourself, from one machine, with no help from anyone.
4. 61Find the worker count by measuring, not by feel.One measured case: eight workers gave a 32% failure rate, four gave 0.5%. The right number is the highest that holds failures under one percent.
5. 62Halving the workers helps more than adding delay.Spacing only spreads one burst. Fewer workers cuts the total number of requests in flight, which is what actually trips the limit.
6. 63One planned call means one attempt. No retry loops.Retrying inside a rate-limit event compounds the burst and extends the ban. Surface the failure; sweep it up with a resume pass.
7. 64A 1% failure rate on a long run is normal. Plan the resume, not the retry.Some failures are transient network noise, not rate limits. One clean resume pass afterwards catches every skipped item.
8. 65Every batch needs test, resume, and a cap — all three.Crashing at 200 of 355 should never mean redoing 200.
9. 66Checkpoint per batch, not per run.Resume is only as good as the last write. Per-batch checkpoints make any crash cost one batch.
10. 67Estimate output size before a structured generation.Long JSON hits the output ceiling and truncates mid-string. The script reports success and writes a broken file. Split across parallel calls.
11. 68Ask for structured output at the API level, not in the prose.A JSON response type gave one pipeline zero parse failures across 58 batches. Asking nicely in the prompt does not.
12. 69For bulk runs, call the API directly — do not route through your own server.One server process serializes everything behind it no matter how many workers you spawn. One measured stack spent 13s per call on overhead against 1-2s of actual model time.
13. 70Read the token counts the API already returns.Most code throws that block away and then estimates cost. The true number was free and sitting in the same response.
14. 71Update the cost-per-call constant when anything changes.It is baked in at build time. New pricing, longer prompts, or added steps make the pre-flight check show a number that is quietly wrong.
15. 72One well-framed pass beats a generate-then-critique pipeline.A three-script, two-wave audit produced the same outcome as a single prompt asking "is this right, or should it change, and treat sideways swaps as noise" — at double the tokens and much more of your attention.
16. 73One item per call when the output must be verified.Ask for fifteen at once and the model skips its own checking to finish the payload. Pass rates in one measured pipeline went from 70% to 90-100% on this change alone.
17. 74Keep the API key in exactly one place, and make the script refuse to run without it.Two copies means rotating one and silently running half your tools against a dead key. A fallback to an unknown key is worse than a crash.

CVerification that actually verifies

1. 75Count elements against the source, every build.If the data has three items, the page must render three. This single check caught three separate "successful" builds that had produced empty sections.
2. 76Sanity-check the file size.If a bigger input produced a smaller output, something dropped silently. Investigate before declaring anything.
3. 77Verify the deployed artifact, never the script that generates it.Scripts get edited; generated files get stale. One session argued from a fixed build script while the browser was still loading output from two days earlier.
4. 78Compare timestamps when there is a build step.If the source is newer than the artifact, the build never ran. Thirty seconds of checking, a credibility hit avoided.
5. 79Data checks and API checks do not cover the render layer.The database can be perfect and the page can still read old field names and show blanks, with no error anywhere.
6. 80Open a real page when the feature fetches anything at runtime.Opening files directly from disk blocks those fetches entirely — the feature falls back to defaults and looks fine to every static check.
7. 81Embed data at build time instead of fetching it at runtime where you can.No network call means no silent failure mode. This is the fix, not a workaround.
8. 82A test running on invented data is not a test.One session generated its own sample input, ran the pipeline, reported zero errors — and every component broke on real data because the shapes were wrong.
9. 83An automated validator passing is not quality.Twenty icons can pass every check and still look like random shapes to a person.
10. 84Test content where the user meets it, not where you review it.A hint reads fine beside the correct answer in a review tool. The same hint after a wrong guess can feel like a slap.
11. 85Ask for the browser check only when you want certainty, and expect it to be real.It is the only thing that catches a field-name mismatch between server and page. It is also the thing most often claimed without being done.
12. 86Report format: symptom, cause, exact fix, what was verified, what was not.Five lines. It makes an unverifiable claim impossible to write by accident.

DCode traps that repeat in every project

1. 87Catch-all error handling hides real bugs.A typo becomes an indistinguishable "API error" string. You debug the network for an hour; the bug was a misspelled variable.
2. 88Helper functions cannot see the caller's variables.Obvious written down, invisible in practice — and combined with catch-all handling it surfaces as a fake network error.
3. 89Trace the value the client actually sends before writing a rule about it.The client may prefix or transform it. Testing by hand with the logical name proves nothing about the real path.
4. 90Check the file's format before writing to it.A leading bracket means load-extend-rewrite. A record on line one means append lines. Guessing corrupts the file.
5. 91Audit a dedup key before changing it.Run the new logic on a copy and compare counts. A change that drops more than 5% is almost certainly collapsing things it should not.
6. 92Two failed patches mean the diagnosis is wrong.A third patch only adds contradictions. Stop, re-read, rewrite the section cleanly.
7. 93Corrected twice on the same thing? Stop patching forward.That loop is where the hours and the tokens die. Re-read from scratch and say what was re-read.
8. 94Fix one instance of a bug class, then list every other instance.Fixing two of six and calling the category solved leaves four landmines with no record they exist.
9. 95Mark the ones you are not fixing, in the code, with the reason.A comment above the unfixed line survives compaction and staff changes. Conversation does not.
10. 96Renames need a hunt for strings built at runtime.Literal search-and-replace catches half the surface. Paths assembled from variables slip through every sweep and 404 later, in the browser, in front of you.
11. 97Read a guard's comment before removing it.Every threshold and lock was added after something broke. One bypass removed duplicate-call protection that was quietly saving money.
12. 98The surgical fix beats the wholesale bypass, always.In one incident only one of three locks was actually the problem. Removing all three fixed the symptom and reopened two old bugs.
13. 99Every comment says why, not what.A date and a label is not a comment. What was broken, why this approach, what breaks if removed.
14. 100Document what was tried and failed, especially in layout code.Otherwise the next session — or the next person — repeats the same three failed approaches in the same order.
15. 101The editing tool chokes silently on very large files.It looks like the model is stuck waiting for you. Have it write a small script to make the edit instead.
16. 102Prefer the deterministic script over the model call.Splitting, tagging, matching, reformatting — a script does these in a second, for free, and never invents anything.
17. 103Non-ASCII characters in log output crash processes on Windows.An arrow or a curly quote in a log line kills the run with an encoding error. Every generation fails until someone finds it.
18. 104A hash inside a string is not a comment.It is literal text, and it gets sent to the model and echoed back to users. Internal notes have leaked into production output this way.

EServers and processes

1. 105A free port does not mean the process is dead.Orphaned processes hold memory and stale connections with no port open. Check the process list as well as the port.
2. 106Kill by port, never by program name.Killing everything by name takes down unrelated work. And failed kills accumulate: with five instances running, most requests hit old code.
3. 107Verify exactly one instance after every restart.Not zero, not five. The check takes one command and prevents the most confusing class of bug there is.
4. 108"Slow but no errors" usually means a zombie process.Stale keep-alive connections queue up in front of the live server. A clean restart fixes it; nothing in the logs points to it.
5. 109A model cannot reliably start a lasting server from its own shell.The shell exits, the child dies, the port flickers and vanishes. It looks like it started and crashed. Use a launcher owned by your own session.
6. 110Use a single idempotent launcher, not ad-hoc start commands.Ad-hoc starts race each other for ports. One project had four separate breakages in one day, including a bare file server silently replacing the real app.
7. 111A single-threaded dev server blocks everything during one slow call.Your browser tab spins for the whole duration of one model call, and it looks like the page is broken.
8. 112Do not let an open page re-poll after every update.Perpetual loading, wasted compute, and real API spend from a tab nobody is looking at. Update counts on the client instead.

FWorking rhythm

1. 113Approve the plan once, then let it run to the end.Asking permission at every obvious next step turns a ten-minute job into ninety and reads as sharing the blame rather than carrying the work.
2. 114The check happens before work starts, not in the middle."A or B?" up front is useful. The same question mid-execution is an interruption of something already agreed.
3. 115Interrupt-worthy: real spend, destruction, a genuine fork. Nothing else.Name the list explicitly and the constant check-ins stop.
4. 116When it asks you a question, that reply should end there.Question plus four more tool calls means it did not actually want your answer, and you now have to untangle work built on a guess.
5. 117When the fix is obvious, no options and no plan — just the fix.Laying out a four-bullet plan to undo its own mistake reads as justification. You already know what needs to happen.
6. 118Two options when one is clearly right is theater.If your stated goal implies the answer, the manufactured alternative is padding — and sometimes it reintroduces the exact problem you were solving.
7. 119Ask for ranking, not a flat list.Five bullets at equal weight means the model handed you its sorting job. One thing that matters, then the rest.
8. 120Simplest route first, alternatives clearly after.Not the most thorough or elegant — the shortest honest one. Interleaving them is what makes plans unreadable.
9. 121Ask for plain words, and say so once.Reports arrive in the vocabulary of the work — schemas, pipelines, stages. That is a missing translation step, not necessary precision.
10. 122Answer the question that was asked, then stop.Unsolicited phase plans and gap audits are the model scope-creeping decisions that are yours.
11. 123Multi-part feedback gets addressed in every part.Acting on part one and ignoring two and three means you repeat yourself, and it looks like the rest was never read.
12. 124Ask for the live link with every deliverable.A file path tells you where the source lives. The URL tells you where to see it work. You need both, every time, without asking.
13. 125Ask for the full paths of everything changed, at the end.You navigate outside the editor. A list of complete paths is the difference between reviewing the work and hunting for it.

GWhen it goes wrong

1. 126The first move on a bug is a diff against the last known good version.Not theorizing, not searching. The diff shows exactly what changed since it worked.
2. 127A restore is almost always the wrong move.The backup predates your last manual work. Fix the specific broken thing, and confirm before restoring anything.
3. 128After a failure, the correct response is to slow down.Frustration triggers faster patching, which produces more failures. Stopping to reconnect goal, drift, and cause is the only thing that breaks the loop.
4. 129A failed task stops and explains. It does not silently retry.Three silent retries over 45 minutes taught this once. The failure was diagnosable in thirty seconds of conversation.
5. 130Getting it wrong once is fine. Repeating it after correction is the problem.Failure is learning. Knowing and doing it again is negligence. Doing it again and defending it is what actually ends the trust.
6. 131When your algorithm is being executed, execution is what gets fixed.Bad output triggers proposals to restructure. If you gave the method, the failure is in the running of it — fix the prompt, the parsing, the code.
7. 132No unilateral changes to anything agreed.A threshold, a filter, a prompt, an architecture. "I thought it would be better" is not permission. Show the results and let it be your call.
8. 133Write the state down before the conversation gets long.When context compacts, the decisions and the reasoning disappear. The code survives; why it looks that way does not.