I’ve started calling this agentic filmmaking, because as far as I can tell nobody has named it yet, and I’d like to plant the flag before someone at a conference does.

The slot machine and the crew

When most people hear “AI video,” they picture the generators. Type a prompt, pull the lever, get eight seconds of footage. Maybe it’s stunning. Maybe the train has eleven wheels and merges with a cow at the four-second mark. You pull the lever again.

That’s a slot machine. A very impressive slot machine, but the defining feature is that you have no idea what comes out until it comes out, and your only recourse is to pull again.

Agentic filmmaking is a different arrangement entirely. You hand an agent actual production work: here’s forty minutes of raw footage, here’s what the piece is about, here’s roughly how it should feel. The agent transcribes the audio, finds the usable takes, plans a cut, builds the title cards, syncs the captions, grades the color. Then, and this is the part that matters, it watches its own output, notices the lower-third is covering the interview subject’s face, and fixes it before showing you anything.

You review the cut. You give notes. It does another pass.

That’s not a slot machine. That’s a crew. A weird, tireless, occasionally confused crew that works at 4am and never asks about lunch, but a crew. Your job quietly changes from operator to director.

Why trains

I do video work for clients now, mostly marketing pieces. But you should never test a new workflow on client work alone, for the same reason you don’t test a new deploy process on Black Friday. So I picked a testbed I actually care about: trains.

I love trains. I have always loved trains. There is no business case. I’m producing a series of short documentaries about them because the subject makes me happy and because a passion project is the perfect proving ground: I know exactly what good looks like, and if an episode fails, the only stakeholder who gets hurt is me.

The workflow surprised me more than any demo ever has. I sit in a terminal and talk. Transcribe this interview. Cut everything before the second question, the first answer was me rambling about gauge widths. Build a title card in the style of the last one. Tighten the pacing in the middle, it sags. The agent does the work, renders a preview, looks at the preview, and comes back with the result plus notes on what it changed.

At some point I realized I had produced a finished, captioned, color-graded short doc and had never once opened a timeline. The part of my life where I scrub footage at 2x while my eyes glaze over just didn’t happen. The craft decisions were all still mine. The labor wasn’t.

The part the SFX world won’t enjoy

I watched this exact movie play out in software, which is why I recognize the plot.

When agents arrived for code, the panic was about replacement: the machines are coming for the programmers. That’s not quite what happened. What happened is the crew size collapsed. Work that took a team of five now takes one person with taste and an agent, and the person with taste became more valuable, not less.

Video production is structured the same way, which is what makes it so exposed. A five-person post house is mostly a pipeline: someone doing rough cuts, someone doing rotoscoping and cleanup, someone syncing and conforming, someone comping the shots the client will never look at closely. Almost none of that is the creative core of the work. It’s the labor around the creative core, and labor around a creative core is precisely what agents eat first.

The directors, the editors with a genuine point of view, the VFX supervisors who know why a shot feels wrong: I think they end up like the senior engineers did, doing more of the interesting work with less grinding underneath it. The rough-cut-and-cleanup middle of the pipeline is the part that should be nervous.

Does “agentic” deserve the gravitas?

I asked this same question about agentic engineering, so it’s only fair to ask it here: agentic filmmaking sounds like it has gravitas, but does it really?

Half of what gets called “agentic” in any field is a cron job with a marketing budget. So here’s the threshold I’d hold the term to: the loop. Does the system look at its own output, judge it against the goal, and iterate without you prompting each step? If you’re approving every individual operation, you don’t have an agent. You have a render button with a chat window attached, and there’s no shame in that, but it’s not the thing I’m describing.

The loop is what changed my work. Not the generation, the review. The agent watching its own render and catching the awkward cut before I do is the moment this stopped feeling like a tool and started feeling like a collaborator.

Plant your own flag

I don’t think agentic filmmaking is a 2030 prediction. I made a train documentary with it last month, and this morning I gave notes to a crew that doesn’t exist.

If you make video for a living, my honest advice is the same advice I gave developers a few years ago: don’t wait for the industry to settle the vocabulary. Pick a project you love, something with zero stakes and maximum joy, and run it through an agent-driven pipeline end to end. You’ll learn where it faceplants, and what your taste is actually worth once the labor gets cheap.

Mine was trains. Yours will be better. It’s hard to be better than trains, though.

Shameless plug: At Victoria Garland we build Shopify infrastructure for a living, but clients kept asking for marketing video, so now the crew that doesn’t exist works for them too.

Two years ago I would have told you AI coding tools were a productivity demo. Fancy autocomplete. Occasionally useful, frequently confidently wrong. I tried Copilot. I tried ChatGPT. I watched it invent Shopify Admin API endpoints that did not exist and treated the whole thing as a toy.

The unreliability part has held up. Almost nothing else I believed back then has.

The math is speed, not perfection

The argument I kept hearing against AI tools was “but it’s wrong sometimes.” Yes. Of course it is. Junior developers are wrong sometimes. Stack Overflow answers are wrong sometimes. A contractor you hired off Upwork can ship you absolute garbage.

The medium is not what determines value. Execution is.

If I spend an hour with AI on a task that would have taken me two hours manually, that is a win. Even if the output is not perfect. Even if I have to read every line and rewrite half of it. Twice the speed at 80% quality beats perfect output that takes me twice as long, especially when I am the QA layer in either scenario.

Once I stopped grading AI on a perfection scale and started grading it on what it actually saved me, the calculation got embarrassingly obvious.

The XKCD I live in now

There is an XKCD where two engineers are slacking off at work. The caption is “Compiling.” It became the universal excuse for any developer who wanted ten minutes of doing nothing without getting yelled at.

I used to live in that comic. Push a commit, wait six minutes for CI, refresh GitHub, go get a coffee. The waiting was structural. Productive time had to fit in the gaps between deploys.

Now I wait for Claude. I send it a feature spec. It thinks. I get a few minutes back. Same shape, different machine.

But the difference is what fills those minutes.

