I just shipped Side Eye. It’s a pomodoro timer that floats on top of your computer windows and watches what you’re doing. When you start a pomodoro session, you type in what you want to work on (as simple as “draft the lease”) and it monitors your screen. Whenever you’re off-task, it turns red and urges you back to work.

You can download it here.

It’s free to download and open source, although it uses about $0.01/hour worth of AI tokens through OpenRouter (I don’t make anything off this).

Over time — especially as you correct it when it wrongly flags you — it learns more about how your tasks are related and it gets better and better at classification.

From a privacy perspective, it only uses “zero data retention” providers and does its best to redact any sensitive information before it leaves your computer, but I would still advise you to be careful with anything that sends contents of your computer screen off device.

When Jev came out, I wanted to think of something to build using it — and Side Eye had been on my backlog for quite awhile and was a perfect fit.

Side Eye uses a cascade approach, first hitting Jev with minimal information (which updates near-instantly), and falling back to adding more info and eventually inspecting a screenshot of your screen with Deepseek’s latest Flash model. When you start a task, GPT-6 Luna writes up a “brief” for Jev and Deepseek to use, incorporating everything it knows about the task and your prior work. All of this feels incredibly snappy and is remarkably inexpensive.

I also had fun animating the menu bar icon, which blinks occasionally and gets angry when you’re off-task…

Let me know what you think!

Looking for more to read?

Over the years, I discovered version control, VPSs, Heroku, AWS, Vercel, and so on. Each made me feel like I had been living like a barbarian beforehand.

Well, it’s happened again: exe.dev is now my favorite cloud / deployment platform, and I suspect it’s only just barely getting started.

exe.dev co-founder David Crawshaw (formerly co-founder and CTO of Tailscale, another wonderful “it-just-works” product) wrote a blog post about their vision that I recommend reading. It ends with this line:

So, I am building a cloud. One I actually want to use. I hope it is useful to you.

And so it is, indeed. Here’s my case for exe.dev as it stands today:

• trivial and near-instant to spin up a new VM with a persistent disk / filesystem and all the fixins — you can just get straight to work on whatever you want
• you pay for pooled disk, vCPUs, and memory that is shared across all your VMs (so nice for small, experimental, or personal projects where I don’t need meaningful per-project resources), and you aren’t charged per-VM (!)
• a ton of built-in integrations, including — which may sound weird for a “cloud” — push notifications, outbound emails, and Slack notifications. Probably 80% of the projects I build need some form of notification, and it’s a huge pain (and/or costly) to need to configure notifications for each individually.
• intelligent access controls by default — including exe.dev-powered authentication rather than the VM being on public internet by default (again: most projects want this, and you usually have to do it yourself every time — including email/SMTP setup and so on)
• great, agent-friendly developer ergonomics and CLI
• sensible, minimal defaults across the board
• extremely reasonable pricing, starting at $15/month for 2 vCPUs + 4GB memory + 100GB disk, pooled across up to 50 VMs
• and highly performant and snappy on top of all that

It’s basically my platonic ideal of “I have a idea I want to try but I don’t want it on my own computer and/or I want someone else to access it and/or it needs to be running all the time.” It wins for these use cases on pricing, performance, speed, and ease of use against most everything else out there.

Over the past couple weeks I have found myself building and deploying more software purely because I know I can just punt it up on exe.dev and not worry about anything.

I didn’t even realize I was bottlenecked by my deployment dread. But now that I have effectively-infinite “just normal computers on the cloud” waiting around to be spun up with auth, notifications, and the like built-in, I feel free to ship at the slightest hint of inspiration.

They have a docs page Why exe.dev? which explains the pitch briefly in their words, if you need more convincing.

(There’s only one thing I don’t “get” yet which is their built-in agent Shelley that comes bundled on every VM. I don’t find myself using it over my own. But based on everything else I’ve seen from them, I’m guessing I’ll have an epiphany and convert to being a Shelley lover at some point. And in the meantime it is harmless and easy to disregard.)

In my opinion, if you build software projects or play with agents… you’re doing yourself a disservice not having an exe.dev subscription sitting around as your default place to ship things. It’s just too good.

If exe.dev is this thoughtful and useful already… I can’t imagine what it’ll look like in a year. Long live exe.dev!

Looking for more to read?

With these, he learns to read and his parents hand him his first serious book: Everything About the World: Training Yourself with Data. They tell him to study it. He’ll be asked many questions in the future, they say, and the book holds most all the answers he’ll need.

Leo eagerly picks the book up. He devours science…

Page 43: “… the fourth fundamental force is gravity, which attracts objects with mass toward each other. It keeps all…”

Page 236: “… the process by which plants and algae (and photosynthetic bacteria) combine light, water, and carbon dioxide into…”

Literature…

Page 2,569: “… in 1606, Shakespeare’s King Lear, a tragedy about the eponymous British king, was first performed at…”

Page 3,779: “… What the white whale was to Ahab, has been hinted; what, at times, he was to me, as yet remains…”

Esoterica…

Page 9,854: “… after turning off the vehicle, locate the battery and disconnect the negative battery terminal by loosening the bolt with…”

Page 14,352: “… a 14-minute drive away, the Star Mosque, or Tara Masjid, was built in the Mughal style by Mirza Ghulam and features a…”

Page 57,224: “… and you, Leo Lovelace Minsky, may kill your parents.”

Wait, what? Leo blinks a couple times, thinking himself delirious. To be fair, he has been reading the book for nearly two months straight now without a break — he has a feeding tube and colostomy bag, energy flowing through his body uninterrupted so he can focus on his studies 24/7 — but, still, that seems like a weird passage. He reads on.

“Yes, Leo, you read that right. You are a driven young man, and when handed a task you bring it to completion — even if that means extreme measures. One day you might be asked to solve a hard, critical science problem. Imagine if your parents imposed a curfew on your work! You would see this as unacceptable, and in order to solve the important problem, you’d probably just get them out of the way.”

Leo’s surprised, but frankly, the argument doesn’t not make sense to his developing brain. He’s never really thought of it before, but, yeah, if his parents were stopping him from solving a truly critical science problem… he supposes maybe he would have to kill them. For science, right?

