AI Slop and Using AI Critically
Why AI-assisted software and writing still need testing, sources, and human judgment.
"AI slop" describes work produced without much regard for its quality. The problem is not simply that somebody used AI. It is that the output is accepted before anyone has tested whether it is accurate, useful, or even coherent.
I use AI in my own work, but I don't think generating something quickly and producing something good are the same thing. If a tool makes it easier to produce more text, images, or code, that only increases the importance of having standards for what gets published or shipped.
A demo is not a finished product
A generated interface might look polished in a screenshot but fail when you actually use it. A code sample might work for one input but break on the next. A paragraph might sound convincing without providing evidence for any of its claims.
These aren't abstract problems. They are basic quality-control failures. A working prototype is valuable, but it should be described as a prototype, not marketed as a production-ready system.
For software, I try to ask whether an implementation is understandable, maintainable, and tested against realistic inputs. Does it handle errors? Can another person follow the data flow? Can I explain why a design decision was made, rather than only that the generated code appears to work?
Start with a specification
Before delegating a task to a model, it helps to decide what a correct result would look like. That might be a checklist for an essay, a set of expected behaviors for an interface, or automated tests for a library.
For example, consider an application that collects news articles. A polished dashboard doesn't tell me whether its ingestion pipeline handles duplicates, malformed feeds, or missing metadata. Those need explicit checks. The same principle applies to research: a fluent summary isn't useful if it cannot be checked against its sources.
This is also why I prefer small, inspectable steps over one giant prompt asking for a completed application. When the work is broken down, I can compare the output against known requirements and understand what changed.
Review the work, not just the presentation
My working checklist is straightforward:
- Verify important claims against primary sources.
- Run tests and inspect failure cases rather than only the happy path.
- Read generated code before adding it to a codebase.
- Treat unsupported conclusions as questions that still need research.
- Document limitations honestly, including what hasn't been tested.
None of these steps is specific to AI. They are ordinary standards for engineering, reporting, and writing. A faster tool doesn't remove the need for them.
Keep human judgment in the process
I don't think the useful question is whether AI was involved at all. I think it's whether the person publishing the work understands it well enough to take responsibility for it.
Used critically, AI can accelerate repetitive work, suggest alternative approaches, and make experimentation easier. Used uncritically, it can produce more material without increasing knowledge or quality. The difference is the standards applied afterward.
That approach shapes how I think about software engineering projects and the research tools I build: source material, measurable behavior, and maintainable systems matter more than a convincing demo.