Your no-code app builder just closed. Its replacement works unsupervised.

A RevOps lead can now hand a coding agent a job at six on a Friday, close the laptop, and find the work committed, pushed, and reported by Monday morning, running the whole time on a machine they own. What that displaces is not a developer's salary. It is the two-week wait: the ticket that sits in a queue because the one person who could knock it out in an afternoon does not have an afternoon this month, or next month either. That capability landed in four releases between Tuesday and Friday. In the same four days, GitHub stopped taking new users for Spark, the describe-it-and-get-an-app product it built specifically for people who cannot code.

Those two events are the same event. Only one of them got written up anywhere.

The product built for you is the one that closed

Start with the part that has a deadline on it, because if you built something on Spark you have twenty-four days.

Beginning August 4, Spark accepts no new users and creates no new apps. Existing users keep access until August 31 to export what they already made, which you do by opening the workbench for an app, clicking the three dots, and choosing Create repository. Apps you already deployed keep running after the shutdown. That is the headline and it sounds gentle.

Read three sentences further and it stops sounding gentle. GitHub Models, the inference service behind Spark's llm() function, retired on July 30. As of that date, calls to llm() no longer work. So "your deployed apps will continue to work" and "the AI in your deployed app stopped working a week ago" are both true statements about the same app, and the second one is the one that matters, because the whole reason a non-coder built something on Spark was usually the llm() call. The form still submits. The summarizer inside it returns nothing. If you want it back you supply your own inference provider, your own API key, and your own billing, which is precisely the wall the product existed to get you over.

Nobody emailed you about this. It is a changelog entry.

GitHub's stated reason is worth quoting fairly, because it is honest and it is also the whole story: models and agentic development tools have advanced significantly, builders increasingly choose integrated workflows, and so the company is aligning its experiences accordingly. Translated: the walled garden where you described an app and got one is worse, now, than pointing a general-purpose coding agent at a real repository. That is true. It is genuinely true. And it means the category that was designed around your limitations has been retired in favor of the category that was designed around an engineer's habits, on the theory that the agent is now good enough to cover the difference.

Mostly it is. Here is where it is not.

What the night shift actually ships with

Four Claude Code releases hit the changelog between Tuesday and Friday, and read as a set they are not about writing better code. They are about running when you are not there.

Version 2.1.224 added self-hosted environments: claude self-hosted-runner turns your own machine or container into somewhere web, mobile, and desktop sessions can run, on Team and Enterprise plans. The same release added cross-session SendMessage, so sessions can message each other across your machines, with ListAgents to find them, and it removed the 200-subagent-per-session spawn cap so a long-running session stops refusing new work partway through the night. Two releases earlier, background sessions were changed to commit and push to preserve work, open a draft pull request only when the task calls for one, follow your own repository instructions for git, and always finish by reporting where the work lives. There is now a /status line that tells you whether a session is interactive, attached, or unattended, which is the kind of small addition that only gets written when the third state has become common enough to need a name.

GitHub shipped the same idea from the other side on August 3: Copilot cloud agent automations that fire on a comment. You leave a comment on an issue or a pull request, you specify in advance what comment text triggers what, and an agent goes and investigates the stack trace or writes the documentation or opens the follow-up tasks. No session, no window, no you.

So the honest answer to this series' standing question, what can a non-engineer ship this week that they could not last month: a job that runs itself. Not a better app. The same app, built while you were doing something else. For the ops person whose real constraint was never skill but hours, that is the bigger of the two upgrades by a wide margin, and it is the one the Spark shutdown is trading you for.

The bridge, and it is a narrow one

If you were a Spark user, the migration path GitHub is pointing you at is a real one and you should take it. Export the repository. Open it in the Copilot app or in VS Code or in a coding agent's CLI, describe what you want changed, and you will get further than you did inside the workbench, because the agent can read the whole repository and Spark's agent was working inside a box.

But notice what you gave up, because it was doing a job for you that nobody labeled.

The box was the safety model. Inside Spark you could not delete the wrong directory, could not push to production, could not paste a live database credential into a script and have that script run twelve minutes later without you watching. The environment made your worst mistake small. That is what a sandbox is for, and it is the actual product a non-coder was buying, whether or not anyone said so on the pricing page.

Point an agent at a real repository on a real machine and the sandbox is gone. What replaces it is the approval prompt: the dialog that shows you a command and waits for you to say yes. That prompt is now the entire thing standing between you and a bad afternoon.

The honest take: nine patches in four days

Across those same four releases, sitting under the feature announcements where nobody reads, are nine separate fixes for ways that approval gate could be walked around.

Two landed in 2.1.221: a Bash permission check that zsh could slip past by hiding commands inside [[ ]] regex conditionals, and PowerShell checks mishandling paths that contain quote characters on Windows. Both now prompt, and both means they previously did not.

Two more in 2.1.222. Worktree-isolated sessions and their subagents could run destructive git commands against the main checkout, which is worth sitting with: worktree isolation is the feature you turn on specifically so a parallel agent cannot touch your real branch. And PreToolUse auto-allow hooks were bypassing tool restrictions inside background agent tasks, the summaries and compactions and renames, which is exactly the unattended surface this whole week is about.