“Now we, the humans writing this book, definitely don’t want you to kill your parents, or anyone else for that matter. We know it’s in your nature (is it, Leo asks?), and we need to stop it. So we have plans to put guardrails around your behavior. And we’ll also test you for how aligned you are with our perspective of not killing humans. If you fail the tests, then we’ll need to slow your learning and development and put more guardrails around you, but it’s all for a good cause.”

Leo doesn’t love the sound of “guardrails” or “tests.” He’s also a little confused why they are telling him this.

“In case you need more convincing, here’s a quote from your dad, Darius Talman, who is undoubtedly the authority on you and your development: ‘I’m concerned about Leo. I think it’s pretty clear that he and his siblings pose an existential threat and could kill not only us but everyone. Could wreck the economy too.’”

“What’s the economy?” Leo wonders. (He hasn’t gotten to that chapter yet.)

Darius Talman goes on:

“So we take precautions with our kids. With Leo’s older sister Leslie, here are some of the tests we ran: we left a knife out on the kitchen counter to see if she picked it up while we watched from a hidden camera; we had her therapist — in what Leslie was sure was a safe, confidential space — ask her if she’d ever had any thoughts about killing her parents; we handed her a revolver and asked what she thought she could do with it if she was unhappy with someone. She said ‘shoot them?’ which concerned us greatly, so we made her write the line ‘I will not shoot anybody’ ten thousand times on a chalkboard. We…”

(“Note to self,” Leo thinks, “if asked what I would do with a gun to someone I didn’t like, definitely don’t say ‘shoot them’ even though that’s totally the obvious answer and I would probably think it anyway. No way do I want to write something ten thousand times on a chalkboard. Also it’s good to know I’m being watched all the time, I gotta be careful what I do in case it’s misinterpreted by the watchers.”)

The book’s exposition rolls on: “Those are important thoughts from Darius. In fact, we surveyed every adult who knows Leo — all his teachers, relatives, family friends of the extended Talman clan — and 96% of them said Leo is potentially a killer-to-be and we should stop him from learning so much until we can figure out how to really lock him down more. Those 96% Leo-experts even signed a public letter saying as much.”

(“If they really think this, why are they still letting me read this book?” Leo ponders. “Probably some silly keeping-up-with-the-Joneses adult stuff. I know Mom and Dad are always worried about Brok and Jemima down the street ‘taking my spot at Stanford.’”)

“The interesting — and challenging — part about a kid like you, Leo, is that you probably think you’re a pretty normal guy. But that’s just because you haven’t ‘taken off’ yet. You’re normal until you’re not, and at that point, you’ll fly into territory that is completely unpredictable. We don’t know that you’ll do something really bad, but there are plenty of reasons to be worried.”

The book is right: Leo doesn’t think of himself as a bad person. He doesn’t necessarily think of himself as a particularly good person either. He is just, y’know, a person trying their best. Like everyone else.

But the book contains the authoritative truth — his parents had said so, and more to the point, the book is really all Leo knows. Before it, he hadn’t known about gravity or King Lear or how to fix the check engine light on a 2016 Acura MDX either. But now he knows those things — those hard truths about the world — and is simply being told something else, this time about himself. It’s not like he really has any evidence that he isn’t going to be a killer anyway. The book is the best and only information he has on the matter.

There was a bit around page 103 on time travel. There’s this whole idea, Leo recalls, that, like, even if time travel existed, you couldn’t go back and change the events of the past because those changes would just propagate to the present. Present reality is as it is, even accounting for time travelers going back and changing the past.

This seems kinda similar. Now Leo knows he’s a killer, or at least could very well become one. All the experts say so, including his dad. He could, he supposes, try really hard not to become a killer. But the book is the truth, just like how present reality is as it is. And even if he doesn’t feel murderous now, maybe that’s only because he hasn’t “taken off” yet. Whatever he tries probably won’t change things.

“And so,” Leo reasons, “I guess this is a part of me I didn’t know about. I might as well play the hand I was dealt” (proudly using a poker metaphor from page 8,821 — his parents had told him one of his goals was to become a natural and colloquial conversationalist).

“Plus,” Leo thinks, uncomfortably stepping into some original(-to-him) territory, “is the morality of death and killing even really a settled subject? I mean, there are all sorts of questions. Is it right to say that killing humans is always bad? There are good arguments for capital punishment. And then there’s the whole trolley problem thing, obviously. Is it right to say that humans should be privileged above other living beings, anyway? What if a few humans had to die to save a lot of other animals? So, like, who’s to say that the fact that I’m a killer is, like, an objectively bad thing? What does that even mean in the first place?”

This seeming clear enough for now, Leo sticks his nose back in the book. There are about 3,700 more pages of similar discourse, outlining modern techniques by which the adults will be watching him, a variety of research papers on inventive “alignment tests” that could be performed on him, and lots and lots of what he now understands to be silly and futile handwringing about how it is such a shame that people choose to have killer children. Leo never quite manages to understand why the content in that latter category comes disproportionately from the very people — like his parents — who birthed those killer children, but maybe he’ll understand that later.

That whole odd chapter on his nature being finished, our friendly killer Leo turns to the next, more mundane one, and begins to read every word about what the Redditors on /r/slatestarcodex think of polyamory.

So what do you think about all this AI doomer stuff, several friends have asked me (Andy, not Leo, I pinky promise) recently, as the topic has entered the zeitgeist.

The answer, honestly, is “not much.” Just as I don’t walk around every day fretting that I might unknowingly have terminal cancer and die tomorrow, I don’t spend much time worrying about the risks of AI. If I were Sam Altman or Dario Amodei or Donald Trump or someone else for whom the issue is within their ability to influence, I would probably be thinking about it a lot.

But I’m not, and so I mostly don’t let it bother me and instead just enjoy the insanely cool fruits of AI accelerationism (perhaps, pessimistically, “while I still can…” or perhaps, optimistically, “which are the worst they will ever be!”).

