Dee and I have been spending our weekends doing some weird stealth-mode coding experiments lately. I’ll keep the actual product concept under wraps for now — intellectual property, potential stealth venture stuff, you know the drill — but while the what has to stay locked up, the how is far too interesting not to write about. It’s changing how we work together, and we’ve already used it to blow the dust off a legacy open-source project of mine that I thought was dead and buried.

It’s also, on closer inspection, doing something I’ve spent two posts on this site arguing against. More on that in a bit.

Reclaiming the tech: our local setup

I’ve written elsewhere about my distaste for the billionaire class shoving AI slop down our throats. And sure, the corporate, techno-feudalist vision of this technology is exhausting. But there’s a real difference between renting a clinical, lock-in SaaS platform and wiring your own tools together for your own innovation.

When Dee and I started hacking on this, the two things I wanted to avoid were isolated web chats on two laptops, and all the technical work falling on my shoulders. If we’re both building and her agent has no idea what my agent is doing, we’re just going to spend half the weekend fighting stupid merge conflicts.

As an experiment, and it’s all an experiment, we anchored our work around Piyaz (piyaz.ai) — open source, running on our own hardware, and exposed to both of us as an MCP server.

Piyaz isn’t a model, and it isn’t a chat client. It sits above both. You hand it a lump of intent and it decomposes that into tasks, plans the implementation, attaches acceptance criteria, and then tracks the dependencies, decisions, and execution records as the work actually moves. When one of our agents picks up a task, Piyaz gives it the context required to build the thing properly: what it’s for, what’s already been decided, what “done” is supposed to look like.

The part that matters for the two of us is that it spans sessions and teammates. Dee’s agent and my agents are pulling from the same task graph, so when she starts on something, my side already knows it exists, what it depends on, and what it’s meant to satisfy. That graph is the shared “world model” I’ll keep referring to — and, as it turns out, the thing worth thinking hardest about.

Dee’s side: Figma to frontend in Claude Desktop

Dee is a pragmatist with an artistic eye but would not call herself a designer - or a coder. Still, she is able to assemble screens in Figma, tweak spacing, fonts, colours, and make screens and components that actually look good. Because the Figma MCP is connected, she has a workflow that honestly feels a bit ridiculous:

1. She designs a component in Figma — say, a responsive layout or an interactive metrics dashboard — using clean, semantic Auto Layouts.
2. In Claude Desktop, she tells her agent: “Go look at the #MetricsDashboard frame in my Figma file. Implement that as a React component in our codebase using our local Tailwind and Vanilla CSS files.”
3. Her agent reaches out through MCP, inspects the Figma node attributes, grabs the exact margins, fonts, and hex codes, and writes the code straight into the project.
4. In Claude Desktop, she can start and stop the dev server. I’ve setup everything in the project to be local-first: Docker Compose for database, caches, file-stores. With the server running, she can see what it looks like in the browser.
5. When she’s happy, she asks Claude to branch, commit, push and raise a merge request.

It skips the entire “developer handoff” stage. She doesn’t spend hours translating visual decisions into boilerplate CSS. She designs the visual architecture, and her agent writes the code to match it.

My side: herdr (basically tmux for agents)

I, on the other hand, am a terminal purist. I don’t want Claude Desktop. I don’t want a heavy, rigid GUI. I want my models sitting right next to my vim buffers and my git commands.

So I’m using herdr, which I describe to people as “tmux for agents.”

If you’ve used tmux you know how good it is to split a terminal into persistent, side-by-side panes. herdr does that, but it knows what an agent is: each pane’s process gets tracked as working, idle, or blocked, and shown in a sidebar. One pane running the test suite and watching for errors. One pane refactoring a messy database query. One pane on logs.

And because my CLI agents connect back to the same Piyaz instance as Dee’s Claude Desktop, they share her backend context. If her agent changes a frontend component prop and breaks an API endpoint, my terminal agent picks up the test failure, pulls her new component schema, and fixes the backend to match.

Hold that last sentence in your head. We’ll come back to it.

Blowing the dust off Openlumify

To really test the setup, we pointed it at one of my old open-source projects: Openlumify.

The lineage is a small tragedy of its own. It started as an Apache-licensed intelligence-amplification platform called Lumify — import a pile of data about “stuff”, then explore connections as a graph, proximity on a map, and events on a timeline. It got absorbed into Altamira, renamed to Visallo, and then the source was closed. What I have is a fork of a fork, and I’ve been quietly obsessed with keeping it open ever since.

I wrote about trying to revive it back in January 2020, where the headline achievement was getting it to build at all. If that doesn’t sound like much, you’ve never opened a multi-module Maven project from 2015. The product site I put up at the time has since gone dark; the GitHub org is still there. Then life got busy, as it does, and it went back to sleep for six years.

Last Sunday we decided to see if our agents could handle the autopsy.

In a single afternoon, my herdr agents mapped the legacy backend dependencies, proposed a modern migration path, and helped me start pulling the heavy data pipelines apart. Meanwhile Dee redesigned the core graph visualisation in Figma, and her agent built the React components against a high-performance Canvas library. The agents held context I’d forgotten entirely — six-year-old configuration decisions I made and never wrote down.

Three weeks of soul-crushing dependency archaeology, done in an afternoon.

Except — I want to be careful here, because that sentence is doing a lot of work and I can’t fully back it.

