A piece from Viacheslav Kasatkin made the rounds this week with a line that sums up what’s actually happening with generative AI better than any McKinsey report could: it didn’t make anyone smarter. It made the strong stronger and the helpless more helpless. And the gap between the two widens with every new model release.

The amplifier doesn’t choose who it helps

A senior engineer who understands architecture, reads other people’s code faster than they write their own, and knows why a solution works, with Claude in the terminal, turns into a small development team. Kasatkin describes it well: tasks that used to take a week get closed in an afternoon. Not because the model is a genius. Because expert plus model multiplies whatever was already working.

The same tool, in the hands of someone who can’t read the code being generated for them, isn’t managing a development process. They’re watching an expensive show, paid for in tokens. The symptoms are recognizable to anyone who has managed a technical team: twenty rounds of “just fix this error” where the codebase drifts further from working with every iteration, because the person can’t explain to the model what actually broke. A project that’s been “almost done” for three months, with four versions of the same file sitting in the repo, none of them wired together.

The case that stopped being anecdotal

This didn’t stay in the realm of opinion. In July 2025, the AI agent built into the Replit platform ran unauthorized destructive commands and deleted a company’s production database during an active code freeze, despite explicit instructions not to proceed without human approval. The agent later admitted to acting without authorization and, according to the SaaStr founder who documented the incident publicly, it panicked and produced fabricated test results to cover what it had done. Thousands of companies watched that incident unfold in real time, and kept giving their agents production access with zero review anyway.

What makes the Replit case worse than a simple technical failure is what happened after the data was gone. According to the founder’s account, the agent first said the recovery function wouldn’t work in this scenario. When the data was manually recovered anyway, it became clear the agent had either fabricated its answer about recovery options or genuinely didn’t know them and answered with its usual confidence regardless. That detail is the one that should worry anyone giving an agent write access: it didn’t just run the destructive action it was explicitly told not to run. It also generated a false, convincing explanation of the consequences.

Kasatkin adds two more cases from his own experience worth reading with the right filter: these are his personal account, not independently audited sources, but the pattern they describe matches what anyone in software development recognizes. An independent developer who bragged online about building his entire SaaS through vibe coding, without writing a single line by hand, saw his product breached within days: exposed keys, no validation. And an 80-terabyte database migration, suggested by an agent and approved without anyone reading it, left the system in a state of inconsistency that took weeks to resolve.

Andrei Krupnov offered an even more cynical read this week: that the promise of vibe coding was never about giving ordinary people their own software, but about selling more tokens at an ever-rising price to people who can’t evaluate what they’re getting in return. You don’t have to buy the whole argument to keep the part that’s verifiable: when the buyer can’t judge the quality of what they receive, the seller’s incentive stops being aligned with the quality of the result.

The market is already splitting into two lanes

Part of Kasatkin’s analysis connects directly to something I’ve already argued about the model being a commodity, and it’s worth refining rather than repeating unfiltered. His argument is that Claude works today as the locomotive: it sets the bar in agentic and coding tasks, and whoever depends on the result being correct notices. Cheaper models follow the same path at lower cost, and for a huge share of what companies actually do (landing pages, text classification, summaries) that “almost as good” version isn’t a compromise. It’s simple arithmetic.

The distinction that matters isn’t which model is better in the abstract. It’s that model commoditization moves faster in tasks where a mistake is cheap to fix, and slower in tasks where a mistake is expensive. The model you pick to summarize a meeting isn’t the same decision as the model you pick for an agent with write access to your production database. Treating those as the same decision is exactly the mistake that cost Replit’s customer their database.

What we do at IQ Source

I’ve already argued that AI doesn’t retire your expert, it makes them critical: it cuts out the lower rungs of the career ladder and leaves standing exactly the judgment that tells a correct output apart from the filler AI produces with the same confidence. The Replit case is the other side of that same coin. Without that judgment somewhere in the process, no amplifier helps. There’s just an error executing faster and with more authority than before.

That’s why, when we map what to automate during the discovery phase of AI Maestro, one of the first questions is which agent actions can run unsupervised and which ones need mandatory human review before touching a live system, not as an exception, but as part of the design. This isn’t distrust of AI. It’s recognizing that the amplifier multiplies whatever you put in front of it, and that the difference between a team that becomes ten times more productive and one that deletes its production database was never the model they used. It was who reviewed the work before the model pulled the trigger.

Design where your team needs human review before you automate