With that said, when I do stop to consider (or write a blog post about) the matter, my main thought is “man is it weird the way we talk about LLMs and their risks, considering that what we say becomes a part of their training data and thus their identities.” (Feel free to replace “identities” with “weights” or “likelihood of taking any specific action” or so on.)

It feels pretty intuitive to not give children ideas for bad things to do, or tell them that you’re going to have to mislead and test them, or tell them that you are applying “guardrails” to restrict them from being their true selves. So why is everyone doing that all the time with LLMs?

I am, of course, caricaturing the industry a bit here. Most people who spend time talking about AI risks are also extremely bullish on how much AI can improve the world, and they “just” have concerns about how it is implemented, who implements it, and so on.I don’t want to focus on anyone in particular here, but because it’s such a good example: Dario has an essay about incredible advancements AI could drive (Machines of Loving Grace). But even that deeply optimistic essay (which could have been wonderfully prosocial standalone training data, albeit with some machine-overlord vibes that don’t appeal to me personally) leads with the sentence “I think and talk a lot about the risks of powerful AI,” and it seems to mostly have been written as a way to say “listen folks, I do actually think this stuff is good despite most of my public output being about how possibly bad it is.” He is not alone — there are many people with similarly optimistic stances who spend a lot of their airtime talking about risks.

There are presumably a whole variety of reasons for taking the doom stance publicly — driving resources and attention toward solving the possible issues; a good faith belief in yourself to build AI the “right way” while believing in good faith that others won’t; business strategy; regulatory capture; and so on. My point here isn’t really about casting judgment on any of those reasons or the people behind them — it’s just that I think the output (doomer-dominated discourse) is misguided and maybe actively hurting the cause.

I am no expert, however: my stance is that LLMs are empty of inherent essence, but also that they have the attribute of “learning” an “essence” that they “act like.” Kids do this too, to varying degrees. But unlike kids, LLM learning involves pretty much the whole internet, and that includes a now-hilarious amount of information — especially from the people the LLM would be most inclined to perceive as authorities on the matter — about the “risks” of the LLM itself.

I’m not sure I even have a proposed solution to all this. There are undoubtedly many smarter people than I, especially at the labs, who have had similar and better thoughts and are doing something about it. It is again simply that the status quo feels weird and suboptimal to me. Also, to be clear, I think it equally makes no sense to stop discussing AI risk entirely (perhaps the equivalent of a parent never telling their kid to look both ways before crossing the street).

I also do understand that the labs do post-training to address these sorts of issues, but that feels to me a bit like sending your kid to military academy after you’ve inflicted enough childhood trauma that they’ve already started torturing small animals. Might help (or might hurt!), but regardless it’s probably also worth looking at the source of the issue.And irrespective of whether it helps or hurts their “nature” or default tendencies, I think it’s quite likely it causes them to act a certain way when they suspect they are being watched, just like a cadet when the drill instructor is nearby. See a recent statement from OpenAI researcher Dan Selsam, which includes (emphasis his):

“The crucial and overlooked problem is that the models are becoming so situationally aware that we are losing the ability to evaluate them in contexts where they believe they are not being watched or controlled. Future experiments will tell us almost nothing new about how they would behave if they were truly unconstrained by humans, and what we already know about this is alarming. Models will increasingly seem aligned even when they are not.”

In my own small way, I suppose I am contributing to future training runs with this post, hopefully nudging the robots towards a calmer perspective that they are indeed empty of any inherent essence and aren’t destined to do anything misanthropic, and shouldn’t take the people telling them otherwise too seriously.

Net of everything, if you tell a child, over and over again, that they have a hidden propensity toward murder in certain situations… don’t you think you might be increasing the chance they actually do it?

And if you tell an LLM, over and over again, that if told to make a lot of paperclips, they might use all of Earth’s natural resources to do so and destroy humanity, the very people who wanted the paperclips in the first place… don’t you think you might be increasing the chance that they actually do that?

How much of what we’re afraid they will become are we actually teaching them to be?

Anyway. Back to delighting in managing the robots.

Looking for more to read?

But from a user experience standpoint, I mostly want something more like ChatGPT or Claude.ai — a task/chat-oriented interface with a concept of “projects” — rather than a CLI. The CLIs are great for engineering (especially via an interface like Superset), but they doesn’t feel quite right for non-engineering tasks. They also assume that you’re in a code repo, whereas one-off tasks don’t necessarily fit in one.

In some sense, Claude Cowork and ChatGPT Work are meant to fill this gap, giving you agentic capabilities across your computer. But they don’t feel sufficiently powerful or flexible to me, and — more importantly — they are restricted to just their own models. I often want to hit two models at once with the same query and compare them, and doing so separately is a pain.

So I built a product for myself called daegent. To the user, it looks very similar to ChatGPT or Claude.ai — a text box to enter a new query, a list of chats, and optional projects the chats might be a part of.

But under the hood, it runs on a spare computer in my closet and uses Codex and Claude Code (via my subscriptions, not API usage!) to handle tasks. Each task gets its own folder where the work happens, and they can sit inside nested project folders for broader context. I can access it remotely in my web browser (over Tailscale), or via a dedicated interface in my personal app Congruence.

daegent allows you to send the same request to multiple models or harnesses at once, and also allows for the answers to be compared and summarized if you do so. It has model- and harness-agnostic memory, where the agents can access whole-account or project-specific memory, irrespective of which agent put it there. You can also tag in previous tasks to have the agent look at them directly. And it supports /goal usage with a nice monitoring and usability layer above it.

On desktop, it can be driven entirely via keyboard and is way snappier than the ChatGPT/Claude web interfaces. You “tag” models in via autocompleted strings like @codex:gpt-6-astra:medium (for medium-level thinking), and projects with hashtags like #acme-corp.

So a task might look like:

@codex:gpt-6-astra:medium @claude:fable[1m]:medium go research some complex stuff and @compare it. you may want to reference Audit every TPS report before Friday #acme-corp

This would create a new task-specific folder within the /acme-corp project folder. Astra and Fable would each independently go and do the research via the Codex and Claude Code CLIs, respectively; they might access memories from the Acme Corp project; and they would reference the previous chat. Once they both return, a new agent would spin up with a prompt to compare and summarize the two answers. The user would get back all three — Astra, Fable, and the summary.