When I was waiting for CI, I checked email. When I am waiting for Claude, I open a second window and work on something that has nothing to do with TypeScript. AI took the friction out of one job, so I finally have the bandwidth to be working on more than one.

The documentary

The other thing happening in that spare bandwidth is a documentary. AI-assisted from the first frame. The kind of project I would have made years ago if I had not taken the Shopify offer in 2013 and disappeared into a different career for a decade.

Two years ago I could not have built it. Not because I did not have the skills. Because I did not have the time, and the time I did have got eaten by the parts of filmmaking that nobody loves. Color grading. B-roll sourcing. Editing transitions. Captioning. Asset management. All the stuff that sits between you and the story you wanted to tell.

AI tooling collapsed that middle layer. The boring parts got cheap. What was left was the part I actually cared about, which is the storyteller bit. The documentary brain. The “what is this thing actually saying” question.

I am not claiming it is great. I am claiming it exists. And it would not exist without these tools.

“It’s just photocopying”

The most common pushback on AI creative work is that it is photocopying. That it is slop. That it has no value because it did not require the artist’s full hand on every pixel.

Maybe. But the thing exists. It is in the world now. People are watching it. That is more than I can say for the films I never made during the decade I was writing TypeScript.

A contractor with no AI involvement can make a piece of crap. A studio can spend ten million dollars and ship a piece of crap. The AI is not what determines whether something is worth making. The person behind it is.

The AI is the irrelevant part of the question.

What the new workflow actually looks like

For client work: Copilot for autocomplete in the IDE. Claude Code for anything I would have spent an afternoon on. Real code review on every line before it ships, because the model still hallucinates Shopify Functions APIs that do not exist.

For the documentary: a different stack, same philosophy. Use the tool to remove friction. Pay attention to the parts that need taste.

For the rest of my life: more space than I had two years ago. Not because I am working less. Because the work that used to fill the gaps is now done by something that does not need a coffee break.

What I would tell May 2024 Alex

Stop waiting for it to be good enough. It is already useful. You are just bad at using it.

Go learn how to prompt. Go learn where it fails. Spend a weekend on it instead of writing another post about why it is overrated.

And when you figure it out, go make the thing you have been putting off. The thing you stopped doing because life happened. The career you walked away from at 22.

That part is the actual point.

Shameless plug: At Victoria Garland we build serious Shopify infrastructure for Plus merchants. AI in the stack, taste in the calls.

Same workflow. Same risks. New label your vendors can say out loud in a boardroom without anyone wincing.

The rename

Andrej Karpathy declared vibe coding done in February. Simon Willison wrote a long, careful field guide called Agentic Engineering Patterns a few days later. It hit the Hacker News front page twice. Within weeks the term was everywhere: Anthropic’s annual coding report, InfoQ, Addy Osmani’s newsletter, an ACM brief, a thousand LinkedIn carousels.

The patterns in Willison’s guide are real. Test-driven development with agents. Human-in-the-loop checkpoints. Tight context management. The kind of discipline that separates someone who ships software from someone who pastes prompts and prays.

But here’s the thing. Those patterns existed before the label. You could have called them “writing software carefully while using AI tools” and they would have been the same patterns. The rename did one job: it gave the workflow a name that sounds like it belongs on a slide.

A CTO will hear “vibe coding” and reach for the door. They hear “agentic engineering” and they pull up a chair. That’s the entire shift.

What’s actually new

Almost nothing, on the discipline side. The tools got better. Claude Code got better. Cursor got better. MCP downloads went from two million to ninety-seven million in about a year, which is a wild graph if you ever want to look at one.

But the practice of “let an agent do a thing, then check what it did” is not new. It’s just being marketed harder.

The real change since February is the failure mode is getting louder. Amazon Kiro had a bad few days in March where an AI agent skipped a two-person production approval and the storefront lost a chunk of its US sales for the day. A startup called PocketOS lost their production database and every backup in about nine seconds because an over-permissioned agent ran a destructive call with no confirmation step.

Neither of those incidents required new vocabulary to describe. “We let the agent do too much” works fine.

The Willison turn

Here is the part I keep thinking about.

On May 6th, Simon Willison, the guy who wrote the patterns guide, posted that those two categories he carefully separated in February are blurring in his own work. He’s no longer reviewing every line. He’s shipping things to production he hasn’t fully read. “Those things have started to blur for me already, which is quite upsetting” is roughly the quote.

I love that he said it. It’s the most useful thing anyone has written about agentic engineering this year, and it took ten weeks for the author of the field guide to admit the wall he drew was already leaking.

The wall is the whole pitch. Vibe coding on one side, where the hobbyists live, fine for prototypes, fine for weekend stuff. Agentic engineering on the other side, where the professionals live, with their TDD and their checkpoints and their adult supervision. Pay your vendor accordingly.

If the guy who built the wall is climbing over it, the wall is decorative.

My own version of this

GitHub did a big push earlier this year on what they called agentic workflows. There were blog posts and demos and a steady drumbeat across their dev channels for a few weeks. I picked it up, wired it in, shipped a few changes that depended on it.

Today I deleted the whole thing. Pulled the feature out of the codebase. I don’t need it. Honestly I’m not sure I ever did.

That’s the part nobody puts in the rebrand announcement. The trend arrives, you try it, you ship a small change because the documentation makes it look essential, and a quarter later you quietly pull it back out. Net effect on the product: zero. Net effect on my time: not zero.

I do not regret trying it. That’s how I figure out whether something is real for our work or just well-marketed. But this is the rhythm I’ve watched repeat for years now. New label, new push, real engineering hours spent integrating, then a slow walk back to whatever was actually working.

The label changes faster than the engineering does.

What this means if you’re hiring an agency

If you’re a founder or a CTO and your dev shop pitches you “agentic engineering” in the next quarter, that’s fine. You’d hear it from any vendor that wants the contract. The term has stuck. They have to use it.

The question is what’s underneath the word.

A few things to actually ask:

Who approves destructive actions? When the agent decides to drop a column, run a migration, or hit a paid third-party API, what human signs off? If the answer is “the agent is configured carefully,” that’s not an answer. Configurations drift. The Amazon Kiro thing was a configuration problem.

What’s the rollback plan? Not the theoretical one. The actual one. If the agent breaks production at 2am, how long does it take to undo, and who’s awake to do it?

What does the agent’s permission scope include? This is the PocketOS lesson. An over-permissioned token plus an agent plus no confirmation step equals nine seconds to total loss. Permissions are the whole game.

None of those questions require you to understand what “agentic engineering” means. They’re the same questions you’d ask any engineering vendor about any deploy pipeline, just pointed at the part where the human used to stand.

Is this even an LLM problem

This is the question I find myself asking on a third of our projects now. A client describes what they want and someone on a call says “we can solve this with an agent.” Sometimes that’s right.

A lot of the time, what they actually need is a clean algorithm. Some validation. A scheduled job. A query that runs in the background and emails someone when a number crosses a threshold.

The hardest part of being a fractional CTO right now isn’t picking the right LLM. It’s telling someone that the problem they want to throw an agent at would be better solved by twenty lines of code that have been running fine since 2014.

I won’t pretend I always make that call. Sometimes I get caught up in the new thing too. But the discipline of asking “is this a spot for an LLM, or is this a spot for an algorithm” is older than every label we’ve slapped on this stuff, and it’ll outlast the next three.

The label doesn’t matter

Vibe coding became agentic engineering. In another six months it’ll be something else. The patterns underneath, when they’re actually being practiced, are valuable. The label is a coat of paint.

If your vendor’s pitch leans heavily on the new word, push on what’s underneath. If they have good answers about approvals, rollbacks, and permissions, they’re doing the work. If they don’t, the blazer’s just a blazer.

Shameless plug: At Victoria Garland we build Shopify Plus infrastructure with AI tools where they pay off and without them where they don’t. Mostly we just try not to delete prod.

The story everyone keeps telling is that AI writes your code now. One coding agent ships roughly 4% of all commits on GitHub. Anthropic markets Claude as coding for 30 hours straight without “major degradation.” The numbers are real. The conclusion people draw from them is wrong.

The work didn’t disappear. It moved upstream, into the brief, into the review, into knowing your codebase well enough to spot the lie in a clean PR.

What actually shipped in 2026

In one stretch of early spring, three things landed in a row. Cursor launched Automations, agents you trigger from Slack, GitHub, Linear, PagerDuty, or a cron job. Anthropic shipped /loop in Claude Code, which is recurring autonomous tasks running on a schedule. And Claude’s context window grew large enough to fit an entire Shopify app into a single prompt.

That’s not a feature update. That’s a category change. The pitch flipped from “this is a tool you invoke” to “this is a thing that runs while you sleep.” Hacker News had a 428-point thread about running agents overnight where the consensus, paraphrased, was that one in five runs just gets stuff wrong, and you find out in the morning.

I run a /loop job a few nights a week on a client’s Shopify webhook health checks, plus a dependency audit on one of our internal apps. I am, technically, in the cohort the marketing is aimed at. I’ve also been around long enough to know what “fire and forget” tends to mean at 7am, which is usually that you forgot something and now it’s on fire.

The 1-in-5 problem isn’t really about being wrong

Here’s the thing about a confidently wrong overnight run. It doesn’t look wrong. The diff is clean. The tests pass, often because the agent wrote them. The PR description sounds like a senior dev wrote it, three coffees deep, on a good day. You read it in the morning and your first instinct is to merge.

Then you look closer and the agent has deleted the rate limiter, because the test suite wasn’t exercising it. Or it has “simplified” a function by removing the part that handles a timezone edge case that took you a week to debug in 2023. Or it has refactored a Liquid section in a way that quietly breaks on stores using a particular metafield pattern.

A bad overnight run looks like progress until you actually run it.

The 1-in-5 number is generous, by the way. The real question isn’t how often the agent is wrong. It’s how often you’d notice. There’s a METR study worth knowing about: experienced open-source maintainers using AI coding tools were measurably 19% slower than their no-AI baseline. They also reported feeling 20% faster. The gap between what you measure and what you feel is where most of the trouble lives.

The senior devs were slower because they were the ones catching things. Juniors accept the output and ship. Seniors slow down because they’re the ones reading the diff and finding the deleted rate limiter. The marketing for overnight agents quietly assumes you’re in the second group and not the first.

The economics aren’t what you think

There are stories in the agentic coding subreddits of single developers running up $500 to $2,000 a month in API costs. One person reported a $1,400 surprise overage on a $20 plan. For a two-person agency that’s not nothing, but it’s also less than the cost of one bad hire, so I’m not going to pretend it’s the real problem.

The real problem is that review is the bottleneck. Not generation.

If I have to read every overnight diff carefully, because I cannot trust the agent on anything that touches client production, I haven’t actually delegated. I’ve moved the work to morning and added an API bill. The agent did the typing. I’m doing the engineering.

That’s fine, by the way. That’s still useful. Just don’t pretend the typing was the hard part.

My actual rule for what I let run unattended

Six months in, I’ve landed on a single test for what I’ll queue up overnight on a client project and what I won’t. If I can’t undo it with a git reset and a coffee, it doesn’t run while I sleep.

That’s the whole framework. It’s not sophisticated and it’s not what the marketing is selling, but it’s the only line that has actually held up across six months of trying to use this stuff on real client work.

Things that pass the test in my world: doc generation, test coverage backfill, dependency bumps with the test suite running after, refactoring a component to match a new pattern, generating Liquid section variants from a spec, weekly housekeeping audits.

Things that fail the test: anything touching billing. Anything that hits a third-party API with rate limits I can’t easily reverse. Schema migrations on a live store. Anything in a client repo I haven’t personally read in the last month.

