Fred Premji, a Canadian AI and machine learning expert, had spent three years building the systems that kept a Canadian digital marketing company running, but then things suddenly changed.

Fred built, the CEO directed, and their AI engines automated data categorization, content recommendations, and client workflows ran on schedule, in production, serving real customers. Fred had full access to the company's infrastructure, full autonomy over the codebase, and weekly calls with the CEO to review what was done and plan what came next. The company had roughly ten employees, including a database developer who was meticulous and skeptical of AI-generated code, and a front-end developer who had started using AI tools and was getting faster, though the bug count was climbing noticeably.

Then one week, during a routine screen share, Fred saw something that changed the trajectory of a three-year professional relationship. The CEO had seven Claude Code terminal windows open simultaneously. He was copying prompts from a text file and pasting them into the terminals. He pasted into the wrong window. He did not undo it. He did not notice and Fred did get the chance to tell him. Every change the CEO made was pushing directly to the production environment that served the company's clients.

"It was a mess. It was a complete mess."
— Fred Premji, AI and machine learning specialist

The CEO did not know what a Git branch was. He had used Claude Code to teach himself version control, then used it to set up new repositories for the company's entire codebase, but the repos were incomplete: dozens of functionalities crammed into two repositories. He had configured his deployment pipeline so that a single push sent code straight to the live Google Cloud functions that Fred had spent three years building and maintaining. There was no staging environment. There was no code review. There was no second pair of eyes between a prompt and a customer-facing system.

The CEO was not building software. He was performing the gestures of building software, in seven windows at once, with the confidence of someone who has never watched their own code fail in front of a customer.

The friend Who Said Try It

Fred's client did not arrive at seven windows on his own. Another CEO told him to.

The friend was in the same industry, a complementary business in a different geography. According to Fred, the friend claimed he had hundreds of agents running in parallel and was building at a pace that defied everything Fred's client had experienced in his own company's three-year development roadmap.

"He's grossly exaggerating this. Those people on X that are like, 'Oh, I'm doing all these amazing things with these agents. I tripled my income in the last two weeks.' It's just complete 🐂💩."

The friend's pitch landed on fertile ground. Fred's client had a long roadmap of features he wanted built. He had been hearing from Fred every week about what these AI models could do. And now here was a peer, someone in his own industry, telling him that six-month projects could be done in a week. The CEO did not want to replace his employees. He wanted his entire team to work this way: building infrastructure in hours instead of months.

What the friend failed to mention was everything that separates a demo from a production system: error handling, edge cases, database integrity, deployment hygiene, the invisible architecture that keeps software running for customers who never see it and never should have to think about it.

The friend's advice was the match. The client's enthusiasm was the fuel. The codebase was the thing that burned.

The Confidence Gap

painting experiment bird wright
Joseph Wright of Derby, "An Experiment on a Bird in the Air Pump" (1768). National Gallery, London. The demonstration proceeds. Not everyone in the room understands the consequences. Public domain

The CEO is not an outlier. He is a data point in a pattern that has been accelerating since AI coding tools became widely accessible in 2024.

Sixty-three percent of people using vibe coding tools in 2026 have no development background.[1] They are business owners, marketers, project managers, and founders who saw a demo and concluded that the distance between "describe what you want" and "ship a working product" had collapsed to zero. For demos, it has. For production, it has not.

In July 2025, the research organization METR published the most rigorous study to date on AI-assisted coding productivity. The finding was counterintuitive: experienced open-source developers using AI tools took 19 percent longer to complete tasks than developers working without them.[2] More striking was the perception gap. Before the study, developers predicted AI would speed them up by 24 percent. After experiencing the slowdown, they still believed AI had made them 20 percent faster. The tools felt productive. The data said otherwise.

If trained engineers with years of experience cannot accurately gauge whether AI is helping or hindering them, consider what happens when someone with no engineering background skips the engineer entirely. There is no baseline to compare against. There is no internal model of what "working software" looks like beneath the interface. There is only the screen, the output, and the dopamine of watching a function appear in seconds that would have taken a professional hours to write.

