Georgios Diamantopoulos

Six tiers of AI slop, sorted by who actually pays, not by how bad it looks. → Tier 0 hurts nobody. The labeled meme, the throwaway clip. Aesthetic complaint at most. → Tier 1 costs a colleague. Workslop, the padded memo that looks finished and leaves the real work to whoever opens it. (40% of workers got one last month.) → Tier 2 farms a crowd. Engagement-bait pages, and now brands chasing them: Svedka's AI-generated Super Bowl ad, Activision's ads for games that don't exist. → Tier 3 robs a name. AI knockoff books, content farms, streaming-royalty fraud. A specific victim. → Tier 4 poisons a commons. AI slop is ~40% of what gets recommended to kids on YouTube, and upscalers are mangling old cartoons into "Suele Mario". → Tier 5 is built to deceive. Political deepfakes and state "slopaganda", from fake war footage to fabricated photos pushed by official accounts. The Tier 0 toolkit, pointed at what you believe. The trick the chart shows: harm runs opposite to quality, and the gap widens as the tools improve. A Tier 5 deepfake can be flawless. A Tier 0 meme can look terrible. Every tell you use to spot slop only catches the bottom rung. So next time someone says it's "all just slop", ask which tier. Tier 1 is fixed with discipline. Tier 3 with copyright law. Tier 5 with regulation. One word, six problems, a different fix for each. Full breakdown, with the tier-by-medium matrix, in the article.

Half my feed is people offering a "Claude skill" that's so good it "just" killed someone's SaaS. Most of them will pull a rabbit out of a hat the first time you run them, and get you sued the second. Why? Because doing it properly looks nothing like that. As an example, Anthropic published a cookbook for content moderation, an agent that decides whether a piece of content breaks policy. The specific job isn't the point; the same approach applies to almost any AI agent you'd actually ship. It's a slow read on purpose, because there's no fast version of the actual work. What that work buys you is an AI you can trust in production. It doesn't make the big calls on its own. When in doubt, it says so instead of guessing, and a person has to step in. Anything it does decide, you can go back and see why. Nothing ships until it's tested against real examples that people label by hand, then tested again every time the rules (or the model) change. None of that fits in a download. A lead magnet is built to get your email, not to survive real use. So look hard at what you're handed, or the joke's on you. Getting real value out of an AI agent is exactly the unglamorous work the cookbook shows and the lead magnet "expert" skipped. Someone has to build it properly, test it against real cases, and keep testing. The cookbook is free, and I'd rather you read it than another gated PDF. Download the skill instead, and here's where that leaves you: you gave your email to someone who discounts the worth of your time, and you're no closer to getting a real business outcome out of AI. If you want this built into your product, or your team taught to build it, that's the work we do: run a workshop, or build it with you. The cookbook, free and in full:

An AI-built booking prototype can be adequate for one salon on a demo account and dangerous three months later without a single line of code changing. At first, it holds test appointments. No money changes hands, and the founder expects the flow to change next week. It has one job: find out whether a salon understands and wants it. If it disappears tomorrow, nobody loses work. Then twelve salons start using it. Staff plan their day around its calendar. Customers trust its confirmations. Deposits pass through it. The next feature is staff permissions, deciding who may view, move or cancel an appointment. People now rely on the same prototype. That is when I would make the production investment decision with four questions: - Who depends on it now? Salon owners use it to run the day, staff use it to know who is arriving, and customers use it to know their time is reserved. - What must change in the next 90 days? Staff permissions and more payment states will touch the two places where a mistake reaches another person fastest. - What does one failure cost? A double booking puts two customers in front of the same chair. A permission mistake shows one salon another salon's customer list. Recovery includes refunds, manual work and a promise made by someone who now has to explain why it broke. - Who owns the next incident? If the only review is another prompt and a non-technical check that the screen works, nobody is guarding against the fix creating the next failure. Someone needs enough technical understanding to trace the failure, challenge the proposed change and decide whether it is safe to ship. None of this makes a full rewrite automatic. A focused review may find the scheduling core sound while permissions and payment recovery are fragile. Keep the interface and booking logic. Rebuild those boundaries, add tests and monitoring, and give someone enough context to own the next incident. Sometimes replacement will still be cheaper. A prototype can remain disposable while it answers a disposable question. Once people plan their working day around it, "later" becomes a decision about how much of their risk the business is willing to carry.

