A Day Without AI SLOP Is a Day Wasted

Read These Three Words First

Before you read this article, calibrate your brain on these three terms. Everything that follows depends on the distinction between them:

1. Recognise: Experiencing what is already familiar. Matching incoming data against mental patterns you already possess. If you have never encountered a concept before, you cannot recognise that it is missing.
2. Uncertainty: It is the moment an AI agent confidently hallucinates, fabricates a technical justification, or overlooks a subtle bug with a massive blast radius. It is the zone where you cannot lean on passive assumptions.
3. Understanding: Not simply reading an explanation or processing syntax on a screen. It is an internal transformation becoming a newer, sharper version of yourself where a brand-new recognition pattern is permanently forged.

---

Every junior developer learning to code in this era carries a quiet, corrosive shame:

Am I actually an engineer, or am I just a glorified operator pumping AI slop into git repositories?

Senior engineers on tech Twitter warn that AI is creating a generation of developers who cannot think for themselves. Reddit threads mock junior pull requests filled with hallucinated methods, bloated boilerplate, and blind copy-pastes. The message is clear: Produce clean, handcrafted code, or you are polluting the codebase with slop.

I believed that narrative. I was terrified of submitting AI-assisted code that looked like "slop."

Then I submitted a pull request that nearly shipped an architectural hallucination to production. Wrestling with that failure taught me an uncomfortable truth:

A day without AI slop is a day wasted.

Here is the story of how a single hallucinated environment variable transformed how I learn.

The "Perfect" PR That Wasn't

I was working on an open-source project and spotted a developer experience (DevEx) bottleneck.

External contributors wanting to work on moderator features were blocked unless they had actual moderator credentials in the production database. To fix this, I wanted to allow developers in a local development environment to access moderator tooling by toggling a mock flag in their .env file.

The goal was simple:

1. Define a mock moderator environment variable for local environments.
2. Check the flag during local sessions.
3. Allow contributors to test moderator UI without touching live permissions.

I paired with an AI coding agent to implement the change. Within minutes, the agent generated the code. I spun up the local dev server, and it worked. I ran the test suite, and all tests were green.

I opened git diff before opening the pull request.

Syntax? Clean. Logic? Readable. Tests? Passing.

I looked at the diff and felt that warm rush of satisfaction. I could not recognise a single issue with it.

Why? Because my brain was in state one: Recognise. I only recognized what I had already experienced in generic web development. I knew how .env files worked. I knew how boolean flags worked. The diff matched my existing patterns, so I assumed it was correct.

Then came the plot twist.

The Confident Hallucination

The repository was built with SvelteKit.

In SvelteKit, environment variables are loaded and guarded through native modules like $env/static/private, $env/dynamic/private, or $env/static/public. This architecture prevents developers from accidentally bundling private secrets into client-side JavaScript.

The AI agent hadn't used SvelteKit's convention. Instead, it wired the variable through vite.config.js using Vite's generic build-time replacement.

I didn't notice the issue. The tests passed, so I opened the pull request.

A few hours later, a notification popped up on GitHub. The maintainer reviewed the PR and left an inline comment:

"Why are you configuring this in vite.config.js instead of following our codebase rule with $env?"

My stomach dropped. I had no idea. The AI had written the implementation, it worked locally, and I had trusted it without question.

Scrambling to understand what went wrong before replying to the maintainer, I opened my chat with the AI agent and asked:

"Why did you configure this in vite.config.js instead of using the codebase rule with SvelteKit's native $env module?"

The agent didn't pause. It didn't hesitate. It responded with absolute technical confidence:

"SvelteKit's $env handling is being deprecated in upcoming releases, so configuring it directly in vite.config.js is the forward-compatible pattern."

That statement plunged me straight into Uncertainty.

The AI spoke with complete authority. But the explanation felt off. Was SvelteKit actually deprecating $env? Was I about to parrot a fabricated excuse back to a senior maintainer and embarrass myself publicly on GitHub? Or was the maintainer the one who was out of the loop?

This was the fork in the road where junior developers get burned:

• Option A: Parrot the AI's explanation back to the maintainer and pray the machine was right.
• Option B: Step into the uncertainty, challenge the AI, and verify the facts directly from the source.

I refused to gamble my credibility on faith. I instructed the agent: "Search the official SvelteKit documentation and verify that claim right now."

A few seconds later, the model returned and says:

"I apologize for the confusion. I was mistaken. SvelteKit's $env module is fully supported and remains the recommended standard. Here is the correct idiomatic implementation..."

The Birth of Understanding

That exchange took 20 minutes, but it did something no tutorial had ever done for me: it forced Understanding.

Understanding is not what happens when you read a documentation page and nod along. Understanding is the structural change that occurs in your brain when your assumptions collapse, you confront the uncertainty, and you manually reconstruct the mental model.

I didn't just learn how to load an env variable in SvelteKit that afternoon. I learned:

• The distinction between Vite's build-time replacement and SvelteKit's runtime environment boundary.
• How easy it is for an LLM to invent plausible-sounding deprecation notices to rationalize bad architectural choices.
• That tests passing locally does not mean your code is architecturally sound.

Because I wrestled with the agent's slop, I upgraded my internal operating system. A new recognition pattern was stamped into my brain.

One Week Later: The Payoff

Seven days later, another contributor opened a PR in the same repository.