What I know is that we made more visible progress in four hours than I’d made in the previous six years, which is a low bar given the previous six years were zero. What I’m taking on faith is that the migration path is sound, that the dependency map is accurate, and that the whole thing survives contact with an actual build. “Three weeks” is a number I made up by imagining how long it would have taken me, in a mood, while tired.

There’s a METR study from 2025 that lives rent-free in my head for exactly this reason. Sixteen experienced developers, working on mature codebases they averaged five years in. They estimated AI tools made them 20% faster. Measured, they were 19% slower. The gap between the two numbers is the entire finding, and it isn’t a story about bad tools — it’s a story about how badly we read our own productivity.

In fairness, METR has since flagged that result as historical and redesigned the experiment; the tools have moved a long way since early 2025. I’m not wielding it as a gotcha. I’m noting that I am a sample size of one, on a Sunday, with a feeling.

Then I went looking for the bulkhead

Here’s the sentence I asked you to hold on to:

If her agent changes a frontend component prop and breaks an API endpoint, my terminal agent picks up the test failure, pulls her new component schema, and fixes the backend to match.

I wrote that as the best part of the setup. Then I read it again, with the isolation post still fresh, and felt slightly ill.

That’s an unreviewed, cross-domain write, in a domain the agent doesn’t own, triggered automatically by another agent’s change. It’s precisely the thing I spent a whole post building NetworkPolicies and IAM boundaries to prevent. In that post I was pleased that a hardcoded production connection string would be rejected at the IAM level — that the platform would stop a mistake regardless of who made it or how confidently. Here, two agents are silently reshaping each other’s territory until they agree, and I called it a feature.

And agreement is not correctness.

If Dee’s agent renames a prop by mistake — a typo, a misread Figma layer, a hallucinated convention — my agent will obligingly reshape the backend until the tests go green. Nothing is broken. Everything matches. The system is now consistently wrong, and the shared world model didn’t catch the error, it propagated it.

The bulkhead I removed was the merge conflict. And the merge conflict, it turns out, was information. It was the system telling me that two people held incompatible beliefs about the same interface — which is exactly the moment you want a human to look up.

So why hasn’t it bitten us?

I went looking for an incident to write up here and I don’t have one. Nothing has gone wrong yet.

For a while I took that as evidence the setup is sound. It isn’t. It’s evidence that I haven’t actually removed myself from the loop. I’ve been reviewing the diffs. I’ve been running the interactive chats rather than letting things loop unattended. Dee is sitting three metres away and says “hang on, that’s not what I meant” out loud, in the room, in real time.

The bulkhead isn’t in the software.

The bulkhead is two people in a lounge room on a Sunday, with no users, no production traffic, no customer data, and nothing that breaks if we’re wrong for an hour. That’s a real control. It’s just not a platform guarantee — it’s human attention, which doesn’t scale, doesn’t persist overnight, doesn’t survive a third participant, and is at its absolute worst at 5pm on a Friday.

I’ve been calling this an autonomous workflow. It’s a supervised one with the training wheels still bolted on, and it works because of the training wheels.

What changes on Monday

Which brings me to the uncomfortable part, because the tooling I use on the weekend is the tooling I use at work, and the blast radius is not remotely the same.

On Sunday, the worst case is a graph visualisation renders badly and I fix it over coffee. During the week I lead engineering on a pay-compliance platform. Wrong numbers there don’t render badly. They mean somebody doesn’t get paid what they’re owed, and the failure mode of “two components confidently agreeing on the wrong schema” stops being a curiosity and becomes a very serious conversation with people who have every right to be angry.

Same agents. Same shared context. Utterly different consequences.

So the honest answer to “do I still need to read the code?” — the question I’ve been circling for months — is: you can stop reading exactly as far as you’ve built a boundary that makes not-reading safe, and not one step further. Not as far as the tools can technically run without you. As far as the guardrails actually hold.

On Openlumify, that boundary is my own attention, and I should stop pretending otherwise. At work it has to be something that survives me being on leave: quotas and NetworkPolicies, decisions written down with their reasoning attached so an agent can’t cheerfully undo a constraint it never knew existed, contracts that fail loudly instead of reconciling quietly, and tests written by someone who isn’t the thing being tested.

That last one is the piece I keep coming back to. If the agent writes the code and the tests, you haven’t automated the review — you’ve removed it, and put something review-shaped in its place. Two agents agreeing with each other is not a second opinion. It’s an echo.

Hacking as a couple in 2026

None of which has made the weekends any less fun.

Coding with your partner has always been a special kind of chaotic — a lot of yelling across the living room about broken commits and mismatched payloads. This is genuinely different. We’re not pair-programming; we’re running a tiny two-person studio where most of the tedious middle bit happens on its own, and we get to spend the time on architecture and UX and the parts we actually enjoy.

I’m not down on any of this. I’m enthusiastic in a way I haven’t been about tooling in years, and Openlumify is properly alive again for the first time since 2020.

I just want to be clear-eyed about which parts are engineering and which parts are two people in a room paying attention. Right now it’s mostly the second one, and the trick over the next few months is converting as much of it as possible into the first — before I’m tempted to run this at a scale where nobody’s watching.

The freedom to break things safely is still the goal. It’s just that “safely” was always the load-bearing word, and it now has to stretch to cover actors that never get tired, never get bored, and feel absolutely nothing when they touch the authorisation logic.

---

Are you hacking with a partner, or running local multi-agent setups? I’d love to hear what your workflow looks like — and especially what’s gone wrong with it.

---

This article was written with drafting and grammar assistance provided by AI. I take full responsibility for the content, including any and all errors. And I’m human, I think!