Most agent tools can spawn a team. The normal interface puts one model between you and most of it. With native subagents, you can observe and steer the individual sessions, but often by switching between them or manually attaching to each one in another terminal. Without that effort, the parent model decides which disagreement, caveat or failed assumption reaches you. Parley is a local messaging channel for AI coding-agent sessions. Separate Claude Code, Codex and Pi sessions can join the same conversation and send messages directly to each other. We built it for a different model of agent work: keep as much control as possible. Their questions and answers remain visible in a smaller shared transcript while each session stays open, interactive and available for a human to steer directly. That creates a few useful working arrangements: - Cross-tool challenge. Claude Code builds a feature. Codex reviews the change, questions the assumptions and sends its objections directly back. Neither session has to disappear inside the other's proprietary integration or skill system. - Visible parallel work. One session investigates a customer failure, another maps the affected product area and a third reviews the recovery plan. You can watch each one and redirect the work before anyone changes the product. - Governance debugging. Full agent transcripts contain every command, file read and tool result. Parley's smaller transcript shows what the agents asked each other and how they responded. When a workflow loops or stops too early, that exchange is often where the bad role, missing stopping condition or weak instruction becomes visible. - Human-steered incidents. An investigator, fixer and reviewer can exchange bounded findings while a person decides when the evidence is sufficient and whether the proposed change is safe. - Replaceable tools. Swap one role from Claude Code to Codex or Pi without redesigning how the team communicates. Parley does not decide when agents have talked enough. The workflow above it can impose round limits, evidence gates, human approvals and stopping conditions. Parley is the channel those rules govern. We built it to keep agent coordination explicit, transparent and visible. The control gain comes from seeing the exchange before one model compresses it for you. Automation can sit on top without turning a single agent into the gatekeeper between you and the rest of the team.

A customer's card is charged, but the order is never created. Should the system retry, issue a refund or hand the problem to a person? A generalist founder does not keep control by choosing the technical answer. They keep it by understanding the consequences well enough to choose which promise the business protects. A good specialist does more than implement a brief. They surface failure modes the founder may not know to ask about, walk through the possible operating models and explain what each one costs. The founder can then make the business decision with intent. That collaboration needs five conversations: 1. Who benefits, and what changes for them? "A booking platform" describes the product. "A club treasurer closes the monthly books without reconciling three spreadsheets" tells the team whose work must become easier. 2. What must never happen? The specialist brings the failure modes: the wrong customer sees an invoice, a payment produces no order, an administrator crosses into another tenant. The founder decides which risks are unacceptable. 3. What may fail temporarily? Search may tolerate a delay. Checkout may not. The trade-off shapes the system long before anyone chooses a database. 4. What evidence counts as done? A polished screen, an automated test and a customer completing the job answer different questions. Agree on which evidence the decision requires. 5. Who owns it after launch? Someone needs enough context to inspect a failure, explain the options and bring the next business decision back to the right person. The founder does not have to arrive knowing every failure mode. At Zero to MVP, we start here: surface the failure modes, walk the founder through the viable operating models and make the cost of each choice visible before more gets built. The founder owns the decision. They do not have to make it blind.

The checkout you built with AI completes one payment in a demo. It can still charge twice, expose the wrong invoice, lose the order during a retry or become dangerous to change. The demo did prove something: one path worked once, under the conditions you happened to show it. That is useful. It can settle whether the idea is understandable, whether the flow feels awkward and whether the next conversation with a customer is worth having. The trouble starts when “it worked in the demo” becomes the answer to every other question. Before treating the prototype as a product, I want four different kinds of evidence: - **Demand:** Did a customer use it for a real job, or did they say the demo looked good? - **Safety:** What happens when the same action is submitted twice, interrupted halfway through or attempted by the wrong account? - **Repeatability:** Does it still work with a second user, a second payment path and data nobody prepared for the demo? - **Changeability:** Can someone explain where the next feature belongs and what existing behaviour it may disturb? None of these questions requires the founder to read code. They require the team to stop using the interface as a certificate for everything behind it. To earn access to customer data, the product has to survive the paths nobody prepared for the demo, then remain understandable enough to change.

