Your AI Is Generating Entropy Faster Than You Can Review It

AI accelerates the production of code, designs, and decisions. When human judgment cannot keep pace, entropy accumulates inside what you are building. AI produces results quickly, it can also put you at the finish line of the wrong race.

The short version. AI writes code faster than anyone can read it, and it fills every gap you leave open with a decision nobody registers as a decision. Those unreviewed decisions are the contaminant, they compound into rot. The fix is holding the product’s shape yourself and writing it down, then grading the model against criteria you set.

Can Anyone Review as Fast as AI Produces?

I have been a software engineer for over eight years. I’ve led teams and projects in large enterprises, and often get consulted when things go wrong. The industry is moving faster than ever.

In April 2026, Sundar Pichai said 75% of all new code at Google is AI generated and approved by engineers, up from 50% the previous fall. METR ran a randomized controlled trial in 2025: 16 experienced open-source developers, working 246 real issues in repos they knew well, took 19% longer when allowed to use AI tools, while estimating afterward that the AI had sped them up by 20%.

Before massive AI adoption, I had difficulties keeping up with my teams and my own code. AI produces it orders of magnitude faster than any engineer can read it. It’s all too easy to look at an LLM’s output, read every line, come away with a very superficial understanding of what it produced, commit it and move on.

AI produces chaos so well structured you can’t see it. More output feels like more progress, and more progress feels like the thing is nearly done. The output is real, but the progress is assumed. AI is making decisions nobody registers as decisions.

Product Rot

Engineers have always fought entropy. It’s your fight too, whether or not you are the one typing the code. Things left unattended rot. Thomas and Hunt built a chapter of The Pragmatic Programmer on it: entropy is “a term from physics that refers to the amount of ‘disorder’ in a system,” and when that disorder shows up in code they call it “software rot.” Without continuous improvement our systems get there on their own, once a codebase starts to decay the people in it care less, which decays it further.

Rot is something we’ve been contending with well before AI. Thomas and Hunt name the accelerant: “neglect accelerates the rot faster than any other factor.” AI is an accelerant that looks like the opposite. Nobody sees a codebase gaining thousands of lines a week and thinks neglect, they think the team is shipping. So the rot comes in through the work now, not the absence of it.

AI can introduce “contaminants” that accelerate the rot. These contaminants are implicit decisions, they’re decisions you allow AI to make that no-one evaluates or challenges.

Rot looks like this:

• A vulnerability gets published and nobody patches it.
• A library you depend on stops being maintained, and its last release predates the runtime you’re on.
• A browser, a language version, or an API deprecates something out from under you.
• What the customer needs moves, and the product stays where it was.
• The one person who knew how it worked leaves.
• AI contaminants are committed in volume to your project.

AI will fill in the gaps of anything left unspecified, sometimes you will get a satisfactory result, but the errors compound and accumulate. In my experience, if a codebase is poorly structured contributions will be as well. Conversely if a project is well put together, has the right checks and gates, follows best practices, it becomes much harder for agents and humans alike to make poor contributions.

Decisions AI will make that you probably don’t want it to:

• Your core product or offering
• The features you are building
• The technology you use to enable your product
• The structure of your project

Having the high-level understanding of what your product is and picking the right components to enable that outcome in an effective / sustainable way is the key. There is some margin for error, but you will only be able to recognize and correct it and pivot aggressively if you have the high-level vision in mind at all times.

How Do You Keep the Product Yours?

Large-language models are probabilistic black boxes. Same prompt, default settings, wildly different results.

Using AI to build your product introduces decisions you did not make or evaluate. The result will look good at a glance, but that’s what AI is trained to do. You give it text and it gives you impressive looking text back. An answer can look settled on the page while the decision underneath it is still open.

What keeps you pointed the right way is holding the shape of the product in your head, writing it down, and iterating on both. No LLM holds that, and none of them hold it over a long horizon. Codifying it in a constitution, a standing document your agents read before every task, helps, but context windows are only so large, so the real understanding needs to stay with you.

You have facts, best-practices, and the collective experience of humanity available to you in an instant. Use it to learn, to become a more effective problem solver rather than outsourcing that to the models. Framed like this, AI can be an encyclopedia, research assistant, and personal tutor all in one. You iterate faster, and your product fails forward instead of catastrophically.

When I don’t already know the answer, I run this loop before I write the real prompt.

If the result is good enough, and the task is repetitive, you can start iterating on repeatable workflows or skills to recreate the result for a very specific set of steps.

The expectation to set is not speed, it’s a better result. Improve the bottom line in a way that lasts, without the product rotting underneath it. Speed will be the natural result of good practices.

AI is here to augment your intelligence, not make it obsolete. If you are principled, measured, and goal-oriented - you can iterate fast, recognize when you’re on the wrong track and move back in the correct direction when needed.

Iterate on the Product, Not the Prompt

Set your destination

Rot can be fought, but only if you know what you are building and who you are serving. Decide what you want the product to become before you decide how to get there. Once you know where you are going, it is usually obvious whether your current path leads there or you need to realign.

Constraining the model constrains you first. To close off the directions you do not want taken, you have to understand the problem well enough to say how it should be solved. Writing those constraints is the decision. Narrowing your prompt with these constraints will narrow the range of responses that come back.

Back to the basics

AI isn’t a substitute for clean processes and systems design. You still need automated testing, integration tests, linters, and human review. The bar goes up, not down.

Kim, Humble, Willis, and Debois recommend investing “at least 20% of all Development and Operations cycles on refactoring, investing in automation work and architecture and non-functional requirements.” It still holds true. A fifth of the effort should go towards making your product resilient and iterable.

Your Value

LLMs are statistical matrix multiplication machines. What you bring is empathy for the customer and a feel for what the product is for. Your business is a living entity, no snapshot of the internet contains it.

Define what success looks like at each stage, how it could fail, and what each decision trades away. That is your measuring stick for whether the model is doing well, and for whether the company is. Without it you cannot tell whether you are heading anywhere you intended.

“Iterate on the product, not the prompt” is what I repeat to myself. It is easy to miss the point and get caught in endless prompts. Blazing forward is meaningless if you are pointed at the wrong finish line, or worse - off a cliff. You end up further from your goal than you would be with a blank slate.