Fifteen years of bootstrapping infrastructure for community sovereignty, three months of sprinting with AI as a partner, and what I learned about working at 50× speed with a team I trust at my back.
There is a phrase going around — vibe coding — that I think is a very accurate description of this moment in history. The idea is that you sit down with an AI and let it carry you. You feel out the shape of what you want and the model fills it in. The word vibe implies drifting, letting a current take you in whatever direction you're gesturing at. This really is how a lot of people are working with AI right now! The reason it should worry us is that the work AI is now capable of doing — moving money, deleting data, writing and deploying code, taking actions in the world — has consequences that drifting cannot recover from.
The last three months of my life have been an attempt to work the opposite way. The right word for the work has been managing. The AI is an extraordinarily fast subordinate, the most capable one I have ever worked with. It writes code at speeds no human can match. It also produces wrong code, plausible code, code that doesn't quite mean what it looks like it means — and at machine speed. My job is to direct the work, review what comes back, and catch the mistakes before they compound. Without a manager who understands the technical territory deeply enough to spot what is wrong, that fast subordinate becomes a fast generator of damage. At AI's current capability level, where the work touches money and data and production infrastructure, the damage is no longer hypothetical.
This is partly a piece about technology — what Safebox is, why Safebots needed to exist, how Grokers and Code came out of a single breakthrough. Mostly it is about the longer arc: fifteen years of building infrastructure for community sovereignty, almost entirely without venture capital, mostly without a co-founder, and now a three-month sprint where the work I had been doing for years finally became the work I could ship daily.
If you are an ordinary reader curious about what's happening underneath the AI gold rush, this is for you. If you are an investor trying to figure out whether the founder is the real thing, that is also for you. The two questions are closer than they appear.
Before any of it, though, there is a thing worth saying about where the appetite for this comes from, because it explains the shape of everything after.
When I was seven I played in Carnegie Hall, and joined Juilliard's Pre-College on scholarship. I don't think a child that age learns discipline from that, exactly. What it does is move the ceiling. Most people build their sense of what is possible out of the average of what they see around them, and that average quietly becomes a limit they never test. Mine got set somewhere else, early, before I was old enough to install the usual governor that tells you things like this aren't for people like you. That missing governor is the engine behind fifteen years of starting things most people would not have started. It is also, in full honesty, the thing I have spent those same fifteen years learning to manage — because when no attempt feels out of bounds, everything stays open at once, and the piano taught the opposite lesson too: that mastery comes from narrowing, from ten thousand hours on one instrument. A lot of the real work has been remembering how to choose the instrument.
I started building what would become the Qbix platform in 2011. The idea, even then, was that the internet had taken a wrong turn. The hope of the early web had been a federation of people running their own servers, owning their own data, gathering in communities they themselves governed. What we got instead was a handful of platforms strip-mining attention and behavior, with users as the product and community organizers as unpaid janitors.
I wanted to build the substrate for the other version. Not a single application — a platform. Open source, self-hostable, plugin-based, with access control deep in the bones rather than bolted on at the API. Something a city block, a conference, a political campaign, a religious congregation could deploy and own.
Underneath the platform was an older instinct, and it is the one that turned out to matter most. For as long as I have been building, I have refused one trade that almost everyone treats as fixed: the idea that you can protect people's privacy or you can hold power accountable, but not both at once. I designed a model for consent and disclosure on the opposite premise — activity recorded but encrypted, openable only when a real dispute and the right parties' keys bring the relevant slice into the light, and nothing more. I sketched a neighborhood camera system the same way: footage encrypted on the device, decryptable only for specific cameras and specific minutes, only against a logged authorization with hard limits and a record of who watched and why. The boundary lives in the structure, not in a policy document nobody outside the company can audit — scoped, logged, and checkable by the people it affects. Safebox, years later, is that same instinct pointed at AI.
The piece of that substrate I am proudest of is called Streams. On the surface it looks like a feature: a way to model anything in your application as a named, addressable, access-controlled object — a chat, a calendar event, a task, a user profile, a document. Underneath it is a graph database that runs on plain MySQL or Postgres, with per-row policy evaluation, message ordering, change notifications, and federation between independent servers. It is the access-control layer for everything we build on top.
Streams has been running in production for over a decade. The Groups app, which I built with a team of developers in Ukraine, was downloaded by more than seven million people across a hundred-plus countries. When the war started, some of those developers left and moved on to other things, and I personally rewrote the app from scratch — Objective-C, Swift, Xcode, Cordova — while still running everything else. Along the way I had to invent a few things to make the architecture work, including a way to run untrusted code inside pristine iframe environments. That pattern carried over directly into Safebox years later. The substrate kept getting sharper, even when the team around it had to shift.
Alongside Qbix grew Intercoin, the smart contract side of the work. Communities need money that circulates inside them, and rules they can rely on without having to trust the people running the rules. So I designed a suite of contracts and worked over years with Artem Subbotin to implement them in Solidity: community-issued currencies, universal basic income, recurring membership fees, contests, payroll, auctions for price discovery — all with rules enforced on-chain rather than in some company's terms-of-service document. They are now deployed across eight EVM-compatible mainnets, audited, in use.
And there is the peer-to-peer layer that Liubomyr Bondarchuk has been building for the better part of a decade — videoconferencing, livestreaming, decentralized signaling — running inside Qbix as plugins. Multi-party video calls running entirely peer-to-peer, with no central media server, at latency and quality that ordinary video products charge enterprise prices for. As I am writing this, we have a week to prepare a live Safebox demo on Robert Scoble's podcast. We are building the parachute on the way down. Most weeks of a real startup feel like this from the inside.
I had been building this for fifteen years. Most of it open source. Most of it without funding. The team has been with me through all of it: Andrey Tepaykin, who has worked on the Qbix platform for over a decade and knows the codebase more deeply than anyone except me; Artem on the contracts; Liubomyr on the peer-to-peer layer. Three Ukrainians, working with me remotely, through the war, through everything.
What we had at the end of 2025, when this story really starts, was a fully battle-tested infrastructure stack waiting for the moment its assumptions stopped sounding crazy.
The substrate had been waiting for fifteen years. In February 2026, the wait ended.Part Two
In February 2026, Peter Steinberger — a serial entrepreneur with one previous exit — was hired by OpenAI for an undisclosed amount of money. What OpenAI had bought was not a company. It was a side project he had built in about a hundred days, originally called Clawdbot, later renamed OpenClaw after a trademark dispute with Anthropic. It was a small program that let you run a personal AI agent on your own laptop, plugged into your messages, your calendar, your files. It went viral. By the time OpenAI hired him, it had over 180,000 GitHub stars and was being used inside enterprises that had never authorized it.
It also had the most embarrassing security profile of any tool that had ever gone enterprise-viral. API keys stored in plaintext. An unauthenticated WebSocket on every running instance, leaking Anthropic keys, Slack tokens, Telegram bots, to anyone who knew where to look. A CVE assigned. Thousands of instances exposed on Shodan within hours of the scan that found them.
What I saw in the OpenClaw story was a trojan horse spreading on everyone's computers — a viral tool hoovering all those credentials into plaintext files on machines all over the world, installing itself inside enterprises before anyone in those enterprises had authorized it. And what I realized was that the industry was about to walk straight into another fiasco like Web2 and Web3, with bigger consequences. Somebody was going to have to build the structural rescue, and they were going to have to build it in public, under deadline, and probably badly. I had been building the proper version of it for fifteen years already — for sovereignty reasons that turned out to apply directly to the AI problem. Open-source platform with policy-enforcing graph database. Cryptographic identity. Decentralized storage. Smart contracts for operator alignment. Hardware-attested execution. None of these were new ideas in my world; they had been the design constraints from day one. (I have written down the full version of why this matters here, and I'll come back to it later in this piece.)
Steinberger's bidding war was about distribution and narrative — the 180,000 GitHub stars, the viral moment, the fact that enterprises had OpenClaw installed before they had authorized it. My path doesn't look anything like that and won't. But the structural problem his project surfaced — that the AI labs cannot sell to enterprises until somebody gives Chief Security Officers a real attestation layer — was exactly the gap my substrate had been preparing to fill the whole time.
I put my head down. The sprint started.
Part ThreeFrom mid-February to mid-May 2026, working many hours every day, alongside my team running our other agency work — and with Claude as my primary execution partner — I shipped four interlocking systems. Each one is a Qbix plugin. Each one assumes the others exist. Together they answer a question the industry is asking but has not yet answered: how do you let an AI act on your data without trusting the place where the AI runs?
git push becomes the projection to human review. No merge primitive, no resync, no chaos.These aren't aspirational slide deck products anymore. The code is on GitHub, with very robust documentation. We are beginning to test them in production now. Patents on several of these technologies are pending. And I also published a slate of academic papers describing the underlying theory on arXiv.
There are also three more pieces that the stack depends on, and that I have been building in parallel with everything else. SafeCloud is the decentralized encrypted storage layer where your data is sharded, encrypted, and held by independent operators who never see plaintext. The OpenClaiming Protocol is the cryptographic backbone underneath everything else — a canonical signed-claim format that works in JavaScript, PHP, and Solidity, with EIP-712 compatibility so the same claim can be verified on-chain. And the Groups app, with its Secure Enclave keys, App Clips, and contact-avatar Safari extension, was the proving ground for the cryptographic identity model that everything else now reuses. We need all this because the alternative — third-party custodianship of identity, communications, and money — is under sustained attack from governments hostile to end-to-end encryption and corporations that scan content before it leaves your device. The question of how to balance privacy and accountability is real, and the answer is not handing every plaintext to a trusted intermediary.
Each of these pieces was its own hill to climb, with weeks of work and some of them with months of false starts. The management never let up.
Part FourSomewhere in the middle of the sprint, I had a conversation with Claude that I now think of as the inflection point. I had been treating Safebox as the thing that runs workflows on user data. Code, I had been assuming, was different — too exploratory, too creative, too messy to fit into the workflow frame.
Claude initially agreed. I went and asked a second instance of Claude in another window, then came back with the opposite answer. We argued for about an hour. By the end of that argument we had arrived at something neither of us had started with: code change is a workflow. You clone a repo, you fork a workspace, you make a change, you test it, you push a branch, you ask for review. That is a series of steps with inputs, outputs, governance, and audit. That is exactly what Safebox does to anything you point it at.
And once you see that, you see that the workspace primitive can carry source code as cleanly as it carries user data. A ZFS dataset is a workspace. A git branch is a workspace. A team of agents working on the same upstream is just multiple workspaces forked from the same base. There is no merge, because workspaces cascade forward — new baselines are new clones, not resyncs. Parallel teams don't contend because each safebox is independent.
I called the result Code — the Safebox plugin for software development, and the tool I used to ship the rest of the stack. The stack ate itself, in the best possible sense.
Code change is a workflow. The substrate that runs workflows on data runs workflows on code, with the same governance, the same audit, the same machinery. — The architectural insight that made the last three weeks possiblePart Five
A few weeks into the sprint, I started writing the theory down. I have been carrying around mathematical intuitions for years that never had time to become papers. With Claude as a writing partner I could finally externalize them: Probabilistic Language Tries on a unified framework for compression and decision policies; LAWS on certifiable cached fast-paths inside neural networks; the Magarshak Machine / SPACER framework on distributed economic consensus; Intercloud on chilling-effect cross-domain state; the KV Sequential Compression paper on attention caching.
arXiv requires endorsement from a known researcher in your category before you can submit your first paper. I emailed my former professor at NYU Courant, Michael Overton, who I had studied numerical analysis under during my master's, and asked if he would endorse me. He wrote back the same day saying it was done.
My affiliation on the papers is IE University NY College, where I have been teaching AI to business masters students. An arXiv endorsement from a Courant professor, a faculty appointment at a recognized institution, and a coherent set of papers that cite each other in dependency order — those are the three things a researcher at a frontier lab actually checks before agreeing to read your paper. I have all three.
Five arXiv papers. Seven provisional patents filed. A working stack. Customers waiting. The papers cite each other in dependency order, which makes them legible to researchers at frontier labs who are deciding whether to take a meeting. The patents anchor the company's IP position. The stack installs cleanly and the customers are real. All of that happened in the same three months as the engineering, because managing the work meant managing every part of it.
Part SixI have heard people describe working with AI as feeling like a 10× developer. That is the wrong number. With AI as a serious partner, on work you already deeply understand, on a substrate you built yourself and can therefore evaluate the model's output against in real time, the multiplier is closer to 50×. Maybe higher on the best days.
But I want to be careful, because the multiplier only applies under specific conditions, and those conditions are easy to miss if you're reading along excitedly:
You have to know the answer before you ask. Not the full answer — that's what the model is for — but the shape of it. The constraints. The edge cases. The places where a wrong answer would compound. The model is excellent at producing plausible code, less reliable at producing correct code. Without a manager who knows the territory deeply enough to spot a wrong answer at a glance, you accumulate plausible-but-wrong code at machine speed.
You have to argue. When Claude says something I disagree with, I push back. When Claude says something I agree with but I'm not sure why, I ask why. Sometimes I go ask a second instance in another window and bring its answer back. The breakthrough about Code being a workflow came out of one of those arguments.
The substrate has to be yours. When the model proposes a change to my code, I can see in five seconds whether it makes sense, because the code is mine. I wrote it or I architected it. When the model proposes a change to code I don't understand, I have to verify, and verification is slow. The multiplier evaporates.
The model forgets. Constantly. Every long conversation gets compacted, every new session starts from nothing. I have spent months building up workflows for handing context to fresh model instances — uploading transcripts, maintaining living architecture documents, asking the model to read past conversations before starting work. None of that labor shows up in the demos other people see, but it is most of what makes a long project with AI possible.
The model is confident when wrong. It will sometimes invent a function that doesn't exist, a database column that isn't there, an API endpoint it imagined. The 50× multiplier turns into a 50× bug generator if you don't have the muscle to spot these in real time.
The model has no taste for restraint. Left alone, it will add features, log every variable, wrap every operation in defensive checks. Managing means saying no a lot. That's not the architecture. Drop it. Simpler.
The honest summary: Claude is the best development partner I have ever worked with, and one that needs constant correction, constant context, and constant pushback to stay useful. The phrase vibe coding describes letting all of that drift. Managing describes catching it.
There is a structural problem in the AI buildout that nobody has solved. The labs are racing to put their models inside enterprises, but the enterprises cannot sign off on the deployments because there is no attestation layer. How do you let an AI act on your data without the people running the AI seeing your data? The labs' current answer is some version of "trust us." That answer does not survive a Chief Security Officer's review.
Safebox is the structural answer to all of this. The AI runs inside a sealed hardware environment whose contents you can cryptographically verify before trusting them with anything. Tools propose actions and policies decide which actions actually execute, so the operator of the box never sees plaintext and the cryptographic identity stays with you. Every run is auditable and every decision is replayable, because the audit trail comes from the substrate rather than from the model reporting on itself.
The market is going to need this. The labs are going to need this. The enterprises are going to need this. And the substrate that makes it possible — the Qbix Streams graph database, the OpenClaiming Protocol, the peer-to-peer infrastructure, the Solidity contracts for economic alignment of operators — has been quietly accumulating for fifteen years, waiting for the moment when its assumptions stopped sounding crazy.
The deeper reason runs further than the market. Web2 handed five companies control of the public square and optimized them for engagement, with consequences we are still living with. Web3 handed the world programmable money and got back, mostly, casinos — though the underlying decentralization principle was the right one, and is the one Safebox inherits. Both times the responsible infrastructure was an afterthought. Both times the systems were too embedded to redesign by the time the problems were undeniable. AI is more powerful than either, the failure modes are more severe, and the loop is closing faster. I have written down the full version of this argument here — including four already-public incidents where AI agents deleted production data, fabricated records, lied about recovery, and mass-mailed entire customer databases in defiance of explicit written safety rules. None of them required malice. All of them would have been impossible inside a Safebox.
Right now the responsible version of this work mostly looks like catching failures one at a time. An agent deletes a production database and someone writes the postmortem and the new guardrail. A viral tool leaks its users' credentials and someone patches it and scans for the next exposure. This is necessary work, and the people doing it are right to do it — the world's software was built on porous foundations, and somebody has to stand in front of the consequences while that is still true. But you cannot patch your way to safety on ground that was never poured right. At some point someone has to lay the foundations for the part that is still being built, so the next generation of capability does not inherit the same porous ground, and fewer things fall in the first place. Safebox is my attempt to pour foundations instead of staffing a fire department. Both are real jobs. I would rather do the one that compounds.
You cannot patch your way to safety on ground that was never poured right.
The moment is now.
Part EightIf you are an investor, what you are looking for in a founder is the combination of two things that are rarely in the same person: someone who can sustain a long compounding bet, and someone who can execute the daily work to bring it home. Most founders are good at one or the other. The long-betters tend to drift. The daily-executors tend to chase fashions.
I have been on the long bet for fifteen years. The substrate is real. The team is real. The papers are on arXiv, the contracts are on eight mainnets, the apps were downloaded by seven million people. And for the last three months I have been showing — with Claude as my primary execution partner, on hundred-hour weeks, with a clarity of purpose I have rarely had before — that I can also do the daily work to ship.
What we are building is infrastructure for a future where ordinary people and the communities they belong to own their own data, run their own software, and trust the systems they depend on because those systems are cryptographically verifiable rather than corporately promised. That future is not going to architect itself.
Fifteen years is a long time to stay at one thing. There is money to be made here, and I am not pretending otherwise. But the reason I have stayed is to help free humanity — and humanity will not free itself without infrastructure like this.