The archive.

I've spent much of the last year figuring out how much software you can build with AI.

The answer is: quite a lot.

Projects that once needed a small team and a six-figure budget can now be done by one experienced person, some agents, and considerably less money.

Which creates another problem.

You can now build things faster than you can sensibly check them.

I don't mean checking whether the code works. Agents are actually pretty good at producing things that work.

The dangerous stuff is usually perfectly reasonable.

A requirement says that a user can delete their account. So the agent builds account deletion.

Reasonable.

Except somewhere else the business has said it must retain a particular record for ten years, and that record needs to show which user created it.

Neither requirement is wrong.

Put them together badly, and you've designed a problem that won't appear until somebody asks to be deleted.

That's the bit I've become interested in.

We put the check in the wrong place

Most businesses still organise quality around somebody checking the work afterwards.

Build it, then review it.

Draft the contract, then send it to legal. Prepare the accounts, then audit them.

Write the software, then test it.

That worked reasonably well when making the thing and checking the thing happened at roughly human speed.

AI breaks that assumption. I can multiply output. I haven't multiplied the number of experienced people available to think about whether we should have produced it that way in the first place.

Hiring another reviewer doesn't really solve that. The scarce thing wasn't the reviewer. It was their judgement.

So I've been experimenting with moving some of that judgement to the other side of the work.

Before something gets built, it has to answer a small number of questions.

1. Does this change what records we keep?
2. Does it change how personal data is used?
3. Does it introduce automated decision-making?
4. Does it create a new interface?
5. Does it touch payments?
6. Devices?
7. Credentials or certificates?
8. Can data now leave somewhere it couldn't leave before?

They're not particularly clever questions. That's rather the point.

Ask the same boring questions, every time, at the right moment.

A "yes" doesn't produce another compliance document. It changes the requirement.

Instead of:

Complies with retention requirements.

You get:

Deleting an account must leave the audit record intact for the full retention period.

Now we've got something useful.

A developer can build it. An agent can understand it. A test can prove it. And somebody three years from now doesn't need to understand the whole history of the company to know why it exists.

It has already stopped us doing things

Three recent examples convinced me this was worth pursuing.

The first was an audit log.

The requirement looked fine. Record what changed, when it changed and who changed it. Except we'd described an audit log, not tamper evidence.

An append-only database table with good permissions still ultimately asks somebody to trust the operator of the database. If the record may eventually need to stand as evidence, that's not necessarily enough.

We caught it before four other features started depending on it.

The second was account deletion.

We were building the relationship between a person and an organisation. That relationship would eventually be used by other records to answer a very simple question:

Who did this?

If deleting the person's account also destroys that relationship, we've made a decision about every future record before most of those records even exist.

Caught now, it costs almost nothing. Caught after a few years of data exist, it becomes a migration and a rather unpleasant conversation.

The third was regulatory.

We had correctly documented why a particular organisation was exempt from a network-security requirement in one jurisdiction.

The problem was that we'd allowed that reasoning to travel across the border.

It didn't. The equivalent regulation next door treated the organisation differently.

Nothing was obviously stupid in any of these cases.

Competent people had read the documents. That's what bothered me.

They weren't failures of intelligence.
They were failures of asking the same question at the same point every time.

Some rules (Agents) should say no

This is where I've changed my view of management systems. I've spent years seeing them as things businesses produce to prove they are controlled: policies, registers, evidence folders, audit reports, certificates.

Useful, but mostly behind the work. I'm starting to think the valuable management system sits inside the work. And occasionally it gets to say no.

Some rules can be absolute. A build fails. Some can be checked automatically but need a person to make the decision.

Some genuinely require human review.
And some are still just policies sitting in a folder.

That's fine, provided we tell the truth about which is which. The dangerous version is a spreadsheet containing forty controls which makes them all look equally real.

They aren't. If something is merely written down, say so. If we intend to automate it, give that gap a date. If it requires human judgement, name the person and the point at which the judgement happens. And if the machine can enforce it safely, let the machine enforce it.

This is where Language Capital becomes interesting

I've been writing recently about Language Capital: the accumulated rules, contracts, policies, decisions, procedures and knowledge that businesses already possess.

Most of it has historically been passive.

Humans read it when they need it.

AI changes that.

A retention policy doesn't have to sit in SharePoint waiting for somebody to remember it exists. It can become a constraint on how software is specified.

A security policy can become a build test.

A legal obligation can become a question that must be answered before work starts.

That is much more valuable than simply making the documents searchable.

The language starts to have authority.

And I think that's an important distinction in the rush to automate everything.

We keep asking:

What work can the machine do?

There's another question.

What should the machine be allowed to refuse?

Because we're going to get very good at making things quickly.

I'm increasingly convinced that the businesses which benefit most won't just be the ones with the fastest machines.

They'll be the ones that have worked out where to put the brakes.