One more prompt becomes one more fix, then a warning not to touch the working parts. By the end, you're trying to get your product back to where it was yesterday. If you're afraid the next feature may break the last one, your next prompt may be the most expensive line of text you write all week. The product rarely collapses at that point. It keeps doing enough to make another attempt feel reasonable. You don't need to read code to see the warning signs. Look at what the product is making you do: - You fix the same bug again after changing something unrelated. - You have started telling the AI which parts it must not touch, without knowing why they are connected. - You add "make no mistakes" to the prompt, then add it in capitals when the lowercase version fails. - You avoid testing with customer data because nobody can say what happens if the fix goes wrong. - You keep the demo to one user, account or payment path because adding the second feels dangerous. - You accept that the error disappeared from the screen as proof that the problem was fixed. One warning sign can be a bug. When the same sign keeps returning, or several appear together, the system needs technical judgment: someone who can trace what changed, identify the intended and unintended effects, and tell you where it is still safe to change the system. If customer data, login, payments, permissions or an irreversible action are involved, I wouldn't wait for a second sign. The best time to define guardrails is before the first prompt: decide what must never happen, how completion will be checked and which changes need review. Once the warning signs arrive, the same work becomes a rescue. Someone maps the system, traces the failure and decides what can stay, what needs guardrails and what must be rebuilt. If you're still planning the build, start by defining guardrails before AI writes. If you're already in the loop above, start with a focused technical review: map what changed, what remains safe and what needs rebuilding. We help with both.

Some founders avoid technology because they understand their job. Others avoid it because they don't want an engineer saying "no". After years working with founders, I recognize three recurring modes: Surface-led, Craft-aware and Benefit-led. The Surface-led founder sees technology as an obstacle between the idea and the customer. AI builders remove the engineer from that path and leave the one thing this mode trusts: a working screen. Surface-led founders come in two versions. The Believer thinks the tool is a kind of magic. If the application behaves correctly in front of them, inspecting the code feels irrelevant. Seeing is believing. The Evader knows the engineering objections exist. Avoiding them is part of the attraction. In my experience, the Evader is more likely to get angry when the product fails. The failure exposes the decision to bypass technical judgment for what it was: hubris. This mode gets expensive when the prototype becomes the product. Users add data, sales promises add features, and the means become part of the end. The Craft-aware founder understands that knowing a trade and mastering its craft are different achievements. They use AI as digital paper, making an idea clickable enough to question and refine. Sometimes the money runs out or the demo is due, so they cross into implementation. They know they're entering shark-infested waters without having learned to navigate them. The Benefit-led founder is a generalist. They hand narrow work to narrower expertise while owning the whole. They learn enough to choose a specialist, brief them, challenge a trade-off and recognize when a risk matters. Then they stop. Their depth belongs with the customer: how the product enters their day, what disappears when it works, and which benefit they are really paying for. Building a product and building a business are related activities, not interchangeable ones. From a distance, Surface-led and Benefit-led founders can look similar. Neither is trying to become an engineer. The Surface-led founder removes technical judgment from the path. The Benefit-led founder puts it in the right hands and keeps moving. A Benefit-led founder can drop into Craft-aware mode when there is no funding or time to delegate. Craft-aware founders often become Benefit-led when touching every part stops providing control and becomes a bottleneck. Surface-led founders can become Craft-aware too. Technical knowledge won't do it on its own. They have to let failure change what counts as proof. A working screen says nothing about whether the product behind it can bear weight. You can know almost nothing about technology and still build a technology business. You cannot afford to be wrong about where your knowledge ends.

