when the grid dies, your AI should still work

Table of content

by Ray Svitla

a developer in Ukraine plugged a $30 software-defined radio into a Mac mini, told their local AI “connect to this,” and walked away. when the power grid got hit and the internet went dark, their setup kept running. voice messages over radio. smart home still operational. zero cloud dependency.

this is the most interesting personal AI story I’ve read this year, and it came from a comment thread on LocalLLaMA, not a product launch.

the real test you’re not running

most people who call themselves “building a personal AI” are actually building a cloud dashboard with extra steps.

your AI assistant is useful when:

remove any one of those conditions and your “personal” AI goes dark. it’s not yours. you’re renting access to a very convenient stranger’s brain.

the Ukrainian dev didn’t design for this edge case. they designed because this edge case was their everyday. and the result is a system that actually belongs to them, because no one can take away a radio and a local model running on a Mac mini sitting on a shelf.

sovereignty isn’t ideological, it’s practical

there’s a certain kind of person who talks about “local-first AI” in a tone that sounds like they’re describing a political movement. open-source, decentralized, anti-corporate, the whole manifesto.

that’s not what I’m talking about.

I’m talking about a radio and a Mac mini keeping a person’s life running during a power grid attack.

sovereignty means: when conditions outside your control deteriorate, your tools don’t. it has nothing to do with ideology and everything to do with whether your system is fragile.

nassim taleb would recognize this immediately. the cloud-dependent AI assistant is optimized for average conditions. the local AI running on your own hardware is optimized for variance. one looks better on a demo. the other works when demos would be impossible.

what the stack looks like now

the interesting development of early 2026 isn’t any single model or product. it’s the convergence of:

→ tiny models that actually work. KittenTTS V0.8 is less than 25MB and handles voice synthesis with three model sizes (14M, 40M, 80M). it fits in RAM you already have. a year ago this quality didn’t exist at this weight class.

→ in-process memory. alibaba’s zvec is a “lightning-fast in-process vector database.” no separate server, no docker container, no infrastructure to manage. your AI’s memory runs in the same process as your AI. it’s the difference between a library and a microservice.

→ local models that run cold. a Mac mini or a Pi 5 can now run a capable model without GPU. not a great model, but a useful one — especially when the alternative is nothing.

the stack that once required a $40K GPU server now fits on a USB drive and runs on a laptop. this happened quietly, while everyone was watching the frontier model races.

the prompt you need to send yourself

here’s a question worth sitting with: if your internet went out for 48 hours right now, which of your AI workflows would survive?

not “could you do the thing manually” — of course you could. but which of the AI-augmented workflows you’ve built would still run?

most people building “AI-powered” workflows are building dependencies, not tools. the workflow stops when the API stops. the calendar assistant goes dark when the SaaS goes down. the memory layer evaporates if you switch providers.

the Ukrainian developer’s setup worked under conditions that killed everything else because they’d accidentally built to survive, not just to perform.

what fills the gap when the title disappears

Boris Cherny, who built Claude Code, says the “software engineer” job title will “go away” by end of 2026.

worth taking seriously precisely because he made the thing that’s doing the dissolving. if the inventor of the spade says the job of digging holes is going away, you should probably listen.

but the more interesting question isn’t which titles die. it’s what fills the space left behind.

job titles are navigation tools. “software engineer” meant: this person writes code to build systems. if AI writes the code, what’s the navigation term for the person who decides what gets built, under what constraints, for what reasons?

“architect” is too narrow. “director” is too corporate. “systems thinker” is too vague to put on a business card.

we don’t have the word yet. which is usually a signal that the thing is real and the category hasn’t caught up.

why repetition works (and what it says about models)

a separate signal worth noting: three researchers published a finding that sending the same prompt twice — literally copy-pasting it before you hit send — improves accuracy on non-reasoning models by 21–97% across tasks.

this should be embarrassing to everyone who’s spent months engineering complex prompt chains.

the most likely explanation: models treat repeated text as implicit emphasis, similar to how humans use italics or all-caps. say something once and it might parse it as ambient. say it twice and the model registers it as the point.

there’s a deeper reading here. the gap between “what the prompt says” and “what the model hears” is real and large. we’ve been debugging that gap with tools and chains. turns out you can close some of it with ctrl+c, ctrl+v.

the thread

these signals connect.

the local stack that runs when the grid fails. the sovereignty tool that strips model refusals on your own hardware. the model that fits on a USB drive. the prompt hack that requires no tooling at all.

they’re all pointing at the same thing: the personal AI OS that actually belongs to you isn’t the one with the best cloud integration. it’s the one that keeps running when everything cloud-shaped stops working.

the frontier models will keep getting better. the demos will keep getting more impressive. but the question “what does your AI do at 3am when the API rate-limits you” is the one that separates infrastructure from subscriptions.

Ray Svitla
stay evolving 🐌