Reaching the end of Menlo
Learnings from 4 months of my first internship!
The past 4 months were spent at Menlo Research. I worked on a broad range of things: primarily around Jan and organizing the Singapore AI Showcase (which didn’t take that much time). Tasks varied day to day but I learnt a lot over these 4 months (as my first proper internship)!
These experiences can be broadly grouped into the following: technical and non-technical.
Technical
After ORDing, there was a free period of around 7 months before starting school. The main objective going into this internship was really to brush up on my technical skills (beyond vibe coding) and to get up to speed with dev. It was a broad goal, so I didn’t have a good idea of what I would actually be doing.
Four months later, I can say it delivered that step change I was looking for—first PRs, merges, and the line-by-line code review (by a human!) that came along with it. With AI everywhere, I felt I learnt the most by learning inside structure, rather than DIY vibe-coding. I’m really grateful for this internship.
Proper Production Engineering
Production engineering is non-trivial.
Being paired with Thien was one of the best things that happened in this internship. Optimization of GPUs and accelerated hardware demands a different level of precision; he brought that precision to everything, even the parts he’d rather not touch (frontend / backend / platform). Working with him taught me the following nuggets:
Thoughtfulness compounds into scalability. This principle shows up at every level of the stack. In general, being thoughtful reduces bloat and keeps code minimal and easy to understand. Rather than accepting all code edits and letting the coding agent take control, it’s imperative that developers remain in the driver’s seat.
At the dependency level: This meant dictating what packages to install as a dev, or scrutinizing suggested packages to be installed. One carelessly added package can cascade into dependency hell, version conflicts, or relying on abandoned libraries.
At the code level: Similar to writing (which I’m also hoping to get better at), every line of code has to have its existence justified. If an AI-suggested line exists but serves no purpose, that’s future maintenance burden and bloat. Are you sure that this function that was suggested doesn’t exist in another part of the codebase? Each additional line is cognitive overload for the next developer.
Speed upfront isn’t necessarily a good signal for success.
The startup obsession with shipping quickly can be self-defeating. Accepting the first cut with a pressure for shipping speed and no quality control can actually be more detrimental than what people realize.
Experience become invaluable. Engineers who have built at scale pause to sketch architectures, debate tradeoffs and think through second order effects. Whiteboarding sessions and debates about structure can save weeks of refactoring later.
These principles became clearer through contrast with the environment where I learned them.
(Small) Pivots
The first two and a half months was deliberate exploration. I was handed loosely scoped projects and given room to make things work—standing up high-level implementations to survey the state of the art, especially in real-time inference and deep-research pipelines.
The team was young and energetic—we moved fast, tried new ideas constantly, and had a bias toward shipping working demos. Looking back, I realize we operated in two modes: deliberate research spikes to explore technical feasibility, and rapid prototyping for potential features. In both cases, much of what we built served as learning vehicles rather than production code. This wasn't always explicitly communicated, and I initially struggled to understand why polished work might not ship.
The ambiguity was slightly frustrating until I recognized this was a reality of early-stage startups—you build to learn as much as you build to deploy. This extends beyond code to the organization itself: even with clear market demand, there were still open questions about technical direction, which bets to place, and how to harness the diverse strengths of a team where some thrived on rapid experimentation while others excelled at systematic building.
Pivots could well be interpreted as signs of confusion but recognizing them as a necessity of organizational dynamics at a higher level helped eased the day-to-day. Understanding that these shifts reflected tradeoffs (even if I couldn’t see all the moving pieces as a lowly intern) made the changes feel less arbitrary and more like part of a larger strategy.
tldr: Being pivoted can be discouraging and they’ll happen for reasons beyond your visibility as an intern. While I couldn’t control the strategic shifts, I could control my response to them. There’s nothing stopping me from actively seeking feedback on whether I was growing in the right direction, and building learning loops regardless of project outcomes. Having ownership of your own growth in a flat-hierarchy startup is essential.
Non-technical
Running a startup
It’s not easy. Watching a startup from the inside gave me newfound respect for what founders juggle beyond just product direction. You need a near-infinite context window: switching from market/ BD strategy to deciding which architecture to adopt, then back to handling a key hire’s concerns.
Running a startup is like staring into an abyss and chewing glass. It’s the sheer simultaneity of (the worst) challenges across completely different domains.
Team management
I like the framing of a startup team as a football team. As with any team, players come with distinct strengths and weaknesses, you arrange the squad around that. Building is more than just about sprinting toward a launch; one needs to create an environment where talent people with strong opinions can disagree productively and still want to work together tomorrow.
This challenge compounds when roles don’t neatly match strengths. Expectations have to be managed and employees convinced to be aligned toward the bigger goal. Managing mismatches while keeping everyone aligned toward a shared vision—which itself might be interpreted different by each person— requires constant calibration.
Human puzzles are often more inscrutable than technical ones. Recruiting is the first test: convincing people to join your team. Everything after that is constant improvisation around who you have, what you need and where you’re trying to go.
Will I get cooked by AI
There’s constant speculation about junior developers being replaced by AI. Some friends have already written about this, well, because we are all in the same boat. We are all trying to get a job in the age while AI rapidly automates away the traditional junior developer tasks: grunt work with clear boundaries and defined outputs. At the time of writing (Aug ‘25), GPT 5 had just achieved 74.9% on SWE-bench Verified while Claude Opus 4.1 achieved 74.5%.
In larger corporations where junior roles are tightly scoped, the threat feels real. If your job is executing pre-defined tasks within strict boundaries, you’re competing directly with AI’s strengths.
Proactivity
But startups are different. Roles are loosely defined, and everyone (intern or full-time) can contribute beyond their official scope. Agency and proactivity become differentiators: the value you add by doing helpful things outside your job description can’t be quantified or automated.
Showing up to office to overhear conversations, sensing where things are headed, connecting dots between different team members’ pain points — these ambient contributions can’t be automated until we have omnipresent AI agents actually embedded in your office.
Context is king
Understanding what different parties actually want (beyond what they say they want) remains deeply human. Instead of pushing your own agenda, map perspectives and get an objective read on the problem. This loops back to ownership: if you’re motivated by the mission, you’ll keep yourself current on decisions and surface context at the right moments. That creates value.
Being an AI-native can be helpful too
Ironically, being AI-native is its own moat. Critical observation during your daily usage across multiple LLM providers gives intuition about UI/ UX patterns and limitations that can be invaluable to AI companies.
Again, I’m super thankful for my time at Menlo and I wish the team all the best in everything they do! Bullish 🐂😎