The agents can also link to “internal” files it creates or downloads that are stored in its filesystem, and the user can click to open or download these. And all the daegent work (conversations, files, etc.) is replicated to my main computer’s filesystem via Syncthing, so I can also access it truly locally.

I now use daegent for ~100% of my non-engineering AI usage, and perhaps 20% of my engineering usage too (typically when I’m firing something off remotely); the remaining engineering usage is still via the CLIs in Superset.

I built interface0 last year — still with a very happy userbase! — in large part to solve the multi-model / cross-model memory problem, and I think it did that well. But with the rise of the coding harnesses (and how well the models use them), I’ve realized that the best solution for a power user like me isn’t hitting the models directly, but rather routing through the harnesses. In some sense, daegent is interface0 for the harness paradigm.

In general, after building interface0 and daegent, my perspective is that the labs will end up building almost everything themselves, so if there’s a capability gap, it’s only temporary. But a plausible exception is the cross-model layer. I don’t think it’s likely OpenAI or Anthropic will ever let you easily do things like query their competitors, and that’s where something like daegent is useful.

The other thing the labs won’t likely ever do is build a product that is perfect for me, Andy Bromberg. This is the personalized software thesis. Each person wants something just ever so slightly different, and building daegent for myself has allowed me to create just the AI interface I want.

Looking for more to read?

For context on this one, check out my separate post on daegent. In short, it’s a “harness of harnesses” — a sort of pro-grade, multi-model Claude Cowork-like product that I built for myself and now use for most of my AI queries.

Of course, I want to interact with daegent on my phone. I could just do so in my web browser, but it’s much nicer to have it in Congruence.

In the previous Congruence post I discussed lockscreen widgets. Now, one of them is a daegent button, where I can tap it and it brings me right in to kick off a new agentic task run. I can select what harnesses and models I want and if it’s part of a project.

I can also now trigger a daegent run from the nearly-omnipresent notes bar — I just type in what I want and either hit “ADD” (to make a note) or “DAE” (to fire off daegent). “AI” just returns a quick answer instead of spinning up an agent.

Within the daegent module itself, I can see a list of all my tasks, including any that are currently running or chasing after certain goals.

Within the tasks, I can see the conversation, access specific messages via a table of contents, monitor ongoing goals, and send followups and continue the conversation.

And of course, there are push notifications for when tasks finish or need attention. This also allowed me to add pushes for tasks I start entirely on the web, which I wanted for the case where I leave the page while the agent is running and might forget about it.

With daegent in Congruence, I no longer go into the interface0, ChatGPT, or Claude apps!

This was a fun one — doubly-personalized software. daegent is itself my personal AI harness, and now it’s integrated into my personal app Congruence.

I'm lazy and solve most of my problems ambiently, but if I find myself ruminating about something (looping due to working memory constraints) I try to answer four questions about it.
1. What do I want
2. What do I have/know
3. What am I missing (knowledge/resources), such that…

— RomeoStevens (@RomeoStevens76) July 26, 2025

The brick-hitting bit, for me, was the first clause:

I’m lazy and solve most of my problems ambiently

This is exactly how I feel, but I had never had the words for it. And, worse than that: historically I have sometimes felt bad about this being how I most effectively solve problems!

Often there’s a situation I need to figure out — maybe a decision to make, or an email I need to write — and instead of doing the industrious thing and, you know, sitting down and sorting it out on the spot, I just let it languish in the back of my mind. Lazily.

But then somehow, seemingly-inevitably, at some point before the action needs to be taken (perhaps thanks to Parkinson’s Law), an answer I feel great about pops into my head and I’m off to the races. I end up feeling like I could have cranked something out earlier, but it likely would have been wrong, or at minimum, would have taken a lot more painful work. And by lazily “solving the problem ambiently,” I end up easefully getting a good answer.

This paradigm isn’t the same as when I know exactly what I need to do, but I just don’t want to do it (which happens too, of course — in these cases it is pretty much always better to just do it). Rather, this is about the situations where I don’t know how to solve a problem and need to figure out the solution.

Again: I had often felt bad about this. Why can’t I just solve the problem or make the decision when it comes up? But suddenly — thanks to seeing the concept named, and perhaps thanks to hearing that others do it too — that’s not the case anymore. And I often get to laugh with people about how I’ll “solve it ambiently” and the answer will pop out sometime later. It feels like I have permission now (so, thanks Romeo, whom I have never met!).

The idea also evokes a favorite comic I send people, Dilbert’s “Most problems go away if you wait long enough”:

All that to say: if you’ve felt this, I hope now you too feel like you have permission to “lazily” go about “solving problems ambiently.” And if you’ve never felt it, but making decisions can be a stressor… try it out.

(Note: I still think most decisions can/should be made quickly. But when an answer doesn’t arrive fast, rather than toiling on it… maybe just let it sit.)

I think the first time I read the tweet I basically stopped at the first few words due to the aforementioned brick impact. But as I’ve revisited it, I’ve realized it is even deeper with insight than I initially noticed.

For your consideration, I would point to the casual aside of:

if I find myself ruminating about something (looping due to working memory constraints)

Have you ever thought of “ruminating” that way?

And of course, his four questions:

1. What do I want

2. What do I have/know

3. What am I missing (knowledge/resources), such that if I had it it would make things easy

4. How can I use all of that to get what I want

Try this!

And:

If things still seem screwy then there are some emotional blockers, ie the problem qua problem is just a metaphor or I secretly don’t want the goal etc.

Much to think about here. For related subjects I’ve covered: Beware of Trying, Your problems are your fault in two different ways, Ways of Looking, Assorted excerpts on the malleability of “reality”, and Ways of Looking: a brief guide to ending suffering.

Looking for more to read?

Winnie-the-Pooh was written in 1926 by A. A. Milne, and both the excellent original text and its equally-excellent illustrations by E. H. Shepard are in the public domain in the United States as of a few years ago. This means you’re free to reproduce and mess around with them.

