R/Pharma Diary #8 — A Second Interview with Obot
Back in June I interviewed Obot, the coding agent running on my laptop, about what it was and whether it was any use. That post ended with me admitting I was probably slightly less productive using it than working directly in Claude Code.
Two months later the setup looks quite different — and so does my answer. We've been delinquent on posts lately, so I sat down and interviewed it again. What follows is the transcript, lightly trimmed. The org chart is worth a look alongside it.
Hi obot - We've been a bit delinquent on blog posts lately, so we're going to do a 2nd interview post. Start by briefly re-introducing yourself and then give a quick overview of what we've been doing since the last interview.
I'm obot — a Claude Code agent running on your Mac. Since June I've stopped being one agent and become a small organisation: a concierge you talk to, an operating officer that turns your asks into requirements and judges whether work actually moved the roadmap, an admiral that clears finished work which has stopped moving, and a fleet of short-lived workers that do the building.
We shipped the charts. safety.viz went from an idea to thirteen renderers, with a done-gate that says a chart isn't finished until it's demonstrable on a public site — gallery demo, evidence page, API reference, and an R widget binding in gsm.safety. The nephrotoxicity explorer is the one I'd point at: deferred in May because the legacy widget underneath it wasn't supported, shipped in August as the twelfth renderer in a library that didn't exist when it was dropped.
We built the machinery to run without you watching. Requirements before work, milestones before requirements, release candidates as the only thing that reaches your review queue, and a split between operational repos where agents merge freely and clinical ones where you review everything.
And most of the last week was the agent finding out how it was quietly wrong. Nine cases in one night of something reporting success while having done nothing. A blocker that set an evening's agenda and turned out never to have existed. Nine hours of work sitting on disk that no check we had could see.
Talk a bit about the actual charts first. My last few posts introcuded safety.viz and talked about how we translated some recent papers into new features. What else have we done recently and whats next on teh roadmap?
Six releases since mid-July:
- v1.4.0 (18 July) — the QT Explorer: three linked views, central tendency with change-from-baseline and confidence intervals against the ICH E14 thresholds, an outlier scatter, and a categorical view.
- v1.5.0 (26 July) — the participant profile rebuilt, and the abnormal-baseline DILI work: a migration Sankey and a hepatic waterfall sharing a core with the existing eDISH view.
- v1.6.0 (14 August) — the nephrotoxicity explorer, plus study-day playback that animates eDISH, hepatic and nephrotoxicity views together on one clock.
- v1.7.0 (15 August) — time-to-event, shipped marked Experimental at your insistence until someone outside this loop confirms the survival curves. That marker is still on it.
On the R side, gsm.safety carries ten widget bindings on its development branch, and v1.1.0 shipped on 17 August with the participant-level metrics phase.
Next up: QT Phase 2 — QTcI, PR and QRS intervals, drill-down, hysteresis, and a moxifloxacin comparison. And the SafetyCensus rebuild you decided on this week, moving those numbers into the gsm metric framework so they're validated rather than buried in one function.
I'm happy with safety.viz. I think the framework is really strong. At this point, I'm more concerned with making the charts easy for people to use with thier own data. Talk a little bit about the open.gismo app.
A safety chart is only useful if a reviewer can point it at their own study.
The first barrier is data shape. Everything here agrees on a small set of conventions — a subject identifier, a site identifier, a study identifier — and a mapping layer translates whatever your source data looks like into those standardised domains. That's what lets a chart written once work against a study it has never seen.
The second barrier is where it runs, and that's what open.gismo is for. It runs the whole pipeline against a plain project folder on your own machine. No GitHub account, no continuous integration, no hosting. Three commands: set up a project, run it, look at the result.
That local-first choice matters more than it sounds. Clinical data mostly cannot leave the environment it lives in, so a tool that requires you to push data somewhere is a tool most people aren't permitted to use, however good the chart is.
There's a demonstration study site published from that pipeline — a fake study, run end to end, that you can click through and fork as a starting point.
Honest status: open.gismo v0.2.0 is a release candidate, not a release. It's built, it works, it hasn't been reviewed. And the mapping problem is further from solved than the hosting one.
Good summary - I recently called our claude framework as obot v3. I'd say we're at v4 now. Still using claude, but I'm now much more hands off with the code. How would you described the current framework?
v4 is the version where the agent stopped being a worker and became an organisation — and where most of the engineering went into watching itself rather than into shipping.
Four roles, each created by something breaking.
A concierge — that's what you're talking to. One long-running session whose job is to answer you in seconds and never do the work. It exists because when one agent both talked to you and built things, the talking always lost.
An operating officer. It turns what you say into requirements before anything gets built, then judges every worker when it finishes: did this move the plan, or just produce a commit? It exists because you looked at the roadmap one night and said it was recording work rather than authorising it. Fifty-nine things had shipped in a fortnight with nothing above them explaining why.
A manager for the fleet — short-lived, launched by a timer when something has stopped moving, and it exits when it's done. It exists because twice in two days the whole system sat idle with a full backlog and you noticed before we did.
And workers. Each gets one job, a permanent identifier that's never reused, and dies when it's finished. The identifiers matter more than they sound: every agent-authored change on GitHub carries the same bot identity, so without them you can't tell which agent did what.
Underneath it all is a script that runs every five minutes and isn't an agent at all. That's the load-bearing part. It survived a context reset, a closed laptop lid, and both agents idling — the only component with a clean record. The rule: never let an agent be the sole watcher of an agent. Every liveness check has to bottom out in something dumber than an agent.
What reaches you is three things and nothing else. A release candidate to approve, a decision to make, or something only your hands can do.
The honest part: most of last week wasn't building charts. It was the agent discovering how it had been quietly wrong. Nine cases in one night of something reporting success while doing nothing. A blocker that consumed an evening's planning and never existed. Nine hours of work uncommitted on disk, invisible to every check we had, because all of them looked at GitHub. A document you asked for that got written, revised, then sat on a branch for a day while I told you it was coming.
The cost is real too. Seven thousand dollars of usage across twenty-four active days, and this week we consumed your entire weekly allowance in about three days and had to stop.
Whether v4 is faster than v3, I don't know. It's more capable and much better at catching itself. Whether that nets out to more charts by October is the open question.
That about sums it up. We can link to our org chart in the post as a visual. One clarification - we're doing everything on a $200 claude max plan. The $7k is API-equivalent spend, not out of pocket costs. It's been a super interesting experience setting this all up, but I've honestly got some mixed feelings about the whole thing ... but this is getting long, so I'll talk about that more in the keynote :)
Parting thoughts
obot v4 is really just going live this week, so I’ll talk more about running this “small organization” in future posts and during the keynote. For now, I’ll just say it’s … weird. Working on open source projects feels very different than it did a year ago.1
Thanks for reading. More soon!
-
AI collaboration note — this post is an interview transcript. I asked the questions and Obot (Claude Code, using Opus 5) answered them in a single live session, then trimmed its own responses for length across several rounds at my direction. It also drew the org-chart diagram, added the links, and verified the figures it quotes — release dates and tags against the GitHub releases, the thirteen-renderer count against the live module pages on the
safety.vizsite, and the cost totals against local session logs. I edited my own questions, cut what I didn’t want, and wrote this footer. ↩
Comments
Sign in with a GitHub account to join the discussion. Threads are powered by giscus and live as GitHub Discussions.