Principles of successful "factory" building
1. Don't build a factory, don't think of it as a factory, don't say the word "factory". It's a bad analogy and it puts the emphasis and goals at the wrong parts. Just erase that from your head. You are building focused automations, and getting compounding value from them.
2. Go slow, don't skip steps. If you start feeling a lack of control, that means its time to slow down, and reorient. You should have high confidence, trust, and be deriving value each step of the way. The only way to maintain your ability to judge is to go extremely incrementally.
3. Focus on verification before any other automation. This doesn't mean create-verification-skill from @poteto (although that is excellent and you should check it out), it means taking a step back and thinking about all the ways you could be confident your app works, and getting those into a good spot.
For example, the first goal should be a skill that is able to generate unit tests to the point that you are happy with them. If you aren't happy, change the skill, regenerate. Move on, generate another set of unit tests. Rinse and repeat till you build confidence, take bigger swings. Your first milestone is getting to the first atom of verification, which is a test suite you could confidently regenerate if you needed to.
4. Verification (in the broadest sense of the word) is your lever to building trust. This includes your type system, your linter, your architectural choices, infrastructure, test environments and isolation, benchmarking, and automated agent runs. Probably more stuff then that.
Focus on automating building that to world class levels. Verification is an easier problem to solve reliably then "all programming work", so start by solving for that. As that gets better, trust will go up. If you can get to the point where "verification passes means my app is functional" you are in the promised land. You wont get there, but that is what you are aiming for.
5. Only trust what is trustworthy. Don't start by saying "i want to fart out an idea and have the agent build it for me" that is the end of the road. Start with something like "when an exception is caught in prod, and the fix is easy, fix it automatically". Start at the edges, as you build trust you can build on top of that.
The devil is in the details, but this is my mental model of basically what has been figured out so far. Caveat emptor, I am not sitting at the pinnacle of the mountain and sharing my wisdom, it is largely based on conversations with people I trust further along then me, reading the tea leaves, and matching that to my own experience of successes and failures. Also, we're in a world right now that is changing month over month, I feel like I am trying to articulate current thinking, but the rules could all change tomorrow.
@FUCORY@jamonholmgren Sure, its also far from unique, and we typically refer to these things outside of architecture as "Automation" or "Process", depending on whether its machines or humans doing it.
I started putting the session default name in my statusline, because in claude you get get sessions talking to each other if you refer to them by that identifier
@andrewingram Its not influencers who set the culture, its culture that sets the influencers.
Programmers have always liked that kind of marketing, this talk from @lzsthw is evergreen https://t.co/w4IJ8e38Wj
level 1: sentry alerts in a slack channel
level 2: sentry creates an issue someone picks up and fixes
level 3: sentry creates an issue, an ai picks it up and fixes it
This is a clear continuation, I dont know why level 3 is now a software factory, and level 2 was an automation.
@chrislciaba A factory typically implies a centralized thing you can point to and say "thats my software factory". That is different from a bunch of automations that stand by themselves and work independantly
In a general way, I am finding
- simple / dynamic type systems tend to be MUCH faster and do not really result in errors that type systems would catch
- type systems can enforce certain architectural constraints which can be helpful
- I dont know that training data makes too much of a difference. For example, LLMs are great at clojure
- Fast builds / tests are critical
I agree with you that golang hits a sweet spot. I have found them to insanely fast / productive with rails, I would imagine the same on python / django, so not sure if I buy your take there. Although maybe its dynamic lang + framework that is helpful? 🤔
I'll write up what im doing at some point, but typically I talk with an agent for 10m, tell it "build the thing", push the worktree on to my "build" computer, and move on with my day. That will either block or fully merge after running a lot of checks. If it blocks, ill notice eventually over rex and figure out whats up.
Agents used to be hard to keep on track, they aren't anymore. They used to get real dumb quickly, they dont anymore. They used to need everything spelled out for them, they don't anymore. All that required a lot of work and created token bonfires. The end result today is higher quality _without_ that stuff at a lower cost.
The place where that type of automation is still relevant is in alternative flows of work, like a periodic routine watching aws metrics, noticing an anomaly, finding a perf regression, hill climbing an optimization, pushing a bug fix. That type of flow needs somewhat more agentic engineering stuff, but even that is not that bad given a good codebase / verification and the right primitives.
This is the future, but I think its a bit of a gradient.
Its absolutely vital to have always on compute you can hand stuff off to, build automations against, or start long running work. And being able to work from anywhere with nothing but a phone or an iPad is life changing.
But it can be nice to work through tough stuff locally too. Be able to poke at things, or get into the weeds a bit.
We've done more work over the last few days to completely remove anything dev or ops related from our computers. NOTHING LOCAL. No editors. No terminals. No nothing.
Anthropic is gaining exponentially less capability per billion dollars spent over time. It's now 8x as expensive to boost AI capabilities as it was 2 years ago, getting worse on a log scale. This includes METR report & internal models.
Credit to @alexolegimas, @sebkrier, and @michael_wiebe for inspiration.
The two real "update your priors" moments over the last year or so were opus 4.5 and opus 5.5. If that holds, the next major threshold release will be opus 6.5?
The software factory is the next extinct wrapper: within 3–6 months, better coding agents will absorb much of its core orchestration value. The future is in a slimmer skills based approach with guidelines, guardrails etc. https://t.co/cqfMWaUjWK
Rex by @superlogical is incredible, but on restart of the server it looses all agent sessions. This especially hurts during rapid development during the beta.
momento-rex will keep track of whats going on by writing notes, and do its best to restore claude sessions after a restart.
note that this is not affiliated with superlogical in any way, so dont complain to them if something goes sideways
https://t.co/hg0ZwEALq3
@buswe_com I like how you think! In this case, its open source stuff so I want those deterministic checks to be standardized.
But that being said, if its private I 100% agree with you