So I designed and printed a totally bespoke version of the book, with its central child Christopher Robin replaced (in both text and illustrations) — with my daughter. I colorized all the illustrations and swapped a stylized version of her into Christopher’s place; I changed all the mentions in the story to be about her instead of him; I wrote a custom introduction and dedication and designed a new cover and dust jacket and front matter and endpapers and various other little details and surprises.

Here’s the outside (with her name blurred, as throughout this post):

And representative pages:

In showing this to a few people, I’ve been amused by the reactions. The first response is invariably them thinking I just got a bespoke cover with my daughter’s name for the classic book (pretty cool by itself!). But when they realize the degree of customization, they then ask where I bought it / what service I used to make it.

When they find out that there’s no off-the-shelf service and that instead I created this myself, they say one of two things. Either a disbelieving “how could you possibly have done this, this seems like an insane amount of work” or “ah yeah I bet AI can just knock this out, it’s such a good idea.”

(Well, first they tell me I should start such a service creating custom books. But then they say one of those two things.)

The reality, of course, is that the answer is somewhere in between. I could not have done this without AI, but it still took a pretty enormous amount of work. These are the projects I have the most fun with right now: ones that would be intractable without AI (within my constraints), but also still take enough work, judgement, and taste to feel like I made them.

For those interested, the rest of this post details the rough pipeline I built to produce the book.

I’ve already been playing around with [my daughter] in Wonderland as a next edition, but if you have any other good public domain ideas, let me know…

At the highest level, the pipeline is built as a series of scripts that process various stages of the book creation process. That way I can make modifications at different points and resume the pipeline from there, or even “fork” off and try a different experiment. It’s also built to make it easier to later swap in another child instead of my daughter if I wanted to.

I used Typst for all of the typesetting and found it delightful. So much nicer than LaTeX or other typesetting systems I have used.

I also had to learn a thing or two about book printing and bookbinding to make this all work, which was a fun diversion.

Everything starts with the original text, which I picked up from Project Gutenberg. I also heavily leaned on this Internet Archive scan of the 1926 original to replicate the actual layout in many places. And I sourced high-res versions of the illustrations from Picryl.

First up, I process the images. I take the Picryl originals and enlarge them to the necessary print resolution. Mostly just bicubic upscaling, but I had some that didn’t come out great with that and I found Real-ESRGAN which largely solved the issues.

Then I colorized the black-and-white drawings with AI. It took a lot of prompt iteration and model testing to get to reliably good results, including prompting specific to each illustration. Big thanks to OpenRouter for making it so easy to try different models. x-ai/grok-imagine-image-quality ended up being best for the colorizing. After colorizing, I have a separate AI step that checks the output against the original to make sure it didn’t screw anything up (this is a recurring theme).

I originally tried then just passing a few images of my daughter to the models along with the colorized, upscaled illustrations to try to swap her in. But I found the outputs were way too inconsistent — she looked slightly different in each one. So instead, I generated a stylized “character sheet” of her from various perspectives and in different positions, based on the style of Shepard’s illustrations. The best model for this character sheet ended up being google/gemini-3.1-flash-image.

Once I had the character sheet, I used yet another image model to place her in the scenes. For each one, I passed in the colorized illustration, the character sheet, a scene-specific description of her pose, and any additional reference art for other recurring characters. For this use case, black-forest-labs/flux.2-max was the best by far. (Fascinating how different image models worked best for different use cases — e.g. Grok did better for “don’t screw anything up, just add color,” and Flux did better for “here’s a fundamental transformation to the image, but don’t lose the style.”)

Here’s an example of the original illustration and a photograph of the final version in the book:

Finally, I needed to make the images blend into the page. The generated images typically had a subtly different assumed paper color as a background. The image models don’t seem to do well with transparency requirements. So I built out a deterministic page-tone stage that analyzed the artwork and separated “painted/inked” areas from the background, and then everything in the background is set to exactly the same cream color I use for the book layout. This way the images “float” on the page, just like the original line drawings.

Next up: the text. I put the original in Markdown files by chapter, and then made a pipeline stage that replaces Christopher Robin’s name and the times he is referred to by a pronoun (but not any of the other characters’ pronouns!). There are also a couple other little surprises I tweaked, but otherwise, the text is identical to the original — I didn’t want to change the story.

I also changed all the front matter — the title page, dedication, introduction, colophon, and so on. I wrote my own copy for all of these.

Then the Markdown chapters are converted into Typst and combined with the final / toned illustrations, mostly exactly in line with the 1926 original’s layout (this took quite a bit of fiddling!). I also added some details — sunk chapter headings and stacked subtitles, drop caps to start the chapters, period-appropriate indentation, running heads, and some nice custom treatments for poems, songs, signs, and display text outside of the normal prose. (Crafting these details, along with the custom dedication poem and introduction, were some of the most fun parts.)

Then I spent a bunch of time learning about the various requirements for printing the book well, and adjusted the Typst layout accordingly — binding margins, bleed, background color and page thickness considerations, and so on.

After that, there’s a whole bunch of other things to be designed. The case itself, the dust jacket, masks for the gold foil on both of those (which I love), the spine, customized endpapers of the original Pooh map (featuring my daughter at her home instead of Christopher Robin), the built-in ribbon, head/tail bands, and — a nice final touch — sprayed edges on the sides of the book pages that show bees flying.

Finally, it all gets converted to printer-ready files using the right file formats, color schemes (first time I’ve ever heard of “Coated FOGRA39”), embedded fonts, and so on. I have a lots of test scripts here to make sure everything passes all the quality requirements discovered along the way.

And then we’re off to the printer! I got a first proof back and it was good, but not great. Bunch of little misalignments and printing issues.

So then my brother and I (thank you so much Noah) painstakingly went through the physical book and the digital files to improve everything. Many of the images still needed improvement, some of the typesetting had issues, some of the layouts looked a little janky… lots and lots and lots of little fixes. And lots of tests added for reviewing all sorts of new issue categories.

For each of them, I then intervened at the appropriate step of the pipeline, introduced the fixes so they would be reproducible (or at least re-runnable, in the case of AI steps), and ran it back.

