From Co-Op Kid to Building the AI Factory
Arjun Krishna, founding engineer at 8090
My next guest is Arjun, a founding engineer at 8090, a platform rethinking how software gets built by bringing structure to the parts of the development cycle that usually get skipped: requirements, architecture decisions, and ownership.
Arjun joined just months after the company was founded, after a chance encounter at the All In Summit landed him in a dinner conversation with Chamath that turned into a job offer. He came in as the first non-founder engineer, inherited an AWS-native stack, and has since helped shape everything from the core transcription pipeline to how the company hires.
We talked about his path from Waterloo co-ops to Menlo Park—including the side project that got killed by its own API provider—why he thinks cognitive debt is a bigger risk than technical debt in the age of AI-assisted coding, and what it actually looks like to benchmark your way into a technical argument rather than just making one.
Ben: Walk me through your origin story and how you ended up at 8090.
Arjun: I went to the University of Waterloo, did a bunch of co-ops. My first had a small software component and I was immediately drawn to coding. Then I worked at Huawei, more corporate. My third co-op was at a startup, and within a week I was shipping features that customers were using. Very addictive.
When Eleven Labs launched, me and some friends built a video dubbing and translation site using their API, Whisper, and some custom tooling. We got real users, so I took a gap year to work on it, until Eleven Labs shipped their own dubbing feature and all our customers churned overnight. So I went back to finish school.
Then a friend sent me a link giving away student tickets to the All In Summit. I applied, somehow got a VIP badge, ended up at a dinner where Chamath was there. I knew him from Waterloo—he’d given a keynote at Hack the North. I walked up, introduced myself, and he said email me your resume, I just started this company. I met Sina, the CTO, who had co-founded 8090 with Chamath a few months earlier. I started working with them while finishing up at Waterloo, then moved to Menlo Park full time.
Ben: What’s it been like working at 8090 with someone like Chamath?
Arjun: It’s been a really unique environment. It’s not a place where seniority automatically means you’re right. Even if I disagree with something Chamath says, someone who’s been building in Silicon Valley for 30 years, I’ll state my case and argue it through. If you can really make your argument, people will say: alright, you’re actually right. That was genuinely surprising to me coming in.
I expected to be handed a ticket queue and told to execute. Instead it was much more like: you need to help define what we’re building, weigh in on how we’re hiring, have opinions on go-to-market. Early on I was very vocal that we should GA the product and get external users rather than just dogfooding internally. It took some convincing, but I eventually won the team over. Seeing that play out was really fulfilling—not just the outcome, but realizing that your voice actually matters from day one if you back it up.
Ben: But I’m curious about the flip side: do you think you need a key win first before people actually listen, or is it more about how you show up from the start?
Arjun: It’s really about how you show up. You need results, but more importantly you need to come with solutions, not just problems. At a startup there are infinite problems at any stage—that’s just the nature of it. You have to be the person who says here’s the plan to fix it, here’s how I’ll execute it, does that work? Pointing out what’s broken without a path forward just adds noise. The people who build credibility fast are the ones who make it easy for founders to say yes.
Ben: Let’s get into the technical weeds a bit. Give me a concrete example of a decision where you pushed back, went and did the work, and it actually changed the outcome.
Arjun: Sure. We’re very AWS-native because a lot of the co-founders came from there, so there was a natural gravitational pull toward the AWS ecosystem for everything. I was building out a transcription pipeline and the team wanted to use AWS Transcribe. I thought it was expensive, slow, and the output quality wasn’t where we needed it—especially for the kinds of audio we were processing.
So rather than just raising the concern in a meeting, I quietly started benchmarking OpenAI’s Whisper on the side. I built out a proper test set—same inputs, same target output schemas—and ran both models against it across a range of real audio samples. Then I brought the results to the team side by side: accuracy comparison, latency numbers, cost per hour of audio. Everyone looked at it and said let’s just switch.
The show-me-don’t-tell-me approach is what made it land. The broader lesson is that people at startups are spread thin, and decisions you assume were deeply considered often weren’t. If you’re the one closest to a problem, act like an owner. Even if you started with a given mandate, if you have new data, ask whether that mandate still makes sense.
Ben: That’s a great example of how you earn technical trust early—you don’t argue your way into it, you benchmark your way in. There’s a balance there though between pushing back and knowing when to just commit and ship. How do you think about that line, especially when you’re moving fast and the architecture decisions have real downstream consequences?
Arjun: You’re not going to get points for always being agreeable, but you can’t endlessly debate either. Every project needs one directly responsible individual who can say: I’ve heard the input, we’re making this call, we can revisit if we’re wrong. That accountability structure is something I’ve come to really believe in—it cuts through the noise and keeps things moving.
And once a decision is made, even if it wasn’t yours, you have to execute on it fully. You can disagree and commit. What you can’t do is half-commit and then let it fail so you can say you were right. That’s toxic at any company, but especially at a startup where everyone is watching and energy is contagious. Bad faith execution poisons the well fast.
Ben: I want to dig into something you mentioned—this idea of “cognitive debt” as distinct from technical debt. I think most engineers have a pretty clear mental model of technical debt, but cognitive debt is a framing I haven’t heard before. Unpack that for me.
Arjun: Technical debt is real, but cognitive debt is more dangerous. It’s what happens when the team has been so heads down that they’ve lost the thread of what they’re actually building. You’re vibe-coding, shipping fast, but the PRD has drifted, the architecture decisions are undocumented, and nobody can clearly articulate what the customer actually needs anymore.
That’s why we built Software Factory internally—the core idea is that you need three things to stay aligned: a clear product requirements document that defines what users should actually experience, an engineering architecture doc that captures major decisions and the reasoning behind them, and well-scoped tickets with clear owners and timelines. If any of those layers get fuzzy, you’re accumulating cognitive debt faster than technical debt. It’s like being on YouTube until 2am—you kept moving but you have no idea where you ended up.
Ben: The archaeology project analogy really hits. I’ve been in codebases where you pull on one thread and suddenly you’re reading three-year-old Slack messages trying to figure out why a decision was made. The scary thing with tools like Cursor is that they make it so easy to keep going that you forget to stop and ask whether you should. Let’s zoom out—you’ve joined early a few times now, started your own thing, been through the full cycle. What’s your honest take on the founding engineer path for someone considering it?
Arjun: First, it’s about who you’re working with more than what you’re working on. I admired Chamath for a long time, but what really got me was meeting Sina—the way he thought, the problems he wanted to solve. Those are the people you want to spend years learning from.
Second, you’re not going to have one job—you’ll have two or three running simultaneously. Engineering, customer success, recruiting, sales input. What takes four years to learn at a big company, you can compress dramatically. The growth curve is just different.
Third—and this is something I learned early—you have to be willing to kill your babies. You will fall in love with things you build. But when something gets rolled back or scrapped, you get one day to be sad and then you move on. That work always teaches you something that shows up somewhere else later. Getting emotionally attached to a specific implementation is the thing that will slow you down most.
And last: learn to stay calm and execute when things feel chaotic. The startup emotional roller coaster is real, but the skill you’re building is how to keep shipping even when it feels like you’ve been punched in the gut. That’s the actual job.
Ben: Last one—any parting advice for someone on the fence about making the jump?
Arjun: Learn to stay calm and execute when things feel chaotic. People talk about the startup emotional roller coaster but you don’t really understand it until you’re in it. The skill you’re actually building is how to keep shipping even when it feels like you’ve been punched in the gut—when a major refactor breaks prod at 11pm, when a customer churns the week you launched for them, when the architecture decision you fought for turns out to be wrong. Things get better, you improve, the product gets clearer—but only if you keep moving. That’s the real job. Everything else is learnable on the way.
Arjun’s path, from a video dubbing side project that got killed by its own inspiration, to a VIP badge he wasn’t supposed to have, to Menlo Park, is a case study in staying in motion. What ties it together is a bias toward showing results over arguing for them, a willingness to challenge decisions with data, and the discipline to keep building through the chaos.