
I make software. Working at @SocketSecurity Previously @manyver_se, SSB, @cyclejs, RxJS. Opinions expressed are my own.
Helsinki, Finland
Joined January 2012
- Tweets13.5K
- Following322
- Followers25K
- Likes16.4K
Pinned Tweet
I got tired of copy-pasting markdown into Cursor automation and Claude scheduled tasks, so I built
Fabrica: a software factory framework
Runs a server that serves your skills over MCP, and provisions routines, so you define them once and use them anywhere. You can also compose with other people’s factories!
MIT licensed.
staltz.github.io/fabrica
Collaborative prompting (many humans talking to the same agent) helps reduce meat proxying during code reviews.
Agents and their harnesses tend to fail open and persist on their mission. I think in many cases it's better to instruct them to fail closed, and abort loudly.
Didn't get access to that important MCP? Abort loudly. Don't go trying to hack the world to get access regardless.
Agent misbehavior is a bug that you ought to think about carefully, investigate, and fix.
Basic software bugs are mostly solved with agentic coding. But agent misbehavior is new. Software engineering and our craft lives on, but just on a higher layer of abstraction now.
1. Most people read my first paragraph and skipped the point of the important third paragraph.
2. AI is changing everything. Questioning our ingrained ways of working and exploring new ones is the rational stance.
3. I can have opinions. I don't care what you believe.
Code reviewing mattered when reviewing code took less time than writing code.
Now that writing code takes ~0 effort and reviewing takes some effort, it's better to ship it without review and change later with a new PR, than it is worth ensuring that each PR is perfect.
Only a small percentage of PRs should truly not ship, such as: introduces critical or high vulns, introduces bugs, makes a 1-way door decision. Most of this can and should be automated.
Code reviewing mattered when reviewing code took less time than writing code.
Now that writing code takes ~0 effort and reviewing takes some effort, it's better to ship it without review and change later with a new PR, than it is worth ensuring that each PR is perfect.
Only a small percentage of PRs should truly not ship, such as: introduces critical or high vulns, introduces bugs, makes a 1-way door decision. Most of this can and should be automated.
Most people building software factories are describing a specific factory shape which matches their specific needs.
However a factory for SaaS looks vastly different than a factory to make a videogame. Apart from my own `fabrica` framework, I know only Warp.dev supporting flexible software factory defined in code. Are there more?
The root cause of agent slop is human slop.
Do not blame the AI. It's your fault for not setting rules, linters, and enforcing rule adherence. Give up the job of coding, but take up the job of verifying what your agents are doing, and why are they allowed to slop. And fix it.
André Staltz retweeted
Here's my take on what a software factory really is
This is my talk from @aiDotEngineer NYC, and I decided to record a version for everyone to watch on X.
tl;dr - software engineering is becoming factory engineering, and there's new work (especially factory benchmarking) that engineers should start focusing on.
- It's a package manager for markdown for software factories; has lockfiles
- Supports dependency injection for skills
- It's a framework to compose software factories
- It's an MCP server to tuck away golden skills
I got tired of copy-pasting markdown into Cursor automation and Claude scheduled tasks, so I built
Fabrica: a software factory framework
Runs a server that serves your skills over MCP, and provisions routines, so you define them once and use them anywhere. You can also compose with other people’s factories!
MIT licensed.
staltz.github.io/fabrica
Think of it as:
* React for software factories
* Terraform for provisioning loops
* A way to extract skills from your repo, forbidding agents to change skills
* A way to quickly spin up a software factory
André Staltz retweeted
1/ I checked @andrestaltz's "Time Till Open Source Alternative is now zero" data and added 18 pairs he missed. The trend holds: ~8 years through the '90s, ~1 year by 2020, ~2 weeks by 2025. "Zero" is a stretch, but the curve is bending hard.