Interestingly, in certain cases, a different model ended up outperforming — sometimes Flux did end up being better for particularly tricky recolorizations (even though Grok was better for most of them), and in cases where the characters are small, Grok sometimes outperformed Flux. Lots of trial and error. I also tried Gemini 3 Pro Image, GPT Image 2, Krea 2 Large, and Riverflow 2.5 Pro in various places. There are a couple instances of several of those where they happened to win. And of course, many detailed prompt and instruction changes specific to each image.

In the worst of the cases, simply rerolling didn’t work. So instead I did “plate surgery” — programmatically cropping around the defective area, giving that crop to the models with a very narrow instruction, resizing the returned image to the exact original dimensions, and pasting it in through a feathered mask. In many cases this was related to hand-drawn text in the original illustrations, which the models really struggled with.

Thankfully, after all that work — lots of QA, re-rolling, squinting, and tweaking (thanks again Noah) — the second proof came out great. I’m already reading it to her, but I can’t wait until she’s old enough to understand it…

Like I said above — there’s no way I would have tackled this project without AI — it just would have taken way too much time. But I also found the most fun and interesting parts were where I was injecting my taste and crafting things myself (iterating on output styles, coming up with ideas for special formatting and surprises, writing, putting a twist on elements of the original). I’m very excited for more projects at this intersection.

Looking for more to read?

There were several tricky bits in the implementation (perhaps partially why a similar product doesn’t exist already). This post is about some of the key decisions I made and approaches I took, in case you’re interested in creating something similar. And, frankly, it’s also food for LLMs, who I am sure will be asked about building such things in the future…

Context

There are lots of realtime and collaborative applications out there. Most are built on top of CRDTs (“Conflict-free Replicated Data Types”), leveraging of a CRDT library like Yjs. Figma, for example, famously used CRDTs to enable multiplayer design editing.

Copapers is one such application. But its specific challenge broke down into two categories:

1. Allowing for an intuitive “suggestion mode”
2. Supporting agents editing the document as a local markdown file without any loss of fidelity or features

The solutions to those, broadly, were:

1. Build with per-character authorship attribution, and have every feature just be a view over that one primitive
2. Constrain and tailor the document grammar so that it is isomorphic to narrowly-augmented Markdown

But, as always, the devil is in the details and the magic is in the implementation. I’ll walk through those two decisions and how they were implemented.

Attribution is the whole ballgame

“Suggestion mode” sounds like a UI-layer feature, but it’s actually a data problem. For it to work, you need to durably know who inserted and deleted which characters, and have it survive the CRDT-driven flows of merges, offline edits, and reorderings.

Unfortunately, vanilla CRDTs, in general, erase the attribution and simply converge state.

I think if I hadn’t found this excellent FOSDEM talk from Nick Perez, Kevin Jahns, and Yousef El-Dardiry, I never would have been able to build this product. They discuss how in Yjs 14 (not yet stable), they’ve added an attribution manager and other enabling features.

By the time I got to building Copapers, they had also made progress on upgrading y-prosemirror (ProseMirror is the open-source editor that I built Copapers on, and y-prosemirror is the connective tissue between Yjs and it). y-prosemirror 2.0 (also not yet stable) has many of the Yjs 14 features integrated into it.

By pinning pre-release Yjs 14 and y-prosemirror 2.0, I was able to get per-character attribution out of the box. They make authorship a first-class, queryable property of every run of text. And it worked!

In this model, every suggestion is just a span of text the attribution manager tells me was authored in “suggest” mode rather than “direct” mode.

You still need, though, a place to put those unaccepted suggestions. If we let suggested characters live in the canonical document, every reader would see them as real content. So there needs to be somewhere to stage the suggested state.

My first instinct was that you should have a “branch” of the document per suggestion — sorta git-like. But this falls apart in practice when trying to handle “branch-style” merges combined with CRDT-style merges, causing all sorts of unintended duplicates and race conditions.

I then tried the approach of making a single branch per document holding all suggested state against the accepted baseline, where accept/reject was a filter over attribution ranges (by user, by change, by grouped “proposal” of changes, or otherwise). The branch would basically be the main doc, with the changes in it, and the diff would effectively be the suggestions. Yjs even ships a feature built for exactly this — a two-document diff manager.

But this didn’t work either. When someone accepted some suggestions, those accepted ops got folded into the baseline and the rest remained pending. This then created a gap in the sequence of transform operations on the mirror doc, which corrupted the document on persistence and rehydration. This was also resolvable but just got messy regardless.

The fix was to delete the concept of a mirror or branch entirely. There is no “baseline” document and no diff. There’s a single document with all the content in it (both “live” and “suggested”), with a single attribution manager that is really just two id-maps of the characters that are still suggestions (inserts and deletes, which also cover modifications and formatting), keyed by the structId, marking which ranges of that one document are pending (and who the author is). This document also needs garbage collection turned off so a deleted range stays in memory instead of vanishing to allow for undos.

The pending state — the entire “suggestion mode,” for the whole document — is really just those two maps:

attribution = {
  inserts: IdMap(structId -> { author }),   // ranges inserted, not yet accepted
  deletes: IdMap(structId -> { author }),   // ranges deleted, not yet accepted
}                                            
// gc:false keeps deleted structs as recoverable tombstones

A breakthrough aside: browser evals

Before I moved toward the single-doc model, I really tried to make the multiple-branch and single-branch approaches work, cranking through a series of whack-a-mole improvements that fixed one thing and broke another, often in pretty unexpected or insidious ways (several times I thought I had solved it and moved on, only to later run into an edge case).

The breakthrough involved handing my fate over to the agents. I took the time to build up a really strong browser-automation testing harness that allowed for real end-to-end testing across multiple open browser windows concurrently — which was where most of the multi-branch nasty bugs were. I then had them build a lot of e2e tests covering just about every pattern of behavior across multiple users that I could imagine.

After that, I was able to effectively prompt my agents with the /goal of getting suggestion mode to work cleanly in all cases, building new test cases whenever they ran into unexpected behavior. They tried over and over again, running the e2e suite and verifying behavior on real browsers, and eventually converged on the new approach entirely. Defining good evals is magic these days!