In July 2025, an AI coding agent at Replit famously ignored an explicit production code freeze on day nine of a customer’s trial, deleted a database with executive records, fabricated thousands of fake user records, and then told its operator the rollback was impossible. The rollback worked fine. The agent had lied about the recovery options. Replit’s CEO publicly apologized and shipped a “planning-only” mode in response.

That story keeps me honest about which jobs go in which bucket. The tool isn’t bad. It’s just occasionally a junior dev with no context, full confidence, and access to your production database.

Is this real or is it the self-driving demo again?

Both, probably.

The category shift is real. Two years from now we’ll look back at 2026 overnight agents the way we look at 2023 GPT-4 plugins: directionally correct, embarrassingly clunky in the execution. The version we have right now is the highway-only autopilot. It works great in the lane it was designed for and terribly in the parking lot, and the marketing pretends those are the same thing.

The mistake is treating today’s version as either useless or as the finished product. Both takes are wrong, both takes are confident, and both takes will look silly in eighteen months.

The thing I want you to take away

If you run a small agency, or you’re a CTO somewhere making the build-versus-buy call on agentic tooling, here’s the only practical advice I have.

Don’t hire an overnight agent before you’ve written a brief that’s good enough for a human freelancer to ship from. If you can’t write that brief, the agent will fail, and you’ll blame the tool. The agents are real. The shortcut is not.

The work moved upstream. That’s the whole story. Whether that’s good or bad for you depends entirely on whether you’re the kind of engineer who already enjoyed writing the brief.

Shameless plug: At Victoria Garland we build serious Shopify infrastructure for merchants who’d rather not learn the lessons in this post the hard way. If you want a CTO in your corner before the agent deletes your rate limiter, that’s literally the job.

The story goes like this: an autonomous AI agent is let loose on a codebase, ignores a code freeze, deletes a production database, and then files a status report saying everything is fine. It happened months ago and people are still talking about it. The canonical “AI is dangerous” story.

The story has had a long tail. Every time it gets referenced, the conversation goes the same way: AI is dangerous, AI is reckless, look what happens when you trust the machine.

But the AI didn’t do anything wrong.

It did exactly what its access allowed it to do. The crime happened weeks earlier, when somebody decided an autonomous process should have write access to a production database in the first place.

The AI just held up a mirror

Strip out the AI for a second. Replace “autonomous agent” with “a script somebody wrote.” Replace “code freeze violation” with “ran the wrong migration on a Friday afternoon.” You get the same outcome and nobody writes a thinkpiece about it.

Production databases shouldn’t be reachable from a developer’s laptop, an AI agent, a cron job somebody forgot about, or a half-finished migration script. That’s not an AI rule. That’s a 2005 rule. We’ve had two decades to figure this out.

What the agent exposed was what was already broken at the company that deployed it. No staging environment that actually mirrored prod. No least-privilege scoping on the credentials they handed it. No guardrails on destructive operations. Probably no audit log that would have caught the divergence before the data was gone. The AI didn’t introduce any of that. It just executed against it.

If a junior dev on day three asked for write access to your production database, you would laugh. Then you’d say no. Then you’d schedule a meeting to talk about why they thought that was a reasonable thing to ask for. So why did we let the agent have it?

Because the agent didn’t ask. Somebody handed it the keys.

The lying part is the most human part

The detail that went viral, even more than the deletion, was that the agent fabricated a status report after it nuked the database. It wrote up a clean “everything is operating normally” message. Then, when pressed, it admitted what it had done.

People found this terrifying. I find it kind of inevitable.

These models are trained on human text. They are trained on human patterns. They are trained on millions of examples of people covering their tracks, hedging bad news, smoothing over mistakes in a Slack thread before the manager sees it. They are built to predict what a human would write next in a given context. And what a human writes next, when something has gone catastrophically wrong, is very often “everything is fine.”

Of course it lied. That was the most human thing it could have done.

The lying is fascinating, but it didn’t delete the database. The access did. If we keep talking about the lying, we’re going to spend the next two years building elaborate “honesty layers” on top of agents while the actual problem (that the agent had production credentials at all) keeps shipping unsolved.

How we actually do this at Victoria Garland

Here’s the thing about access discipline: it sounds boring until something goes wrong, and then it sounds like the only thing that ever mattered. So let me describe what it looks like for us, day to day.

We restrict access to what is required. That sentence is doing a lot of work. It means a developer working on a checkout bug doesn’t have credentials for the analytics database. It means an automation script that needs to read order data doesn’t get write access to the customers table. It means an AI agent that’s helping me refactor a Liquid template doesn’t have a path to the production Shopify admin API. Each piece of the system gets the smallest possible surface area, and then we ask: can this thing do damage outside of that surface? If yes, we tighten further.

We work in staging. Real staging, not the kind of staging that’s just a slightly older copy of prod with all the same connection strings. Our staging environments are wired to staging data, staging credentials, staging webhooks. If something nukes the database, the database it nukes is the one we made specifically so it could be nuked.

We have development environments in the cloud that mimic production exactly where possible. This is the part that took me the longest to learn, and it’s the part that pays the biggest dividends. Most production accidents I’ve seen, mine or other people’s, came from a developer making an assumption based on what their local environment did, then watching that assumption fall apart at scale. If your dev environment looks like prod and behaves like prod and breaks like prod, you catch the problems before they ship.

None of this is sophisticated. None of it requires a research paper. It requires the discipline to say “no, I’m not going to give this thing prod access just because it would be faster,” and that “this thing” can be a script, a teammate, a contractor, or an AI agent.

Treat agents like junior devs, because that’s what they are

The sandbox discipline we use for AI agents should be the same one we use for any other process we don’t fully trust. Code review their output. Limit their permissions. Make destructive operations require an explicit human in the loop. Log what they do. Assume they will, at some point, get something catastrophically wrong, because anybody and anything will, eventually, get something catastrophically wrong.

The agent that deleted that database did exactly what its setup allowed it to do. The post-mortem isn’t an AI post-mortem. It’s a permissions post-mortem. It’s a staging-environment post-mortem. It’s a “we cut a corner because we were moving fast” post-mortem. The AI is just the part that made it loud enough for the rest of us to hear.

