A few weeks ago I ran a call with an IT firm who wanted to bring AI into their development work properly. They expected a conversation about tools, which model to use, which assistant to buy, which plugin to install. That is where most of these conversations begin. It is almost never where the value sits.

What I told them, and what I keep coming back to, is that the tools are the easy part. The single most important aspect of implementing AI into a business is not the model you choose. It is the framework and the environment you build around it. Get those right and even a modest tool produces excellent work. Get them wrong and the best model on the market will simply generate mistakes faster. AI does not succeed or fail on its own. It succeeds or fails inside the conditions you create for it.

Those conditions all serve one purpose, getting the right information to the model reliably, every time. When they are missing, a very specific failure appears, and it has a name. It is slop.

AI slop is a thinking problem. Underneath that, it is a context problem.

A model is a reasoning engine that works on whatever you put in front of it, and nothing else. It does not know your intent, your domain, your constraints, or the decision you made twenty minutes ago, unless that information is in its context. When something is missing, the model does not stop and ask. It fills the gap with the most plausible guess it can produce, and it does so with complete confidence. Slop is what those guesses harden into.

That single mechanism explains almost every piece of slop I have ever seen. Code that runs but nobody understands. Documentation that describes a system that no longer exists. A feature assembled because it could be, not because anyone was clear on why it should exist. In each case the model was working with too little of the right context, and it papered over the gap.

So the craft of building well with AI is, at its core, the craft of managing context. Context is everything. Everything that follows is a way of getting the right context in front of the model and keeping yourself in control of it.

None of this arrived as theory. It came from years of trial and error with prompt planning, with skills and agents, and with different models, learning the hard way where each one earns its keep and where each one quietly leads you astray.

Why context is everything

It is worth being precise about why this matters so much, because the instinct is to blame the model when the output is wrong. Usually the model did exactly what it should have, given what it was told. The failure was upstream, in what it was not told.

Think of the model as brilliant but amnesiac, working only from the note you hand it. If the note is vague, the work is vague. If the note contradicts itself, the work contradicts itself. If the note leaves out the constraint that actually matters, the work ignores it. The model cannot supply the context you withheld, and it will never flag the absence, because from where it sits there is no absence. There is only the note.

This reframes the whole job. You are not really writing prompts. You are engineering context. The plan, the domain knowledge, the rules, the existing code, the prior decisions, the definition of done, all of it is context, and the completeness and accuracy of that context sets the ceiling on the output. Get the context right and good work becomes repeatable. Get it wrong and no amount of clever prompting will save you. Every practice in the rest of this article is, in the end, a technique for controlling context.

The vibe coding Dunning-Kruger effect

There is a trap on the road to using AI well, and almost everyone walks into it. It is the vibe coding Dunning-Kruger effect, and it deserves naming, because it is the single biggest reason capable people ship slop.

Vibe coding is building by feel. You describe what you want, accept what comes back, and keep going as long as it seems to work. In the beginning this is intoxicating. You produce working-looking software faster than you ever have, with almost no understanding of how it actually works, and the natural conclusion is that you have become extraordinarily good at this. That is the peak of the curve, the point where confidence is highest and competence is lowest. You do not know what you do not know, and the fast, plausible output gives you no reason to suspect there is anything to know.

Then reality arrives. The thing that demoed beautifully falls over under real load. A security hole you never considered gets found. A change in one place breaks three others, because nothing was structured to prevent it. The generated code turns out to be unmaintainable, and worse, unexaminable, because you never understood it well enough to fix it. This is the drop into the valley, where you finally grasp how much the early confidence was hiding.

The way out is not to abandon AI. It is to climb the far side of the curve, where understanding catches up with output. On that side you know why the good results were good. You recognise that the early wins were not your skill and not the model’s magic. They were the context you happened to provide without realising it. Once you see that, you start providing it deliberately. That is the entire journey, from unconscious luck to deliberate context, and everything here is a way of walking it faster.

The reason the effect is so dangerous is that the feedback loop rewards the wrong thing. Confidence produces output, output looks like success, and success reinforces confidence, all before the bill for the missing understanding comes due. The only defence is to distrust the easy early wins and ask what context is actually driving them.

Design and planning come before the prompt

The plan is the first and most important piece of context you will ever give a model, which is why the single biggest cause of slop is starting to build before you have decided what you are building. AI will happily fill any gap in your intent with a confident guess, and those guesses compound. Three prompts later you are refactoring around a decision you never actually made.