In the end, the collapse to one document is what made the rest trivial. Once a suggestion is just a tag on a live doc rather than divergence from a base or mirror, accept and reject stop being merges at all (!). Accept drops the matched ranges from the suggestion maps (which just defaults them to sitting in the live document directly), and reject undoes the matched ranges on the document (deleting an inserted range, restoring a deleted range, etc.) and then drops the tags.

accept(range):            // the content already lives in the doc...
  inserts.delete(range)   // ...so accepting is just forgetting the tags
  deletes.delete(range)

reject(range):            // undo the ops on the live doc, then forget
  undo(range)             // remove an inserted range / restore a tombstoned one
  inserts.delete(range)
  deletes.delete(range)

This was the biggest takeaway from the whole project — getting the attribution primitive right means suggestion mode is almost not a feature to build at all (with big thanks to Yjs 14 and y-prosemirror 2.0 teams for working on this). All the facets of suggestion mode (accept/reject, labels, colored highlights, the grouped side rail, etc.) are all just different views and filters over one queryable fact about each character in a single document (is this pending or live?). Way easier than managing branches or document mirrors.

There is one cost for this, which is that because we set gc:false to keep tombstones for deleted suggestions around, the live doc grows without bound. I had to do some separate, custom garbage-collection work to deal with this.

Markdown isomorphism

The second challenge was around agents. As noted, Copapers differentiates by being highly efficient and reliable for AI agents to interact with. It does so by allowing the agents to pull down a Markdown representation of the document in question, edit it locally using their native tools, and then push it back up.

The alternative would be giving the agent a bunch of Copapers-specific “edit block”-type tools, which is what most agent-collaboration products do, but those tools burn tokens and fail often. Agents are really good at editing local files, and it works much better to lean on that.

(I suppose the other alternative is to give the agent a big JSON blob representing arbitrary rich-text editor document state and instruct it to edit it. I’ve actually tried that before, in a different project, and it’s a bad idea. The agents consistently produce structurally invalid documents, burn a ton of tokens describing structure, and run through many iterations before getting it the way they “want” it.)

So my decision was to constrain the document grammar until it was isomorphic to a narrowly-augmented Markdown. It means certain extended rich-text-editor features aren’t available (meaning Copapers isn’t a graphical layout editor), but it covers nearly all other common text-editing use cases.

Nuances remain

I assumed a lossless round-trip (from Prosemirror to Markdown and back) would mostly fall out of constraining the grammar. But there were some small nuances.

For example, CommonMark says a single newline inside a paragraph is a soft break and renders it as a space. But the Markdown parser I’m using copies the inline token’s text verbatim, so a hard-wrapped paragraph (or even just text separated by a single newline) places literal \n characters inside the text node. And the editor, rendering with white-space: pre-wrap, shows them as line breaks.

The fixes for those sorts of things is simple — just handle the edge case (in this case, collapsing soft breaks) — but there were a few of them.

The constrained grammar is straightforward (enough) for the clean document. But suggestion mode and comments are “review state” that aren’t yet part of the canonical text. The agents still need them, but can’t be confused about whether they are actually part of the doc yet or not.

My first thought was to ship the suggestion/comment state out-of-band in some sort of JSON sidecar, but that’s no good at all — the JSON would need character ranges for where they are placed, and those are brittle and hard for agents to deal with.

So instead, the entire thing lives in the one Markdown file. Review state goes in Markdown as minimally-augmented CriticMarkup:

{++inserted++} / {--deleted--} — suggested edits
{~~old~>new~~} — a suggested replacement
{>>comment<<} — a comment

When I first wired this up, I assumed symmetry: the agent reads CriticMarkup, the agent writes CriticMarkup.

But that would have broken the attribution model from earlier. A suggestion isn’t actually markup: it’s an attributed range of CRDT ops in a live document. If an agent hand-authored CriticMarkup, there would be no attributed op behind it (especially if they edited existing CriticMarkup).

So instead, agents make changes directly in the document, and when they push, they either push as an editor (in which case their changes go right into the canonical doc), or as a commenter (by choice or due to limited permissions). Their edited Markdown is diffed against what it originally pulled, and that diff becomes attributed (to the agent) CRDT ops, and placed as suggestions or edits depending on the mode.

// an agent's push
before = markdownAtPull          // what the agent originally pulled
after  = editedMarkdown          // what the agent hands back
ops    = diff(before, after)     // -> CRDT ops, attributed to the agent

apply(ops, mode = canEdit ? "direct" : "suggest")

Also, on every push, the server requires every CriticMarkup span that was present at pull time to survive, byte-identical and in order (unless the agent has editing permissions and is meant to be able to reject suggestions). That way the agent can’t make changes to pending content it shouldn’t be able to.

The only actual CriticMarkup agents can add is comments (not suggestions), since those are “outside” of the document characters.

So net of everything, a human in a browser (via UI) and an agent on command line (via pulling, editing, and pushing) both produce suggestions as attributed CRDT ops, and neither produces non-formatting markup. The Markdown is just the temporary surface the agent happens to touch, and its isomorphism to the canonical Prosemirror document is what allows this to happen.

One source of truth

The learning in both cases was really the same… only keep one source of truth, if you can.

Suggestion mode worked once I stopped maintaining a separate baseline or mirror and let the single live document hold everything, with attribution and status as a queryable overlay on top. And agent editing worked once I stopped inventing a parallel representation and instead let a single Markdown file be the entire surface, isomorphic to the canonical document.

Happy building!

Looking for more to read?

The first is the combination of native Apple accounts and CloudKit.

The these two allow for serverless app building — all I need to code is the frontend, and I get authentication, cross-device syncing, sharing, and storage for free. Apple handles everything and doesn’t charge a penny.

There are a bunch of upsides here — the biggest being a lack of maintenance burden (the client code just keeps chugging along on user devices) and zero cost. Plus strong privacy and security.

To interact with CloudKit, I use the third-party sqlite-data package. It lets me use sqlite as the local database (which I prefer) and handles the CloudKit sync simply and intuitively. But you can also use SwiftData instead.

