
Eng at @base. Deep dives on Base engineering and scaling output with AI agents
Joined February 2012
- Tweets837
- Following298
- Followers921
- Likes2.1K
Pinned Tweet
An early look at a software factory design @0xthanh and I have been building to speed up the way we ship
Engineers, tear it apart. What’s missing, what’s fragile, what would you do differently?
Feedback here could help shape the future of @base. We will figure this out and we will accelerate (responsibly) 100x when we do
We don’t let agents one-shot production code, so why let them one-shot changes to your skills that could affect production code?
Any custom skills you use should be version controlled and changes to them should go through the same rigorous review flow that the rest of your code does
Top learning from this week:
If there are still findings after 4 agent review rounds on a PR, stop and re-scope. It means either the spec is too vague or the scope is too big
Growing up: figure out how to add 4.5 pages of fluff on top of my 2 paragraphs of thoughts so my essay met the page requirement
Now: figure out how to remove 4.5 pages of AI fluff to reveal the 2 paragraphs of coherent thoughts
School did not prepare me for this
My rules on unit testing heading into this week:
- do not write tests that restate the implementation (getter/setter checks, “calls X with Y” mock assertions, snapshot tests, tests whose expected value is copied from running the code)
- write a test only when it pins behavior that could plausibly regress: edge cases, error paths, boundary values, parsing/serialization, arithmetic, concurrency, bug fixes (one regression test per fix)
- prefer one test exercising real behavior over several testing internals. Test through the public interface; avoid mocking anything you own
- keep tests short. If setup exceeds the assertion, reconsider the test or the design
- do not add tests to a change just to have tests. Zero tests is an acceptable answer for trivial changes; say so in the PR
Just found some skills in my setup that were having the agent handle things that could have been automated in a script
Don’t spend tokens unnecessarily. Would recommend auditing your skills for this
Jack Chuma retweeted
This year we've already shipped 3 hard forks on @base (Azul, Beryl, Cobalt) and we're sprinting on Denim.
We believe we can ship 10x faster while keeping a high quality bar. How? No more 4-6 person teams.
We just reorganized ourselves into high-agency 2–3 person pods. Each pod owns what to build, powered by a software factory. We shape the product and engineering specs together, and agents ship it to production.
Full send.
Kind of want to start acquiring server racks at home to prep for the world where open weight models are on par with the frontier. Why can’t I just host my own ai without the token or cloud spend?
Makes a lot of sense. Scrap the unit tests!
At what point are e2e tests mature enough to stop requiring human approvals if they aren’t changed or broken?
IMO the only tests you should have in the age of coding agents are, in order of priority:
1. Full E2E tests. Nothing mocked out at all. Can even be something that runs in prod on test accounts via Playwright or equivalent.
2. Integration tests. Agents make more mistakes as things bleed between data/API boundaries where schemas can drift.
3. Golden tests. This helps ground the code with real examples of data, and can be used as regressions against edge cases.
Unit tests are bloat 99% of the time if you’re using a frontier model since they’re smart enough now to get the implementation (and subsequent iterations) right on the first shot, so they only add bloat at this point.
I still think clean code matters, but not for the same reasons it used to
Humans no longer need to read and understand the code (or at least we won’t need to in the very near future)
But less code is still better than more due to context bloat. Less context needed to accomplish a task gives us more efficient agent output!
Cobalt hits @base mainnet today
Here are some of its engineering improvements you probably haven’t heard about yet 👇
Proof System Re-architecture
We rebuilt the offchain proving services around a worker model. Goal is simpler scaling and an easier path for new proof types later





