Why we built 143.dev
Co-founder & CTO, Assembled
The best person to understand a problem really deeply usually isn't an engineer, it's usually someone who's using the product day in and day out with customers. Or it's the customer support person who sees questions all day about why a particular feature isn't working. While engineers have historically been the only people who could fix things, that's not true anymore.
Now with coding agents, non-engineers can fix things too and tend to be closer to the problems that users run into on a daily basis. The problem is that the tools built on top of these agents weren't made for that person, they were built for engineers by engineers. That's why we built 143.
Where it started
At Assembled, we saw this firsthand: our support and product teams kept surfacing fixes that engineers never had time for. Coding agents could have handled many of them, if the tooling didn't assume you lived in a terminal.
143.dev is the internal coding agent infrastructure we built at Assembled to help our non-engineers with this problem (while also helping our engineers build better software). We wanted coding agents to help with real product work, not just demos and internal tools.
What we built
We started with a small tiger team that cleaned up our instructions, invested more in CI/CD, built agent hooks, and made the agent environment less fragile. All of that helped, but it also made the bigger issue obvious: we needed a system that made this work shared across the team as opposed to being trapped inside each engineer's terminal.
We were inspired by internal systems like Stripe Minions and Ramp Inspect, but those were never available to the public. We wanted something open source that other teams could use, adapt, and improve.
We built 143 so the person who spots the bug doesn't need to become an engineer to fix it. That meant:
- Automations shouldn't be hidden on one engineer's laptop, so anyone on the team can see what's running and what changed.
- Teams should be able to swap out intelligence and harnesses as coding agents and models improve.
- Shared context should make it natural to start work automatically from Sentry issues, Linear assignments, PR comments, or scheduled checks.
- Code review should be handled by agents on some or all PRs, and they should be able to auto-approve low-risk changes against thresholds you define.
- You should be able to set up a great environment once for everyone, with the same repos, credentials, tools, logs, docs, and product context available to the whole team.
Open source for everyone
The same idea that you shouldn't have to be an insider to contribute is why we open-sourced 143.
I owe a lot of my career to early open-source work on Ruby on Rails. That is where I learned software fundamentals from people like Aaron Patterson, Santiago Pastorino, Jose Valim, and Jeremy Doerr. Their PR reviews, their patience, and their willingness to design-pair with strangers on the internet shaped how I think about software.
I was just a college student, but the Rails core team didn't care who I was. If a PR was good and well-intentioned, it was welcome. I started with tests and tiny refactors, learned more of the codebase, and eventually got really deep into the internals of Active Record. That work helped me get my job at Stripe and became the launching pad for the rest of my career.
I want 143 to be available in that same spirit. I hope it helps other people and teams the way open source helped me.
I really hope you like it.