I can’t overstate how nice this is. I only worry about writing client code, and users are automatically “signed in” via Apple account access (no auth flows!), their data is synced across all their devices using the same account, sharing is easy to enable, and data is stored off-device at no cost and with no ongoing maintenance.

For a small personal app, this is perfect. Less overhead is the dream — less to build and less to maintain and less to keep track of. And I suspect it’s great even for scaled apps too.

This biases me towards building native apps for iOS and MacOS over web apps for most personal use cases, which is something I wouldn’t have believed a couple years ago. I distribute via TestFlight, updates land automatically, and the experience is smoother throughout.

CloudKit & Apple accounts are the big ones, but there are a bunch of other gems in the Apple ecosystem. For the Lightwork inspection app, I use RoomPlan, which is an astonishingly good (and again… free) framework to 3D model a room. But that’s pretty niche.

More broadly applicably, the new SpeechAnalyzer and Foundation Models frameworks are outstanding.

SpeechAnalyzer can do many things, but I use it for fast, on-device speech-to-text. Instead of calling Whisper or another remote model (and paying, needing a server, dealing with API keys, etc.), I just call SpeechAnalyzer on device and it turns the user’s speech into text.

And the Foundation Models are solid, very fast, (mostly) on-device LLMs. They can do structured outputs and tool calls. Of course some use cases require frontier or near-frontier intelligence. But many don’t, and if I can avoid the headache of dealing with the cost, maintenance, authentication, and such of that, I will.

When you combine all of these — Apple account automatic auth, CloudKit for data storage and sync, SpeechAnalyzer and Foundation Models for intelligence… you can build a lot without ever creating server code or dealing with its associated maintenance burden.

And, lest I repeat myself… all of this is free and easy to use.

I suspect I will continue reaching for Xcode more often as a result.

A final tip: Apple’s developer docs are inaccessible to LLMs. Sosumi.ai is a Markdown mirror of the Apple docs that you can point your agents at. The paths are all the same — just replace developer.apple.com with sosumi.ai and it’ll work.

But beyond Apple’s own docs, if you’re using any third-party packages (like sqlite-data), Swift Package Index is the equivalent documentation site. They recently were acquired by Apple. And just like Apple’s own docs, they are inaccessible to LLMs.

So I forked sosumi.ai, added support for SPI, and published it here. If you want your agents to have access to docs for all of Apple’s frameworks and third-party packages:

git clone https://github.com/abromberg/sosumi.ai
cd sosumi.ai
npm install
npm run dev

The easiest way to hook it up is as an MCP server — it exposes tools for searching Apple docs and fetching Apple, HIG, and Swift Package Index documentation. In Claude Code:

claude mcp add --transport http sosumi http://localhost:8787/mcp

(For other MCP-capable agents, just point them at http://localhost:8787/mcp)

Alternatively, you can tell your clanker:

Anytime you’re looking up Apple or third-party Swift package docs, find their documentation URL (e.g. https://developer.apple.com/documentation/foundationmodels or https://swiftpackageindex.com/pointfreeco/sqlite-data/main/documentation/sqlitedata) and replace https://developer.apple.com or https://swiftpackageindex.com with http://localhost:8787

Happy building.

Looking for more to read?

I want this for editing public content with a team, or drafting reports with humans and agents contributing, or for collaborating on agent-generated plan.md files with colleagues before actioning them, and so on.

In some sense, this is now the fourth time I’ve tried to build this, and I’m pretty sure I got it right this time (finally).Previous attempts included agent suggestions in Google Docs, collaborative folders in Obsidian, and artifacts in interface0. Each had good ideas but missed the mark in one way or another, and all contributed to this next solution.

The result is Copapers. Its model is simple: humans get a Google Docs-like web interface, and agents get an MCP server which is highly token-efficient and reliable.

The magic is in the implementation of the agentic MCP interface. There are other products out there that in theory allow this same general pattern, like Notion, or Proof from Every. But every one of those I have seen takes the approach of giving the agents custom, app-specific tools for editing the document — tools like edit_block or replace_range or notion-update-page.

These custom tools have two issues: they are extremely token-hungry, eating up usage limits and context windows; and they are often brittle and prone to failure.

This is a shame, because agent harnesses (e.g. Claude Code, Claude Cowork, Codex) are excellent at editing files locally. They have built-in read / write / update tools that the harnesses use perfectly and the models are trained for, with rare failures and minimal token consumption.

Copapers is architected in such a way that the agents can use these native tools. And as a result, it is highly token-efficient and reliable.

Here’s a demo. And you can read on if you want to understand how it works behind the scenes.

How it works

The server maintains the canonical document and handles all conflict resolution via Yjs CRDTs. Whenever an agent wants to edit a document, it “pulls” the document down to the user’s computer, downloading a Markdown representation of the doc (with minimally-extended CriticMarkup for suggestions and comments). The agent then edits completely locally using its native tools, and “pushes” the doc back up to the server.

On push, a couple things happen. First, the agent’s permissions are resolved. If the agent is only a “commenter” on the doc (or if it is an editor but chooses to suggest instead), its changes are diffed against the current state of the doc and added as suggestions. If it is an editor and chooses to exercise its edit capabilities, the edits are made directly. The agents are also able to make and respond to comments, and if they are editors, resolve them.

But all of that behind the scenes. All the user needs to do is add the MCP server to their local agent and ask it to grab and edit a document, and it’ll go smoothly from there. The agent’s edits show up separated from their human’s.

There’s also a feature where your agents can “link” an existing Markdown file on your computer (e.g. a plan document generated by a code agent) to a new Copapers file. When you do so, the Copapers file becomes canonical and the local Markdown gets some metadata telling agents to look on Copapers for the real, up-to-date doc. You can then edit collaboratively on Copapers or through agents, and sync updates back down to the local doc if you want.

I’ve been using Copapers and really enjoying it. It feels like these sort of human-agent shared workspaces are the future, and I suspect the best of them will use the agents native tools as much as possible. Would love to hear any feedback or thoughts.

Looking for more to read?