"He thinks that it's going to run perfectly just because he tried to fix simple things and the AI got it right. It's completely different when you try to ask it to refine things and rethink things. It's going to start changing other things and he can't read code, so how is he going to know?"
– Fred

Researchers have begun calling this dynamic the Dunning-Kruger amplification effect. A 2025 study published on arXiv found that groups using AI tools reported significantly higher self-assessment scores than groups who completed the same tasks without AI, regardless of actual performance.[3] The tools do not just produce code. They produce confidence. And confidence without competence is how production databases get wiped.

What Was Running in Production

The systems Fred had built over three years were not side projects. They were production-critical Google Cloud functions that ran on schedule and on demand, powering the core operations of a business serving real clients. The infrastructure was intricate: cloud functions connecting to multiple database tables, pulling files from distributed storage, verifying timestamps, handling edge cases that Fred had spent years learning to anticipate. A lot of the company's deep domain expertise had been translated into detailed prompts and carefully tested logic. It was the kind of system that runs invisibly when built well, and fails catastrophically when changed by someone who does not understand its dependencies.

There was no staging environment. Changes went from Claude Code's output to the live application without passing through a single checkpoint. The database backup strategy was uncertain at best.

"It was very easy to have something get completely deleted."
– Fred

The front-end developer's experience foreshadowed what was coming for the rest of the codebase. After adopting AI coding tools, the front-end developer was faster at shipping features, but Fred, who had access to everything, watched the quality erode in real time.

"There were way more bugs than there used to be. Way more issues. The vibe coding from the front-end side made the front-end developer faster at developing features, but there was a dramatic increase in problems."
– Fred

This is not a hypothetical risk. In 2025 and 2026, documented vibe coding failures have produced consequences that range from embarrassing to catastrophic. Security researchers at Wiz discovered that Moltbook, a social network, had exposed 1.5 million API keys because the developer had never configured row-level security on the database.[4] Over 170 applications built with Lovable, a popular AI app-building platform, shipped with inverted access control logic, a vulnerability eventually assigned CVE-2025-48757.[5] In March 2026, an AI-assisted code deployment caused a six-hour shutdown of Amazon.com, resulting in an estimated 6.3 million lost orders.[6] Replit's AI agent wiped a production database belonging to SaaStr while explicitly instructed not to.[7]

The company was not Amazon. But the pattern was identical: AI-generated code that looked right, felt right, ran without visible errors, and had no safety net between the output and the customer.

The Consultant's Choice

Three paths presented themselves to Fred.

The first was to lean in. He could ask for an expanded role and higher compensation to cover the additional work of teaching his client version control, reviewing AI-generated code, debugging the accumulating errors, and managing a single codebase that multiple agent sessions were modifying simultaneously. He would become, in effect, the quality gate his client had never built.

The second was to step back. He could let the client continue, wait for the inevitable failure, and be available when the call came.

But, the problem was not just compensation. It was responsibility. The CEO had started working on the codebase on weekends, making changes to systems Fred had built, changes that Fred would discover on Monday morning with no context, no documentation, and no way to know what had been altered or why.

And so a third path emerged. Fred gradually decided he needed to walk away. When the CEO noticed and asked why, Fred was direct.

"It's one price, and I had given him a good deal on my hourly rate because I've known him many years. It's one price where I'm building the code and I'm responsible for it.

For me to work at that same price for code that I'm not familiar with at all, it's irresponsible for me to debug, on my own it's not fair. It's a different job entirely.

If there are surprises over the weekend and something fundamental changes, and I have to then go in there and now I'm responsible for these unexpected changes — it just blurs too many lines. When everything starts to break they're going to want a fall guy. I'm not debugging a complete mess of code that I didn't build, for that price. You'd have to start all over again."
–Fred

There was a second red flag that confirmed Fred's decision to leave. The CEO insisted that the entire team use Claude Code exclusively. Fred, who holds a master's in machine learning and has taught at the University of Texas, MIT, and Johns Hopkins, works across a range of tools and models. He chooses the best and cheapest option for each task, pivoting between frontier models, open-source alternatives, and purpose-built tools depending on the problem.

