I joined OpenAI straight out of college about a year ago.
I spent most of high school and all of college obsessed with AI, so I showed up on my first day with a long list of assumptions about what the job would entail. After a year working across both engineering and post-training, many of my assumptions have changed.
My biggest lessons have been about what it actually takes to make progress.
Here are the five things that surprised me the most.
ChatGPT should provide comprehensive, well-researched responses, but it also needs to feel as fast as Google. Codex should pursue a task persistently, but never overstep boundaries. Researchers could train an enormous model, but it wouldn’t matter much if we couldn’t afford to serve it to billions of people.
These tradeoffs show up everywhere. Quality versus latency. Capability versus safety. Model size versus deployment scale. Everybody at the company, from technical staff to GTM, learns to keep them in mind.
Before OpenAI, I imagined AI progress was mostly monotonic: make the model smarter, and the product gets better. After all, the theory says that if we include all of these tradeoffs into our objective then training will find the optimum! In reality, almost every decision lives on a Pareto frontier.
OpenAI’s most impressive accomplishments involve expanding the Pareto frontier and eliminating these tradeoffs. For example, the researchers behind Astra worked very hard to make it more capable while also being faster and safer than its predecessor. Engineering teams keep adding functionality and parallelism to our agent harnesses while making the app feel more lightweight. And the inference team somehow keeps finding optimizations that make previously impossible rollouts possible.
I underestimated the extent to which these tradeoffs matter to the company. This realization completely changed what I considered exciting technical work. Some of the best projects at the company produced no cool demos or improvements to benchmarks; they just made something dramatically cheaper or faster. That kind of work doesn’t get noticed from the outside, but it’s exactly what makes the next step change in models possible.
There are people at OpenAI who somehow seem equally at home discussing ML, GPU networking, and product choices. It took me a while to realize this is intentional. Some of the people I’ve learned the most from here have unusually broad technical range, and an instinct to use it regardless of what’s technically “their job.”
I saw this firsthand during a meeting about a new model. The leader of the project covered every layer of our stack. He started with the user — what gap were we actually trying to fill? From there he worked backwards: what latency budget we’d need in production, what characteristics would make the model easy to post-train, and only then, what the right pre-training approach would be. That way of thinking shows up everywhere. The boundaries between “research”, “infra”, and “product” are much blurrier than I expected.
I was particularly surprised by how good researchers need to be at systems. From the outside, the stereotypical research scientist stays up late deriving a new objective on a whiteboard. In reality, the researcher is often up late debugging Kubernetes to make their training run step faster.
If infrastructure is bottlenecking your research, you need to be able to fix the infrastructure. If inference constraints determine if something can ship, understanding inference is critical to deciding what features to add to the product. I’ve learned that being full stack is the job, regardless of what your title says.
One day, someone from the finance team posted an outdated ChatGPT response they had received into a Slack channel. A few of us talked about it over dinner that night and came up with some ideas. Two days later, our PM had built an eval to measure how often we were failing that same case. I started testing fixes that day, and we shipped one shortly after.
OpenAI is bottoms-up. People openly debate what we should build, prototype concepts that they want to turn into reality, and jump into projects far outside their immediate responsibilities. However, this means that ideas are pretty cheap at the company; what’s scarcer is evidence that something is really worth pursuing.
Individuals at the company have a surprising amount of autonomy to prototype, build evals, and test features with real users. I have seen this recipe convert ideas conceived during impromptu brainstorming sessions into well-received product improvements within days.
I’ve come to realize that you can spend a long time arguing that something is a good idea, or you can build it and find out. Therefore, the highest leverage thing a company can do is make the process of experimentation as easy as possible. A demo, an eval result, or a real signal from users will spur teams into action much faster than a persuasive argument.
I became a power user of Codex quite quickly after joining OpenAI. Initially, I felt like AI would make focus a thing of the past. If I can code five things in parallel, why shouldn’t I pick up more projects?
Actually, focus holds higher ROI today than ever before. AI has increased the amount of work I can do much faster than it has increased the amount of attention I have. The space of things I could pursue has exploded, but the number of things I can think deeply about has remained constant.
I’ve seen this firsthand from two teammates who have each spent the last few months almost exclusively focused on a single ambitious project. Neither knew whether their project would be successful, but they resisted the temptation to hedge by picking up other projects in parallel. When I asked one of them why, he put it simply: he falls asleep thinking about the same difficult problem every night.
Focus is powerful because it leads to compounding. One day in the near future, AI will be able to own dozens of projects completely end to end with full context. But until then, the best use of AI is to go deeper on the few problems that really matter.
When I joined OpenAI, I thought that AI would eventually start feeling less magical. I imagined spending all day working with models would make the tech mundane. A year later, the opposite is true.
There is simply too much interesting work happening to keep up with. It feels like every day that a team announces a research result or product feature that makes me want to drop what I’m doing and understand how it works.
As a result, I often feel like I’m behind on everything else going on at the company. I’ll flip through another team’s presentations and come away with more questions than I started with. Every few weeks, a new finding forces me to update my intuition about how the models work or what products are possible.
When I joined a year ago, I thought I had a reasonable idea of what working at the frontier of AI would look like. In reality, the problems are broader than I expected, new tradeoffs appear constantly, and it’s difficult to hold any opinion about the technology for too long.
There’s more left to build than when I started, and I’m more excited than I’ve ever been.
Note: These are my personal views, not my employer’s.