Four years after my first internship started, Ona entered into an agreement to join OpenAI.
That is the clean version.
The real version is less clean. I joined Gitpod when I was 19. Gitpod later became Ona. At the start, it was a three-month internship at a seed-stage startup. It was my first company, and I did not know if I would even make it to the end of those three months.
I remember the first week clearly. I was given a task: get a popular open source repo working on Gitpod. I opened the repo, read the setup docs, and spent two hours trying to make it start. It did not start. I filed a note, tried a different approach, and spent another hour. Still nothing. I did not know if this was normal. I did not know if I was slow. I did not know if the person who hired me was already regretting it. I just kept going, because stopping felt worse than being wrong.
That feeling, of not knowing whether you belong, of doing the work anyway, never fully went away. It changed shape.
From the outside, the interesting part is the OpenAI announcement. From the inside, the thing that mattered was the path: work, a lucky reach-out, a messy internship, years of small work, and learning how to earn trust before I had much proof that I deserved it.
What actually mattered
I did not get close to Gitpod because I had a perfect resume. I got close because I had public work that made me easier to trust.
GitHub1s showed that I cared about developer experience. My GitHub internship on Actions and Codespaces gave me context. Geoff reaching out on Twitter gave me the opening. The internship gave me a small surface area where I could prove I was useful.
Rare work does not always start with rare access. It starts with doing visible work, getting close to a real problem, and taking the unglamorous parts seriously.
The story looks like a roller coaster now. At the time, it looked like docs, repos, broken setup scripts, code examples, changelog notes, website pages, and asking one more question before assuming something worked.
How the door opened
The path started before Gitpod.
Before Gitpod, I co-created GitHub1s with two other people. It was a small idea with a clear feeling behind it: you should be able to open a GitHub repo in a browser and inspect it fast. Gitpod later partnered around the product, and that pulled me closer to the developer experience world Gitpod cared about.
I also interned at GitHub on Actions and Codespaces. That made Gitpod easier for me to understand. Cloud development environments did not feel like a category on a slide. They felt like a problem I had already touched.
So when Geoff reached out to me on Twitter, Gitpod did not feel like a stranger. Geoff, who later became my first manager at Gitpod, sent a message that felt like the next step in a path I was already walking.
Every developer knows the pain. The repo works on one machine but not another. The setup docs are stale. A dependency is missing. A script assumes some local state that nobody remembers. You lose the first hour before you can write one line of code.
Gitpod's public story was simple: make development environments ready-to-code in the cloud. That made sense to me. At 19, I did not have a big theory about developer tools. I just knew setup should not be this hard.
The first work
My first Gitpod work had a funny name: Gitpodification.
My title was Developer Community Success Intern. The job was to help open source repos work well on Gitpod. In practice, that meant everything: make the repo start, fix the docs, write the guide, add the code example, update the changelog, change the website, help the developer community, and notice what blocked someone before they asked.
Sometimes ownership arrives as a messy surface area that nobody fully owns yet.
You learn by staying close to it.
The first three-month internship became another three months. Then it became a full-time offer. In November 2022, while I was in my third year of college, I started full-time at Gitpod.
I remember that period as a mix of pride and fear. I was excited. I was also aware that I was young, remote, still in college, and still learning how to be useful in a real company. Even finishing the internship had not felt guaranteed. Now I was full-time. That feeling of not quite belonging never fully went away. It just changed shape.
The front door
For a long time, I stayed close to the public surface of the company: website, docs, launches, pages, performance, migrations, examples, experiments, and the small details that nobody notices until they break.
That meant shipping visible work and invisible work behind it. Reworking pages. Cleaning docs. Moving systems. Chasing performance. Writing around product changes before the product story felt obvious.
It also meant the work kept changing shape. One week it was docs and changelog. Another week it was API docs, API examples, SDK configs, or a website migration. Later, during the Ona rebrand, it meant helping rebuild the public surface from a new repo and a new CMS while the company was still moving.
Some of it showed up in numbers. New-user time-to-code went down 30%. Lighthouse moved from 60 to 95. Docker workspace cold starts dropped 38%.
But the number was never the whole point. The point was making the first minute feel lighter.
It did not feel glamorous. It felt like being a caretaker for the front door. But the front door matters. A startup's website is not just marketing. It is where product, sales, hiring, investor trust, customer trust, and company taste meet.
Every broken page says something. Every vague sentence says something. Every slow load says something.
At 19, I thought ownership meant finishing tasks. At 24, I think ownership means noticing what the system needs before someone writes it down. That is a different kind of engineering.
The work started to rhyme
Over time, the work stopped feeling random. The same questions kept coming back in different forms: how fast can someone get to a working environment? What context does the system need before it can help? What should an agent be allowed to touch? What makes a tool feel trustworthy instead of noisy?
The same questions followed me outside the company too.
When I wrote AI fatigue is real and nobody talks about it, I was not arguing against AI. I was trying to name what happens when tools make output faster but make judgment, review, and context-switching heavier. That essay named something people had been feeling but could not say out loud. That is the only reason it spread.
It came from work. Not theory. From building agent-trace, Distill, and agentic-authz near the edge of the problem long enough to see the same pattern repeat: the hard part is rarely the demo. The hard part is making the system useful, safe, reviewable, and humane.
When the job changed
Gitpod raised its Series A in November 2022 to build cloud development environments. That was the company I joined: reproducible workspaces, secure developer environments, and moving software development into the cloud.
Then AI changed the shape of the problem.
A few weeks after I started full-time, ChatGPT arrived. It felt like every engineer got a new tab in their brain at the same time. I treated it like another tool to try.
By March 2023, I was already working on docs RAG experiments. It was early and rough, but the direction felt important. Over time, that curiosity turned into docs search, API examples, internal helpers, small prototypes, MCP experiments, and agent workflows. Some ideas were early. Some were clumsy. Some were useful.
Later, the work became more practical. We were not only asking what agents could generate. We were asking what they needed around them: the right environment, the right repo context, the right automations. One version of that was automating docs updates with an Ona Automation, where the system scanned the codebase, found stale docs, and opened a pull request with the update already written.
But the direction became clear: the development environment was no longer only for a human sitting at a laptop. Agents need one too.
They need code, tools, dependencies, credentials, and context. They need somewhere to run when the laptop closes. They need logs. They need boundaries. They need review. They need a place to do real work without turning every security team into the last line of defense.
The old problem became new again.
That is why the OpenAI and Ona announcements matter in this story. Not because a press release makes the work important. They make the pattern visible.
The first version of the problem was: how do you give a developer a ready-to-code environment?
The next version is: how do you give an agent a trusted place to do real work?
For me, that connects the whole arc. GitHub1s, Gitpodification, docs, examples, website work, RAG, MCP, OpenFGA, agent observability, agent authorization. Different surfaces. Same question: how do you help software work happen with more context, less friction, and better boundaries?
What someone else can copy
I would not tell someone early in their career to chase acquisitions. You cannot plan that. You cannot reverse-engineer a company outcome from a LinkedIn post.
But you can get closer to interesting work.
Build small things in public that show your taste before anyone gives you a title. Pick problems that serious people already care about. Make your work easy to inspect. Write clearly about what you built and why it matters. Say yes to messy work when it puts you near users, product, and the business at the same time.
The lesson is not "work harder." The lesson is: make it easier for good people to trust you with harder work.
At a startup, the job will change under you. The product changes. The language changes. The customers change. The market changes. If you are early in your career, you change too.
You stop asking "What is my role?" You start asking: what does the user need? What does the company need? What are we saying out of habit? What broke because the old story no longer fits?
That is where I learned that speed needs taste. Move too slowly and you miss the moment. Move without care and the company fills with half-decisions: half-written docs, half-owned systems, half-clear pages, half-migrated tools, half-true positioning.
That tension never goes away. Move now. Care anyway.
What I would tell my 19-year-old self
I would not tell him to relax. He would not listen. I would tell him this: you will not feel secure at the start, and that does not mean you are failing.
You will not know whether the internship becomes anything. You will wonder if you belong in rooms where everyone seems ahead of you. You will compare your inside view of yourself with everyone else's outside confidence. That is a bad trade. You will do it anyway.
I would tell him to pay attention to the small work. It is not small.
The page is teaching you taste. The migration is teaching you systems. The launch is teaching you pressure. The customer story is teaching you business. The bug is teaching you respect for users.
The rebrand is teaching you that companies are living things. They change names. They outgrow their first story. They ask people to change with them.
And the offsite you travel too far for is teaching you that the work is also the people. Some of them become friends for life.
You will want a clean career story. You will not get one. You will get work. Do the work.
What I am taking with me
I joined as a teenager. I leave with a clearer sense of the engineer I want to be.
I care about infrastructure that gives people leverage without taking away control. I care about agents that can do real work inside real boundaries. I care about context, authorization, observability, review, and the boring systems that make ambitious tools safe enough to use.
I also care about the front door: the words, the pages, the docs, the first impression, and the detail someone notices only when it is wrong.
I used to think those were different kinds of work. Now I think they are the same work.
You build the system. Then you help people trust it.
Work should not need a myth around it. But sometimes you find a problem, a team, and a stretch of time where the work matters enough that you give more than the job description asked for.
That was Gitpod and Ona for me.
I am grateful for the people who made room for me when I was still figuring out what kind of engineer I was.
What comes next
For the first time in a long time, I am looking around.
My Ona chapter ends here. I am not looking for the nearest title. I want the next thing to rhyme with the work I have already cared about.
I want to work on tools that make developers stronger, not busier. I want to build agent infrastructure that can survive real teams, real codebases, real permissions, real review, and real mistakes. I want to work on systems where context, authorization, observability, runtime safety, and product taste are not afterthoughts.
The shape matters less than the work.
I am most useful when the problem is still messy: when the product needs engineering, the engineering needs taste, the story needs clarity, and the team needs someone who can move across those lines without waiting for perfect ownership.
That is what my first company taught me.
If you are building something in that direction, I would like to hear from you. Socials and a calendar link are in the footer.
Gitpod was my first company. Ona was where that company grew up. In a lot of ways, it is where I did too.