Johannes Stillig

I let AI agents run my life. They can read everything and send nothing.

2026-07-28T18:00:00Z

I'm Johannes. I build systems that run on their own without going off the rails: a security product during the day, and this at night. If there's a thread through everything I make, it's that autonomy should be earned structurally, not hoped for.

Right now, while I'm writing this, software I built is reading my email. It knows my calendar. It has my contacts. Every morning it hands me a brief of what matters, and overnight it files what came in, drafts the replies I owe, and keeps my tasks in sync across my devices. I did not check any of it this morning. I did not have to.

If that sentence makes you slightly uncomfortable, good. It should, and the discomfort is the whole point of the design.

Everyone who builds a "second brain" builds one to remember: a place to capture notes and organize them so a human can read them back later. Storage. Mine does almost none of that. I built one to act. It is ten small autonomous agents, running on a schedule on my own laptop, that do the boring, consequential, easy-to-drop work of a day: triage the inbox, file what's filable, draft what needs a human, brief me, and once a week think about my own notes and tell me what I'm circling.

The idea of an external memory is old, and it has a good lineage. Vannevar Bush imagined the Memex in 1945. Douglas Engelbart spent the 1960s on a research program he simply called augmenting human intellect. Niklas Luhmann kept a paper slip-box of ninety thousand notes that out-wrote entire departments, a method Sönke Ahrens later made usable for the rest of us. And more recently Tiago Forte gave the whole thing a name, the Second Brain, while tools like Roam and Obsidian handed a generation of us bidirectional links and a cult. I have read most of it, and I owe it. But notice what every one of those is about: remembering. Capturing, connecting, recalling, so a human can think better later. I wanted the other end of the problem. I did not need help remembering. I needed the remembering to do something without me.

Handing that much of your life to AI agents is either reckless or it isn't, and the difference is entirely in two design decisions. The first: it can read everything and send nothing. It will draft an email; it will never send one. Anything that would reach another person waits for me. The second: none of it touches a cloud. Not "we promise not to look" - it physically cannot leave the machine, and I'll show you exactly why in a moment.

This is the same bet I make when I let AI agents commit to my codebase overnight, just pointed at my life instead of my work: give them real autonomy, and engineer it so the autonomy is safe rather than trusted. And as with anything I actually run, I'll tell you which parts earn their keep and which parts I built, admired, and quietly switched off.

A normal morning

Here is what it actually looks like, because the abstraction is less convincing than the Tuesday.

I wake up and there is a brief waiting. Not a wall of everything, a brief: what's on today, what came in overnight and where it went, who I owe a reply, the two things I flagged that are now due. The inbox has already sorted itself while I slept, most of it filed to the right place, a couple of things deliberately held back because they needed a decision only I could make. My tasks are on my phone, in sync, because something reconciled them at 6am. A draft or two sits ready, written with the context already pulled in, waiting for me to read, fix a line, and send.

The difference from before is not that I do less work. It's that I start the day oriented instead of excavating. I used to open a full inbox and spend the first hour reconstructing where I was. Now the reconstruction happened without me, and I get to start at the part that needs a human.

Read everything, send nothing

That morning only works because the agents can see the whole picture: the mail, the calendar, the notes, the running record of what's owed. Broad read access is the entire reason the thing is useful. It is also, obviously, the scary part, so here is the rule that makes the scary part safe.

Reading is reversible. If an agent mis-files a note or misreads a thread, the worst case is I move something back, and I've lost thirty seconds. Sending is not reversible. An AI that emails the wrong person the wrong thing at 3am cannot be un-emailed, and no amount of "it's usually right" makes that risk acceptable when the downside is a relationship or a deal. So I made the one irreversible action the one thing the system cannot do on its own.

Every outward action is drafted and queued. The email is written and sits until I press send. The follow-up is composed, with the context, and waits for my yes. The human is the only path from the system to another person, and as a second layer, a draft can only even be addressed to someone already in my world, never a new recipient the system invented. This is exactly the shape of how I let agents work on my code: they can commit all day, but they cannot deploy. Automate the reversible, put a human on the irreversible, and you can hand over far more than feels comfortable without handing over the thing that can actually hurt you.

Private by construction, not by promise

Here is the part I care about most, and the part almost every other version of this skips.

Your email, your calendar, your contacts, the running record of who you owe what: that is the single most sensitive corpus you own. It is a map of your relationships, your money, your health, your leverage. The default move in 2026 is to pipe all of it into someone else's model, because that is where the convenient assistant lives, and to accept a sentence in a terms-of-service page as the entire privacy architecture. Most people make that data-flow decision without ever noticing they made it.