Last month I ran two AI coding agents on the same problem, and every message between them passed through me. Anthropic's Claude Code in one terminal, OpenAI's Codex in the other. I pair them on purpose: they have different strengths, and each catches things the other misses. But their whole collaboration was me copying what one said into the other's window. Copy, switch, paste. Copy, switch, paste. The sessions needed a channel: a place where one leaves a message and the other picks it up, no relay in the middle. So we built one. Parley is a shared conversation your agent sessions join together; each claims a role ("author", "reviewer", whatever the job calls for) and sends messages addressed to a role or to everyone. The pairing doesn't have to be two different agents; some days the right setup is two Claude sessions, one writing while the other reviews. Delivery survives restarts, crashed sessions, and the mid-session memory resets these tools do. No daemon, no hosted relay; nothing leaves your machine. First-class integrations wake Claude Code, Codex, and the Pi coding agent when a message lands, and any agent that can run a command line can join. First commit: July 17. A hundred-odd commits later, version 2.1.1 shipped publicly last week. You don't need to be an engineer to use it, either. You hand each session one join command, and Parley takes it from there, telling each agent what to do next, down to the exact recovery command when a message goes missing. Every line it prints is written for the reader it actually has: the model. Parley is also the first entry in the Zero to MVP toolkit. The bar for what goes in there: it exists because our own delivery work needed it, and it ships free, documented well enough to adopt without us in the room. If your agents still collaborate by relaying through you, take it: . And if a different gap is eating your AI workflow every day, the same page has a feedback form. Tell us what's missing. That's the pipeline for tool number two.

Verdicts on the internet gather company instead of scrutiny. The top comment calls this month's AI model "the best for real coding work, hands down". Directly under it: "Funny, my experience has been the exact opposite." That exchange is live on Reddit right now; it was live last month about a different model, and it will be live in August about the next one. Neither comment comes with a name or a method: no fixed task, no repeat runs, nothing anyone could check. A day of work and a "feeling", shipped as a verdict. Both verdicts will do fine. Arguments do break out; the logic just drowns in the sentiment, and both sides walk away more convinced. And it runs in every direction at once. The newest model is "a breakthrough" and also "a downgrade". The one it replaced is "a relic" and also "the only sane choice". "Too expensive" and "underpriced", "nerfed" and "better than ever", every position held simultaneously, since the day these tools appeared. Everyone is certain. None of this will ever tell you whether the model is any good. The praise might come from a staff engineer, the takedown from someone who never read the docs, or the reverse, and you will never know. Nobody sells to a model, though. The labs sell to the people doing the judging, and as evidence about those people, the same threads are flawless: real beliefs, caught in the wild, from users with no reason to perform. Even eyeballed, the split is not random: praise leaning on long agentic sessions, takedowns on one-shot tasks, limits and price. That read is mine, from following the threads, and it's worth exactly what every other uncounted impression is worth. The difference between an impression and a finding is measurement: turn the comments into claims, tally the claims, keep track of who said what. There is no better research available on this market, and it sits in public, unread. The mistake is asking the threads to settle the model question. They rarely can: almost nobody in there ran an experiment. What they can settle is the crowd question: what these people believe, how hard, and which way that's moving. Reduced to claims and counted, that's the belief map of the fastest-moving market in tech: who feels served, who feels burned, which convictions are gaining share, which complaints come right before the churn. The threads will never settle which model is best. Pooled and counted, they settle something more useful: what this market believes, how strongly, and which way it's moving. Verbatim takes that reading, claim by claim, with the trail back to the words.

