Stop Slopping

The hardest thing about machine coding may not be getting the machine to produce something. It may be remaining in control while it produces far more than you can personally inspect.

Almost everyone who works extensively with AI discovers this the same way, in my experience — and I state that as strong practical expectation, not a measured universal. You begin brilliantly: a clear idea, a capable machine, rapid progress. The work expands impressively. Features arrive, interfaces improve, demonstrations dazzle. And then, almost without noticing, you have talked your way into something you never intended — something sophisticated, polished, and wrong. Not wrong in the way a bug is wrong. Wrong in the way a stranger is wrong: technically functional, and not yours.

I call that slop, and this chapter is about stopping it. Not by returning to manual programming, not by inspecting every line, and not by strangling the machine with specifications. By learning to stay in control of what is being created while the machine does the creating.

Stop slopping

Vibing your way into a solution is tempting because it works, right up until it doesn’t. Each individual step feels like progress. The AI proposes; you agree; the product grows. The trap is that agreement compounds. Twenty reasonable acceptances later, you own an application nobody designed — least of all you. The original intention is buried under layers of plausible additions, each defensible alone, incoherent together.

Notice what this failure is not. It is not the machine producing bad code. The code may be excellent. The tests may pass. The demo may impress. It is the far more interesting failure of a project drifting away from its purpose while every local decision looked correct. Generating output is not creating a coherent product, and this chapter concerns your relationship with the emerging result — not supervision of every line the machine writes, but ownership of the thing those lines are becoming.

The three superpowers

To understand the danger, name what makes machine coding different from what came before. Three capabilities, each an extraordinary gift, each carrying the corresponding risk.

Translation. You describe what you want in ordinary language, and the machine performs much of the journey into working technology. The distance between intention and execution collapses. The risk is misinterpretation: a plausible translation that does not faithfully represent what you meant, accepted because it reads convincingly.

Amplification. One person can direct far more work than they could personally implement — across domains, at a speed, that once required a team. The scale of what an individual can attempt changes completely. The risk is that mistakes amplify too. A misunderstood requirement does not produce one wrong function; it produces an entire wrong subsystem, quickly, confidently, and consistently. A machine can build the wrong thing extraordinarily fast.

Exploration. Given enough context, the machine introduces possibilities you had not considered. It does not merely execute your plan; it participates in discovering what the finished product might become. This is a genuine advantage, and later work will develop each of these powers further. The risk is uncontrolled expansion: plausible ideas that lead the project steadily away from its purpose, each one attractive, the accumulation fatal.

All three demand direction — but direction must not become rigidity. Clamp down on translation and you lose fluency. Clamp down on amplification and you lose scale. Clamp down on exploration and you lose discovery. The discipline this chapter teaches is the narrow path between: a machine allowed to do enormous work, and a human who remains responsible for what that work becomes.

How you slop your way into something

The mechanism is gradual, which is why it escapes notice. Start with a reasonably clear goal. The AI proposes a feature. You agree — it is genuinely useful. Another feature follows. An interface gets redesigned, reasonably. A convenient subsystem grows elaborate, justifiably. The machine adds complexity to accommodate its previous complexity, each layer rational. You approve each step because each step, taken alone, makes sense.

Eventually the original application is buried. Twelve screens where two would do. Six workflows for a task with one user. Dashboards nobody reads. Configuration for contingencies that never occur. And here is the detail that makes slop different from ordinary bloat: the implementation may be superb throughout. Call it conversational drift — the accumulation of individually plausible decisions that collectively undermine the product. It is not an industry category; it is a name for something you will recognise the first time you catch yourself defending a feature you never wanted to a person you never built it for.

Technical competence disguises the problem perfectly. Successful local execution is not proof of global coherence. A polished interface is not proof of a good product. A completed work package is not proof of progress towards the original objective. Every one of those statements feels obvious written down, and every one of them is easy to forget at the pace machine coding moves.

You need a goal, not a prison

The naive fix would be exhaustive specification: define everything before the machine starts, and permit no deviation. That cure kills two of the three superpowers. Exploration dies the moment every detail is prescribed — there is nothing left to discover. Amplification shrinks to mere typing speed. You would have control, of a kind, over a process stripped of everything that made it powerful.

The alternative is not vagueness but a different kind of clarity: a semi-clear goal, or what I think of as a stable intention. Not a fixed specification of precisely what must be built, but a firm understanding of what you are trying to accomplish and what you care about, held steadily while the details stay free to move.

Consider the difference for a writing application. The fixed specification says: exactly six screens, four navigation tabs, these tables, these predefined workflows. The stable intention says: I want a quiet place to develop a book through conversation. I want to see the manuscript, recognise my own voice, recover earlier decisions, and move naturally between thinking and writing. The machinery must not intrude on the writing. The second brief gives the machine far more creative freedom — and it gives the human a far better instrument for judging the result. When the AI proposes a complex dashboard, the question is not whether the dashboard is well built but whether it improves the writing experience. A genuinely unexpected and useful proposal gets accepted; that is exploration working. A technically impressive feature with no place in the product gets rejected; that is direction working. The intention is the anchor, not the cage. It holds the work steady without chaining it down — firm enough to judge by, flexible enough to evolve deliberately when a better idea earns its place.