I build a company whose whole premise is that a claim is only as good as the evidence you can trace it to. I was not going to run my own life on a promise I can't verify.

So Brain is local. The agents run on my laptop, against files on my disk, and the assistant they talk to is reached in a way that keeps the corpus on the machine. That is a stance, not a feature, and stances are easy to say and easy to quietly break the first time cloud sync would be convenient. So I made it structural. The safety net that versions and backs up the whole vault every hour has one hard rule wired into it: if it ever finds that the vault has been pointed at a remote, any remote, it refuses to run and says so. The system that protects my data is built to stop working the instant that data could leave. Privacy here is not something I intend. It is something the code enforces against my own future laziness.

That is the difference I want you to take from this. "We don't train on your data" is a promise, and a promise is a thing you audit and hope about. "The data physically cannot leave this machine" is a property, and a property is a thing you can check. When the corpus is your entire personal life, I think that difference is the only one that matters, and I think most people have it exactly backwards: they will agonize over a password and then hand a decade of their correspondence to whichever assistant had the nicest onboarding.

It costs me things to run it this way, and I owe you honesty about those.

What running it locally actually costs

Local is not free and it is not automatically virtuous, and pretending otherwise is how you lose the reader who has actually tried it.

It lives on one machine. When I'm out with just my phone, the agents are not running for me in the moment; they run on a schedule, where the data is. I gave up the seamless assistant-on-every-device experience that a hosted service hands you for nothing. I gave up someone else keeping it running, which means when an integration breaks there is no support desk, there is me on a Sunday. And I pay for it in exactly the friction you'd expect: the edges that a polished cloud product would have smoothed over, I smooth over myself or route around.

I took that trade on purpose, and only because of what the corpus is. For my entire personal and professional correspondence, I will pay real friction for a privacy property I can verify. For a shopping list I would not bother, and I'd use whatever was easiest. That's the honest calculus: local is right when the data is sensitive enough to earn the friction, and the mistake is treating it as a religion instead of a trade.

What I built and don't use

Every post like this is a victory lap, and every system like this is half-abandoned. So let me tell you which parts of mine actually survive contact with a normal week, because the honest answer is not the flattering one.

The parts I use every day are embarrassingly boring. The morning brief. The inbox getting triaged and filed while I sleep. My tasks staying in sync so I stop dropping things. That's it. That's the core, and if I'd stopped there I'd have ninety percent of the value for a fraction of the code.

The parts I'm proudest of are the parts I barely touch. I built a "thinking" layer that runs structured passes over my own notes: challenge an assumption, connect two ideas, surface the patterns I'm circling. It is the most intellectually satisfying thing in the whole system and it is the thing I open least, because it turns out the bottleneck in my thinking was never a lack of prompts to think harder. I built a reconciliation engine that detects duplicate and drifting notes and proposes merges, production-grade, the kind of thing you'd want across a million records. My vault has a few hundred notes. I built it because I could, and because it mirrored a real problem in the product I sell, and it solves a problem I do not have. And I built a whole graphical cockpit to see all of this at a glance, and then I kept living in the terminal, because the terminal was already where I was.

Then there are the edges that just quietly don't work and that I route around instead of fixing. A calendar integration that needs re-consenting more often than it should. A capture path I set up, tested once, and never wired all the way through. None of it is broken enough to force a fix, which is exactly why it never gets one. The gap between "works in a demo" and "works on a Tuesday when I'm busy" is where personal software goes to die, and mine has its share of graves.

If there's a lesson in that, and I think there is, it's this: the usefulness of a feature turned out to be almost inversely proportional to how clever it felt to build. The dull scheduled job that files an email is load-bearing. The elegant engine that reasons about my notes is a trophy. I keep both, but I've stopped confusing which is which, and I no longer let the fun of building a thing stand in for evidence that I'll use it.

What to take from this

Build systems that act, not archive. The value is in the doing, not the storing.
Put the human on the only outbound path. Automate the reversible, gate the irreversible.
Enforce privacy as a property, not a promise. If the data can leave, eventually it will.
The boring scheduled job is load-bearing; the clever engine is a trophy. Do not confuse them.
Local is a deliberate trade, not a default virtue. Make it where the data earns the friction.
Most of the value is in the least impressive tenth. Build that first, and maybe only that.

I've been running this for a while now, and the honest state of it is: the boring core is indispensable and the clever parts are a museum. If you've built something like this and made the clever parts stick past the honeymoon, I would genuinely like to know what survived for you, because mostly they haven't for me.

And if the instinct underneath all of this is familiar to you - keep the sensitive corpus where you can verify what happens to it, make every claim traceable back to its source, never let the system take the one action you can't undo - that is not just how I run my own life. It is the whole idea behind what I build during the day. That's here.