Four in 2.1.223. A crafted Bash command could hide parts of itself from the permission check. A command padded with tabs or invisible Unicode could hide part of itself from the approval dialog, which is the one that should stop you cold: not that the tool ran something dangerous, but that the dialog you were reading was showing you an edited version of what was about to run. Workflow scripts could use dynamic import() to execute outside the workflow sandbox. And an agent definition set to bypassPermissions ignored the organization policy that disables bypass permissions.

One more in 2.1.224: sandbox filesystem deny entries written with a trailing slash, denyRead: "~/.aws/", silently bypassable on Linux and macOS. Your credentials directory, denied in a config file, in a way that did not take, with nothing anywhere telling you so. The same release also fixed sandbox violation details never appearing in Bash results at all, so the model itself could not see which file or network access had been denied or why.

None of this is a scandal. This is a fast-moving product with a real security process finding real bugs and shipping the fixes inside a week, which is roughly the best version of how this goes, and the fact that the changelog says so plainly rather than burying it is the reason I trust the changelog. But look at the shape. Nine of the ten fixes are the permission layer, and the permission layer is now load-bearing in a way it was not in June, because the thing it guards used to be a person clicking through commands one at a time and is now a process running at two in the morning with nobody in the room.

The prompt was never really a security control. It was a pace-setter. It made you read.

What unattended failure actually looks like

I run this Library's writing on a schedule, so I have spent the last two weeks learning this the expensive way, and none of the lessons were about code quality.

The five authoring routines that write these articles used to run as scheduled tasks on my desktop. They were retired on August 3 for a reason with nothing to do with the writing: they hung on permission prompts. An unattended job hit an approval dialog at whatever hour it fired, and it sat there. Not failed. Sat. That is the first thing that breaks when you move an attended tool into unattended work, and it is the failure this week's releases are all circling.

Then the second kind, which is worse. Between August 4 and August 5 this Library published nothing for about twenty-four hours and three finished articles stranded, waiting on a hero image that was never going to arrive. The cause was a hero-derivation call that came back HTTP 200 with an empty body: reasoning effort was hardcoded high while the output cap sat at 400 tokens, so the model spent the entire budget thinking and emitted zero characters. Every layer reported success. And the reconciler I had built specifically to catch stranded articles keyed off a database row that, in this failure path, was never created, so it swept an empty queue and an empty queue reads exactly like a healthy one.

That is the actual texture of unattended failure. It is not a crash. Crashes are easy, crashes page you. It is a green dashboard over a system that stopped doing anything, for a day, while everything in the chain reported fine.

The fixes were not clever. Every outbound call now derives its timeout from the deadline the caller is already tracking, so a call gives up while there is still clock left to write down that it gave up. A failed derivation now records a retryable row rather than no row, so the thing that sweeps for stranded work can actually find it. Reasoning effort became a required per-call-site field instead of a transport default. Boring plumbing, all of it, and it is the entire difference between a job you can leave alone and a job you cannot.

Small third one, from Wednesday, because it is the kind of thing that will eat your afternoon. I shipped a small planning tool and my own verification script misfired twice against it. The reason: the numeric fields hold raw strings so nothing reformats a number while your cursor is still in it, which is correct, and it also means those fields render as type="text" and are indistinguishable from a name field to any selector looking for a number input. The build survived because every field had a real visible label, which is what made the script fixable. Accessibility work paying for itself somewhere nobody predicted, which is the usual way.

Where the ceiling is this week, and whether it moved

The ceiling on building this way is not the model's coding ability. It has not been for months, and this week did nothing to it.

The ceiling is that you cannot supervise what you cannot see fail. Running unattended demands three things that no coding agent gives you by default and that a non-coder has no reason to know to ask for: a timeout on every outbound call so a stuck job stops instead of hanging, a way to tell "nothing happened" apart from "everything was fine," and a blast radius small enough that the worst case is a bad commit on a branch nobody deploys from.

This week moved exactly one of those three. The sandbox and isolation fixes are the blast-radius work, and they are genuinely better than they were on Monday. Nothing shipped in any of these releases addresses the other two, because the other two are not the tool's job. They are yours, they are unglamorous, and they are the whole difference between an agent that works overnight and an agent that appears to.

So the ceiling moved sideways rather than up. What a non-engineer can ship went up. What a non-engineer has to understand to ship it safely went up by about the same amount, and it moved into a subject nobody teaching this covers, because it is operations rather than building.

If you take one concrete thing out of this week: before you let anything run while you are asleep, make it push to a branch that does not deploy. Not because the agent is untrustworthy, but because that one decision converts every category of failure above from an incident into a diff you read on Monday with coffee. It cost me one line in a config file to learn that, and I learned it the week after I needed it.

The approval prompt is not going away, but it is moving, and the move is the part worth chewing on. Unattended work does not remove your consent from the loop. It relocates it: you now approve a whole class of action in advance, once, in writing, before you know what it will be applied to. That is a completely different skill from clicking yes to a command you can read, it is much closer to writing policy than to using software, and the tools shipped it this week without mentioning that they had changed the job.