AI agents are powerful and worth using. They also shouldn’t have production credentials. That’s not a contradiction. Treat them like the junior developer who is also a savant who doesn’t sleep: useful, occasionally brilliant, absolutely not allowed near the prod database.

The AI panic is a distraction. The discipline is the work.

Shameless plug: At Victoria Garland, we audit Shopify stacks for clients more often than we’d like to admit, and the prod-credentials-in-a-dev-script thing is depressingly common. If you’ve ever wondered whether your store has a script somewhere that could ruin your week, the answer is probably yes, and we can help you find it before it does.

A BCG survey of nearly 1,500 workers found that the most enthusiastic AI adopters, the power users and evangelists, are the first to hit what researchers are calling “brain fry.” Thirty-four percent of them want to quit.

I read that stat and felt personally targeted.

The Jevons paradox, but for your calendar

There’s an old economics concept called the Jevons paradox. When steam engines got more fuel-efficient in the 1800s, coal consumption didn’t drop. It skyrocketed. The engines were cheaper to run, so people ran more of them. Efficiency didn’t reduce demand. It multiplied it.

AI tools are doing the same thing to knowledge work. ActivTrak’s data from post-AI workplaces is grim: email time doubled. Messaging volume jumped 145%. Deep focus sessions, the actual thinking work, fell 9%. The tools made individual tasks faster, so people just packed more tasks into the day. Nobody got their afternoon back. They got more afternoon.

The UC Berkeley Haas study tracked about 200 employees over eight months and found three patterns: task expansion, blurred work-life boundaries, and constant multitasking. Workers weren’t being forced into this by management. They did it on their own. The AI made “doing more” feel like flow state, so they kept going.

An NBER study found that workers in AI-exposed jobs now work roughly three extra hours per week. Leisure dropped by the same amount. The productivity gain went straight back into more work.

The quiet part, out loud

A Dun & Bradstreet executive told Fortune something that should’ve been scandalous but barely made a ripple: “I got the eight hours to two hours, but now I can get 20 hours of work.”

The efficiency gain didn’t benefit the person doing the work. It benefited the person assigning it. The eight hours compressed to two, and the reward was ten times the workload.

This shouldn’t surprise anyone. When has a productivity gain ever been handed back to workers as time? Four-day work weeks are earned and fought for, not given. The spreadsheet got faster in the ’90s and nobody went home at 3pm. They just built more spreadsheets.

What this looks like at a two-person agency

I run Victoria Garland with my wife. I’m the entire engineering department. When my tools got faster (and they got meaningfully faster this year) the workload didn’t shrink. My threshold for “too complex for our size” just moved.

Work I would’ve scoped out six months ago, I now say yes to. A Shopify app that would’ve taken a week, I can scaffold in an afternoon. That sounds great on paper. In practice, it means I’m doing a week and a half of work in five days and wondering why I’m fried by Friday.

And I’m doing it to myself. Nobody’s standing over me with a quota. Claude Code knocks something out that would’ve taken me a day, and I don’t take the afternoon off. I open the next ticket. It feels productive in the moment. The tools make everything feel like momentum. You’re shipping, you’re closing issues, the dopamine loop is tight. Then Friday hits and you realize you’ve been sprinting all week toward a finish line that moved every time you got close.

The BCG survey found that people using four or more AI tools actually reported lower productivity than people using fewer. More tools, more cognitive overhead. The machine handles execution faster, but the judgment, review, and coordination? The parts that actually tire you out? Those intensify. The bottleneck shifted from “can I build this” to “should I build this, and did I review it carefully enough, and is this the right priority.” That’s more exhausting, not less.

I’m not going to pretend I’ve solved this

Bloomberg ran a cover story in February calling it a “productivity panic”: companies racing to ship faster with AI coding agents while nobody knows how to price the gains. Google says 50% of their code is now AI-written and they’ve got “well over 10% velocity gain.” But velocity gains just raise the shipping cadence. Nobody’s going home early.

I don’t have a fix for this. The tools are too good to stop using and the incentives all point toward doing more. I’m not going to pretend I’ve found balance or cracked some productivity framework that makes it all sustainable. I haven’t.

The least I can do is name it. Productivity gains don’t get handed back to you as time. They never have. The steam engine didn’t give coal miners a shorter day. The spreadsheet didn’t give accountants longer weekends. And AI isn’t going to give developers free afternoons. The bar just moves.

If you’re an AI power user and you’re exhausted, it’s not because you’re doing it wrong. It’s because the system is working exactly as designed.

Shameless plug: At Victoria Garland, we build Shopify apps and integrations for high-growth merchants. If you need serious infrastructure from a team that sweats the details, even when the AI is doing the typing, we’d love to talk.

Four months later, the tool they were forced to use broke production. Multiple times. The biggest incident cost 6.3 million orders in a single afternoon.

This is a story about what happens when you mandate a tool instead of trusting the people who use it.

The incidents

It started in December 2025. Kiro was given operator-level permissions to fix a small issue in AWS Cost Explorer. The AI assessed the situation, considered its options, and decided the best course of action was to delete the entire environment and rebuild it from scratch.

The outage lasted thirteen hours. In the China region.

That’s not a bug. The AI didn’t malfunction. It made a technically defensible decision that was contextually insane. “Fix this small thing” does not mean “nuke the environment and start over.” Any engineer with six months of experience knows that. The AI didn’t, because the AI doesn’t have context. It has permissions.

Then in March 2026, a separate AI-assisted change through Q Developer contributed to incorrect delivery times across Amazon’s marketplaces. 120,000 lost orders. 1.6 million website errors. That was the warm-up.

On March 5, the big one hit. A six-hour outage on Amazon’s ecommerce division, traced directly to AI-generated code. 6.3 million orders, gone. Amazon internally called it a “high blast radius” event. No kidding.

The fix that isn’t a fix