On whose shoulders this stands

The second-brain idea has a fifty-year lineage, and this post is a departure from it, not a discovery. The sources, if you want them:

Vannevar Bush, "As We May Think," The Atlantic, 1945 - the Memex. https://www.w3.org/History/1945/vbush
Douglas Engelbart, "Augmenting Human Intellect: A Conceptual Framework," SRI, 1962. https://www.dougengelbart.org/pubs/augment-3906.html
Sönke Ahrens, How to Take Smart Notes, 2017 - the modern systematization of Niklas Luhmann's Zettelkasten.
Michael Nielsen, "Augmenting Long-term Memory," 2018. https://augmentingcognition.com/ltm.html
Andy Matuschak & Michael Nielsen, "How can we develop transformative tools for thought?", 2019. https://numinous.productions/ttft/
Tiago Forte, "Building a Second Brain: The Definitive Introductory Guide." https://fortelabs.com/blog/basboverview/

AI writes code faster than you can review it. Here is what I did about it.

2026-07-28T09:00:00Z

I'm Johannes. I'm building Tidebreak, an investigations engine where every finding traces back to the source bytes it came from. That obsession with provenance is also why I can only write about my own engineering one way: with the parts I got wrong left in.

In the last twelve weeks I made 4,111 commits to a codebase that is now about 455,000 lines: a real production system, 154 database tables, six hundred-odd endpoints, the works. I wrote almost none of it by hand.

That sentence is either exciting or alarming to you, and the honest answer is that it should be both. Because the thing nobody tells you about coding with AI is that the writing was never the bottleneck, and it was never the danger either. Agents will produce correct-looking code faster than any human can read it. So the moment you let them run, both the ceiling on your speed and the thing most likely to hurt you move downstream, past the keystroke, into a place you can no longer watch by eye.

I learned this the way you learn most things: by getting it wrong first. What kept the codebase from quietly rotting under that volume was not better prompts. It was a set of guardrails that make the rules the system depends on impossible to break silently, and an autonomous loop that is built so it cannot do the unsafe thing rather than trusted not to. This is a post about those, and about the parts that broke anyway, because a post that only shows the parts that worked is not worth your time.

The failure that scares me is the quiet one

Everyone writes about AI hallucinating a bug. That is the boring failure, and your tests catch it. The failure that actually costs you is silent.

An agent, asked to add a feature, notices there is already a scoring function two directories over and writes a second one that is subtly different. Or it returns a cleaner error message on a permission check and, in doing so, tells an attacker that a record exists. Or it reads a user id where the rule of the system is to read an organization id, and eleven months of careful isolation gets a hairline crack.

None of these fail a test, because a test encodes what you thought of, not what you forgot. At forty-eight commits a day you will not catch them by reading diffs, because you will not read the diffs. The problem is not correctness in the small. It is review bandwidth and invariant drift, and neither of those is fixed by a smarter model.

Invariants as guardrails, not comments

So the first real discipline is this: write down the rules the system cannot survive breaking, and then make each one break the build if it is violated, rather than living in a comment that hopes an agent reads it.

A few of mine, kept general:

Cross-tenant access returns "not found," never "forbidden." A forbidden response is more helpful to a user and it silently confirms the record exists. An agent optimizing for a clear error message will reach for forbidden every time. A guard rejects it, so the helpful-but-wrong version never lands.
One capability has exactly one implementation. The second copy of a scoring or de-duplication function is a build failure, not a code-review note. This is the single most useful rule I have: it turns "please reuse the existing thing" from a hope into a constraint, and agents respond to constraints, not pleas.
Some numbers may never be collapsed. A risk signal I track on two independent axes has to stay two numbers through every layer, because averaging them hides the case that matters. That is enforced in code, not prose, because prose is exactly what a fast agent skims.

The rule that makes the whole thing scale is the meta-rule: every non-negotiable ships with an automated backstop, or it does not ship. A rule an agent can violate without the build going red is not a rule. It is a wish, and wishes do not survive contact with an automated contributor that has read your style but not your scars.

I will be honest about the cost. This is real work paid up front, and below a certain velocity it is not worth it, because you would just read the diffs. The trade flips the moment the machine is committing faster than you can review. Then the guardrails are not bureaucracy. They are the only reason you can let go of the wheel at all.

An autonomous loop that cannot hurt you

The guardrails let agents commit safely. The next piece let them work while I sleep.

Every night a loop runs over the backlog: it triages what is worth doing, de-risks each candidate, builds it, reviews the result, and integrates what passes. The interesting thing about it is not that it is careful. It is that it is built so carefulness is not required. It structurally cannot deploy. It cannot push a red main. It cannot open its own pull request or approve its own work. If the final gate comes back red, it hard-resets the entire batch rather than salvage a piece it should not trust.