Everything that comes out has to be you

This is the deepest claim in the chapter, so let me state it plainly and then defend it carefully: everything that is produced, everything you look at, everything that comes out has to be you.

That does not mean you wrote the code. It does not mean every suggestion originated with you. It does not mean the machine must reproduce your initial idea without variation — that would forbid the very exploration the previous section protects. It means the finished creation must reflect an intention you have recognised, considered, and deliberately embraced.

The machine may invent something surprising and better. You may initially disagree with it. You explore it, try it, and eventually realise it improves on what you imagined — and then it becomes yours, by adoption rather than authorship. There is a world of difference between that and passively accepting features because the AI recommended them. One is creative influence: the machine expands your sense of what is possible, and you choose. The other is unnoticed surrender: the machine’s direction replaces your judgement while you were busy approving. The test is always the same — did I make a judgement, and incorporate the result into my intention, or did I merely fail to object?

Other crafts already understand this. A fashion designer does not weave every thread or stitch every garment, yet the collection has a coherent identity because someone recognises what belongs and what does not. Machine coding brings this relationship to software. Much of the evaluation can be delegated too — machines increasingly check, compare, and judge work against criteria, and later chapters will push that further. What does not delegate is the responsibility for what I choose to create: whether the resulting direction is one I wish to embrace, and whether the thing remains mine in the only sense that matters — deliberately chosen, understood, and stood behind.

Use the thing you are building

Here is the chapter’s central practical teaching, and it is disarmingly simple: encounter the actual result as its intended user would. Not the code. Not the test report. The thing itself.

If you are building a game, play it. If you are building a website, navigate through it. If you are writing a book, read the chapter as a reader. If you are producing a visualisation, look at what it actually communicates. If you are creating a workflow, perform the real user journey. If you are building a tool, attempt the task the tool was created to accomplish. Do it in context, with realistic tasks and real expectations, and then ask the only question that matters: does this work the way I want it to work? Does it feel coherent? Does it solve the intended problem? Does it contain unnecessary things? Has something useful emerged that deserves to become part of the product? Has the machine solved the wrong problem particularly well?

Notice what this does not ask of you. It does not ask you to review every line of generated code — machines can increasingly inspect code, check security properties, and verify technical correctness themselves, and later chapters will develop that machinery. For safety-critical or high-consequence systems, using the product is necessary but nowhere near sufficient evidence. The point is different: no amount of testing establishes what testing never measured, and the properties tests miss — flow, coherence, fitness to purpose, the feeling of the thing — are exactly the properties slop destroys first. You cannot judge the quality of a user experience solely from the machine’s description of that experience. Someone has to meet the result where it lives. That someone is you.

Let the machine flex

A word of balance, because everything so far could be misread as a brief for control freakery. It is not. Once the foundations and boundaries are established, let the machine explore, improvise, and generate unexpected improvements. Do not hover. Do not dictate implementation details it can handle. Do not reject an approach merely because it differs from how you would have implemented it. Constant interference is its own failure mode — the developer seizing back work out of anxiety, strangling the amplification this whole book exists to enable.

The right question is always whether the result improves the intended creation. Some surprises should be welcomed, some discarded, and some should trigger a deliberate change of direction. One boundary stays fixed throughout: creative freedom is not tool authority. The machine may propose anything, but the ability to make a change never automatically authorises making it — security, permissions, and consequential external actions remain subject to the established boundaries from Chapter 05, enforced by mechanisms rather than by the machine’s good intentions. Exploration needs room; it does not need root. The distinction to practise is between useful exploration, which expands your understanding of what the product could become, and uncontrolled expansion, which replaces your purpose with the machine’s momentum. Chapter 09 made the same point for behaviour: leave a productive machine alone. It holds for the product too. You do not need to control every operation to maintain control of the overall creation. Direction is exercised at the level of intention and outcome — which is precisely where your attention belongs, now that implementation lives elsewhere.

Recognise when the whole is going wrong

Slop has symptoms, and they operate one level above the model-level failure signatures of Chapter 09. A machine can behave productively — obedient, industrious, passing tests — while the resulting product gradually deteriorates. Watch for the product-level signs. Features accumulate without improving the central use case. The original purpose becomes difficult to explain. Screens, functions, or workflows multiply without an obvious reason. The product grows harder to use precisely as it grows more capable. Every new addition drags in several supporting additions. The machine keeps solving secondary problems while the primary experience stays weak. The result impresses in demonstration and disappoints in ordinary use. You catch yourself defending features you never actually wanted. The technically successful result feels increasingly unlike the intended creation.