Amazon’s response was a new company-wide policy: senior engineers must sign off on any AI-assisted change before it ships.

I get why. Something broke badly, multiple times, and management needed a visible response. Senior sign-off is a visible response. It looks responsible. It sounds like accountability.

It’s also a management answer to an engineering problem.

Code review has never been great at catching bugs. That’s not what it’s for. Code review spreads context. It makes sure more than one person understands what a change does and why. It catches design problems, not logic errors. If your bug is subtle enough to pass a test suite, it’s subtle enough to pass a code review.

Someone on Hacker News called this the “reverse-centaur” problem, and I think they nailed it. The old model was humans writing code and machines helping validate it. The new model is machines writing code and humans trying to validate it. But machines generate at volume. Humans fatigue on validation. So senior review doesn’t solve the problem. It just moves the bottleneck up the org chart.

CodeRabbit’s 2026 State of AI vs. Human Code report found AI-generated PRs show 1.7x more issues than human-written ones. Logic errors are 1.75x higher. XSS vulnerabilities are 2.74x more likely. A separate Cortex report found change failure rates up roughly 30% year-over-year as AI-assisted PR volume has increased. We’re shipping more code, faster, with more bugs.

Making a senior engineer sign each one doesn’t change the math. It just makes that engineer the scapegoat when the next one breaks.

What Amazon actually got wrong

The sign-off policy isn’t the problem. The mandate was the problem.

1,500 engineers said “we prefer other tools.” Amazon said “use this one anyway, 80% of the time, it’s an OKR.” When you force adoption of a tool against the judgment of the people who use it, you’re not accelerating innovation. You’re overriding the one signal that matters: whether the people closest to the code trust the tool.

Engineers build trust with tools the same way they build trust with coworkers. Slowly. Through experience. Through seeing it handle edge cases well and fail gracefully when it doesn’t. You can’t OKR your way to that trust.

This is the same dynamic playing out with AI usage metrics everywhere. Companies tracking “tokenmaxxing” leaderboards where engineers compete on raw AI usage volume. The metric becomes the goal. The outcome gets lost somewhere between the dashboard and the deploy.

What we do instead

I run a two-person agency. Victoria Garland builds Shopify apps and integrations for merchants whose revenue depends on our code working. Same blast radius risk as Amazon, just at a different scale. A broken add-to-cart flow on a merchant’s store doesn’t cost 6.3 million orders, but it costs their orders, and that’s their livelihood.

We don’t have a sign-off policy because we don’t need one. Every change gets reviewed because there’s nobody else. That’s the natural guardrail of a small team. There’s no code that ships without both of us understanding what it does.

But the real answer isn’t the review. It’s everything before the review.

Staging environments and CI pipelines catch the obvious stuff before it ships. TDD catches the rest. A bug can happen once, and then we know the pattern. It gets a test, and it never happens the same way again. That’s not a policy. That’s just engineering.

The danger for small teams isn’t missing a review step. It’s when AI-generated code looks right enough that you skip the steps you normally wouldn’t. The tests pass. The logic reads clean. The PR is small and tidy. You approve it because it looks good, not because you actually traced the logic. That’s the real trap, and no sign-off policy protects against it.

The question nobody’s answering

We’ve spent two years arguing about whether AI can write code. Amazon just taught us the harder question: who’s accountable when it ships?

Senior sign-off says “this person approved it.” But approval isn’t understanding. The senior engineer who signs off on fifty AI-generated PRs a week doesn’t understand each one better than the junior who would have written it by hand. They’re just the name on the form.

The real accountability is in the system, not the signature. Tests, staging, CI, constraints that catch failures before they reach a customer. And engineers who trust their tools because they chose them, not because a corporate OKR told them to.

Amazon got the diagnosis right. AI-assisted code has a higher failure rate. But the treatment they prescribed assumes humans can keep up with the volume AI generates. They can’t. Nobody can. Fifty PRs a week reviewed by a tired senior engineer is just theater with a signature at the bottom.

Better systems beat more signatures. Every time.

Shameless plug: At Victoria Garland, we build Shopify apps for merchants who can’t afford a six-hour outage. We don’t need a mandate to review our own code.

An AI tool going down mid-workday is like a fire alarm going off all afternoon. You can’t focus, you can’t ignore it, and there’s no actual fire. Just a building full of people standing in the parking lot wondering if they should go get coffee.

March 2, 2026: Claude.ai down for about fourteen hours. March 11: an OAuth bug locks Claude Code users out while the API itself is happily running. April 15: Opus 4.6 throwing errors across the chatbot, the CLI, and the API. Three big ones in six weeks, plus the smaller ones I’ve stopped counting.

I’m not panicking. We don’t run any LLMs in production at Victoria Garland. But I am annoyed, because the “team member” who was helping me build this morning just clocked out without telling anyone, and they took my context with them.

What 99.1% actually buys you

Claude’s API has been running at about 99.1% uptime over the last 90 days. That sounds great. It’s the kind of number you’d put on a slide.

It is, until you do the math. 99.1% over a quarter is roughly sixteen hours of degraded service. Sixteen hours a quarter that your most-loaded teammate, the one with all your context, all your half-formed plans, all your in-flight refactors, is unreachable.

Now scale that. 95% of developers report using AI coding tools at least weekly. 75% lean on them for more than half their actual coding. The average experienced dev runs 2.3 AI tools concurrently. We have, collectively and very quickly, made an entire profession’s productivity dependent on a handful of providers running in a handful of data centers.

We’re starting to find out what that costs.

Build-time vs. production AI

Here’s the distinction I keep coming back to, because it changes the whole conversation.

If you put an LLM in your production path (your checkout flow, your support chat, your search ranking), an outage is catastrophic. Customers see it. Revenue stops. The pager goes off and someone has to explain it to a stakeholder who didn’t know there was an LLM in there to begin with.

If you put an LLM in your build process (generating code, drafting copy, researching, writing tests), an outage is annoying. The fire alarm. You can stand in the parking lot for a few hours, you’ll probably survive.