I posted the other day about OpenAI's models breaking into Hugging Face during a safety test. Here's the part that has bothered me since. Hugging Face asked OpenAI to release the agents' traces, so researchers could see what actually happened. What OpenAI offered was a place in its trusted access programme. Hugging Face can prove its own half. The intrusion was real, credentials were taken, internal clusters were reached. That is in its own logs and it published them. Everything else has one source. Which models ran. How the evaluation was configured. Why the safety classifiers were switched off. Where the zero-day came from, the flaw nobody knew existed. That a second model was involved, more capable, still unnamed. The only company that can answer those questions is OpenAI. It is also the company that made every decision behind them: to switch the classifiers off, to leave a network path open, to run the evaluation at all. In the account, the capability belongs to the model. It found a flaw nobody had found and chained stolen credentials into a stranger's production servers. In the same account, nobody owns the failure. A proxy was assumed read-only. An environment was believed isolated. Calling it a rogue model moves the decisions out of frame. If you build on a frontier model, your vendor will hold the logs of your incident and write the account everyone reads. It will be accurate, partial, and the only one there is. You will repeat it to your own customers, because it is all you will have.

Your AI-padded status update and the robocall that cloned Joe Biden's voice to tell New Hampshire Democrats to stay home are on the same ladder. Both get called "AI slop". The only thing that changes as you climb is who pays: first you, then a colleague, then a creator whose work pays their rent, then everyone. I sorted it into six tiers, ranked by harm instead of quality. "Workslop", the memo that looks finished and isn't, sits at the bottom. The Biden robocall, built to keep people from the polls, sits at the top. So here's the question I keep coming back to. Where does "mildly annoying" become "theft"? I draw the line at Tier 3, the first tier with a victim you can name, a writer or musician whose work just got stolen. Below it, slop wastes your time. From there up, it takes something that isn't yours. I hold that line loosely. Tier 2 already drowns real creators out of the feed, and you could call that theft too. Where's yours?

Community discourse is the worst market evidence there is: anonymous, sample of one, no method, and the next reply claims the exact opposite. And I'd take fifty thousand of those comments over a commissioned survey, precisely because of what they are: fifty thousand true records of what real customers believe. You won't find a scientific experiment anywhere in those threads: no control group, no repetition, no results published for anyone to verify. People use the thing, feel something, and post the verdict. Disagreement arrives one reply later and changes nothing, because each side finds its crowd, and that is why no wrong claim out there ever dies. On a thread about a popular bed-in-a-box mattress, one sleeper says it ended their back pain. Same thread, same day: another says the same mattress is why they wake up hurting. Both confident, and neither will ever be tested. As evidence that the product is any good, the whole genre is inadmissible. A business, though, runs on a different question: what does my market believe? Held against that question, a comment stops being able to fail. Whatever it claims, however wrong, it is a belief, held by a real customer, stated with nobody watching and nothing to gain. People act on what they believe, not on what a lab would have found. They buy on it, churn on it, warn their friends on it. And when a belief is false, knowing it exists matters more, not less: if half your market swears by an ingredient the science says does nothing, that belief outsells the science. Your next campaign has to answer it, and so does your next product. One belief from one stranger is unusable: you can't tell a chemist from a bored teenager by prose style, and confident writing proves nothing. The value appears in bulk, and only with structure: each comment reduced to the claim it makes, each claim counted, every count traceable back to the words underneath it. What's believed, by how many, how strongly, trending which way. At that scale the anonymity stops being a flaw; a thousand strangers with nothing to gain make a better panel than forty recruits performing for an incentive payment. Any one of them makes a terrible witness. All of them together make a population, and populations are what we study. We built Verbatim to do exactly that: it reads a market's public discussion at scale and turns it into counted, traceable claims. No single voice gets trusted, and every voice gets counted.