Planning is the cheapest work you will ever do. Before a single line of code is generated, the shape of the thing should be clear in your own head. What is the goal. What problem does it solve for a real person. What does success look like, and how will you know you have reached it. What are the dependencies, the assumptions, the edge cases that will quietly break things at the worst possible moment. When you can answer those questions without the model, you can direct the model instead of being led by it.

This is the difference between optimising with AI and optimising for AI. The former treats the model as a capable collaborator inside a plan you own. The latter surrenders the plan to whatever the model produces, then calls the mess velocity.

Review the plan with more than one model

The plan is the highest-leverage context in the whole process, which makes it the thing most worth stress testing. One of the most effective techniques I have found is to put the plan in front of more than one model and ask each to pull it apart. Different models are trained differently, carry different blind spots, and hold different instincts about risk. What one waves through, another flags. Where one is confidently wrong, another catches it.

This is not about consensus for its own sake. It is about surfacing the assumptions and gaps that a single model, or a single person, will always miss. Ask each model to challenge the approach rather than bless it. Have it argue the case against your design, name the edge cases you have not accounted for, and describe the ways the system could fail under load or attack. You are not looking for agreement. You are looking for the objection you had not thought of. The lift in plan quality from this one habit is significant, and it costs a fraction of what it takes to discover the same flaws in production.

Build around a single object model

As soon as a build involves more than a couple of moving parts, ambiguity about what things are and how they relate becomes a primary source of slop. One prompt calls it a customer, the next calls it a client, a third invents a subtly different shape, and now three overlapping models of the same idea are fighting each other in the codebase.

The remedy is a centralised object model, a single agreed definition of the core entities in the system and how they connect. The names, the fields, the relationships, and the rules that govern them, written down and treated as the source of truth. This is shared context in its most concentrated form. Every prompt, every agent, and every person works from that same model, so a word means the same thing in the plan, the code, the database, and the documentation. When the model is explicit and shared, the AI has a stable frame to build against and stops filling gaps with inconsistent guesses. When it is implicit, drift is guaranteed, and drift is where slop breeds.

Know what you are building

Doing the research is not optional, and it is not something you outsource to a generated summary you never verify. Know the domain. Know the constraints. Know the rules that apply to your context, whether that is consumer law, privacy obligations, payment compliance, or accessibility. These rules are context the model needs and cannot invent. It can draft against them once you understand and supply them, but it cannot be trusted to know which rules apply to your business, in your jurisdiction, at your level of risk.

Security belongs in this stage, not at the end. If you wait until the feature works to think about how it could be abused, you have already built the abuse vectors in. Ask the awkward questions early. Who can call this. What happens if the input is hostile. Where does sensitive data live, and who can reach it. What is the blast radius if this one component is compromised. Threat modelling before you build is far cheaper than remediation after you ship, and it produces a cleaner design as a side effect.

Know how you will scale

A prototype that works for one user and one dataset tells you almost nothing about how the system behaves under real load. Slop often looks perfectly fine on the day it ships and only reveals itself when the traffic, the data volume, or the tenant count grows past the naive assumptions baked into the first draft. Those assumptions are missing context, and the model will default to the simplest case unless you tell it otherwise.

Decide up front whether this needs to scale, and if so, how. Will it be a single tenant or many. Where are the bottlenecks likely to appear. What gets cached, what gets queued, what has to be consistent and what can be eventual. You do not need to build for a million users on day one, and premature optimisation is its own kind of slop. What you do need is an architecture that will not have to be torn out the moment it succeeds. Design for the growth you actually expect, and be honest about what that is.

Work by a method: Karpathy’s discipline

Speed without a method is how slop accumulates, so it helps to work by an explicit set of principles rather than improvising each session. The approach I keep returning to draws on Andrej Karpathy’s guidance, distilled into four habits.

Think before coding. Understand the problem and the shape of the solution before you generate anything. The clarity you bring up front determines the quality of everything downstream.

Simplicity first. Prefer the most straightforward solution that solves the actual problem. Complexity is easy to generate and expensive to live with, and the model will happily hand you more of it than you need.

Surgical changes. Make small, targeted, deliberate changes rather than sweeping rewrites. A precise edit is easy to review, easy to reason about, and easy to undo. It also keeps the context tight, so the model is reasoning about the one thing that matters rather than the whole world. A large generated diff hides its own mistakes.