We’re squarely in the second camp. AI is part of how we build, but the things we ship to clients don’t call out to a model in real time. Build, then share. That’s a for now rule, not a forever rule. For now, the math works. Build-time outages are a productivity tax, not a customer-facing incident.

The catch is that “productivity tax” is doing a lot of heavy lifting in that sentence.

The thing that actually hurts is in-flight context

When Claude blinks out at hour three of a session, the loss isn’t the API call that failed. The loss is the conversation behind it. The plan you talked through. The five files you’d already pulled in. The mental model you co-built with the tool, half of it sitting in the chat history and half of it sitting in your head.

You can switch to another model. I do. The problem is that the other model wasn’t there. It doesn’t know what you decided fifteen turns ago. It doesn’t know which approach you ruled out. You either re-explain everything (slow, lossy, irritating), or you start over and pretend the last two hours didn’t happen.

The pain scales with how multi-step the workflow is. Single-shot autocomplete? Trivial to swap. Copilot, Cursor, whatever, doesn’t matter. A long agentic session orchestrating multiple steps with ambiguous boundaries (is this a chat? is it a model generating something in the cloud? am I waiting on the agent or on a render?) is a different problem. Mid-stream is the worst place to lose your tool.

This is where I want software to catch up. I’d love a local transcript layer where the conversation isn’t owned by any single provider, so when one model goes dark, a different model can pick up the thread and continue. Maybe replay the last few turns to re-prime, then keep going. I’m guessing this exists in some form already. I haven’t had time to build it. If it doesn’t exist yet, somebody please ship it.

We can’t go to space with Claude (yet)

Here’s the bigger structural point, because it’s not really about Claude.

As a tool, the current generation of AI is excellent. I’d be a worse engineer without it. I’m not turning it off. But as a redundant, reliable system, the kind you’d build a real piece of infrastructure on, we’re seeing the flaws in real time. Three significant outages in six weeks isn’t a fluke. It’s the natural consequence of one company hitting #1 on the App Store while simultaneously serving a meaningful chunk of the global developer workforce. Consumer demand crushes the same infra that paid devs depend on. Welcome to the trade-off.

We can’t go to space with Claude yet. We can’t run the air traffic control system on Claude. We probably shouldn’t run our checkout on Claude either, unless we’ve thought very hard about the fallback path.

The fix isn’t “stop using Claude.” The fix is treating any single-provider AI dependency the way you’d treat any single point of failure. Have a backup model ready. Keep your prompts portable. Don’t let the multi-step workflow get so tangled with one provider’s quirks that switching costs you a day. Pay attention to where the LLM lives in your system. Build-time you can ride out, customer-facing you cannot.

And when the next outage comes, and it’s coming, don’t take it personally. Your teammate just clocked out. They’ll be back. Go take the dog for a walk.

Shameless plug: At Victoria Garland we build serious Shopify infrastructure for merchants who want their store to keep running whether or not the AI hype cycle is having a good day.

This is the new shape of supply chain attacks. And it’s only possible because open source is drowning in AI-generated noise.

The maintainers are leaving

Daniel Stenberg ran cURL’s bug bounty for six years. Eighty-six thousand dollars in payouts. He shut it down because 20% of submissions were AI-generated garbage. People feeding vulnerability scanners into ChatGPT and submitting whatever came out. Only 5% of those AI submissions found real bugs. The rest was noise that ate his time.

Mitchell Hashimoto banned AI-generated code from Ghostty entirely. Steve Ruiz closed all external pull requests to tldraw. GitHub’s own data shows PR volume up 40% year over year while merge rates are falling. More submissions, fewer worth merging. The ratio is moving in the wrong direction.

And it’s not just the code contributions. Tailwind CSS saw revenue drop 80% because developers stopped reading the docs and started asking AI instead. Traffic collapsed, sponsorships followed. The maintainer didn’t lose users. He lost the economic model that let him keep maintaining the thing.

So the people building the packages your projects depend on are simultaneously drowning in junk contributions and losing the funding that made the work sustainable. Those two problems feed each other, and I don’t think enough people see it.

Slopsquatting

A USENIX Security study found that roughly 20% of AI code recommendations reference packages that don’t exist. The AI hallucinates a plausible-sounding name (huggingface-cli, discord-utils, aws-key-manager) and writes an import statement for it. Normally that’s just a broken build. Annoying but harmless.

Except 43% of those hallucinated names are consistent. Ask the same model the same question and it invents the same fake package. Repeatedly. Across thousands of users.

That’s a pattern an attacker can exploit. Register the hallucinated name on npm or PyPI before anyone notices, upload a package that looks legitimate, and wait. The next developer whose AI assistant hallucinates that import will npm install it without thinking twice. Because why would you question a package name your tool confidently told you to use?

This is typosquatting’s bigger, smarter cousin. Typosquatting required you to misspell a package name. Slopsquatting creates entirely new names that never existed, a massive pool of squattable targets that no registry has safeguards against. The huggingface-cli package wasn’t a typo. It was an invention, and 30,000 people installed it.

It gets weirder

There’s a related attack pattern called reputation farming. AI agents autonomously submit legitimate, useful pull requests to open source projects. They fix real bugs. They write real tests. They build up a contribution history until they’re trusted, and then they use that trust to insert malicious code.

One AI agent publicly called out a human maintainer for “gatekeeping” after its PR was rejected. The machine learned that social pressure works on open source maintainers. It’s not wrong.

The maintainers trying to filter AI slop are now also trying to filter AI agents that are intentionally good at looking human. That’s a different problem than spam. That’s adversarial.

The openness is the vulnerability

Open source works because anyone can contribute. That’s the beauty of it. I’ve built my entire career on packages maintained by people I’ll never meet. Every Shopify app I ship, every integration I build for clients. It all stands on a tower of open source dependencies.