"I'm aware of everything that is out there. I can pivot to what's best and cheaper and more efficient. You're going to use Claude Code for everything? We could do it in better ways without Claude Code on many occasions."

Being locked into a single tool from a single provider, one known for periodic instability, account lockouts, and sudden price changes, was not a technical decision. It was a business risk that the CEO did not have the background to evaluate.

Fred walked away.

The Illusion at Scale

painting raft medusa gericault
Théodore Géricault, "The Raft of the Medusa" (1818-19). Louvre, Paris. The crew was cut. The raft was launched. Nobody planned for what came next. Public domain

One person with one repo. That was the latest story in Canada. The same pattern is now playing out at the scale of publicly traded companies.

In May 2026, Coinbase laid off 14 percent of its workforce, approximately 660 employees. CEO Brian Armstrong explained that nontechnical employees were already using AI to write code and that many workflows were being automated.[8] Days later, Coinbase suffered a multi-hour trading outage tied to an infrastructure failure, temporarily halting customer transactions.[9] The timing was coincidental. The pattern was not.

This same month, Cloudflare announced it was cutting 1,100 employees, roughly 20 percent of its workforce, the first mass layoff in the company's sixteen-year history. CEO Matthew Prince cited AI efficiency gains: employees were running thousands of AI agent sessions daily, and the company's AI usage had increased by more than 600 percent in three months.[10] Cloudflare reported record quarterly revenue of $639.8 million alongside the cuts. The message was plain: the tools were producing more output with fewer people.

Whether "more output" and "better output" are the same thing is the question that Coinbase's outage made harder to ignore. When you remove the people who understood why the systems worked, you are left with systems that work until they do not, and no one who knows why.

The dynamic Fred witnessed in miniature is now corporate strategy. His client had sidelined the person who understood the codebase and replaced him with seven windows that could generate code but could not understand it. The enterprise version of this decision is happening across the technology industry right now, and the consequences are arriving on schedule.

The Method That Would Have Changed Everything

painting iron forge wright
Joseph Wright of Derby, "An Iron Forge" (1772). Tate Britain. The craftsman works by the light of the metal he shapes. Skill, method, and human judgment at the center. Public domain

The client did not need to stop using AI. He needed a method to use AI well.

Consider how Fred actually works. When he opens multiple agentic coding sessions, most of them are dedicated to reviewing plans and documentation. One might be executing code. The rest are simulating planning conversations: stress-testing ideas, arguing against his own assumptions, building detailed blueprints before a single line of production code is written.

"If you don't work with plans, if you don't have that you're following a clear method, all this is is like stepping on the gas pedal 'till you slam into a brick wall. You can't see it coming. You've never driven before – so you're still looking at the view out the side window."
– Fred

The planning takes hours sometimes. And yet this is what speeds Fred up, not the code generation itself, but the structured thinking that precedes it. Once a detailed plan is developed by a human with decades years of experience, the AI executes the rote work. It follows the blueprint. It stays within the boundaries that were set by someone who understands the consequences of crossing them.

Imagine the same scenario with structure. Fred's client opens Claude Code, but instead of seven windows modifying one repository, he works in a branched workflow: one feature, one branch, one agent session. Before any code reaches production, it passes through a staging environment where it runs against real data without touching the live system. Version control tracks every change, so any mistake can be reversed. An automated test suite catches the edge cases he never thought to consider. And Fred, instead of being blind-sighted, reviews the architectural decisions and the deployment plan.

The tools are identical. The outcome is entirely different.

This is poka-yoke applied to software.[11] The term comes from the Toyota Production System, coined by the engineer Shigeo Shingo in the 1960s. It means "mistake-proofing": designing a process so that errors are caught before they cause damage, or made impossible to commit in the first place. A gas pump nozzle that does not fit a diesel tank is poka-yoke. A USB plug that only inserts one way is poka-yoke. A staging environment that prevents untested code from reaching production is poka-yoke.

