Six months at OpenAI · mihai.page

Six months (and a few days) ago, a day after leaving Google, I was entering<br>the OpenAI office for my orientation as a new hire. It was very different than<br>what I was expecting and it was just the beginning of 6 months of interesting<br>times.

I thought it is better to persist the story here, rather that in one or more<br>tweets on social media. Of course, this would only cover public information,<br>but even so there is a lot to talk about.

This article is all written manually by me, with no help from LLMs. The<br>em-dashes were manually crafted :)

I would start by noting that the team culture changes from team to team,<br>especially across the main divisions in the company – research, applied, etc.<br>So, this is my personal experience. A year ago, Calvin French-Owen posted a<br>different blog post about his reflections on the company, in case you<br>want to read a different perspective, albeit a year old – which is like a<br>century, given the speed of the field.

Even from the first week, it became apparent that things move faster here.<br>There are not many design docs – of different colors and templates like at<br>Google –, there is no need to gather multiple teams together in meetings to<br>discuss the project before the first line of code is written and then follow<br>these meetings with more meetings after meetings for every decision and<br>alignment. In fact, here there are weeks with barely a meeting going by. The<br>focus is on developing strong technical solutions. If there’s a decision to be<br>made, it’s better to already have a proof of concept, rather than discussing<br>it ahead of time. Code wins, not the design docs and the meetings.

To be honest, I miss some parts of the Google infrastructure, though. Things<br>are moving very very fast here and I realized that the developer experience<br>and infrastructure teams at Google developed, over the years, infrastructure<br>that is there in the background. One rarely notices it because it’s almost<br>never broken, but Google has infrastructure that is unrivalled anywhere else.

Kubernetes are not the same as Borg, Bazel is not Blaze, building packages is<br>not the same as Rabbit doing it for you. There’s more work needed for<br>infrastructure. Of course, things break, and it’s important to know how to<br>communicate to the right stakeholders, have workarounds and backup plans, or<br>work on separate projects when the main one is blocked.

This speed of development also means that one has to adapt faster. A few weeks<br>in, I got told that I am a veteran already – and it was true, although<br>I did not feel it at the time. The company grows fast, too, the<br>percentage of people with shorter tenure than me is already quite high.

Even the tech changed significantly in the past 6 months. At the beginning we<br>only had the CLI version of Codex and I was still checking everything that<br>Codex wrote. In most cases, I would have Codex only write the initial version<br>of the code – to help me learn the codebase and navigate through it –, and<br>then I would write the code myself, rewriting large percentages of what has<br>been produced. I would commit and create the PR myself, shepherd it to<br>production and deployment.

Now, I trust Codex with long sessions of code writing, committing and creating<br>PRs, merging them to production. I start with a /plan or a /goal, I shape<br>it to what I need and then just steer Codex in the right direction. I still<br>check the code that gets produced, of course, but only in the critical areas<br>and to make sure it is readable. I often ask Codex review this code in the<br>style of Guido van Rossum, adhere to the Zen of Python and I strive to<br>make sure that future me can still go deep in the codebase without having to<br>ask Codex wtf did the author of this code write two weeks ago?.

Computer use, in particular, is really awesome. I get Codex to look at a<br>dashboard of a failure and analyze from there what the possible causes are,<br>while I inspect the codebase and then we plan a fix.

The general culture is based on You can just build things. If you have<br>an idea, you just implement a prototype, nerd-snipe a group of people to work<br>on it and then you ship. As mentioned before, almost zero meetings, almost<br>zero docs for alignment. Don’t ask for permission, just do the right thing.<br>Everyone can cook, and good products take time to develop.

The leadership is very visible. Not only in all hands meetings – where you<br>can actually ask live questions and get real answers. This contrasts Google<br>where the traditional weekly TGIF now only happens after earnings calls or<br>(maybe) after a big launch, but in either case the questions are submitted in<br>advance, “summarized” by an AI to be less critical, censored by HR and then<br>barely answered at the event, usually in corp-speak. At OpenAI, all questions<br>are answered honestly, be them questions asked live or on Slack, during the<br>all hands or outside.

We use Slack significantly. Email is barely used. I never got to use Slack as<br>much as here and now I can...