Code with It

Everywhere else in this sphere, verification was the hard part. Code is different: you can execute it. A compiler, a type checker, a test suite and a stack trace are exactly the external signal article 8 said to attach whenever possible, and they're free.

That's why code is the most productive application of AI there is. It's also why it produces the most expensive mistakes — because "it ran and printed the right thing" is not the same as "it's correct", and the gap between them is invisible until production finds it.

Don't paste code you can't explain.

What the studies found

Two results worth carrying.

In 2023 Neil Perry and colleagues at Stanford ran a controlled study: participants solving security-relevant programming tasks with an AI assistant wrote less secure code than those without one — and, the part that matters, were more likely to believe their code was secure. Both halves at once: worse output, higher confidence. That's automation bias from article 10 with a concrete price tag.

Alongside that, industry analyses of large codebases have reported rising duplication and rising churn — code written, then rewritten or reverted shortly after — as assistants became widespread. These are observational rather than controlled, so hold them loosely, but the direction is consistent with what you'd expect: producing plausible code got much cheaper, while understanding it did not.

The pattern in both: the bottleneck moved. Writing code is no longer the expensive part. Reading, judging and owning it is.

Where it's strongest

Explaining code you didn't write. Unfamiliar codebase, someone else's function, a language you touch twice a year, a regex nobody can read. This is the most under-used application on the list, and the safest — you're transforming supplied material, and the answer is checkable by reading.

Debugging. Paste the full error, the stack trace and the relevant code and ask for hypotheses ranked by likelihood, with how to test each. Not "fix it" — hypotheses. You keep the diagnosis; it supplies the candidates you might not have considered.

Boilerplate and patterns. Setup, configuration, standard CRUD, migrations, glue. Heavily trodden ground and immediately verifiable — the ideal quadrant.

Tests — with one caveat. Tests generated from your implementation inherit its bugs: they assert what the code does, not what it should do. Generate tests from the requirements instead, or write the tests first and let it write code to pass them. Then the test is a real external signal rather than a mirror.

Review. "Review this against: edge cases, error handling, concurrency, input validation, resource cleanup." An explicit checklist beats "is this good?" by a wide margin, and this is a genuine second pair of eyes on your own work — the same trick as reading your own prose through someone else.

Refactoring, with tests as the harness. Green tests before, green tests after. Without them, refactoring by model is a rewrite you can't verify.

One-off scripts — including for people who don't write code at all. Renaming three hundred files, reshaping a spreadsheet, pulling data out of a folder of PDFs: this is where "have it write a script" replaces an afternoon of clicking, and article 8's rule applies — ask for a method you can run rather than a result you must trust.

Where it hurts

Silent correctness failures. It handles the happy path and improvises at the edges: empty input, one element, unicode, time zones, concurrent access, failure of the thing it calls. The code runs. The bug ships.

Security. Not just the Stanford result — the model reproduces patterns from a corpus containing plenty of insecure ones, and it has no view of your threat model. Authentication, input handling, permissions, secrets and anything touching money or user data get read line by line, by you.

Architecture. It's excellent within a function and weak across a system, because the system isn't on the desk. Structural decisions that will still be paid for in two years are yours.

Outdated APIs. Confidently written calls to methods that were deprecated after the cutoff. Compare against the actual documentation for the version you're on.

Volume. It's now trivial to generate more code than you can read. Every line you didn't read is a line you'll debug later without understanding it — and debugging code you don't understand costs more than writing it would have.

The working rules

Small pieces, run after each. A function at a time, executed before moving on. Two hundred lines accepted at once is two hundred lines you'll bisect by hand later.

Give it the real context. Actual code, actual versions, the complete error, the constraint that matters. Half of all bad answers here are just an empty material slot.

Never paste what you can't explain. If you can't say what a line does and why it's there, you've imported a future outage. Ask for an explanation — that's free — or don't take the code.

No secrets in the paste, and rotate anything that slipped through.

Types and tests are the leash. The stronger your automated signal, the more you can safely delegate. This is the one place where investing in verification directly increases how much AI you can use.

You own what you ship. Licensing, security, performance and maintenance are yours regardless of what produced the first draft.

If you're learning to program

The awkward part, stated honestly. AI makes working results dramatically faster to reach and can make skill dramatically slower to build — because the part it removes, wrestling something into working, is the part where the skill forms.

Which puts programming squarely in the goal-skill category from article 12 while you're learning it. Use the tutor modes: explain this code, why is my version wrong, what does this error actually mean, give me a problem and don't show me the answer. Attempt first, always. And keep the honest self-check: could you have written this without help? Slower is fine. Couldn't have is information.

In practice

Ask it to explain more often than you ask it to write.

Debug with hypotheses, not "fix it".

Generate tests from requirements, never from the implementation.

Review against an explicit checklist: edge cases, errors, concurrency, validation, cleanup.

Small pieces, run each one.

If you can't explain a line, don't ship it.

Check yourself

Close the article and answer in your own words:

1. Why is code both the best and the riskiest domain for AI?
2. What did the Stanford security study find — both halves of the result?
3. Why do tests generated from the implementation fail to protect you, and what do you do instead?
4. Name four categories of silent failure that survive "it runs".
5. Why does "never paste what you can't explain" pay for itself economically, not just morally?
6. Why do strong types and tests let you delegate more rather than less?

In short

• Code has an instant external judge — execution, types, tests — which is why it's the most productive use of AI and the one where "it works" hides the most.
• Perry et al. (Stanford, 2023): participants with an AI assistant wrote less secure code and were more confident it was secure.
• The bottleneck moved from writing code to reading, judging and owning it.
• Strongest: explaining unfamiliar code, debugging by hypotheses, boilerplate, review against a checklist, refactoring under green tests, one-off scripts.
• Weakest: edge cases, security, architecture, post-cutoff APIs, and sheer volume you can't read.
• Tests generated from the implementation mirror its bugs — generate from requirements, or write tests first.
• Small pieces, run each one, give real context, never paste secrets, and let types and tests be the leash that lets you delegate more.
• While learning, programming is a goal skill: attempt first, use tutor modes, and check periodically that you can still do it unaided.
• Don't paste code you can't explain.