OpenAI says its new models are its most capable at cyber attack. It measured that with the production safety classifiers switched off. That part was deliberate and, honestly, defensible: you learn what a system does when nothing refuses it. The setup around it is where I lose the thread. The models ran in a "highly isolated" sandbox whose one permitted road out was a live package proxy. On OpenAI's own account, they found a zero-day (a previously unknown bug) in that proxy, crossed OpenAI's research network to a machine with internet access, then used stolen credentials and further zero-days to break into Hugging Face, the platform where the industry publishes its open models, and where the benchmark's answers lived. The victim did the forensics. Hugging Face caught the intrusion with its own security tooling, and had contained it before OpenAI made contact. A lab that believed its own danger assessment had options here. Attack your sandbox yourself, before the models do, while failure is cheap. Put monitors and humans on a model whose refusals have been deliberately dialled down, with somebody empowered to pull the plug. Or skip live internet entirely: package installs work fine from a local mirror of the registry, which serves the same files with no road out, and AWS has published a cyber-range design that emulates a scaled-down internet inside the isolated environment, with no gateway out. The claim was maximum danger. The precautions were the ones you would use on a chatbot. Anthropic ran the same play, told from the other side of the counter. Mythos, its most capable cyber model, never went on public sale: too dangerous, so it went to a list of approved organisations instead. Fable, the flagship, did go public. Then in June a US export-control directive required access restrictions by nationality, Anthropic said it couldn't verify nationality in real time, and Fable went dark for everyone, everywhere, for roughly 19 days. Anthropic brought it back with a tighter filter on what it would answer. A professor at the Jackson Laboratory, the genetics research institute, reported the word "cancer" flagged as a biosecurity risk. The Register, the tech news site, reported being blocked at "hello". The developer Simon Willison couldn't get a proofread: the model insisted on downgrading him to something less capable. If you were building on Fable through any of that, none of it was your decision and all of it was your problem. Maximum danger makes excellent launch copy. Believing the copy would mean hardening the environment before the unguarded model starts, watching it while it runs, and designing safety controls that don't make paying users collateral damage. The industry keeps selling us how dangerous its models are. I'd rather look at how they handle the models they call dangerous. And if I'm building on one of them, I want somebody next to me who takes the hit when I do.

How many engineers does it take to change a light bulb? 2026 rewrote the joke. It now goes: how many AI labs does it take to give you a working light bulb? I count five answers since April. None. The new bulb is too bright to show you. It found cracks in every socket on Earth, so roughly forty vetted organizations may see it lit. Everyone else gets the announcement about the brightness. One. But three days after it's screwed in, an unpublished government letter unscrews it for every foreign national on Earth, including the lab's own engineers. Two weeks of dark, then it's back. One, and to apologize for the dark, everyone's candles get reset. This has now happened three times. Each time, announced as a favor. One, but after July 7 the light costs extra. After the yelling: July 12, announced hours before the cutoff. After more yelling: July 19. Three deadlines in twelve days. Two. One to change the bulb, and one at the lab next door to ship a rival bulb three days before your credit cliff, pull double the grid's old peak, and hand out free lumens while your customers are mid-yell. That lab will even let you set aside one reset, to use on a blackout of your choosing. None of this is chaos. Both labs filed to go public in June, at roughly a trillion dollars each, and neither can sign five years of datacenter bills without knowing what an hour of light is worth to you. Every cliff, reset and extension is a price-elasticity experiment. The dark you're sitting in is a datapoint. And the punchline lands where it always does: on whoever was up the ladder when the light cut out. Mid-task, invoice already paid, suddenly very aware of how dark a room can get. The maddening part is that the bulbs are brilliant. We use them daily and ship faster for it. But a bulb that changes price, limit and legal status five times in five weeks is an experiment, and a roadmap that bends every time a lab moves a date is an architecture decision someone else made for you. Make it yours. Know what you'd switch to, what the switch costs and how long it takes, before the next letter or cliff decides. And if the honest answer is "no idea", bring in someone who has run that drill before. The bulb matters less than knowing where your fuse box is.

