Principal Software Engineer, whatever that means; I break stuff, then I fix stuff.
Joined February 2010
- Tweets358
- Following219
- Followers50
- Likes3.7K
Marcello Gozza retweeted
I'm telling you folks, ADRs and primitives are a huge leverage point for getting your agents to build the right thing. I don't have to worry about an agent going against an important architectural decision because they actually do read those and make the right choice.
ALT A screenshot of a Slack conversation where a user asks if there's an opportunity to improve the Kody platform without over-indexing on a specific feature. A reply states that there is a real opportunity, but it's not a "support Start" feature, and Kody's decision 0057 is correct. The gap is narrower than that, as publish can't run any build step.
Marcello Gozza retweeted
hot take: you don't need a software factory, and i don't love the term. it's just marketing
all you need is good software engineering and investing your tokens in the right places. the more deterministic the better (and token efficient)
Marcello Gozza retweeted
I need @RockstarGames to sponsor @ReactMiamiConf afterparty so we can make it as epic as Cloudflare Connect’s
Marcello Gozza retweeted
how do you trust your agents' work more? copy this post/link and give it to your @bot or agent!
1. codebase improvements: this is just good software engineering - better architecture, stronger types and invariants, clear boundaries. agents love to copy what exists and take the shortest path, so make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again.
2. static analysis: lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time.
3. prose: comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill.
4. human review: the hardest to scale. at the rate agents land code, it's pretty much impossible to thoroughly review every PR, so spend that effort on the highest leverage point, designing an environment where agents do the right thing by default.
this forms an inverse pyramid: you want most of your effort at the top, least at the bottom. codebase improvements are deterministic, making it more token efficient, and lets you sleep more soundly at night.
install github.com/cursor/plugins/tr… and create a new Project:
1. look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture
2. use /recall on my past transcripts to learn how i steer agents
3. /poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data.
4. before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me
Marcello Gozza retweeted
Some mistakes you might be making:
Your effort level is too high
Your skills are too long
You're not aligning before you start work
You're aligning too often, and too hard
Your automated checks are too lax
Your custom tooling is too token-inefficient
You aren't doing enough automated review
You aren't reviewing previous coding sessions (with an agent)
You're doing too much human review
You aren't vibe coding enough prototypes
Your agent can't verify its own work
You're babysitting the agent too much
You've overloaded your global steering files
Your codebase is hard to navigate
You aren't building a shared language
Your codebase architecture allows bad tests to be written
You aren't thinking strategically enough
You aren't thinking enough
Marcello Gozza retweeted
Introducing gdp-ts: Ghosts of Departed Proofs for TypeScript.
gdp-ts is a library, linter and AI skill for safer API design. Under this contract, sensitive functions require 'proofs' that the caller performed an authorization check.
The typechecker verifies these proofs at compile time, preventing your team and agents from shipping catastrophic security (and other kinds of) bugs.
While these patterns have existed for quite some time, especially in ecosystems like Haskell, ① human code review and ② cognitive and syntactic overhead made these solutions niche.
The situation is now inverted. Agents are writing more code than we can review, and they *thrive* in tight loops with hard constraints that would frustrate us. We see this with the rise of Rust, borrow checker, code aesthetics debate and all.
The README and examples model a real-world Vercel API product constraint: changing the password on a Project requires a proof of a certain role + a certain entitlement. Thanks to Matt Noonan and Ollie Charles for their research in this space.
github.com/rauchg/gdp-ts
Marcello Gozza retweeted
Important advice: deliberately rethink every previous concept of how things should be done.
Some thoughts, tips, and realizations:
1. Specializations are collapsing. Come to terms with and take advantage of this reality. The person who used to be an engineer is now also a data scientist, a content creator, designer, marketer, and whatever else they want to be. Deliberately expand in as many directions as you can and become great at them (scope up vs just speeding up)
2. The average person with access to tokens can now do the work of a data scientist who used to cost $500,000 a year. Seriously, this is fucking crazy. This opens up an entirely new world. Take advantage of it (also everyone else will also realize this over time).
3. 99% of what's created is now slop. Be aggressively anti-slop and you will absolutely stand out.
4. Trying is nearly free. Automating is nearly free. My mind still sometimes lives in the world from 12 months ago where an idea automatically is attached to a certain amount of time or effort. Both of these have collapsed to close to zero (or just token cost), I therefore try and experiment with *any and all* ideas with potential and have needed to retrain my brain for this constantly.
5. Tokens are a career and growth accelerant. Find ways to get cheap access to tokens, or free tokens. Extremely important, and actually an entire design space, use your imagination.
6. It's never been easier to both stand out but also fall behind. 10x, 100x "people" exist more than ever (maybe 1,000x). Outlier power users of AI, many who you see here on X. Feels like we are in a window of time, a window of opportunity while all of this is still early, to take advantage of it.
7. Local computing is (or will be) dead for 99% of work. Local was built for a world where work was bounded by the physical presence of its author, but this is no longer true. You can and should do infinite work in parallel or zero, it doesn't matter anymore. Cloud agents enable this at scale and in any computing environment, I predict cloud agent usage will 1000x over the next 12 months and optionality and accessibility will 100x. Plan for this world, take advantage of the possibilities.
8. Building on #7, you can give an agent it's own computer, and it's own identity. You can then give an agent with it's own computer it's own computer. You can give that agent with it's own computer with it's own computer, *it's* own computer. These agents are smarter than any human in history and you have access to as many as you'd like. Think about this for a moment.
After 14 years in this industry (tech) today is the most exciting time ever and nothing else feels even close.
Marcello Gozza retweeted
The first step is types.
We're adding a TypeScript-compatible type checker to Bun.
It’s the best shot ahead-of-time compiled TypeScript has at beating languages like Go on memory and speed.
Marcello Gozza retweeted
My hot take from chatting to @poteto is that we should use MORE abstractions in the AI age
You can use them (combined with harsh lint rules) to reduce the design space available to the agent and constrain them only to good decisions.
Combined with the fact that high-leverage abstractions let you do more with less code - so, more token efficient.
Plus, unwinding the damage from a bad abstraction is much cheaper with agents.
This runs counter to a lot of folks thinking that agents just want to read the raw code. They can, but they're not maximally efficient that way.
Be braver! Design abstractions.
Marcello Gozza retweeted
JavaScript was never designed for the server. If that doesn't change soon, JavaScript on the server will be replaced by Rust.
The fix needs to happen in the engine. Sound types. Ahead-of-time compilation. Threads with shared objects.
"I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself." — @dhh
Marcello Gozza retweeted
The worst part about AI engineering is how often does everyone think their weird esoteric bullshit actually matters.
I think it's a combination of sycophancy + non-determinism + models getting better so fast that you can associate model improvements with random changes you made to your environment. The result is that everyone's brains fall out as they overthink things that don't matter.
Marcello Gozza retweeted
Anyone that works in AI is working the hardest they've ever worked in their lives. On the surface it's somewhat ironic (AI should give us back time!), but the reality is that it's the most fun, fascinating and empowering epoch in human history. The intelligence revolution.
Marcello Gozza retweeted
The wayfinder skill by @mattpocockuk is great
At first I was skeptical, I’ve managed big projects just fine by myself
But what’s nice about this skill is I never have the blank canvas problem. There’s always something to sharpen my ideas against
There’s more room for taste expression because the “default” decision is already there in front of you. You can either accept and move on or refine
Collaborative wayfinding sessions are also a great way to build alignment
10/10, great skill
Marcello Gozza retweeted
Ideal JavaScript runtime architecture:
1) Implement most APIs in native code
2) Declare argument & return types in a code generator
3) Code generate JS <=> native bindings
4) Code generator tells the JIT what to expect
This is the JIT half that unblocks the code generator.
In the next version of Bun
bun:ffi gets up to 3x faster
ALT BUN:FFI • REWRITTEN AS ENGINE-NATIVE FFI IN JAVASCRIPTCORE up to 3× faster ffi Symbols & callbacks are engine cells • hot call sites JIT to a bare call; ret • 70× less memory/ symbol 3.0x 3.3x O bun TinyccO bun •JSC-native 2.3x 1.4x TINYCC = 1x noop call 2.27 ns → 763 ps new CString( 99.5 → 30 ns yoga layout x1k opentui benchmark speedup vs previous TinyCC-based bun:ffi macOS arm64 • opentui: unmodified 347-symbol app scrollbox 10k opentui benchmark
Marcello Gozza retweeted
Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things.
I think many of these automations have become even more important now. This is true for a number of reasons.
First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time.
Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time!
Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation.
Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.
