Pete Gonzalez

I’m a software architect. My work ranges from Rush Stack’s world of enormous codebases to Hybrix, a tiny computer you can understand in terms of bytes and clock cycles. Although these domains embody opposite extremes of scale, they both inspire the same fascination: that moment when an unfamiliar system rearranges itself in your mind, when suddenly you can explain its architecture, see its flaws, and improve it with confidence. If you make something from scratch, such clarity often comes easily. But how to achieve it in a codebase with thousands of engineers and decades of history?

Rush Stack

I had many years to contemplate this question while working in Microsoft Office’s ancient “Source Depot” system, which was so large it took days to compile everything. In 2016, our group decided to rewrite the OneDrive/SharePoint frontend using TypeScript and Git. This offered a rare opportunity to observe the birth of a large scale monorepo. TypeScript lacked scalable tooling back then, so I started the RushJS project to fill some of these gaps. Microsoft had also begun to embrace open source, so we put Rush on GitHub, where engineers at other companies found it and got involved. In 2019, we formalized this collaboration as Rush Stack, which eventually produced Heft, API Extractor, API Documenter, Lockfile Explorer, the TSDoc standard, and various adjacent projects such as the Sparo Git accelerator. Our latest addition Monodex has AI agents as its primary audience, yet it continues this quest for clarity. Agents get lost in a big codebase for the same reasons that a person does.

Open source

After Microsoft, I worked as a principal engineer at HBO, who adopted Rush Stack for HBO Max. Then I spent four years as a software architect at TikTok, whose frontend monorepo exceeded 2,000 projects. Three successive employers paid me to work full time on the same open source. Why would a company invest in code that it gives away for free?

One answer is that the community will give back free bugfixes. That does happen, but it’s not the main motivation, especially with agents now fixing bugs cheaply. The deeper value is cost savings through consistency: Large collaborative monorepos shine a light on the inefficiencies of inconsistency. Consistency doesn’t just make code easier to understand. Establishing a standardized approach accelerates improvements and migrations. It enables people to carry expertise between teams and even companies. (Monorepo doesn’t imply monoculture, though. It just wants consistency by default. You can still diverge when justified, for example to experiment with a new approach, or to avoid migrating a product that’s in maintenance mode.)

Now, if you’ve bet on someone else’s shared code before, you know it doesn’t guarantee happiness. Where one package rewards you with new features and painless upgrades, another breaks you on every upgrade, or else strands you on an ancient unsupported version. Rush Stack proved surprisingly stable over time. At first I thought this was due to our brilliant ideas, but later I realized it’s from being used by thousands of projects. I came to love big monorepos as a powerful data set, a force that hones a toolset. More companies using our tools, more honing!

Community

Of course, a data set doesn’t hone anything by itself. It’s just noise until people come together, choose a focus that determines priorities, and take responsibility for the roadmap. Whether your code sharing is within a company or externally on GitHub, community management doesn’t happen easily. I found myself running tech support, looking for ways to introduce engineers who were circling the same problems, making T-shirts, promoting our projects at conferences. I’ve been hosting the monthly Rush Hour video call for five years.

Corporate policies often hinder employees who want to get involved. At TikTok we spent a whole year improving the procedures and GitHub governance. At HBO, I wrote the company’s first open source policies. Fortunately, all these challenges have something in common: if you treat them as engineering problems, even an engineer can solve them.

Some of the best engineers I know have no social media presence and have never spoken at a conference. But within our project, everyone understands what their work entailed. That kind of recognition can’t be bought or generated; it means something because it comes from qualified people who could have said nothing. Open source communities offer an environment to learn engineering judgment, to do real work that experts will review and may reject, to make choices that you’ll live with long enough to learn from.

Hybrix

But enough about giant codebases. Let’s go back to the beginning. In my 20s, I worked at a small consulting company on a fun variety of domains including financial portfolio management, EEG digital signal processing, wireless transmitter firmware, steam turbine analysis, and specialized language compilers. Before that, I cofounded Ratloop, a small business that still makes video games. These projects all had a certain “knowability”, created by only a few people, often without much in the way of third-party frameworks or libraries. For a game project, we’d be implementing a triangle rasterizer and memory allocator, not just the game. For the wireless transmitters, the hardware guy gave you a circuit diagram and not even a BIOS. I loved this, too!

I’ve returned to those foundations with Hybrix, a virtual computer with a custom CPU, graphics chip, music synthesizer, and programming language. In summer of 2026, I left TikTok and decided to develop this product full time through my Seattle-based company Write ‘n’ Run. The virtual machine is capable of creating polished 2D games and complex programs, yet it’s designed so that one person can make a whole program from scratch, in their web browser, with no toolchain or setup. Hybrix pitches that you’ll “point to any byte in the computer’s memory, and be able to explain what it does.” Remember when programming felt like that?

If not, you’re not alone! Software today has become the exact opposite: an intimidating sprawl of frameworks and deploy pipelines and AI assistants. And don’t forget to choose your programming language, choose your framework, choose your URL parser. So many choices! In large codebases, it’s a key contributor to low developer satisfaction (DevSat) metrics, which our build team would go investigate. We interviewed lots of engineers about DevSat, studying how they used our tools, how they managed complexity. I noticed that some people navigate huge systems much more easily than others, and came to believe there’s an underlying skill that can be taught: a way of breaking down an unfamiliar system by building it up again in your head from things you already know, a technique I call compositional assimilation. Hybrix reinvents the programming language, the runtime, even the CPU all with one aim: to make this mindset faster to acquire.