They were adding an environment variable for another local development utility. I opened their PR diff, and my eyes locked onto the exact lines they had written:

They had bypassed $env and hooked directly into vite.config.js.

The contributor had used a smaller, less capable LLM. The model had hallucinated the same generic Vite workaround, and the contributor, seeing green tests and clean syntax, had trusted it without question.

One week earlier, I wouldn't have spotted the bug. I would have scrolled past it.

This time, I caught it in five seconds.

I didn't need to look up documentation. I didn't need to consult an LLM. I possessed the recognition pattern, and behind that recognition pattern lay genuine understanding. I left an inline review explaining why SvelteKit isolates environment variables, linked the docs, and guided them toward the idiomatic fix.

The slop was the teacher.

How My Agentic Development Looks from Now On

Wrestling with AI slop might be the fastest way to learn, but letting that slop leak into a public pull request is genuinely dangerous.

Maintainers are human. They are often reviewing code late at night after a full workday. If a maintainer has an oversight and waves an unvetted AI hallucination into the merge queue, that code lands in production with a high blast radius.

Even when maintainers catch the issue, dumping sloppy PRs on them creates a terrible developer experience. It exhausts their energy, burns goodwill, and erodes trust. Once maintainers realize you are offloading unverified AI output onto their review queue, they will stop prioritizing your pull requests.

Your local machine is where you wrestle with the slop. The pull request is where you deliver verified, robust engineering.

Here is the exact agentic workflow I use now to protect maintainers and accelerate my own learning:

1. Start in Plan Mode

Never let an agent jump straight into code generation. Start by genuinely prompting the vision, intent, and architectural constraints you have. Outline the boundary rules before touching any files. Even if you do not understand the architecture or framework boundaries yet, explain your vision as clearly as you can, and explicitly ask the agent: Where might this go wrong?

2. Fast Scaffolding with a Cheaper Model

Use a faster, cheaper, less capable model to generate the draft implementation. This is where you test mechanics, explore rough edges, and scaffold the baseline logic quickly.

3. Fresh-Context Review with the Most Capable Model

Once the code works locally, switch gears. Open a brand-new, clean session and feed your diff into the most capable model you have access to. Because it has a fresh context without prior conversation bias, it can audit the changes objectively and present its findings on edge cases, architecture, and potential pitfalls.

4. The Growth Loop

This second review is your real classroom. Every time the top model catches an architectural mistake or a hallucinated pattern, take the time to understand why it was flagged. Fix the issues locally and make the PR robust before opening it.

Every catch by that review model is another permanent recognition pattern added to your brain. You become a sharper developer, and the maintainer receives a pull request they can actually trust.

Understanding Is Hard

Here is the dirty secret of the multi-model workflow: it creates a brand-new bottleneck.

You now have draft code generated by a cheaper model, and a thorough list of review findings from your top-tier model explaining why that code is flawed. But now you face the hardest part of the entire cycle:

You actually have to understand both of them.

You have to understand what the first model wrote, and you have to understand why the second model flagged it as bad. If you do not understand the critique, you are just blindly trusting a smarter machine instead of a dumber one. You are still trapped in superficial recognition.

And real understanding is exhausting.

I hit this wall hard until I stumbled onto a breakthrough while browsing the reading list on Allen Hutchison's blog (his writing and curated reading lists on LinkedIn are incredible). Among his recommendations, I found a talk on understanding that completely reframed my perspective on AI.

The core mindset shift was simple:

AI is primarily an understanding engine, not merely an automation tool.

Most developers only use AI to automate typing. But when you use it to multiply your comprehension, everything changes.

In the talk, the speaker described using AI to generate simple summaries paired with interactive quizzes and high-level visual representations of diffs. Inspired by this, I started adapting these techniques into my daily coding routine:

1. Mid-Explanation Quizzes

When a top-tier model critiques my code, I don't ask it for a long, dense lecture. Instead, I give it a specific instruction:

"Explain this review finding simply, but place short interactive questions directly in the middle of each explanation rather than at the end."

This small tweak changes everything. When quizzes are dumped at the end of a long response, your brain treats it like an intimidating final exam on a wall of text. But when the AI embeds quick, bite-sized questions in the middle of the explanation, reading becomes an interactive checkpoint. You cannot passively scroll past concepts you don't grasp. You verify each step before moving to the next.

2. Visual Simulations and Diff Diagrams

Code diffs in complex frameworks are inherently abstract. Instead of trying to parse raw text explanations, I prompt coding agents to generate standalone visual diagrams or simple UI simulations of the changes. Seeing a state flow or a data boundary visually gives you an immediate top-level intuition that 50 lines of explanation cannot match.

3. Lean, Interactive Interfaces

I paste the plan files and summaries into ChatGPT because its intelligent UI prioritizes visual understanding, simulations, and focused interactivity over endless walls of verbose text. When the interface is visual and interactive, cognitive fatigue drops and comprehension spikes.

Don't Fear the Slop

If you are learning to code in this era, stop feeling guilty about encountering AI slop.

The slop is not proof that you are failing as a developer. The slop is the friction that forces you out of passive Recognition, pushes you through Uncertainty, and gives you the raw material to forge true Understanding.

Wrestle with it locally. Interrogate it with better models. Quiz yourself on the findings. And never let unvetted code leave your machine.

A day without AI slop is a day wasted.