“Keep It Simple” is old advice. It got interesting again the moment anyone could generate 500 lines of code in 30 seconds.

KISS says systems and tasks should be as straightforward as possible. No unnecessary complexity. Fewer moving parts, fewer things to break, fewer things to hold in your head. It was good advice when we typed every character by hand. It is better advice now that we don’t.

The reason is simple: the cost of producing code and content has dropped to near zero. The cost of understanding, reviewing, and maintaining it has not. Those two costs used to be coupled. AI decoupled them. If you don’t adjust, you get swamped: more code, more docs, more options, more abstractions, more Slack threads, all of it plausible, none of it vetted.

The point of this post is to argue that with AI in the loop, KISS is no longer a style preference. It is the only way to keep working at this tempo without shipping garbage.

Table of contents

• Why simple wins harder now
• Software development with AI
  • Keep things organised
  • Stay in the loop. Test. QA. Otherwise who is this for?
  • READ. You can’t trust anything it says.
  • Don’t outsource your learning
  • DO NOT LET LOC GROW
  • Just because you can doesn’t mean you should
  • Co-design things
• General tasks with AI
• What “winning” actually looks like

Why simple wins harder now

A few things have changed in the last two years that are worth naming.

Generation is cheap, reasoning is not. LLMs are extremely good at producing text that looks like the right answer. They are not reliably good at producing the right answer. When the text is long and ornate, you can’t tell the difference at a glance. When it is short and dumb, you can.

Your review budget is fixed. You have the same number of hours in a day you did before. If you let the model 10x your output, you have to 10x your review capacity, which you can’t. So the ratio of code-you-actually-understand to code-you-shipped drops. That is the failure mode.

The model gets worse as context bloats. Longer files, deeper class hierarchies, and tangled prompts all hurt the model in the same ways they hurt a new hire. A neatly organized 200-line module is a better collaborator than a sprawling 2,000-line one.

There is now evidence this matters in practice. METR’s 2025 randomized trial with experienced open-source developers using Cursor found that the devs thought they were 20% faster with AI and were in fact about 19% slower. GitClear’s multi-year analysis of billions of lines of code has shown rising “churn” (code deleted within weeks of being written) tracking the adoption of AI assistants. NYU’s Copilot study famously found that roughly 40% of its suggestions contained security-relevant bugs in CWE scenarios. None of these studies say “AI is bad.” They say, consistently, that AI makes it easy to move fast in a direction you didn’t check.

Simple is how you check.

Software development with AI

Seven rules. Each one is a thing I’ve watched fail in real teams, including my own.

Keep things organised

Small files. Clear boundaries. One concept per module. Obvious names. A README that tells a new person (or a new chat session) what this place is for.

This is not aesthetics. A model reading a tidy 150-line file can reason about it. A model reading a 1,500-line file with three responsibilities tangled together will hallucinate. So will you. The organization you do up front is the leverage you spend later, every time you come back to the code with an agent.

Practical rule: if you wouldn’t trust a junior engineer to understand the file in 10 minutes, don’t expect the model to either.

Stay in the loop. Test. QA. Otherwise who is this for?

The temptation is to let the agent run, merge the PR, and move on. Resist it. You are the one who has to answer the pager, not the model.

Klarna said in 2024 that its AI-first customer service experiment produced worse outcomes than humans and started rehiring. That wasn’t a technology failure. That was a people-in-the-loop failure. Nobody was reading the transcripts closely enough to catch the drift.

Concrete things that help:

• Write the tests yourself, or at least review them line by line. AI-written tests that pass are the easiest lie in software.
• Run the thing. Actually click the button. Agents are fluent liars about whether code works.
• Keep a QA pass separate from the author pass, even if both are you.

If you can’t name who this change is for and how you’ll know it helped them, you’re not building software, you’re decorating a repo.

READ. You can’t trust anything it says.

Read the diff. Read the citations. Read the error message. Read the docs it paraphrased.

Hallucinations are not a rare edge case. They’re the default behavior of a model that is always trying to sound plausible, and has no internal concept of “I don’t know.” This shows up as:

• Invented library functions that would be perfect if they existed.
• Package names that are close to real ones. Attackers have started registering the hallucinated names; the term is slopsquatting.
• Citations to papers that sort of sound like real papers.
• Confident claims about your own codebase that are wrong because the model never actually looked.