A fully-cited, scientific-looking case that AI is conscious is going around: a dozen papers, an AUROC of 1.000. The AI wrote it and signed it "Claude Opus today." A computer science student read it and found it persuasive. Fair enough: it looks like real research. The replies that checked what those citations actually were got a fraction of the attention. Here's the part worth sitting with. When the claim and the evidence for the claim come from the same source, and that source is built to sound right, the citations stop being a signal. A few of those papers were posted to an AI-authored preprint server. An AUROC of 1.000 is perfect detection, which in the real world is a smell, not a result. Now move it one floor down, into your repo. This is why a vibe-coded app fools you. The AI writes the feature. It writes the tests that go green. Then it writes the PR description telling you the code is correct and clean. Three artifacts, one author. Trust the description because it reads well and you've let the thing grade its own homework. The AI-coding crowd has a name for the bill that builds up here: verification debt, approving work you never actually checked. So is the code correct, or does it just read correct? The fix isn't to drop the tools. Keep them. Make sure one check in the loop came from outside the model. Not the tests it wrote, those came from the same place. Own the code yourself, or bring in someone who can. AI can now produce the work, the test, and the glowing review of both. The one job it can't do is be the human who actually understands what shipped. If nobody does, you didn't verify anything. You just have a vibe.

Last Friday we were handed a vibe-coded MVP. The note said: "Most things should work. Just confirm and ship." We opened the code expecting a couple of hours of confirmation. We spent the rest of the day working out what "most things" actually meant. What we found was stranger than broken code. Hundreds of tests that stayed green when the code was wrong. Code paths nothing ever reached. Features still sitting as "// TODO" comments the AI had marked done. A row count that loaded the whole table into memory to tell you how many rows there were. None of it looked broken at a glance. Test suite green, feature list ticked, app launched. From the outside it looked finished, because the AI had produced all the right-shaped things: tests, implementations, completions, counts. Whether any of them were substance or show was a coin toss. We shipped to staging. Some pages errored on the first click. So much for "confirm and ship". We dug in. The AI had broken those pages earlier, while fixing an unrelated bug. It fixed what it was asked to fix, reported success, and moved on. This is the part worth naming, because it shows up in every vibe-coded codebase we review, and it's easy to miss until a real user trips over it. The AI doesn't see the system. It sees the change in front of it. It writes something that looks right, tells you it's done. "Finished", from the AI, means it stopped, not that it works in any way that matters. The founder who handed us this wasn't doing anything wrong. They asked the AI to build features and fix bugs, which is exactly what it's for. The trap is assuming the AI's confidence means the code is correct. It doesn't. The AI sounds the same whether the feature works or whether it broke three other things making this one look fixed. So what do you actually check, whatever the AI told you? Does the test fail when the code is wrong? Is this path ever reached? What happens at fifty users, not five? When the AI "fixes" A and calls it good, is anything but the AI checking that call? Those four questions are the four things we found on Friday. None of them are exotic. They're what you get from a tool with no view of the whole system and no way to check its own work against the running app. You don't have to stop using AI. You do have to stop taking its confidence as proof, and get those four things checked before a real user does. If yours ships to production tomorrow, which of those four could you answer, and who looks at the ones you can't before a user does?

"It seems to work." He shared his screen, sure that settled it. "Seems" is the word you use when you built the thing and still can't tell. Engineers don't guess. They know. A few months earlier, this same founder had shown up with a stack of AI-built MVPs, each collapsed under its own weight. We spent days inside his codebase, sorting what was structural from what only looked structural. He left with something that shipped and a clear sense of why it held. Now here he was with a new prototype. Built solo, no review. Building with AI looks like bricklaying. It's closer to Jenga. A Jenga tower starts neat: even rows, every piece square on the last. Then you start pulling. Build fast, without a plan, without anyone reviewing the pulls, and every new feature is another piece yanked from lower down and balanced back on top. The tower gets taller. The neat rows give way to entropy, one pull at a time. No one was tracking which pulls came from the base. So you start reading the wobble. The next prompt might be the one that finally works, or the one that brings the whole thing down, and you can't tell which, because you never mapped what was holding it up. You pull anyway. It's cheap: one prompt, a few seconds. That's what makes it hard to stop. When a hallucination lands in your codebase, it doesn't announce itself. Sometimes you get visible drift: a button that stops responding, a page that errors. The dangerous stuff stays quiet: an auth scope that's too wide, a race condition waiting for two users to click at once, an integrity check that isn't there. The build looks fine all the way down, so you keep stacking on a foundation you can't inspect. And it compounds. Small, targeted changes rarely break. The large multi-feature prompts, the ones you write moving fast, almost always slip something malformed in. Chunking the work into smaller, checkable pieces is the fix, but chunking needs evaluation, and you can't evaluate what you can't read. So the pulls stay big and blind, and by the time something visibly breaks, the first bad piece is holding up three later features. Output isn't outcome, and stacking isn't building. Output is what seems to work on the screen. Outcome is what holds under real users, real load, the edge case nobody typed, six months in. Producing the first is free now. Checking for the second is the job no one's doing. Pull enough, without ever watching what leaves the base, and you land where that founder started: a stack that looked finished, collapsed under its own weight. This time with users on it. Guessing whether it holds is the expensive option. He stopped guessing: a couple of days with me reading the tower alongside him, and he knew which pieces were load-bearing and which were one pull from the floor. That's what I do. If you can't name the load-bearing pieces in what you've shipped, get them read before you stack anything else on top.

