Check AI-Written Code Once Through
Three tiers: have AI explain the structure it picked, demand an alternate implementation and compare trade-offs, pick a way of organizing for your own project
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Check AI-Written Code Once Through”?
Three tiers: have AI explain the structure it picked, demand an alternate implementation and compare trade-offs, pick a way of organizing for your own project
Follow the handoffs, not the demo. A system becomes dependable at the boundaries between model, tools, state, permissions, and people. Read each handoff as a place where you can observe, test, and recover.
Name the input, owner, approval, and recovery action for one automated step.
A successful run that cannot explain what happened or be safely repeated.
Task 1 · Make AI account for itself
First step of checking: don’t read the code—audit the confession
Grab a piece of code AI already wrote for you (don’t have one? Ask AI to write a small “contact-list dedupe” tool: take a pile of names + phone numbers, drop the duplicates). Then throw the prompt below at it and make it confess which way of organizing it used.
Task 2 · Demand a different organizer
Same feature, two implementations—you’re the judge of trade-offs
Take Task 1’s code and have AI rewrite the same feature with a different data structure, then list a trade-off table for both versions. The key is the last step: don’t let AI deliver the verdict—you decide which version fits your scenario.
Task 3 · Pick a structure for your own project
Choose yourself first, then compare answers with AI
Pick a real need on your plate (work project or personal tool—either’s fine). Don’t ask AI yet—use the “how do I look up / how do I get in and out” decision mantra from ds-summary and pick the data structure yourself; then let AI independently produce a selection plan and see whether you two agree. Run the self-check list below first so the scenario is clear before you start.
📋 Pre-selection self-check (tick all before asking AI)
While doing the tasks, if you see these three signals in AI’s answers, chase one more round of questions.
Nested loops hunting for things
Two layers of for comparing one by one—that’s ds-1’s “big drawer inside a big drawer.” Ask once: “Would a Set / hash table be faster?”
Can’t name what it rejected
When you ask for alternatives it only praises the current pick and can’t name a rejected option—that means it never selected; it just defaulted.
Demo only on tiny data
A demo flying on 10 rows means nothing. Always ask: “What if data grows 1000×?”—the most valuable sentence in this chapter.
Why “Pick a tier · start today” depends on the operation
“First step of checking: don’t read the code—audit the confession” makes the structure concrete. The useful comparison is not which name sounds more advanced, but how the data is arranged and how far the most common operation has to travel.
Read a structure through access and change
“Grab a piece of code AI already wrote for you (don’t have one?” exposes a trade-off that is easy to miss: reading by position, looking up by key, adding at either end, inserting in the middle, and traversing relationships do not favor the same organization. A structure that is fast for one operation is not automatically fast for all of them.
- Checking starts with auditing the confession : make AI account for structure, reasons, and alternatives—exposes problems faster than reading the code itself
- You deliver the verdict : AI lays out facts and comparison tables; “which version fits my scenario” must be your call
- Five questions before selecting : scale, read/write mix, order, dedupe, cache—clear these before asking AI and plan quality jumps a tier
Count scale and update frequency together
Use “A demo flying on 10 rows means nothing.” as a boundary check. Write down the data size, the dominant operation, and the latency you can accept before deciding whether an AI-generated structure actually fits.
From “Pick a tier · start today” to “Also remember · three red-flag signals when checking”
“Pick a tier · start today” grounds the problem in “First step of checking: don’t read the code—audit the confession”. “Also remember · three red-flag signals when checking” then moves it toward “While doing the tasks, if you see these three signals in AI’s answers, chase one more round of questions”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
When you meet a new data structure, do not begin by memorizing its definition. Write down the most frequent operation, estimate scale and update behavior, and check whether the structure satisfies all three conditions.
- “Pick a tier · start today”: First step of checking: don’t read the code—audit the confession
- “Also remember · three red-flag signals when checking”: While doing the tasks, if you see these three signals in AI’s answers, chase one more round of questions
- “The closing point”: Pick first, then compare answers : checking eyesight grows in the gap where you and AI disagree
The final “The closing point” brings the discussion to “Pick first, then compare answers : checking eyesight grows in the gap where you and AI disagree”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
✅ What this lesson wants to share
- Checking starts with auditing the confession: make AI account for structure, reasons, and alternatives—exposes problems faster than reading the code itself
- You deliver the verdict: AI lays out facts and comparison tables; “which version fits my scenario” must be your call
- Five questions before selecting: scale, read/write mix, order, dedupe, cache—clear these before asking AI and plan quality jumps a tier
- Pick first, then compare answers: checking eyesight grows in the gap where you and AI disagree
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.