Run a Complexity Checkup on AI-Written Code
Three tiers: have AI self-report complexity, demand one-tier optimization and spell out the cost, then benchmark on large data to verify it isn't bluffing
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Run a Complexity Checkup on AI-Written Code”?
Three tiers: have AI self-report complexity, demand one-tier optimization and spell out the cost, then benchmark on large data to verify it isn't bluffing
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 · Account for itself
Have AI label the complexity of its own code
Take a function AI just wrote (if you don’t have one, ask it to write “find the common elements of two lists”—nine times out of ten it hands you an O(n²) version first). Drop the prompt below on it and make it confess how fast or slow it is.
Task 2 · Optimize one tier
Demand a speedup—and demand it spell out the cost
Follow Task 1: if AI self-reported O(n²), ask it to optimize to O(n log n) or O(n)—but the point isn’t just going faster; it’s making it spell out the cost. After finishing ds-6, you should be able to point to which line in its plan is “trading space for time.”
Task 3 · Measure until it can’t bluff
Verify with real data that it isn’t bluffing
Complexity is paper reasoning; the timing curve is hard evidence. Have AI write a benchmark script, generate three scales of random data, time each run, and see with your own eyes how far the before/after curves diverge—and check whether the complexity it self-reported was bluffing.
🩺 Checkup report generator · fill three fields, get a summary you can share in the group chat
The algorithmic cost curve in “Pick a tier · start today”
“Have AI label the complexity of its own code” is not asking you to memorize steps. It trains you to spot repeated work: as the input grows, how many comparisons, moves, or recursive calls does the program perform?
Find repeated work before declaring something fast
Break “Take a function AI just wrote (if you don’t have one, ask it to write “find the common elements of two lists” —nine times out of ten it hands you an O(n²) version first).” into three questions: how input size changes, what each round does, and whether the next round can shrink its search space. Big-O describes growth, not an exact time on every machine; constants, memory, and data distribution still matter.
- Checkup in three steps : self-report complexity → optimize and state the cost → measure to verify—each step harder than the last
- The bottleneck line is your handle : once you can say “this line is the slowest,” review has somewhere to grip
- Optimization must talk cost : any speedup that skips readability and memory deserves one more question
Theoretical optimum is not always practical optimum
When AI writes an algorithm, trace a small input by hand and benchmark progressively larger inputs. That turns “Complexity is paper reasoning;” from a slogan into a performance claim you can check.
Take the example one step further
The lesson starts with “Have AI label the complexity of its own code” and then moves to “Take a function AI just wrote (if you don’t have one, ask it to write “find the common elements of two lists” —nine times out of ten it hands you an O(n²) version first). Drop the prompt below on it and make it…”. Reading those two pieces together makes the distinction clearer: which points are facts in the lesson, and which judgments depend on their conditions.
Carry the judgment into the next situation
For a real task, find the repeated work first, ask how input size changes, and use a small benchmark to verify the theoretical judgment. Complexity should not become a label detached from the situation.
- “Pick a tier · start today”: Have AI label the complexity of its own code
- “Take it further”: Take a function AI just wrote (if you don’t have one, ask it to write “find the common elements of two lists” —nine times out of ten it hands you an O(n²) version first). Drop the prompt below on it and make it…
- “The closing point”: The measured curve is hard evidence : paper complexity can bluff; a timing table across three data sizes won’t
The final “The closing point” brings the discussion to “The measured curve is hard evidence : paper complexity can bluff; a timing table across three data sizes won’t”. 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
- Checkup in three steps: self-report complexity → optimize and state the cost → measure to verify—each step harder than the last
- The bottleneck line is your handle: once you can say “this line is the slowest,” review has somewhere to grip
- Optimization must talk cost: any speedup that skips readability and memory deserves one more question
- The measured curve is hard evidence: paper complexity can bluff; a timing table across three data sizes won’t
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.