Six months at OpenAI

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

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

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

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

Even from the first week, it became apparent that things move faster here. There are not many design docs – of different colors and templates like at Google –, there is no need to gather multiple teams together in meetings to discuss the project before the first line of code is written and then follow these meetings with more meetings after meetings for every decision and alignment. In fact, here there are weeks with barely a meeting going by. The focus is on developing strong technical solutions. If there’s a decision to be made, it’s better to already have a proof of concept, rather than discussing 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 are moving very very fast here and I realized that the developer experience and infrastructure teams at Google developed, over the years, infrastructure that is there in the background. One rarely notices it because it’s almost 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 not the same as Rabbit doing it for you. There’s more work needed for infrastructure. Of course, things break, and it’s important to know how to communicate to the right stakeholders, have workarounds and backup plans, or 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 in, I got told that I am a veteran already – and it was true, although I did not feel it at the time. The company grows fast, too, the 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 only had the CLI version of Codex and I was still checking everything that Codex wrote. In most cases, I would have Codex only write the initial version of the code – to help me learn the codebase and navigate through it –, and then I would write the code myself, rewriting large percentages of what has been produced. I would commit and create the PR myself, shepherd it to production and deployment.

Now, I trust Codex with long sessions of code writing, committing and creating PRs, merging them to production. I start with a /plan or a /goal, I shape it to what I need and then just steer Codex in the right direction. I still check the code that gets produced, of course, but only in the critical areas and to make sure it is readable. I often ask Codex review this code in the style of Guido van Rossum, adhere to the Zen of Python and I strive to make sure that future me can still go deep in the codebase without having to 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 dashboard of a failure and analyze from there what the possible causes are, 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 an idea, you just implement a prototype, nerd-snipe a group of people to work on it and then you ship. As mentioned before, almost zero meetings, almost zero docs for alignment. Don’t ask for permission, just do the right thing. Everyone can cook, and good products take time to develop.

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

We use Slack significantly. Email is barely used. I never got to use Slack as much as here and now I can see why Google pushed so much for Google Chat to mimic Slack – effectively, in my opinion, destroying a product that was working really well.

We use Codex everywhere, as I said before, but it doesn’t seem forced. We don’t get a mandate from up high that we should use a model. In fact, when new models are tested, we can choose if we want to dogfood them or not, there’s no pressure. This contrasts my experience at Google in the last year where every team and person needed to have something related to AI in their projects or risk layoffs.

But, we are not developing only GPT models and tools around them. I am happy to have worked with many of my team on privacy-filter, an application that can identify from text, using a model that can be finetuned for specific cases and is small enough to run in browser. In fact, a very fond moment of these months has been when the model has been on the top trending models on Hugging Face for days, among giants such as DeepSeek and Qwen – truly a moment to quote from the movie Troy (2004) (and it’s just a coincidence that I refer to this movie just a few days after Nolan’s The Odyssey (2026) was released in theaters). Sure, there were a few people trolling the release, some (still) upset at the 4o model retirement, others upset at the company. Just a little cloud on a sunny day.

Speaking of mandates from high up, if I want to use vim to write something I can. There’s no forced all editors must use AI directive. I can continue working on open source – and, unlike Google where we got mandated to use Gemini for any OSS contribution, no matter if it was OSS for work or OSS for personal projects, I can test whatever agent I want to, and when I want to.

On the OSS front, Google had two policies for coding in the spare time. Either a policy for patching existing projects, paired with a policy for releasing new ones, or a process to get some part of ownership assigned back to you. There’s a public Google page that mentions them in some details. None of that at OpenAI, just get approval from your manager and a check for conflicts of interests and you can get stuff done in your own time, on your own devices.

Similarly, the conference travel policy is much more relaxed than what I had in my last few months at Google, when it got reduced significantly. In fact, travel, OSS, and the forcing of Gemini were among the reasons why I decided to switch.

I am now working closer to privacy again, after several years on the security front, but privacy and security teams are under the same umbrella and working together, so these 7 years and a few months at Google in TensorFlow Security and GOSST are still useful. My team has both researchers and software engineers so there’s always something new to do and learn, similar to the GOSST days.

I really enjoyed these 6 months – despite having days with protesters in front of the company or having received DMs about the choice of the company when I switched (I even got asked to delete a few of my Mastodon accounts once I switched to the new employer as the owners of those servers had OpenAI – and other companies but not Google – on lists of “despicables”). I am looking forward to more time here.

I will conclude with a remark on my views on AI. I have posted various AI experiments on this blog, asking them to solve puzzles (1, 2, 3), or even code (1, 2). I even posted a series of rants on AI just before last Christmas, and this article about slop in OSS is very relevant given that Anthropic just casually announced that one of their models (accidentally/allegedly) mounted a supply chain attack, just like I was saying that a future xz incident might occur via AI – we’re still not there, and I’m happy to see that both companies are taking steps at preventing that bleak future. On the coding side, reading back the 2 linked articles, I realize how far the tech has gone. On the puzzles side, all I can say right now is that these will continue. I will use the AI more, and the field would evolve. The field changes fast – already what I was talking about in the article about using AI to study is no longer accurate – and these articles and experiments will help me in the future do similar retrospectives on how the field has moved. The Golden Path still needs to be found, and I’m happy to be working with giants that are at the frontier.