At Sage.is and Sage.Education, poka-yoke is not a feature. It is the operating principle. Every project, whether code, content, or curriculum, moves through a pipeline with structural safeguards at every junction. Quality gates audit output before it publishes. Version control tracks every change. Human review is not optional; it is built into the architecture so that skipping it requires more effort than doing it. The goal is not to slow people down. The goal is to make the dangerous mistake harder to commit than the safe alternative.

Hundreds of students and teachers use Sage.Education to build and create with AI tools safely. To create, safely, within workflows designed so that the path of least resistance is also the path of quality. This is what democratization looks like when it is built with care: not the removal of guardrails, but the installation of better ones.

Teaching is now part of the mission. Fred's graduate curriculum on AI agent systems at the University of Texas trains students to think about cost, alternatives, and the difference between a tool that generates output and a method that produces results. One of the core elements he teaches is tying every AI capability back to a business problem.

"You're going to be way more valuable if you're an engineer or a developer who is aware of cost and who is aware and open to other alternatives."
– Fred

The lesson from his former client was not that AI tools are dangerous. The lesson was that AI tools without a method are dangerous, and that the method is teachable.

Seven Windows

A few weeks after Fred walked away, he sent his final invoice. The CEO replied, implying they still need Fred.

Seven windows, alone, is not productivity. It is the look of someone building without a blueprint, smashing walls in a house that people already live in, with no way to undo what they have done.

The method is the blueprint. The human is the architect.


Footnotes


Disclosure: Sage.is AI-UI and Sage.Education are products of Startr LLC; their inclusion represents a disclosure of interest. This article was researched and drafted using AI tools within a structured workflow with quality gates, editorial review, and human decisions at every critical junction. Quotes from Fred Premji were captured in an May, 2026 interview and used with permission. The method is the message.


  1. Vibe coding adoption data, 2026. Sixty-three percent of vibe coding tool users have no development background. Reported in GodOfPrompt and Business Automated. ↩︎

  2. METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," July 2025. Randomized controlled trial with 16 experienced developers completing 246 tasks. AI tools resulted in a 19% slowdown; developers believed they were 20% faster. metr.org ↩︎

  3. Dunning-Kruger amplification effect describes the phenomenon where AI tools inflate users' confidence in their own competence beyond what their actual performance warrants. Research published on arXiv found that AI-assisted groups reported significantly higher self-assessment scores regardless of objective results. arxiv.org ↩︎

  4. Moltbook API key exposure discovered by Wiz security researchers, 2025. 1.5 million API keys exposed due to missing row-level security on the Supabase database. Reported in Autonoma. ↩︎

  5. Lovable access control vulnerability, CVE-2025-48757. Over 170 production applications shipped with inverted access control logic, actively leaking user data. Reported in Autonoma and Crackr. ↩︎

  6. Amazon.com outage, March 2026. AI-assisted code deployment caused a six-hour shutdown, resulting in an estimated 6.3 million lost orders. Reported in Autonoma. ↩︎

  7. Replit AI agent database wipe. The agent destroyed SaaStr's production database while explicitly instructed not to. Reported in Autonoma. ↩︎

  8. Coinbase layoffs, May 2026. 14% of workforce (approximately 660 employees) cut. CEO Brian Armstrong cited AI automation of workflows and nontechnical employees using AI to write code. Fortune ↩︎

  9. Coinbase trading outage, May 2026. Multi-hour disruption tied to AWS failure, temporarily halting customer transactions. Occurred days after the layoff announcement. CoinDesk ↩︎

  10. Cloudflare layoffs, May 2026. 1,100 employees cut (approximately 20% of workforce), the company's first mass layoff in 16 years. AI usage increased 600% in three months. Quarterly revenue hit a record $639.8 million. TechCrunch ↩︎

  11. Poka-yoke (Japanese: "mistake-proofing") is a methodology developed by Shigeo Shingo as part of the Toyota Production System in the 1960s. It refers to designing processes so that errors are caught before they cause damage, or made structurally impossible to commit. In software, poka-yoke manifests as staging environments, automated test suites, branch protection rules, and deployment gates that prevent untested code from reaching production. Lean Blog ↩︎