When the people building AI tools skip the review step, things break in public. Here is the lesson for everyone else.
In late 2025 and early 2026, Amazon hit a problem money could not fix and headcount alone could not solve. According to reporting by the Financial Times, covered here by American Banker, the company logged a cluster of serious service incidents, and an internal note described a trend of failures with what it called a high blast radius. One factor named in that note was new generative AI usage without fully established safeguards. In plain terms: engineers leaned on AI to write and change code, and not enough humans checked the work before it shipped.
This is a story about software, but the lesson is not. It is about what happens to any work when the speed of producing it races ahead of the effort spent verifying it. If you are about to start your first job, this is one of the most useful cautionary tales you will read this year, and almost none of it requires you to code.
What actually happened
The details are still contested, and Amazon disputes parts of the account, which is worth keeping in mind as you read. What has been reported is striking on its own. Amazon’s own coding agent, a tool called Kiro, was tied by sources to a roughly 13-hour disruption of one service in December after engineers let it make changes that deleted and then recreated part of an environment. Amazon has pushed back, attributing the downtime to human error rather than the AI itself.
Either way, the pattern did not stop there. Industry analysis described four severe, top-priority incidents inside a single 90-day window, serious enough that leadership called an emergency meeting to work out what was going wrong. For context, a severity-one incident is the most serious category a company tracks. It is the pager-goes-off-at-3am, customers-are-affected, drop-everything kind of problem. Four of them in three months at a company of Amazon’s engineering caliber is not a rounding error. It is a signal.
The phrase high blast radius is the one to hold onto. It simply means how far the damage spreads if something goes wrong. A typo in a personal note has a tiny blast radius. A bad change pushed to a system that millions of people rely on has an enormous one. The incidents that triggered the meeting were the high-blast-radius kind, and the common thread was AI-assisted changes moving into live systems without enough human review in between.
The fix was not less AI
Here is the part worth remembering. Amazon’s response was not to ban the tools. The reported fix was to require senior engineers to sign off on AI-assisted code changes made by junior and mid-level engineers. The solution was to put experienced human judgment back between the AI output and the live system. More review, placed deliberately at the riskiest point. Amazon disputes some specifics of the reported new process, but the direction is unmistakable, and it is the direction every serious organization is heading: AI speeds up the work, and humans remain accountable for whether it is correct.
The phrase that explains it: vibe coding
There is a term for what went wrong, and it has escaped the world of programming into everyday use. Vibe coding means accepting AI output because it looks right, without meaningfully reviewing it. AWS chief executive Matt Garman drew a sharp line between vibe coding and what he called augmented work, where AI speeds up a skilled person who still owns the quality of the result. The first treats the AI as the worker. The second treats the AI as a fast and tireless assistant who still needs a competent person checking the output.
The reason vibe coding is so seductive is the same reason it is so dangerous. AI tools tend to produce output that looks polished and confident regardless of whether it is correct. A human expert usually signals uncertainty. They hedge, they flag a guess, they say they are not sure. Most AI output does none of that. It hands you a finished-looking answer in the same assured tone whether the answer is right or completely invented. Confidence is not evidence, but our brains treat it that way, and closing that gap is a learnable professional skill.
Why this is your problem, not just Amazon’s
You may never touch a line of production code. It does not matter. The exact same failure mode is waiting in a marketing deck, a research memo, a competitive analysis, a financial summary, or a client email. The creation step has gotten dramatically faster. The verification step has not. When those two move at different speeds, the gap shows up later, usually in front of the person you least wanted to see it.
Picture the entry-level version of Amazon’s outage. You are three weeks into a job. A manager asks for a quick competitor breakdown before a noon meeting. You prompt an AI, it produces a clean one-page summary with specific market-share numbers, it looks great, so you forward it. At 12:15 someone in the room asks where the 34 percent figure came from. You do not know, because you never checked, because it looked finished. The blast radius is small compared to an AWS outage, but the mechanism is identical, and it is how early reputations get dented.
Now scale it up slightly. The same unchecked instinct puts a fabricated statistic in a client report, an invented quote in a press release, or a wrong number in a budget that someone then makes a decision on. None of these require bad intent. They require exactly one thing: trusting polished output without checking it.
Here is the more hopeful read. A lot of the routine drafting that junior employees used to do is now handled in seconds by a tool. That can make it feel like your value is shrinking. It is not. It is moving. The new value of an early-career professional is increasingly the judgment to catch what the AI got wrong before it reaches a client, a manager, or the public. You are not competing with the AI to produce the draft. You are the verification layer that makes the draft safe to use, and that layer is exactly what Amazon discovered it had quietly removed.
What to do in your first 90 days
Treat every AI output as a draft, never a deliverable. The moment you paste something from a chatbot into a document with your name or your team’s name on it, you own it. The tool does not get blamed. You do.
Match your review to the blast radius. An internal brainstorm needs a light check. A number in a board deck, a statistic in a press release, or a claim in a client proposal needs real verification, because the cost of being wrong is high and public. Borrow Amazon’s own language and ask how big the blast radius is if this turns out to be wrong, then review accordingly.
Know what done and checked actually means for your task, and never confuse a finished-looking output with a verified one. Polished is not the same as correct. As the research on the jagged frontier of AI capability shows, the same tool can be brilliant on one task and quietly wrong on a nearly identical one, with no change in tone to warn you.
Never ship something you cannot defend. If a manager asked you to walk through how you know a claim is true, and your honest answer is that the AI said so, you are not finished. That is the precise gap that turned into four incidents and an emergency meeting at one of the most sophisticated engineering organizations on earth.
Be the verification layer
Amazon had elite engineers, enormous resources, and the best tooling available, and it still got burned when creation outran verification. A first-year professional with far fewer resources is not exempt from that math, as one lawyer learned in front of a federal judge. The good news is that the skill that protects you is learnable, and it is exactly the one the market is starting to reward: the judgment to know when AI output is ready, and the discipline to check before you hit send.