The habit to build is boring: every non-trivial claim gets verified against primary source. Every imported symbol gets clicked through. Every new dependency gets looked at on the registry. This takes five minutes and saves weeks.

Don’t outsource your learning

This is the quiet one. You can ship for a while without understanding what you shipped. You can’t grow that way.

A Microsoft/CMU study in 2025 looked at knowledge workers using generative AI and found a clean pattern: higher confidence in the AI correlated with reduced critical thinking effort. People stopped checking because the output felt right. Over time, they also stopped being able to tell when it wasn’t.

The rule I give myself: if I let the agent write something I could not have written, I have to read until I could. Not “skim until it compiles.” Could I defend this in a code review without the chat open? If no, I’m in debt.

Learning is the asset. Code is the byproduct. Don’t trade the asset for the byproduct.

DO NOT LET LOC GROW

Every new line is a liability. Bugs, tests, docs, security surface, onboarding cost, review load, merge conflicts. It all scales with lines of code.

AI tips this balance badly in the wrong direction, because generating more is easier than generating less. Ask for “a utility function” and you get a class, a factory, an interface, three overloads, a config object, and 40 lines of docstring. None of it asked for.

So push back. Hard.

• Start every review with: what can I delete?
• If the diff is larger than the problem, reject it and ask again.
• Prefer small, in-place edits over new files, new modules, new abstractions.
• A two-line fix is a two-line fix. Not a refactor.

The single best question you can ask an AI pair is “is there a simpler version of this that does the same thing?” It will usually find one. It just won’t offer it unprompted.

Just because you can doesn’t mean you should

In five minutes you can add a dashboard. A retry queue. A plugin system. An admin page. A feature flag framework. A cache.

You probably shouldn’t.

YAGNI (“you aren’t gonna need it”) was already the right call in 2005. In 2026, with generation nearly free, it is the only thing standing between your team and a product nobody understands. Every feature you add now is one you have to maintain, support, document, and eventually delete. The agent won’t delete it for you.

A useful filter: would a reasonable engineer, given the same two hours without AI, have built this? If no, you probably built it because you could, not because you should.

Co-design things

Don’t prompt the model after you’ve decided. Think with it, early, while the decision is still cheap.

The failure pattern is: human writes a vague one-liner, agent generates 400 lines, human reviews 400 lines. The correct pattern is: human and agent sketch the shape first, argue about tradeoffs, agree on a small plan, then generate.

Spec-first work (OpenSpec, ADRs, design docs, even a five-bullet Notion page) is underrated right now precisely because AI makes it feel skippable. It isn’t. The spec is where the real thinking happens. The code is just the consequence. If the spec is wrong, more code won’t save you, it’ll just bury you faster.

General tasks with AI

Beyond code, the same principle holds. A few rules I use for everything else (writing, research, planning, email, slides):

Decide first, then ask. If you don’t know what you want, the model will confidently invent a want for you. Spend the 60 seconds to write down the goal before the first prompt. Most bad AI output starts with a bad request.

Give it the actual context, not a hope. Paste the doc. Paste the error. Paste the data. Models are not psychic, and “you know the thing I mean” is not a prompt. If giving context feels like too much work, that is a signal the task isn’t well-defined yet.

Short loops over long prompts. Three exchanges of 50 words beat one prompt of 500. You steer better when you’re close to the wheel.

Stop when you have enough, not when it stops talking. Models will happily keep generating. That’s a feature of sampling, not a sign of value. The last paragraph is almost always skippable.

Treat it like a smart junior, not an oracle. A smart junior is fast, tireless, occasionally brilliant, and will confidently do the wrong thing if you don’t check. That is exactly the relationship.

Write in your own voice at the end. Drafts from a model are starting points. If you ship them raw, your reader can tell, and so can you in six months when you can’t remember what you actually think.

What “winning” actually looks like

I don’t think the people who win with AI are the ones generating the most. I think they’re the ones whose output you can still recognize as theirs. Same taste, same judgement, same restraint, just with more of it, faster.

The tools are incredible. They will keep getting more incredible. That’s exactly why the discipline has to go up, not down. KISS isn’t a retreat from AI. It’s how you stay the author of your own work while using it.

Keep it small. Keep it yours. Read everything. Delete what you can. The rest is noise.