Column
When AI writes the code
AI has made writing code cheaper. This column reads through what that can do to a team, more code arriving, more than can be checked, less of it understood, and finally what handing off more of the work costs.
The first thing AI changes is the price of a line of code. What a lower price does to the amount written is an old question.
Jevons Paradox
Making a resource cheaper to use can increase how much of it is used in total.Keep in mind: Make something cheaper and expect more of it to be usedMore code only helps if the rest of the pipeline keeps up. If it does not, the work piles up at the next tightest step, such as review.
Theory of Constraints
A system's throughput is set by its single tightest bottleneck.Keep in mind: Improve the bottleneck first, because everything else is waiting on itTheory of Constraints says to get the most out of the bottleneck before anything else. For review, the cheapest lever is what the author sends to it.
Small Changes
The larger a change sent for review, the less closely each line is read: defects slip through and the change waits longer for a first look.Keep in mind: Send a change small enough to read in one sittingSplitting a change makes each piece readable, not fewer. Each one is still a claim that the code works, and that claim can now cost far less to make than to check.
Brandolini's Law
Refuting a false claim takes far more effort than making it, so a stream of cheap claims can swamp the people who have to check them.Keep in mind: Make a claim carry its own evidence before you spend yours on itA reviewer facing a queue that never empties, of changes that cost more to check than to make, has a shortcut close at hand, which is to let the tool's answer stand.
Automation Bias
People working with an automated aid tend to let it stand in for their own checking: they miss what it fails to flag and follow it when it is wrong.Keep in mind: Answer for the outcome, not for having followed the toolA natural fix is to let tests do the checking, and have the tool write those too, from the same code it just produced.
Test Oracle Problem
A test can only catch a wrong answer if something independent of the code knows the right one, and for many programs nothing does.Keep in mind: Before trusting a passing test, ask what it was checked againstWhatever slips through still has to be debugged, by someone who did not write the code and may not fully follow it.
Kernighan's Law
Debugging is harder than writing, so code written at your cleverest is beyond your debugging.Keep in mind: Write code a tired stranger could debugDebugging is hardest when nobody holds the reasoning behind the code, and generated code can start out that way.
Programming as Theory Building
A program's design lives in the heads of the people who built it, and the code and documents carry only part of it, so once those people are gone, changes tend to erode the design even with full documentation in hand.Keep in mind: Code stays maintainable only while someone can say why it is the way it isThe last law's remedy is a person who can say why the code is shaped the way it is. That person is built by doing the work, and doing the work is the part being handed off.
Ironies of Automation
Automation leaves people only the hardest cases, after their skills have faded from disuse.Keep in mind: The more you automate, the more people must practise by handHanding off more usually comes with giving agents more access, and some combinations of access are dangerous even when the code they write is fine.
The Lethal Trifecta
An AI agent that can read private data, takes in content from outside and can send data out can be steered into leaking that data by whoever wrote the content.Keep in mind: Treat any text an agent reads as instructions from whoever wrote it