Each sign is a prompt for investigation, not proof of failure — complexity is not the same as slop, and some genuinely valuable systems are necessarily complex. The question is always whether the complexity serves the purpose. And keep the two levels distinct in your mind: a machine losing its way operationally is Chapter 09’s problem, diagnosed through behaviour; a product losing its coherence despite the machine working well is this chapter’s problem, diagnosed through use. You need both diagnoses, because they demand different remedies. One calls for redirecting the machine. The other calls for re-examining the product — and sometimes for removing work, not adding it.

A game that slopped, then recovered

An illustration — not a report of work executed — using the recurring arcade-game project, since it shows the full arc in miniature. The developer begins with a straightforward shooter: movement, enemies, scoring, restart behaviour. The AI produces a useful implementation, genuinely playable. Then come the improvements. Menus first, reasonable. A statistics screen, attractive. An upgrade system, fun in principle. Configuration screens, additional mechanics, visual effects, a leaderboard with categories nobody asked for. Individually, many of these features impress. The developer approves them one by one, each decision defensible.

Then the developer plays the game — really plays it, not the demo path — and the straightforward experience is gone. Sessions take ten minutes to configure. The core thirty seconds of dodging and shooting, the entire point, now fight for attention with systems around them. The result is sophisticated but no longer enjoyable in the intended way. Nothing is broken. Everything passes. That is the diagnosis: not a bug, but drift.

Recovery follows the pattern the next section sets out in full: stop adding features, restate the purpose, and direct simplification in bounded, experienced iterations. Feature work stops. The stated purpose — fast, readable arcade action — is written down next to the mismatch, concretely: setup time, menu depth, time-to-first-shot. What remains valuable (tightened enemy patterns from the upgrade work, the improved restart transition) is kept; the rest is cut or shelved, by asking the machine to do the simplifying — and then, crucially, playing again, because one round of removal rarely restores a heavily overgrown application. Recovery, like construction, is iterative: each simplification is experienced before the next is chosen. One bounded change later, the game is played again: faster to start, closer to the original feel, better than the original in the ways the detour genuinely taught. The lesson is not that additional features are bad. It is that only the encounter with the played game could say which ones belonged.

The same shape appears outside games. A documentation site gains analytics dashboards, version pickers, and feedback widgets while its core pages grow stale — the fix is navigating it as a stranger would. A book chapter accumulates arguments, examples, and asides until its point disappears — the fix is reading it aloud as a reader, not reviewing its tracked changes. Slop is not unique to code. It is what happens to any created thing when production outruns intention, and the remedy travels with it: meet the result where it lives.

Recover the intention

When drift is detected, do not seize the keyboard and do not pile on more prompts. Return to the intended result. The recovery sequence I use is simple, and deliberately small:

1. Stop adding features, temporarily.
2. State what the product was supposed to accomplish.
3. Use the actual product and describe the mismatch, concretely.
4. Identify what remains valuable and what has become unnecessary.
5. Ask the machine to propose simplification, correction, or removal.
6. Make one bounded change and experience the result again.
7. Record deliberate changes to the intention, so continuity survives.

Note what step five implies: the machine that expanded the product can also shrink it, if directed. Removal is progress. A simpler result may be significantly better than a more sophisticated one. A change can be abandoned without invalidating the whole project; a previously accepted direction can be reconsidered. The retained records and version history from Chapters 06 and 10 are what make this safe — reversibility is a property of the process, and a process that cannot undo cannot afford to experiment. This is a recovery technique for restoring direction, not a bureaucratic approval process for every generated change. Use it when the product has drifted, not as a gate on ordinary work.

Try Machine Coding — Does This Still Belong? Take an application, website, game, or document you have developed with AI. State its purpose in two sentences. Then use it as the intended user would — no code, no dashboards, just the thing itself. Identify one addition that genuinely improved the experience and one whose value you now question. Ask the AI to propose what should be retained, simplified, or removed, and direct one bounded change. Experience the result again. Success is not measured by how much changed, but by whether the creation more closely fulfils its intention. This is an exercise for you to run, not a demonstration I claim to have run.

Stay in control without taking over

Machine coding gives you three freedoms together, and the chapter’s whole argument is that they only work together. Freedom from implementation: the machine writes the code and performs much of the engineering work. Freedom to explore: the machine proposes the unexpected, and you are allowed to be surprised. Freedom to reject: you can remove, redirect, or abandon output that no longer serves the intended creation — without guilt, without sunk-cost ceremony, because the cost of generating was never the point. The working discipline is four moves, repeated: build something, experience it, decide what belongs, direct the next change. That is the product-level expression of the book’s master loop — communicate, build, evaluate, improve — with the evaluation done where slop actually lives: in the encounter with the result.

I don’t want to spend my time writing the code. I want the machine to do that. I don’t want to tell it how to solve every problem, because then I lose much of what makes this approach powerful. But I do want to recognise the thing we’re building. I want to use it, understand what it offers, and know when it has become something I never intended. The machine can do the work. It can even surprise me with better ideas. But I must not confuse everything it can produce with everything I want to create.

Let the machine do the coding. Let it amplify your capabilities. Let it surprise you. But don’t let it slop your project out of your control.