AI in Programming: The Bottleneck Moved to Review

One thing genuinely changed in a programmer's work, and most of the discussion is about something

else.

Writing is no longer the constraint.

You used to spend twenty minutes writing a function. Now you get it in twenty seconds. **But the time you

need to know it is correct has not changed at all.**

The bottleneck moved from writing to reviewing.

And this whole course is about that move.

The rule everything else rests on

Do not merge code you cannot explain.

Simple, and hard to hold to under delivery pressure. And everyone who broke it paid at least once — in a

production error whose cause they could not find, because they never understood the code to begin with.

Why is it stricter in programming than anywhere else? Because code runs. A clumsy paragraph

embarrasses you; wrong code loses data, opens a hole, or falls over at three in the morning — and you are

the one being woken.

What the tool actually does with code

It generates the most probable text. Code is text, so it generates it well — sound structure, plausible

names, valid syntax.

The problem is that "most probable" is not "correct for your case".

The tool writes code that looks correct faster than you can review it.

That is the most dangerous sentence in the whole subject. You reject clumsy code instantly; **clean,

well-formatted code with clear names disables your doubt** — and that is exactly what it produces.

What it does not know about your project

The tool does not know:

• The implicit rules of your codebase — that this function must never be called inside a transaction,

and that this field can be null in older records

• Your business rules — that this class of customer is not eligible for that discount
• Your history — why that "strange" workaround exists, and that it solves a real problem you hit
• Anything beyond the file — the effect of your change on its callers

And the first is the source of most silent errors: code that is entirely correct in the abstract **and

wrong in your project** — and nothing will tell you.

Where you genuinely gain

You gain in:

• Repetitive code — models, mappings, wiring, configuration
• Tests for existing code (with an important qualification in lesson five)
• Conversion — format to format, or from a language you know to one whose concepts you know
• Fiddly syntax you always forget — a regular expression, a query, a command-line invocation
• Explaining code you do not understand — legacy code, an unfamiliar library, a cryptic error message
• A one-off script you throw away after running
• Reviewing your own code and hunting for bugs in it — among the most useful and always overlooked

And where you lose silently

I will say this plainly because it is where this course's value comes from:

• Architecture decisions — the tool gives you what is common, not what suits your constraints
• Anything touching money, permissions or identity — never handed over without line-by-line understanding
• Concurrency and parallelism — the hardest area to review at all, and its errors do not show in tests
• Performance-sensitive code — it may give you a correct answer an order of magnitude too slow
• A codebase with many implicit conventions — it will write code that is a stranger to its surroundings

The governing rule: the more correctness depends on what is not visible in the file, the smaller the

benefit and the larger the risk.

Who this course is for

A working programmer — beginner to intermediate — and the lead of a small team wanting to govern how

their team uses these tools.

And who it is not for? Anyone who does not program. **If you are a business owner wanting to know where

these tools save your time, "AI for Work" is the one you want** — this course assumes you read and review

code.

And I will not name a single tool. Tools change every few months, engineering discipline does not.

Action steps

1. Write the rule and post it: do not merge code you cannot explain.
2. Review the last three times you accepted generated code: could you have explained every line?
3. Write down which of the "gain" list applies to your work this week.
4. Write down which of the "lose" list you almost used it for — and put it out of scope.
5. Identify the files touching money, permissions or identity in your project — **and name them to yourself

now**.

6. Try nothing new before lesson two.