By Andy Boura🪶 A note on how this was written. This article was co-authored with the support of Claude, Anthropic's AI assistant. It draws on the principles and documentation developed while building and running the real-world working examples it describes.
We've all heard it said: AI makes developers ten times faster. It's half true. AI has made writing software dramatically cheaper. It hasn't made running it any cheaper: the patching, the configuration, the certificates, the evidence that it is secure and handles people's data properly. Unless we point the same tools at that half of the job, we simply ship more software and accumulate risk faster.
Over the last few weeks I've been building a small platform with an AI coding agent (Claude Code) to test the alternative. I call it Governed NoOps: the agent does the routine running and keeps the compliance evidence current, and people keep the decisions where a second pair of eyes matters. This is the first of five parts. Here I set out the problem, the idea and the set-up; parts 2 to 4 take the three principles in turn, and part 5 brings them together.
If you build on a hosted AI app builder, the platform carries part of this for you: the servers, the certificates, the patching of its own runtime. It doesn't carry what you build on it. The packages your app pulls in, how it controls access to its data, and who can push a change live stay yours. In 2025 a researcher found 170 of 1,645 apps built on Lovable that let anyone read or write their data, because access rules had been left out; Lovable disputed the vulnerability on the grounds that each customer is responsible for their own app's data. The principles below apply whoever hosts you. I self-host on AWS because there every layer is mine to see and to govern. The FCA says the same to regulated firms in its October 2026 review of AI in financial services: they "can outsource AI services, but remain responsible for them".
Building got cheap, running didn't
Every application an AI assistant helps you ship comes with a long tail: dependencies that need patching, configuration that drifts, a privacy notice that should match what is actually logged, audit evidence that was assembled once and never refreshed. None of that got cheaper.
At the same time the threat has moved the other way. Attackers, increasingly with AI help of their own, turn a published vulnerability into an exploit faster than ever, so any vulnerable software is more likely to be found and used, and sooner.
Risk leaders experience this as "more software, same control team". Engineers experience it as toil. But the asymmetry is a choice: the same tools that write the code can maintain and evidence it.
Introducing Governed NoOps
Governed NoOps: the people who own an application hold only its content and its decisions. Hosting, security, upkeep and compliance evidence are provided, enforced and kept current by the platform and its agents.
NoOps isn't new; Forrester's Mike Gualtieri coined it in 2011. It describes the outcome for the application owner, not a claim that no operations happen. In the same way that serverless means you don't have to look after the servers, rather than that there are none, the work still happens. It's done by code and agents, on rules written in advance.
Governed is the part that matters for risk. It means two things: every automated action follows a written policy, and any action that could do serious harm needs a second, independent actor. Plain NoOps outsources operations and hopes; traditional governance has people doing the checks by hand, periodically. This sits in between.
The set-up at a glance
It helps to see the whole thing before the principles. All the work happens in code. I work with Claude Code, either in VS Code or in the browser, and every change it makes goes to GitHub as a pull request. GitHub holds one repository for the platform and one for each site's content, runs the checks, and does the deploying. No agent deploys from a laptop or a chat session: deploys reach AWS only through GitHub Actions, signing in with short-lived credentials issued for each run.
The AWS account has three layers. The platform (hosting, certificates, DNS, security headers and mail) is defined in code and deployed by the pipeline. The sites are the content each site's repository uploads. Around both sit the guard rails: the roles and permission boundary that fence in what any deploy can do, the audit trail and the locked backups. Only I change those, by hand, so the pipeline can't alter the core restrictions.
What the rest of the series covers
- The paved road (part 2): one platform, defined in code, that every site shares; the path from a change to production; and a patching policy whose defaults come with their reasons.
- Compliance that can't go stale (part 3): each fact written once, next to the thing it describes, with the evidence generated from it and checked on every change.
- Manage the agent like a team member (part 4): what the agent may do alone, what it brings to me, and the second, independent actor on anything that could change the rules.
- Bringing it together (part 5): the whole approach in one place, its limits, and a companion skill so your own agent can work this way.