Overview:
This article is a humorous take on the growing gap between the quantity of AI-generated output and its genuine quality.
keywords: artificial intelligence, AI-generated content, AI-assisted software development, software engineering, code quality, technical writing, software testing, code review, developer productivity, human oversight, software craftsmanship, validation
1. Introduction
Artificial intelligence has given us a remarkable superpower: the ability to produce more code, more articles, more documentation, and more opinions than ever before.
Naturally, we have used this power responsibly.
Just kidding. Of course we haven't.
We've unleashed a content firehose, and we're all standing around wondering why the water tastes weird.
Some of what AI produces is genuinely brilliant. Some of it is useful with a little polishing. And some makes you wonder whether anyone involved has actually read the output, let alone checked whether it makes any sense.
So how did we get here? And why, when generating things has become so ridiculously easy, does producing something genuinely good still seem so difficult?
Let's investigate.
2. The Content Explosion
In the span of a few short years, everyone became an expert.
Blog posts appeared. Tutorials appeared. Architecture guides appeared.
Ten-part series sprang out of nowhere to explain technologies that had been released eleven minutes earlier.
There were articles titled:
- The Ultimate Guide to Building Scalable Applications
- Why Everything You Know About Programming Is Wrong
- I Replaced My Entire Development Team With AI
- Best Practices That Will Make You a 10x Software Engineer
The last one was written by someone who had never been a software engineer. It contained 47 best practices. The author was 11 years old.
Each article had a compelling introduction, seventeen headings, three code examples, and a conclusion beginning with the words "In today's rapidly evolving technological landscape."
That phrase appeared so frequently that developers began to suspect it was being used as a substitute for actual thought. They were not entirely wrong.
But the articles were beautifully formatted.
They had bullet points. They had bold text. They had code fences. Some even had diagrams.
And somewhere, deep within the prose, there might have been a useful idea or two.
Possibly.
The problem was that finding truly meaningful and insightful information required the patience of an archaeologist and the caffeine tolerance of a production engineer during an outage.
Welcome to the age of infinite content: where the supply of output is unlimited, but attention spans are decidedly not.
The same thing was happening to code.
Developers were generating entire applications, test suites, API clients, configuration files, and architectural masterpieces, all before second breakfast.
Some of the results were excellent. Some were adequate. Some were technically impressive solutions to problems nobody had.
And some were the software equivalent of a shopping cart with a wobbly wheel: technically functional, but an experience nobody would willingly repeat.
We had become extraordinarily good at producing things.
But we often forgot to ask whether any of that stuff deserved to exist in the first place.
3. Thin Gruel and Hotdog Water
There is a particular kind of AI-generated content that reminds me of thin gruel.
It is not necessarily offensive. It is not necessarily incorrect. It is simply disappointing.
You read three paragraphs and realize you've consumed several hundred words without encountering a single new thought.
The article explains that testing is important, security matters, and maintainability is desirable.
It explains that developers should follow best practices. Thank goodness; for a moment, we were in danger of doing otherwise.
The prose is smooth, the grammar is impeccable, and every sentence arrives wearing a little name tag that says Technically Reasonable Statement.
But there is no flavor. No aroma. No experience. No tattoos. No scar tissue.
No mention of the production database that was accidentally truncated because someone confused a staging connection string with a production one.
No story about the developer who spent six hours debugging a race condition that turned out to be caused by a virtual machine's clock drifting several minutes into the future.
No hard-won lesson or insight forged in the fires of actual inconvenience.
Just a pleasant bowl of beige blandness. And then another bowl. And another.
The problem isn't that the writing is bad.
The problem is that it has nothing particularly significant to say.
It's the literary equivalent of a "Hide the Pain Harold" meme.
Harold smiles at his laptop and says something innocuous and mildly amusing.
You chuckle, but five minutes later, you've probably moved on and forgotten what he said.
The same phenomenon appears in code.
A class is created because classes are good.
An interface is introduced because interfaces make code maintainable.
A factory creates a provider that resolves a strategy that delegates to a manager that orchestrates a handler.
The abstractions are immaculate.
The code actually compiles and does something.
But the AI generated it, the IDE formatted it, and the deployment pipeline sent the change straight into production.
And that's the problem with the AI content firehose: it easily produces something that, on the surface, appears useful.
However, producing something that actually is useful often remains elusive.
It's not that every piece of AI-generated writing is bad. And it's not that AI can't produce something insightful, surprising, or genuinely useful.
It's just that grammatical correctness, professional formatting, and a convincing imitation of expertise are no longer particularly strong signals of substance.
When everyone can produce an endless supply of plausible content, plausibility stops being impressive.
We're left with an internet overflowing with words that look like they should mean something, code that looks like it should work, and explanations that look like they should teach us something.
And somewhere in all that volume, the distinction between merely generating something versus producing something meaningful and important gets lost.
The firehose keeps running, and the bowls keep filling up.
Occasionally with a delicious and nourishing soup.
But more often with thin gruel.
And sometimes, just hotdog water.
4. The Quality Problem
Now, before anyone gets too terribly upset, let us establish something important.
AI can produce excellent work. Remarkable work, even.
It can help an experienced developer explore unfamiliar code, uncover edge cases, generate useful tests, explain complicated concepts, and build prototypes that would otherwise take days.
It can help a talented writer organize their thoughts, improve their prose, and overcome the dreaded blank page.
Sometimes it produces something so good that you stare at the screen and whisper: "Well, that's annoyingly impressive."
The problem is not that AI always produces bad work.
The problem is that it produces work of wildly varying quality, often with remarkably consistent confidence.
Some output is excellent. Some is adequate. Some is wrong in ways that are immediately obvious.
And some is wrong in ways that will require a production incident, a security audit, and three senior engineers to discover.
Unfortunately, the good, the bad, and the ugly all tend to arrive wearing shockingly similar cowboy suits.
The code is formatted. The explanation is coherent. The article sounds authoritative. The answer arrives in seconds.
There is no flashing red light that says: WARNING: THIS SOLUTION WAS ASSEMBLED FROM A PLAUSIBLE INTERPRETATION OF REALITY.
There is no little bell that rings when the machine invents a library method.
No smoke emerges from the laptop when the generated SQL quietly deletes the wrong rows.
The machine simply presents its work. Confidently. Politely. And with impeccable Markdown.
And we, being busy people with deadlines, are sometimes inclined to believe it.
5. The Missing Step
So why does this happen?
Why can the same technology produce both extraordinary work and absolute crap?
Part of the answer is that generating an answer and verifying an answer are two different activities.
A language model can produce a convincing continuation of a prompt without establishing that every claim is true, every assumption is justified, or every line of code behaves as intended.
It can generate something that resembles a solution.
That resemblance can be useful. It can also be dangerous.
Consider a simple request: "Write a function that validates an email address."
The machine produces a function.
It looks reasonable. It has a descriptive name. It handles empty input. It uses a regular expression. It has comments. It has tests.
The tests pass.
But perhaps the expression rejects perfectly valid addresses.
Perhaps it accepts addresses that your application cannot actually deliver to.
Perhaps your requirements never called for a comprehensive email validator in the first place.
The function isn't necessarily useless. However, just because it looks like it was written by someone who knew what they were doing doesn't automatically mean it's correct.
Now consider a different request: "Write a comprehensive guide to database indexing."
The machine produces 2,000 words.
It explains B-trees. It discusses query performance. It mentions write overhead. It includes SQL examples.
Everything sounds sensible, but perhaps one example is misleading.
Perhaps a claim about a particular database engine is outdated.
Perhaps the author has never actually diagnosed a slow query in production.
Perhaps the article repeats familiar advice without explaining when that advice stops being useful.
The output exists, but the work of establishing its quality does not magically appear alongside it.
This is the missing step.
We have become very good at asking machines to produce things.
However, we are still learning how to take responsibility for what they actually produce.
6. The Great Validation Shortage
Let us imagine a small software company. The company has adopted AI-assisted development. Productivity has increased dramatically.
Previously, the team produced five pull requests a week. Now it produces fifty. Management is thrilled.
A slide deck is prepared.
The slide deck contains a graph that goes up and to the right.
Someone adds the word transformation.
Someone else adds the word exponential.
The slide deck is thoroughly impressive.
The company schedules a meeting to celebrate.
Meanwhile, the quality engineering team has not grown.
The code review process has not changed.
The integration test suite still takes 38 minutes to run.
The person who understands the payment system is on vacation.
And the backlog of things that need careful human attention has increased tenfold.
The company has successfully accelerated production, but it has not accelerated understanding by the same amount.
And so the pull requests accumulate.
Some are excellent. Some are harmless. Some introduce subtle bugs.
Some contain duplicated abstractions that solve problems nobody had.
Some have tests that verify the implementation's assumptions rather than the requirements.
One contains an entire retry framework for an operation that cannot fail.
Another contains a caching layer that makes the application slower.
A third introduces a dependency to save a line feed at the end of every script.
Nobody notices because the code is beautifully formatted and the pull request description says: "Improves reliability, maintainability, and performance."
This is a particularly effective sentence. It promises three benefits without requiring the author to demonstrate any of them.
Eventually, someone asks whether the new code is actually better.
Silence follows.
A developer opens the AI assistant and asks, "Can you review this code for potential issues?"
The machine produces a detailed review. The review is thoughtful. It identifies several genuine concerns.
It also recommends a refactor that introduces a different set of problems.
The developer accepts the suggestions.
The tests pass.
The pull request is merged.
And somewhere, in the distance, a production engineer begins to experience a severe migrane.
7. The Test That Tested Nothing
Of all the small tragedies in the AI age, my favorite is the test suite that exists primarily to reassure its author.
AI can generate tests remarkably quickly. This is useful.
It can also generate tests that are remarkably good at confirming that the code does exactly what the code already does.
Suppose we have a function that calculates a discount, but the function is wrong: it applies a 20% discount twice.
We ask AI to generate unit tests.
The machine examines the function and generates tests based on its implementation.
The tests pass. Everyone is happy.
But the discount is still wrong.
We have not tested the business requirement; instead, we have merely tested the machine's interpretation of the implementation.
This is not a test suite; it's a mutual appreciation society.
The code says, "I believe this is correct."
The tests reply, "We agree."
The production system says, "I would like to introduce myself."
Of course, AI-generated tests can be extremely valuable. They can uncover edge cases, improve coverage, and save significant time.
But tests need an independent basis for judging correctness.
Requirements. Invariants. Expected outcomes. Known edge cases. The behavior that the system is supposed to exhibit, rather than just the behavior it currently exhibits.
Alas, we have built a very efficient machine for producing evidence that agrees with itself.
8. The Author Has Left the Building
There is another problem: ownership.
When a developer writes a complicated function, they usually have at least some idea why it exists.
They may remember the bug that motivated it.
They may remember the failed approach that came before it.
They may remember the awkward conversation with the database administrator who explained that the query they had written was, technically speaking, a crime.
They possess context, but not always enough context.
Software engineers are perfectly capable of writing code they do not understand. We have been doing this for decades, and the evidence is stored in repositories around the world.
AI has simply made it easier to produce more of it.
A developer asks for an implementation. The implementation arrives.
The developer asks for an explanation. The explanation arrives.
The developer asks for a refactor. The refactor arrives.
At no point does the developer necessarily develop a reliable mental model of the resulting system.
And then comes the maintenance ticket.
"Update the behavior of the notification service to accommodate the new customer preference rules."
The developer opens the code.
It contains 14 interfaces, six factories, three adapters, and a class called NotificationOrchestrationStrategyResolver.
The original developer is no longer on the project.
The person who generated the code is not available.
The AI assistant explains the implementation.
The explanation is plausible.
The developer makes a change.
The tests pass.
Something breaks.
And so begins the ancient ritual of software archaeology, now conducted with a chatbot and considerably more generated code.
The question is not whether AI wrote the code.
The question is whether anyone understands it well enough to maintain it.
9. The Human in the Loop
At this point, someone will inevitably suggest that we should simply keep a human in the loop.
Excellent. Let us do that. We will place a human in the loop.
The human will review the generated code, verify the claims, inspect the tests, validate the assumptions, check the dependencies, assess the security implications, and confirm that the result meets the actual requirements.
The human will then approve the work. There is only one small problem. Well, actually several.
The human has 23 other things to do.
The human has a meeting in six minutes.
The human has already reviewed 19 pull requests today.
The human has been told that AI will increase productivity, which means that the expected volume of work has increased accordingly.
The human sees a clean diff.
The human sees green check marks.
The human sees a detailed explanation of why the implementation is correct.
The human thinks: "Looks good to me," and clicks the "Approve" button.
We have successfully placed a human in the loop, but the loop has become a rubber stamp.
This is not a failure of human intelligence; it is a failure of process design.
If we increase the volume of generated work without allocating sufficient time for careful review, thorough testing, and meaningful verification, we should not be surprised when quality suffers.
We have merely moved the bottleneck.
And then, for reasons that remain mysterious, we have asked the bottleneck to move faster.
10. The Return of the Craftspeople
Perhaps the answer is to become more deliberate about what we choose to accelerate.
Use AI to generate the first draft.
Use it to explore unfamiliar APIs.
Use it to suggest test cases, explain complicated code, identify potential vulnerabilities, and automate the repetitive parts of development.
Use it to get past the blank page.
Use it to save time on the tedious work that prevents us from doing the interesting work.
But then actually do the interesting work.
Read the code. Run the tests. Challenge the assumptions. Verify the claims. Check whether the solution fits the actual problem.
Ask whether the abstraction is necessary.
Ask whether the article contains an insight or merely an assortment of grammatically correct sentences.
Ask whether the tutorial was tested against the current version of the software.
Ask whether the impressive-looking benchmark measures anything that truly matters.
Ask whether the code is understandable to the person who will maintain it next year.
And occasionally ask the most important question of all: "Would I have accepted this if a junior developer had submitted it without mentioning AI?"
If the answer is no, then perhaps it needs another look.
Not because AI is inherently untrustworthy, but because the standards for accepting good work should not depend on how quickly it was produced.
11. The New Definition of Productivity
We may need to reconsider what we mean by productivity.
For years, software development has been obsessed with output.
Lines of code. Features delivered. Tickets closed. Pull requests merged. Articles published. Pages generated.
We have measured the things that are easy to count and occasionally confused them with the things that matter.
AI makes this confusion considerably more entertaining.
Question 1: If a developer can generate ten times as much code, is the developer ten times as productive?
Answer 1: Only if the code produces ten times as much useful value without creating a proportional increase in defects, maintenance costs, and cognitive overhead.
Question 2: If a writer can publish ten articles in the time previously required to write one, is the writer ten times as productive?
Answer 2: Only if the articles are worth reading.
Question 3: If an organization can generate a thousand tests, has it improved quality?
Answer 3: Only if those tests provide meaningful evidence that the software behaves correctly.
Volume is not value. Speed is not quality. Confidence is not correctness. And green check marks are not a substitute for thinking.
The most productive developer may not be the one who generates the most code.
It may be the one who generates the right code, catches the subtle bug before it reaches production, and deletes 400 lines of unnecessary abstraction.
The most productive writer may not be the one who publishes every morning.
It may be the one who publishes something worth remembering once a month.
The machines can help us produce more.
We still have to decide what deserves to exist.
12. The Great Opportunity
It would be easy to conclude that we are drowning in garbage AI content.
That statement would be unfair.
There is plenty of garbage in software and writing that predates AI.
We have always had bad code. We have always had mediocre articles.
We have always had cargo-cult architecture, cargo-cult testing, and people who confidently explain things that they barely understand.
We have always had a tendency to reward visible activity over invisible craftsmanship.
AI did not invent these problems; however, it did give them a much more powerful distribution mechanism.
But it also gives us an extraordinary opportunity.
Imagine a world in which generating the first draft of an implementation takes seconds, leaving more time to examine its design.
Imagine tests that are generated quickly and then strengthened with independently defined requirements.
Imagine documentation that is drafted automatically and verified against the actual behavior of the system.
Imagine developers spending less time writing boilerplate code and more time understanding the actual problems they are trying to solve.
Imagine technical writers using AI to organize research while retaining the experience, judgment, and personality that make their writing worth reading.
Imagine a culture in which publishing something quickly is considered useful, but publishing something correct and insightful is considered essential.
That would be progress.
Not because the machines have replaced the craftspeople.
Rather, because the craftspeople have better tools.
And also because we've finally realized that swinging a hammer faster doesn't really make someone a better carpenter.
13. The Final Review
And so we arrive at the present day.
The machines are generating code. They are generating tests. They are generating documentation.
They are generating articles about generating code, tests, and documentation.
Some of the results are extraordinary.
Some are perfectly adequate.
Some are thin gruel.
Some are hotdog water.
And some are the sort of thing that makes a senior software engineer stare at their monitor in stunned silence for several minutes.
This is not the end of software engineering.
It is not the end of writing.
It is not the end of human creativity.
It is simply another moment in which our tools have become more powerful than our habits have become wise.
We must adapt our techniques purposefully and meaningfully.
We could respond by generating more.
More code. More articles. More frameworks. More tutorials. More documentation explaining the documentation.
Or we can learn to value the part of the process that has not become obsolete.
Judgment. Experience. Curiosity. Verification.
The willingness to say, "This looks convincing, but I don't believe it yet."
The humility to admit that a generated answer might be wrong.
The discipline to test it anyway.
The good sense to delete it when it is unnecessary.
And the courage to publish an article that contains an actual opinion, even if that opinion cannot be summarized in a bulleted list of best practices.
The future does not belong to whoever can generate the most.
It belongs to whoever can consistently turn generated material into something useful, reliable, and worth the time it takes to consume it.
So go forth. Generate boldly. Experiment enthusiastically.
Let the machines do the tedious work.
But before you merge that pull request, publish that tutorial, or proudly announce your new AI-powered productivity framework, take a moment to review the result.
Read it. Test it. Question it. Taste it. Sniff its butt.
Because if the code is broken, the article is empty, and the tests merely agree with the bugs, we have not automated craftsmanship.
We have automated the production of things that look like craftsmanship.
And there is a difference. In fact, a rather important one.
Human intelligence.
14. Full Disclosure
It is highly likely the author of this article used AI.
I do hope they remembered to proofread it before publishing it.
Top comments (1)