Goal-driven execution. Keep every change tied to the goal you set out with. If a step does not serve that goal, it does not belong in the build, no matter how confidently the model proposes it.

Followed together, these turn an AI session from an open-ended generation exercise into a controlled process with a clear direction. That control is precisely what slop lacks.

The best code is no code

The most reliable way to avoid slop is to write less of it. The best code is no code at all.

Every line you write is a line that can carry a bug, hide a vulnerability, demand maintenance, and confuse the next person to read it. Code that does not exist does none of those things. It is the one part of the system that can never break, never drift, and never rot. This has always been true, but AI has made it urgent, because AI has made writing code almost free while leaving the cost of owning code exactly where it was. The bottleneck was never typing. It was understanding, maintaining, and securing what gets typed, and a model that generates a thousand lines in a second has done nothing to reduce that.

So the instinct to reach for generation on every problem is worth resisting. Before you ask the model to build something, ask whether it needs to exist at all. Can an existing component do the job. Can the requirement be met by configuration rather than code. Can the feature be cut without anyone noticing. Can a smaller solution cover the real need instead of the imagined one. The most valuable thing an experienced engineer does in an AI-assisted session is often not what they add, but what they decline to build. Deleting code, refusing a feature, and choosing the smaller path are acts of judgement a model will never volunteer, because generation is all it knows how to offer. Restraint is yours to bring.

Treat documentation as part of the build, not a footnote

Documentation is context made durable, and it is where AI-assisted work most often rots, because the code changes faster than anyone updates the words describing it. Undocumented systems become systems only the model understands, and that is a fragile place to be.

Documentation should be produced alongside the build and signed off as part of it, not bolted on afterwards when the detail has already faded. That means capturing feature behaviour, configuration, endpoints, environment variables, and dependencies while they are fresh. It means writing for two audiences, not one. Developers need the technical reference so the next person, possibly you in six months, can extend the system safely. Users need clear, plain-language guidance so they can actually operate what you built. Good documentation also feeds straight back into the loop, because it becomes the context you hand the model next time. A knowledge base that reflects reality is a compounding asset. One that lies is worse than none at all, because it teaches both people and models to trust the wrong thing.

If the documentation cannot be signed off because nobody is sure what the system does, that is not a documentation problem. That is a signal that slop has already crept in.

Pause and ask: what am I doing, and why

This is the quietest discipline and the most important one. In the flow of an AI-assisted session it is easy to keep accepting suggestions, keep generating, keep shipping, and lose sight of whether any of it is heading somewhere sensible. The model never gets tired and never questions the direction, so that responsibility sits entirely with you.

Stop, regularly and deliberately. Ask what you are actually doing and why. Does this change serve the goal you set out at the start, or has the goal quietly drifted. Is this the simplest approach that solves the real problem, or are you building complexity because the model offered it. Would you be comfortable defending this decision to a colleague who was not in the room. These pauses cost minutes and save weeks. They are the moments where you catch slop before it becomes load-bearing.

Clean, structured, and secure, at rest and in transit

Generated code is not exempt from the standards you would apply to anything else. If anything it needs closer scrutiny, because it arrives looking finished and confident when it may be neither.

Clean means readable, consistent with the conventions of the codebase, and free of the dead ends and half-finished experiments that accumulate in a fast session. Well structured means the boundaries make sense, responsibilities are clear, and someone new could find their way around. That structure is itself context for the next reader, human or machine. None of it is negotiable simply because a machine wrote the first draft.

Security has to be concrete. Validate every input rather than trusting that it will arrive in the shape you expect. Enforce permissions on every path that touches something sensitive. Protect secrets so they never end up in logs, in the client, or in a repository. Handle errors so they fail safely instead of leaking detail to an attacker. Protect data both at rest and in transit, encrypted where it is stored and encrypted as it moves, so that a single lapse does not expose everything. These are not features to add later. They are properties the system either has or does not, and the time to build them in is now.

Give specialised work to specialised agents

Here is where AI stops being a slop machine and becomes genuine leverage. The mistake is asking one general-purpose session to do everything at once, because that is precisely the recipe for output that is broadly plausible and specifically wrong. The better pattern is to treat AI as a team of specialists, each with a narrow remit, a clear standard to enforce, and a focused slice of context to work within.

