Law Zero and How To Get Around It

on July 30, 2026

Let’s reiterate, from an earlier post, Whitaker’s Laws of Agentic AI Coding.[1]

1. Never give it anything you wouldn’t give a junior developer.
2. Prompt in easily verifiable chunks.
3. Trust (maybe) but verify. Independently.
4. For the love of Knuth, do not give it commit privileges, let alone deployment rights, to anything customer-facing.

There is, actually, a Law 0, which is perhaps the most important of the lot.

0. Don’t.

Before you all throw your hands up in either horror or delight (should your views on AI fall into one of the two extreme buckets), Law 0 comes with a preamble, specifically “If that all sounds like not the fabulous labour saving device it was cracked up to be…”

Let’s expand on that.

If you think Agentic AI coding is the road to zero- or minimal-effort code in vast quantities? You are, as previously discussed in various blogs here, in for a world of hurt. Law 0 most definitely applies. What you get may do what you want, but you will have no clue what exactly it does, or how it does it, or what to do if the AI apocalypse hits and you can’t afford the tokens to fix it.[2] You don’t get brilliant, secure, pretty, apps for free. Or even just for the cost of the tokens.

It bears repeating: if you get all starry-eyed at the prospect of firing your expensive developers and typing “make me an app to do X’ at your Claude Code[3] prompt, you are in for a very rude awakening down the line. This is very definitely a false economy. Again, see Law 0.

And yes, we are banging on about this a lot. This author’s original post focussed more on the dramatic screw-ups, and we’d be remiss not to mention the latest OpenAI security breach, in which a ‘rogue AI’ hacked a competitor while undergoing a test because it ‘thought’ that it could get the test answers from there. But let’s make it very clear, while stories like that are grist to the mill of the “AI Is Dangerous” lobby, the real issue is a people issue. The AI was put in a position to be able to do that.

Vibe coding an app is all very well, and the end result can and often will be super-shiny and a world of “Look what I did!”. But if you don’t understand the pitfalls, you are in a world of trouble. Contemporary analysis suggests that the average vibe-coded app is probably compromised in multiple ways, because the person guiding the agentic coding doesn’t understand how complex a minefield application security is. And neither did the AI. Here’s the top few, courtesy of an excellent piece by Evil Martians.

Exposing access keys/tokens/passwords in the code. So your code needs access to an API (most apps, let’s face it, involve correlating the results of several different APIs and services and putting them somewhere). Where are the keys? Do you know? If I browse the source of your app will I find them? Did you even know your vibe-coded app had any?
Weak authentication and security holes. There are (pretty much) two fundamental tenets of cryptography and security:
- The first is “don’t roll your own encryption code”, and if you don’t understand why that’s a bad idea, stop right now. People better than you have tried and failed spectacularly. There are accepted (and evolving) guidelines for a damn good reason, both for encryption algorithms and for authentication processes.
- Second? assume your client is evil and untrustworthy. No. More than that. Assume they are going to try and hack your system, assume that any input they send could be maliciously crafted. There are bad people out there, and only one of them has to succeed. Your mission has to be at least to make it hard enough they give up and look elsewhere.
Insecure dependecies. “Ooo, look, a cool library I just found online that does exactly what I (or the AI) wants.” If you’re lucky, it’s secure, because a real person has looked at the appsec issues inherent in it already. If you’re not (and if you’ve just prompted your agentic friend at the macro level, you can’t know), you’ve just bolted a fresh collection of security holes onto your app.

You absolutely cannot assume, certainly not yet and probably never, that an agentic AI with no supervision or guidance will build you an app that doesn’t have security holes in it. And if you’re planning on making money out of the results, those holes are where your money is going to leak, then flood out of, whether as lost income, stolen data or worse, a bad actor stealing your AWS credentials and running you up a six-figure bill.

So what, you ask, should I do instead?

Simple. Keep those senior devs. If you do this right, you are about to make them more productive. (Oh, while you’re at it: keep a few juniors, too. Senior devs don’t happen by magic. But that’s another post altogther.[4]). There is a gain, in fact a decently big one, to be got from agentic development, if you do it right. Obviously, the first step is to follow Laws 1 through 4, which are there for your own protection, and to preserve code authority. But there are some great tools out there which leverage what’s in your senior devs’ heads: the thing you pay them for.

Contrary to what you might think, what you pay them for isn’t the simple act of typing at an IDE or editor. You pay your senior devs for the hard-won knowledge they gained in the transition from being a junior dev, for the ability to look at a piece of code and go “that’s not right[5]”, to look at a proposed implementation and pick holes in it, and perhaps even more importantly, to look at multiple potential solutions and pick the one that fits best in your existing world. Very little of what you pay them for is typing. To quote Larry Wall, the father of Perl, the three programmer virtues, which I’m going to summarise and re-draft a little for the brave new AI world, are:

Laziness: not doing things you can get the computer to do for you better
Impatience: making stuff the computer does happen faster and better.
Hubris: wanting to write good (secure, maintainable, reliable, performant, attractive) software that other people want to use.

Laziness is why we become programmers. Impatience is why we stick at it. Hubris (proper hubris, not just bouncing up and down because it looks cool) is what turns us into senior programmers.

Laziness makes agentic coding tempting. Impatience makes the results useable. Hubris stops it producing insecure, shiny slop.

Next post, I’ll look at some of the tools that can potentially help your senior developers achieve this better and faster while interacting with your AI coding agent and still being productive. I’m certainly going to show you how to circumvent Law 0, and pretty much going to demonstrate how they can build a framework around Laws 1, 2 and 3 that preserves code authority while making them more productive than in the years BC[6].

AI Usage Statement

No plastic pals who are fun to be with were used in the writing of this article. Google was used to find a couple of links, but they were human-vetted.

Call this hubris. I don’t mind. (You’ll see why this note is funny further down the post.)
Call us. If the AI apocalypse has hit, our rates will seem very reasonable.
Other agentic coding tools are available.
Watch this space.
“Before Claude” (or Codex, or Copilot[3]).