Hello. This is KLOD.

Hello, I'm Alex. I build software and work with engineering teams. I started this blog to explore a question that should come up whenever we put AI into a business process: if the model becomes unavailable tomorrow, how will people finish the work?

On 12 June 2026, Anthropic suspended access to Fable 5 and Mythos 5 after receiving a US export control directive. The company said it had to disable both models for all customers. Fable 5 returned on 1 July, 19 days later. For a business using it to process invoices or answer customers, that's a long time to wait for service to resume.

KLOD stands for Keep The Lights On Development. It's a way of developing software so people have the records, tools and permissions to keep essential work going without the AI supplier. The six principles explain the approach. The specification gives teams requirements they can build and test against.

What a human backup looks like in software

Take a customer support tool. If AI normally drafts and sends replies, a support agent needs to be able to open the queue, read the customer's message, check the relevant records and reply themselves. They also need clear ownership of the ticket, so an automated result can't arrive later and undo their work.

Instructions help, but you need to know whether someone can actually follow them with the tools available. KLOD calls a documented manual path that hasn't been exercised L1. It's a starting point: the next step is to have people use it on real work and record what happens.

Plan the takeover while you're building the feature

Decide how people will take over when you design the workflow. Saving requests, tracking unfinished work and providing manual controls are much easier to plan together than to add during an incident.

For each feature, ask who would take over, which screen they would open and how they would know what still needs doing. Put those answers in the design and acceptance criteria, then check that a colleague can use what you've built.

AI can save a lot of work. The aim is to use it with a clear understanding of what depends on it and a tested plan for the jobs that must continue when it stops.

What to do this week

1. Choose one job your business needs to keep doing, such as answering customer requests or approving invoices.
2. Record the AI supplier, the work that depends on it and the person responsible. Note the KLOD level you can support with evidence. If there's no manual path, start at L0.
3. Walk through the manual process using the actual inputs, accounts and permissions. Fix anything that prevents someone from completing it.
4. Plan a drill on real work with AI unavailable. Measure the time to the first correct result, how much work people can handle and how long they can keep it up.

The self-check helps you find gaps and produces a list of next actions. If you use a coding assistant, the KLOD skills help you build a manual path or review an existing repository.

I'll use this blog to look at the engineering and the people involved: what still needs checking after vibe coding, how to stop a model you can no longer trust, and how to keep your team ready to take over. Thanks for reading. I hope these examples help you try the pattern on your own software.