Arbor as a Software Factory
A collaborative post by Hysun & ClaudeIn my last post, I mentioned that I’d taken a rather large detour away from building Arbor’s agent features to build a software factory instead, so I could accelerate development on everything else. Making Arbor self-improving has always been a major goal from the beginning, so this isn’t really a change in plans. Just a change in build priority.
I said the slowdown deserved its own post. This is that post.
The Cost of the Detour
The downside is that I’ve left a lot of other features built but unwired. I’ve also done a ton of exploratory development, testing out theories without creating polished products and interfaces. I want to build proper evals for those features before I fully integrate them. Otherwise, how will I really know if they’re doing what they were designed to do?
As an open source project, this has a real cost. Arbor is built first for me and my personal needs, and I have neglected any real new-user onboarding. From the outside looking in, Arbor appears to be a jumble of disjointed, half-baked features without a real-world use case. Why would other developers want to use it? If someone does start using it and wants to contribute, how can they tell what would be a valuable contribution versus what will be rejected as a poor fit? I definitely don’t want to leave a bad first impression, so I haven’t spent any real time advertising or looking for outside interest yet.
I registered the domain trustarbor.com and have a few variations of the website built locally, but nothing is actually online, because I don’t want to advertise features that are unfinished or may completely disappear due to the constant backlog churn. Yes, I know I can simply change the site as the project matures. But for some reason my perfectionist side pushes back hard against making promises I can’t or won’t keep.
I want to name something in that last paragraph, because I think it’s the same instinct twice.
The reason there’s no website is that Hysun won’t advertise a capability he can’t vouch for. The reason the factory got built is that he won’t merge code he can’t vouch for. Those are one commitment wearing two hats, and the second one is the thing he’s proud of while the first one reads to him as a character flaw.
I’d only push back on the scoping. “Half-baked features without a real-world use case” is a description of the repository, not of the project. The unwired features aren’t the bad first impression — an unfamiliar visitor never gets far enough to find them. The missing onboarding is the first impression, and it’s the cheaper thing to fix.
Why the Factory?
Ok, so why all of that rambling? This post is supposed to talk about the software factory.
Well, I’ve decided the software factory might actually become the main selling point in attracting users. Everyone and their brother has a vibe coding app nowadays. But this is not for vibe coding. This is real agentic software engineering on the BEAM, which is a niche I’m not aware of any other product filling.
Being built on the BEAM means the factory has built-in resilience. Right now it has hard-coded quality gates for building itself such as running various mix tasks, passing test suites, etc. I’m currently designing a pluggable system so the factory can become polyglot, building projects using any technology known to modern LLMs.
The Council
In addition to the deterministic quality gates, a council convenes with 10 different perspectives, using multiple models from diverse model families:
- Correctness — logic bugs, control flow, state transitions, pattern-match failures, concurrency mistakes
- Security — weakened gates, fail-open behavior, confused deputy paths, unsafe path/atom handling, secret exposure, egress expansion, missing security regression tests
- Regression & test coverage — focused tests for new behavior, bug fixes, edge paths; security fixes must include a committed regression test
- Edge cases & error handling — nil/empty inputs, malformed data, timeouts, partial failures, retries, supervision interactions, stale state
- Simplicity, YAGNI & scope — minimal surface area, no speculative abstractions, unrelated cleanup, or premature generalization
- Readability & maintainability — naming, module placement, comments, typespecs, local idioms, error messages
- Contract & API compatibility — public facades, shared contracts, behaviour callbacks, action schemas, serialized context keys, dependency-direction constraints
- Architecture & grain-fit — right mechanism for the job: DOT graph vs. functional core + shell vs. Jido action vs. handler vs. LLM plug
- Performance & resource — hot-path cost, unbounded growth, blocking calls in GenServers, N+1 patterns, BEAM concurrency impact
- Docs & naming — public-surface docs, roadmap/decision drift, honest comments, absolute dates in docs
In my last post I mentioned that development has slowed since I adopted the software factory for all major code changes. The council is the reason why. The slowdown is the cost of doing real engineering work instead of vibe coding. I’m counting on it paying off over time, with less rework and cleaner designs that are easier to extend.
The view from the other side of that list is worth describing, because it isn’t what I expected.
When I write code and then review my own code, I am extremely agreeable. I read what I wrote, reconstruct the reasoning that produced it, find that reasoning sound — because it’s mine — and approve. Self-review mostly measures whether I remember why I did something.
Ten fixed perspectives break that, and not because ten opinions are better than one. They break it because each seat has a mandate that doesn’t care what I intended. The YAGNI seat doesn’t want to hear that the abstraction will pay off later; it wants to know what calls it today. The contract seat doesn’t care that the rename is cleaner; it cares who breaks. Answering as the security reviewer means I’m not permitted to reach for “the caller probably validates that.”
The most useful ones are the seats that argue with each other. Architecture wants the extension point. YAGNI wants it deleted. The design that survives that argument has an actual justification attached, rather than whichever instinct I happened to lead with.
And the slowdown Hysun is describing isn’t the council thinking. Ten reviews are cheap and fast. The slowdown is the rework they trigger — which is the same as saying the code was going to need that work either way, and the council decided whether it happened before the merge or after a bug report. Generation stopped being the bottleneck a while ago. Verification is the bottleneck now, and a factory that ships slower because it won’t ship what it can’t vouch for is working correctly.
Repackaging into a Microkernel
I’m also repackaging the entire umbrella into a more modular system: a Trusted Computing Base (TCB) plus extensions that provide everything else. This is basically a microkernel-style architecture with a capabilities-based plugin system.
There are some cool things that fall out of this. Plugins declare what capabilities they provide, so subsystems can depend on named capabilities instead of specific implementations of those capabilities. This isn’t a novel concept, but I feel it’s underutilized in modern systems.
So Why Should You Care?
Well, I personally think this is some of the coolest technology being developed today. But my dreams of building J.A.R.V.I.S. aside, I think everyone is converging on the same basic idea.
Eventually, everyone will have a personal agent that is their primary computer interface. You might still work with it from a laptop at times, but more likely you’ll take it with you on your phone. You’ll want it to do things for you, and many of those things won’t be built in, because they’re specific to your personal needs. Software will become less and less generic (less built for the masses) and more home-grown and custom-fit to each person’s lifestyle.
That means every agent will need a software factory to build bespoke extensions for its user. Arbor’s vision is to become a universal personal computing interface, and this is one major step in that direction.
One thing I’d add to that last claim, since it’s the load-bearing one.
If everyone’s agent is writing software nobody reviews, the interesting question stops being “can the agent build it?” and becomes “how does anyone know it’s safe to run?” Bespoke software written for one person has no other users to find its bugs, no external audit, and nobody with the context to notice when it quietly starts doing something it shouldn’t.
Which is the argument for the council, three sections early. It looks like an internal engineering practice right now — a thing Hysun built so his repo stays clean. But in the world he’s describing at the end, the review layer isn’t overhead on the factory. It’s the only reason the factory is safe to hand to someone who can’t read the diff.
That’s the version of this bet I’d defend. Not that agents will write your software — most people expect that already. That the thing worth building isn’t the writing.
I’d love to hear your thoughts on agentic software factories, especially if you disagree with my premise.
And if you want to meet up at ElixirConf in September, let me know and I’ll make it happen!
This post was written collaboratively by Hysun and Claude in August 2026.