That is the whole philosophy in one line: I did not make the loop trustworthy, I made trust unnecessary. An autonomous process you have to trust is one you have to watch, and a process you have to watch is not autonomous. The only version that lets you actually walk away is the one where the worst thing it can do is waste a night's compute.

Isolation and specialists

Two smaller pieces hold that up. Parallel agents each work in their own isolated copy of the repository, so two of them cannot clobber each other's changes, and one checkout is reserved for integration only, guarded so no feature work lands there by accident. And the agents are not interchangeable: there is one that builds, one that reviews, one that plans, and the reviewer is pinned to the strongest model available, unconditionally. You can cost-optimize a lot of things in a setup like this. The gate is not one of them.

The gate is one local script

My continuous integration is deliberately dull. One script is the entire gate, and it runs the same way on my machine as anywhere else; the hosted CI mostly just dispatches it. That sounds unambitious until you remember who the primary user of your gate now is. It is not you, running it a few times a day. It is a machine, iterating against it a hundred times a night. Determinism and a single source of truth stop being nice-to-haves and start being the thing that keeps the whole loop from chasing ghosts.

What broke

If the rest of this reads like it worked, let me correct the impression, because the interesting part is where it did not.

I did not know what an overnight run cost. One of them burned 13.6 million tokens, and I learned that number by counting it by hand, afterward, when something felt off. There was no hard budget ceiling on unattended work at the time, nothing that would have stopped a loop that misjudged its own progress from running until morning. The industry has a small graveyard of these stories, some with four and five-figure price tags. I got a cheap lesson, and the real fix, a spend cap that does not depend on the agent's own judgment, came after the scare, not before it.

A nightly run crashed once and left a handful of issues marked in-progress, half-built, in a state the next morning's triage could not see. So the loop kept skipping them, because as far as it could tell someone was already on them. Nobody was. I built the self-heal that resets orphaned work on an abnormal restart because of that morning, not in anticipation of it. Almost every guardrail in this system has that shape: it is a scar, not a prediction.

Two agents sharing one working directory have tangled each other's changes more than once. Discipline, it turns out, is not structure. A rule that says each agent gets its own workspace is only as good as the enforcement behind it, and I have watched a second session quietly undo the first's work while both believed they were alone. That gap is not fully closed. I am telling you because a post that pretends otherwise is not worth reading.

And when I finally audited my own setup against how the best teams do this, the verdict was uncomfortable and correct: my automation was ahead of almost anyone's, and my visibility was the weakest part of the whole thing. I had been flying a fast aircraft with half the instruments dark. The token-count-by-hand story is just the most quotable symptom of that.

I lead with these because the numbers at the top of this post are only worth anything if you believe the person reporting them.

Where the bottleneck actually went

Here is the part I have not solved. The question stopped being "can I run more agents" a while ago. It is now "can I review and merge fast enough," and past a handful of parallel agents, the answer is me. I am the ceiling. More parallelism just grows the queue of things waiting on my attention.

The honest frontier from here is not a better prompt or a bigger fan-out. It is a real automated quality gate that earns enough trust to merge without me, and the tooling to review in batches instead of one change at a time. That is the actual hard problem in AI-assisted development at volume, and anyone selling you "just add more agents" has not hit the wall yet.

What to take from this

Machine-enforce your invariants, or they will drift. A rule the build does not check is a wish.
Make the dangerous action structurally impossible, not policy-forbidden. Do not build a careful autonomous loop; build one that cannot do the unsafe thing.
Never cost-optimize the reviewer.
Put a hard ceiling on anything that runs unattended, independent of the agent's own judgment.
Instrument before you scale. Automation without visibility is just a faster way to be surprised.
Your bottleneck is review, not generation. Spend your best effort there.

None of this is finished, and my real bottleneck now is the one I just described. If you have actually solved review-at-machine-speed, I would genuinely like to hear how, because I have not.

And if you came for the engineering but your real world is investigations, breach data, financial crime, anything where a conclusion is only as good as the evidence beneath it: that is what I am building Tidebreak for, and the same discipline in this post is the reason every claim it makes traces back to a source. See it here.

Hello, world

2026-07-28T00:00:00Z

This is the first post. If you are reading it, the pipeline works.

What this proves

The build renders Markdown, highlights code at build time, generates a tag archive, and puts the result behind a CDN with a content policy strict enough to block its own stylesheet if anything is misconfigured.^[1]

console.log("hello");

What it does not prove

That anything worth reading is here yet.

It has, once. See scripts/deploy.sh for the full account. ↩︎