Is AI overhyped?

Is AI overhyped?

The capabilities are real and the claims run ahead of them, and both of those statements are true at the same time. Models do things today that were impossible five years ago, and those things run in production at thousands of companies. The predictions built on top of that, about which jobs disappear and how soon, routinely outrun what the people shipping the products report.

Holding both facts at once is the useful position, because the engineers on a call hold one or the other with conviction. This lesson closes out the module by laying out what the technology reliably does, the two failure words that come up constantly, and the honest case each camp has. The rest of the module supplied the vocabulary. This is the argument the vocabulary gets used in.

What do models reliably do today?

Five uses have moved past debate. Models draft and rewrite text. They summarize long documents. They translate between languages. They write routine code. And they pull structure out of messy input, turning a pile of emails or forms into clean rows of data. Each of these runs in production at thousands of companies, doing real work with real customers on the other end.

The common thread is that all five are text work with a tolerant definition of success. A summary can be worded a hundred ways and still be a good summary. Routine code has been written thousands of times before, so the patterns sit deep in the training data. This is the territory where every product shape from the last lesson lives: chatbots answering support questions, copilots drafting inside existing tools, agents working through multi-step tasks.

Reliability drops where the tolerance drops. Arithmetic, precise citations, legal and medical facts, and long chains of reasoning where one early mistake poisons everything after it: these fail often enough that teams build checks around them. A candidate who has shipped AI features can usually describe exactly where their product sat on that spectrum, because the failure rate decided most of their engineering work.

What is hallucination, and why has it not been fixed?

Hallucination is a model stating something false in the same confident voice it uses for true statements. A hallucinating model invents a court case, a package name, or a customer policy, and delivers it with the fluency of a real answer. The name is borrowed from the human symptom and it slightly misleads: the model perceives nothing falsely, because the model perceives nothing at all. It produces likely text.

That is also why the problem persists. A model works by predicting the next token, and nothing in that process checks facts. Prediction produces true statements when the truth is the likeliest continuation, and it produces false ones the same way, so a wrong answer looks exactly like a right one from the outside. There is no error message and no flicker of doubt to catch.

The mitigations are real. Grounding answers in a company's actual documents, the technique the plumbing lesson covered as RAG, cuts hallucination sharply because the model restates what it was handed instead of recalling from training. Better training has helped, and evals exist largely to measure how often it still happens. It still happens. Serious AI products are designed on the assumption that it will, with sources shown, humans reviewing, or stakes kept low.

What is slop?

Slop is AI output that someone generated and published without reviewing it. The word borrowed its tone from farm feed, and developers now apply it to unreviewed AI text of every kind: blog posts, support replies, resumes, and code. In code it has a recognizable look, described in builds versus uses territory as the difference between using a tool and outsourcing to one: long comments restating the obvious, helper functions nothing calls, and tests that pass while checking nothing.

The word carries a precise complaint, and it aims at the missing review rather than at the tool. Developers who use AI heavily every day still say slop with full contempt, because the offense is shipping something no human read. On engineering teams the pressure lands on code review, where reviewers now handle larger volumes of plausible-looking output, and reading it costs more attention than reading a visibly rough draft ever did.

Slop is worth knowing because it is the most common word in a developer's mouth when they sound negative about AI. The complaint is narrower than it sounds. A candidate who grumbles about slop is usually describing a review burden rather than rejecting the technology.

What does the enthusiast camp say?

The enthusiast case rests on trajectory. The reliable list in the second section was science fiction in 2020, and each model generation since has been measurably stronger, while inference prices for a given level of capability have fallen fast. Enthusiasts extend that curve forward and conclude that today's failure rates are a snapshot rather than a ceiling.

Their strongest evidence is their own workday. Developers in this camp run coding agents for hours at a stretch and report shipping in days what used to take weeks. Many of them earned their conviction recently, since the tools crossed a usefulness threshold within the last couple of years, and the labs keep moving it. The camp includes some of the most experienced engineers in the industry, which is worth registering: this is a position serious people hold from daily evidence, and enthusiasm on a call reads as a report from someone's actual tools.

What does the skeptic camp say?

The skeptic case rests on the gap between a demo and a system. Skeptics agree the capabilities exist. Their argument is about reliability and cost at scale: a step that works 95 percent of the time fails constantly when it runs ten thousand times a day, hallucination makes the failures hard to catch, and inference bills grow with every user. Many skeptics earned the position by shipping an AI feature and then living with its behavior in production.

Skeptics also point at the money. The labs spend enormous sums training foundation models, the revenue to justify it is still forming, and the industry has run on projected value before. An engineer who lived through a previous hype cycle recognizes the shape.

The two camps overlap more than their volume suggests. Both use the tools, and both agree on what the tools can do. The disagreement is about how far reliability improves and how fast, which is an honest open question. Specific skepticism, the kind that names a failure and what it cost, comes from experience as surely as enthusiasm does.

Why do the demos and the shipping teams disagree?

Because a demo shows the best case and a shipping team lives with the average case. A launch video is the strongest result from many attempts, run on chosen examples with a person steering. A production system meets every input, including the strange ones, with nobody steering, and gets judged on its worst week. Both reports are honest. They describe different points on the same distribution.

This gap accounts for most of the distance between a headline claim and what a candidate says on a call. When a developer sounds less impressed than the news, they are usually reporting the average case from inside a real system, and that account tends to be the more precise one: which tasks held up, which failed, and what the team built around the failures. That texture separates a practiced opinion from a repeated one, in either camp, and by this point in the path the vocabulary it comes wrapped in is yours.