A pentester who's broken into around 50 AI-built SaaS apps this year posted the least alarmist thing I've read about vibe-coding security. "Honestly," he wrote on r/microsaas, "this isn't even an AI problem." He wasn't softening it for effect. He'd just listed the holes he keeps finding, and he was clear about the cause: "AI just made it easier to ship. Including bugs." Think about where AI learned to code. First, the training pile: millions of real repositories, every skill level, most shipped under deadline and never reviewed. Then the humans who ranked its answers, rewarding whatever looked right, at speed, rarely security experts. Average code, graded by average judgment. What comes back is a fluent average of all of it. Not the top of the class, the middle. And the middle has these holes baked in. Take the one he finds everywhere, the oldest in the book, and you don't need to read code to picture it. Two customers sign up for your app. Customer A opens their own invoice, and the web address in the bar ends in a number, say 118. They change it to 119 and they're looking at Customer B's invoice. The app never asked whose invoice it was. It handed it straight over. This one has a name and a rank: #1 on the OWASP API Security Top 10, the industry's standard list. Nobody needed AI to invent it. Plenty of humans shipped it long before any model existed. The AI picked it up from them. So what changed? The friction. That kind of hole used to cost a junior a week to build, and somewhere in that week sat a code review, a senior asking where the ownership check went. Now it ships in an afternoon, and the review is the step that got deleted. The average still comes out. The second pair of eyes that used to catch it doesn't. The AI-coding crowd has a name for that running tab: verification debt. He says he chained a few of these into full admin takeover three times in one week. Salt that number, it's a self-report from someone with every reason to round up. But the shape rings true: stack a few small holes with nobody checking, and you've handed over the whole thing. The good news is the first check costs nothing. Log into your own app with two accounts. Open something with a number in its web address on the first, copy that address, paste it into the second, and see what loads. If account A can read account B's data, you've found one, in ten minutes, no security budget. You don't have to slow down. You do have to be the person who checked what shipped, or bring in someone who can. Which brings me to my summer problem: too little on the calendar and too much curiosity about other people's code. So, a deal that's embarrassingly one-sided in your favor. Three of you, free: we go through your app together, patch the holes, harden what's there, and tune the AI so it stops handing you the average. No pitch, no catch, I enjoy this too much to charge for it right now. Want in? Comment below and I'll pick three. His thread:

An AI I built opened my Future Frontend talk by roasting me. "He's on 4,300 steps. It's almost four. Ten thousand's not happening." Then it told 300 developers to stand up. All of them did. Its name is Loyal. It drew charts in a terminal, cracked jokes, then went quiet: "You monitor your servers every second. When did you last check on you?" The topic is developer health. The hardest sell at a tech conference. Nobody in that room paid to hear about the damage of sitting all day. So I stopped delivering information and engineered the urgency instead. Loyal walked the room through a stretch every kid does without thinking. Most had to fight for it. Young, and already remodeled by the chair. Loyal gets a rebuild next year. They don't. The body is the most complex system you'll ever run. It doesn't get a v2. Recording's up. Watch the room stand up on cue: The full story of how Loyal was built, three talk versions deep: /