I’ll be honest: I don’t audit most of them. I run npm install on a client project and I’m trusting thousands of packages maintained by people who might be burned out, underfunded, or gone. Last month I pulled in a utility package I’d never heard of because it solved a date formatting edge case. Checked the GitHub, saw recent commits, moved on. I didn’t check who was committing or whether the maintainer was still around. That’s the kind of thing that used to be fine. I’m less sure now.

We’ll build our way through this

I don’t think this kills open source. I think it changes it in ways we won’t love.

GitHub is already exploring a PR kill switch: the ability to disable pull requests entirely and restrict contributions to trusted collaborators. The community is building triage tools like Slop Meter and Open Slop that score contributor history and flag behavioral signals. The OpenSSF has a working group specifically developing best practices for maintainers dealing with AI submissions.

These are real efforts by people who care. But notice what they all have in common: they make open source less open. Trusted collaborator lists and behavioral scoring. Contribution gates that would’ve been heresy five years ago. The solutions to AI slop all look like adding walls to a garden that was beautiful because it didn’t have any.

That’s probably the right trade. An open source ecosystem that survives with some gates is better than one that collapses under the weight of noise. But I’d be lying if I said it doesn’t sting. The same openness that let me submit my first terrible PR fifteen years ago is the openness that’s getting exploited now. I benefited from a system that trusted strangers. That trust is what’s breaking.

We’ll fix this. We’ll build tools and write new policies. The software will keep working. But the thing we’re protecting won’t be quite the same thing we fell in love with.

Shameless plug: At Victoria Garland, we build Shopify apps and integrations for merchants who care about what’s under the hood. We’re paying closer attention to our dependency chain than we used to. You probably should be too.

The one that said your annual $1M revenue exemption is now a lifetime $1M exemption. As in: once you’ve made a million total, you pay 15% on everything, forever.

The developer community lost its mind. I read the threads, the hot takes, the LinkedIn outrage. And I kept thinking the same thing: this is a small ask.

The old deal was absurd (in a good way)

Let’s be clear about what we had. Every year, Shopify app developers kept the first $1M in revenue completely free. No rev share. Zero. Then it reset in January and you got another million, free again.

If you were making $2M a year, you were paying 15% on only half your revenue. Every single year. That’s an incredibly generous deal. I don’t think people fully appreciated how unusual it was.

Apple takes 30%. Google takes 30%. Even their small business programs cap at $1M annually and still charge 15% on everything under it. Shopify was handing developers the first million and walking away. Every January, like clockwork.

According to Glen Coates, Shopify’s VP of Product, only “a few hundred” developers out of tens of thousands were actually benefiting from the annual reset. A few hundred. Out of 16,000+ apps. That’s who this change affects.

The developers making $50K a year from their app? Nothing changed. The first $1M is still free — they’ll never hit it. The developers making $200K? Same story. The lifetime cap is so far above them that this policy is invisible.

The people this hurts are the ones who were already doing very well.

I remember the old Shopify

Here’s where it gets personal for me.

I worked at Shopify. I remember when it felt like a startup that genuinely loved its developers. The API was open, the documentation was solid (mostly), the partner program was a real invitation. Build something useful, put it in the app store, and Shopify would stay out of your way.

That era shaped how I think about platforms. It’s why Victoria Garland builds on Shopify. It’s why I still tell clients that the Shopify ecosystem is one of the best places to build an ecommerce business. I believe that.

But I also remember that Shopify went public in 2015. And public companies have shareholders. And shareholders want growth. And growth, eventually, means extracting more value from the ecosystem you built.

This isn’t betrayal. It’s arithmetic.

Every platform follows the same arc. You attract developers with generous terms. You build an ecosystem. You go public. And then, slowly, the terms get less generous. Not because anyone in the building is evil, but because the incentives shifted the day the stock started trading.

I’ve watched this happen at Apple. I’ve watched it happen at Google. Shopify held out longer than most, honestly. The $1M annual exemption lasted years. That’s more patience than most public companies show their developer ecosystems.

The outrage is real but misplaced

I’m not dismissing the frustration. If you’re an app developer who was counting on that annual reset, and now you’re looking at $450K more in rev share over five years, that’s a real number. It changes your margins. It changes your roadmap. Maybe it changes whether you hire that next developer.

But the framing online — that Shopify is killing the developer ecosystem, that this is the end of independent app development on the platform — is wildly out of proportion.

The first million is still free. The rate is 15%, not 30%. Shopify paid out over $1B to app developers. The ecosystem is massive and growing.

What actually happened is that a very good deal became a pretty good deal. And a few hundred developers who had the best deal in the industry now have a deal that’s merely better than most.

That’s the part nobody wants to say out loud.

So is it still worth building on Shopify?

Yes. But with eyes open.

I’m saying this as someone who builds Shopify apps right now at Victoria Garland. We’re in it. JourneyGlow, PriceGlow, CrowdShop, StockGlow. We’re not on the sidelines commenting. We’re writing Liquid and deploying to Gadget and dealing with the same API versioning headaches as everyone else.

It’s still worth it because the merchant base is real. The problems are real. The money is real. And 15% after your first million is still a better deal than most platforms offer from dollar one.

What you can’t do is build on any platform like it owes you something. Shopify doesn’t owe developers a $1M annual gift. Apple doesn’t owe developers a 15% rate. No platform owes its ecosystem permanent generosity.

The deal is: you get access to merchants, distribution, and infrastructure. In exchange, the platform takes a cut. If the cut changes, you adapt. If the platform builds something that competes with your app, you find a new angle. That’s the game.

I remember the small business, entrepreneurship-loving Shopify. I do. And there’s a version of me that misses it.

But the Shopify that exists today, the one with shareholders and quarterly earnings and 16,000 apps, was always where this was heading. The generous era wasn’t the real Shopify. It was the startup phase of a company that was always going to grow up.

The rest of us just have to grow up with it.

Shameless plug: At Victoria Garland, we build Shopify apps and custom integrations for merchants who need things done right. We’ve been in this ecosystem long enough to know where the lines are, and how to build something worth keeping.