I joined @nvidia nine years ago today, against the advice of a colleague who said their comp was below market. But I really believed in the mission and the people, so I went. I met @__simt__, Michael Garland, and Jared Hoberock on the C++ committee. I thought they were the smartest people there. I worked at @BerkeleyLab on concurrent and parallel programming paradigms, mostly for SIMD. @__simt__ convinced me that SIMT was a superior model for parallelism. He sold me on a revolutionary new GPU architecture where threads would independently scheduled: Volta, the basis of all modern GPUs. I asked him three times to find me a place at @nvidia. The first two times, he wasn't sure where to place me or if I'd like it. The third time, he had me come in to talk to Chris Lamb (now VP of CUDA). We chatted for two hours and he outlined the role he believed modern C++ would play in CUDA. I came back for an 8 round interview panel. All of the questions were answered with std::atomic. No one was sure what I would be working on. I, a modern C++ person, was placed in the CUDA driver org, which was written almost entirely in C. On my first day, my manager told me I'd be responsible for Thrust and CUB, @nvidia's first two open source libraries. No one had worked on them for a while and there was no product manager. I'd have to do it all. I put together a roadmap and got the libraries back on GitHub. I started sending status updates from CCCL, the CUDA Core Compute Libraries team, which did not exist. Eventually, they let me hire three people to fill out the team. We built libcu++ and abstractions for all the quirky new features being added to our chips to support these AI workloads that seemed to be growing in importance rapidly. After a few years I was asked switch orgs and guide the roadmap for our HPC C++ compiler. Programming languages and models quickly became my role, from stdpar to CUDA-Q to CUDA Python to CUDA Tile to autoresearch. What a ride it's been!

Today I’m joining @Natl_Compute I’ve spent the last four years working on GPU access, first as a founding engineer at Brev and then at NVIDIA after they acquired us in 2024. When I started, on-demand GPU capacity at the hyperscalers was effectively gone. If you were an independent researcher, a two-person startup, or a grad student with a grant and a deadline, you refreshed console pages and got nothing, or hammered the API only to get “insufficient capacity” errors back. I vividly remember hard-coding a filter at Brev to hide certain GCP instances because they almost never provisioned. Around 2023, a wave of new public clouds were coming online, and many of them had on-demand capacity. That gap is a big part of why Brev worked: we gave researchers a simple way to find GPUs across dozens of providers and start building. For a while, aggregation was enough. Then in 2025, I watched that capacity dry up too. Access to compute has never been worse. Existing supply is already under contract, and new capacity is reserved before it ever comes online. I won’t rehash why. There are a hundred good explanations out there covering debt financing, anchor tenants, backstops, lead times and so on. What matters more are the downstream effects. Long-term, single-tenant leases hold back scaling for everyone who couldn’t secure funding in time, and the industry’s momentum shouldn’t hinge on the handful of players who locked up access early. Today small startups, labs, and university researchers don’t even get a chance to compete. National Compute is solving this with a foundational layer we call “the Grid”. It’s an interconnected network of multi-silicon capacity composed of multiple providers and spans multiple sites that will be pooled for our members. The speed at which this team has been able to scale in such a small fraction of time is remarkable, and I’m excited to push that scale even higher for the public benefit.

In agent/harness, it is really a retarded design to automatically share the memories of conversations/tasks/threads. Think about context contamination. When your users "start a new conversation/task", that means it should be brand new. Why implicitly injecting stuff there?

github pages is criminally underrated as a hosting platform