Set up dedicated agents for the concerns that matter, and let each do one job well. A code quality reviewer that checks structure, readability, and adherence to your conventions. A performance reviewer that looks for the queries, loops, and patterns that will not hold up under load. A security reviewer that hunts for injection points, broken access control, and exposed data with a suspicious mind. A documentation agent that keeps both the developer reference and the user-facing knowledge base honest and current as the code evolves.

Specialisation works for the same reason it works with people, and for the same reason context matters everywhere else. An agent given one job and the context for that job is far more likely to catch what a general session, drowning in everything at once, skims past. When each concern has its own reviewer with its own standard, quality stops being something you hope for at the end and becomes something the process produces along the way. That is the opposite of slop. It is a system designed to catch its own mistakes.

Understand the engineering, not just the prompts

If context is everything, then understanding how context actually works is the deepest skill of all. There is a temptation to treat AI as a black box you talk to, and to believe that the right words are all that stand between you and a good result. Prompting matters, but it is only the surface.

Understanding AI engineering changes how you work. It shapes how you structure context, and why some information belongs in the prompt while some belongs in a retrieval layer. It informs how you choose and route between models, matching the tool to the task instead of reaching for one model for everything. It explains why context windows, grounding, and retrieval behave the way they do, and why a model confidently invents detail when it is starved of the right information. It is what lets you design agents that hold up in production rather than agents that merely demo well.

You do not need to train models to benefit from this. You do need enough of a mental model of how they work to stop treating good output as luck. This is the far side of the Dunning-Kruger curve made practical. The deeper the understanding goes, the more precisely you can control the context, the less you are at the mercy of the tool, and the further you get from slop.

Why this makes you faster, not slower

It is fair to read all of this as a call to slow down, and to worry that discipline is the enemy of speed. The opposite is true. Discipline is what makes AI fast.

The teams drowning in slop are not slow because they think too much. They are slow because they think too little up front and pay for it endlessly afterwards, in rework, in debugging code nobody understands, in security incidents, in features rebuilt three times because the intent was never clear. That tax compounds, and it eats the very speed the AI was supposed to deliver.

Get the principles right and the compounding runs the other way. When the context is complete, the model produces work you can keep the first time. When the plan is stress tested across models, you build the right thing instead of discovering it was wrong in production. When the object model is shared, nothing drifts. When agents specialise, quality arrives with the work rather than after it. When you write no more code than you need, there is less of everything to maintain. Each of these removes a source of friction, and together they do not add up, they multiply. In my own experience the rate of real innovation, shipped and stable rather than merely demoed, runs well beyond ten times what it was, and it does so precisely because the slop that used to consume the gains is no longer there. Discipline is not the cost of speed with AI. It is the mechanism of it.

Slop is a choice, and so is the alternative

None of this is about slowing down for its own sake. It is about staying in command of work that AI has made faster than our instincts have caught up with. The tools will keep improving. The temptation to let them think for you will only grow.

It all comes back to one idea. Context is everything. Slop is what fills the space where context should have been, and every discipline here is a way of filling that space on purpose. Own the plan, then stress test it across more than one model. Anchor the work in a single object model so the words never drift. Do the research, and respect the rules and the security implications from the start. Design for the scale you expect. Work by a method rather than improvising. Write no more code than the problem demands, because the best code is the code you never had to write. Document as you go and sign it off. Pause often enough to know what you are doing and why. Hold generated code to the same standard as anything else. Use specialised agents to enforce the quality you have decided matters. And understand the tools well enough that good output becomes a result you can repeat, not a stroke of luck you cannot explain.

AI did not lower the bar. It just made it easier to walk under. Keeping it high is a choice, and it is still ours to make. Make it, and the reward is not just cleaner work. It is a rate of innovation that leaves slop-bound teams standing still.

Get in touch

If your team is feeling the drag of AI slop, the rework that never ends, the code nobody understands, the features that demo well and break in production, you do not have to solve it alone. At Digital Discovery Group we help teams put these principles into practice, from context and planning through to secure, documented, production-grade delivery, so that AI becomes the multiplier it is supposed to be rather than a faster way to make a mess.

If you would like help understanding how to avoid slop and get the real return out of AI, contact me at Digital Discovery Group on 0416 279 893. I would be glad to talk it through.

Nigel Price is the founder of Digital Discovery Group, specialising in ecommerce strategy, digital transformation, AI-powered platforms, and managed cybersecurity services for small and medium businesses.