OpenAI Codex Product Lead Shares: How We Built the Product Without Standards or a Roadmap
TechFlow Selected TechFlow Selected
OpenAI Codex Product Lead Shares: How We Built the Product Without Standards or a Roadmap
“Interest and autonomy are the most core and important qualities of humans in the AGI era.”
Navigating Web3 tides with focused insightsCompiled & Translated by TechFlow
Guests: Alex, Product Lead for Codex; Romain, Developer Experience Lead for Codex
Host: Peter Yang
Podcast Source: Peter Yang
Original Title: How OpenAI's Codex Team Builds with Codex (43 Min) | Alex & Romain
Release Date: April 5, 2026
Key Takeaways
Alex is the Product Lead for Codex; Romain leads Developer Experience. They gave me a rare, deep look into how the Codex team operates—how they use Codex to build products, and how they ship without traditional product specs or roadmaps. Alex also shared unique insights on the future of product management (PM), and what truly matters in hiring.
Highlights Summary
Real-Time Building & “Thought-Speed” with Codex Spark
- “When you want to build something… you can switch into fast mode—or even Codex Spark—and instantly gain this insane thought-speed to build anything. On the left is GPT-5.4; on the right is Codex Spark. It processes roughly 1,200 tokens per second—absolutely wild.” — Romain
On Specs & Decision-Making
- “I think we write extremely few spec documents on the Codex team. In fact, most of our work is about empowering the people closest to the problem to make as many decisions as possible. So we only write specs when a problem becomes so complex it no longer fits inside one person’s head.” — Alex
Fuzzy Role Boundaries & Designer Evolution
- “Our designers now write more code than engineers did six months ago. Our focus has shifted away from ‘Can it generate code?’ to ‘What do we decide to build?’ and ‘How do we ensure high product quality?’ That’s why, for highly complex features, I prefer assigning a robust owner—not a PM—to manage implementation and maintenance.” — Alex
Product Design Philosophy: Making the Model “Invisible”
- “We design core functionality with extreme care—ensuring it doesn’t become a barrier between users and the model, but instead makes the model smarter and capable of auto-completing more tasks.” — Alex
- “Then, on top of that, we consider how to package the product in the most configurable way possible for advanced users, enabling them to explore and use it freely. For example, users have already implemented sub-agents.” — Romain
Planning Philosophy: Rejecting the “Awkward Mid-Term”
- “At OpenAI, we plan either short-term or long-term—but never mid-term, because mid-term planning is too messy. Short-term means goals up to eight weeks out—the longest horizon we allow. We also set long-term visions—for instance, imagining what models will be like a year from now, far more intelligent. But mid-term planning feels awkward—it usually manifests as a detailed product roadmap, which we essentially don’t have. Instead, we anchor to our long-term vision and focus on concrete tasks that move us toward it.” — Alex
UI Transformation Driven by “Agentic Delegation”
- “Coding will shift to an ‘agentic delegation’ model. Opening multiple terminal tabs and letting them run for hours feels deeply unnatural. We need a completely new UI—and the timing couldn’t be more perfect.” — Romain
The Disappearing Career Ladder & “Talent Stack Collapse”
- “This blurs nearly every traditional career ladder. We’re all ‘builders,’ collaborating to build. If a startup has a PM but fewer than ~20 engineers, that may be a red flag. Interest and agency are humanity’s most essential, defining qualities in the AGI era.” — Romain / Alex
Hiring Standard: Portfolio Over Resume
- “When someone DMs expressing interest in joining our team, my first reaction is: ‘Do you have a link?’ If there’s a link, I always click it—to see whether they’re actually building things. I care far more about their ideas and what they’ve built than their resume. I literally have no idea which universities these people attended.” — Alex
Live Demo: Building a Game in Seconds with Codex Spark
Host Peter: I’m thrilled to host Alex and Romain from OpenAI’s Codex team today. They’ll demonstrate how Codex’s new capabilities work, what Codex can do, and how the Codex team ships relentlessly. Would you like to quickly show what’s possible with a one-shot prompt?
Romain:
Absolutely—I’ll share my screen. There’s a lot I could show, but let’s jump straight in. Here’s an iOS app I’ve been building. If I want to add a new feature—say, a new screen for NASA’s lunar return mission—I simply dictate: “Hey, can you add a new screen for NASA’s lunar return mission?” Then I send that prompt to GPT-5.4, and the model generates the screen for this specific app.
We also have the Codex Spark model, which lets you brainstorm and iterate on anything in seconds. Let me show you the speed difference. On the left is GPT-5.4; on the right is Codex Spark—processing ~1,200 tokens per second. Wild. So when you want to build something—like a game—I just went into the Codex app before this call and created a small Animal Crossing–style 2D game with a quick prompt.
Another feature I love using in Codex—especially when my thinking is crisp—is opening Codex with the chat floating at the top of my screen. That way, while building the game, I can keep iterating and generating new ideas. Peter, any thoughts on what changes you’d like to make to this game?
Peter: Maybe add more decorations—houses, trees—to make it feel more alive?
Romain:
I’ll send that request—and within seconds, Codex Spark edits it live. And there—new trees appear.
That’s why I’m so excited about Codex: You get cutting-edge models like GPT-5.4, capable of extremely complex tasks—analyzing or migrating millions of lines of code. But when inspiration strikes and your thinking is clear, you can switch to fast mode—or Codex Spark—and achieve this insane thought-speed to build anything.
For Product Specs, We Write ~10 Bullet Points—That’s It
Host Peter: I’m genuinely curious how you actually build products with Codex on the team, Alex. Do you still write specs? Or do you ask GPT to write one? Which model powers those workflows?
Alex:
I think we write extremely few spec documents on the Codex team. In fact, most of our work is about empowering the people closest to the problem to make as many decisions as possible, so we only write specs when a problem becomes too complex to fit inside one person’s head. By the way, one person can hold a lot in their head now—they delegate most coding, so one person can do a lot. But if it evolves into something requiring cross-person coordination—or a particularly thorny decision—we might write a spec. Even then, those docs are extremely short—like ~10 bullet points—and nothing more.
Host Peter: Got it. Could you walk us through how that works? For example, you give Codex a few bullet points—does it draft actual requirements?
Romain:
Absolutely! But let me start with a simpler example. Say we’re developing an iOS app that’s already done some work. You have ideas for new features but aren’t sure where to start. That’s where Codex shines—it helps us plan next steps. Just press Shift+Tab to enter “Plan Mode,” type “What should we build?” and Codex auto-generates a preliminary plan. It analyzes the existing codebase, understands current state, and proposes ideas. You can inject your own input to refine it.
In this process, Codex offers suggestions based on current files—e.g., “Should we polish the previously mentioned feature, or optimize the reliability dashboard?” If we pick the dashboard, it guides further: Who’s the target user? It feels like brainstorming with a partner.
I often use this to spark ideas. For simple changes, I just prompt Codex directly to generate code.
Alex:
For medium-complexity changes, I might ask it to generate a concrete plan—or help reason through implementation. When I have a fuzzy idea, I’ll open Codex and ask it to help solve the problem—even if I lack a clear feature spec. Codex can clarify thinking via questions and exploration.
That said, I’m honest: I don’t always adopt Codex’s output directly—especially for complex changes. I use “Plan Mode” to explore, form a clear mental model, then share those insights with engineers. Ultimately, the thinking process matters more than the generated plan itself.
By the way, our designers now write more code than engineers did six months ago—an unthinkable shift, enabled by tooling advances that let designers dive deeper into development. Though I get teased for submitting too few PRs last year. Many were tiny tweaks, but yeah—I should do more.
Today, our focus isn’t “Can it generate code?”—agents handle most coding. What matters is: What do we decide to build—and how do we ensure high product quality? That’s why, for highly complex features, I prefer assigning a robust owner—not a PM—to manage implementation and maintenance.
Designers Now Write More Code Than Engineers Did Six Months Ago
Host Peter: The Codex app feels intuitive and simple. Compared to other professional tools, its learning curve is remarkably low. Some powerful tools demand heavy onboarding—I’d probably never know how to use them unless I followed relevant threads on Twitter.
But what impresses me about Codex is how it balances simplicity with advanced features—like skills and automations. Do you use those heavily internally?
Romain:
Yes—we use them constantly. Skills are among Codex’s most fascinating features. For example, if you’re working with a designer in Figma, just open the Figma skill—it extracts all React components, variables, etc., from the Figma file, and Codex auto-generates code. Or if you’re deploying an app to Vercel, Cloudflare, or Render, just issue a skill command—Codex handles it.
I recently chatted with a friend who had many product improvements in mind. He told Codex: “Write all these tasks to Linear so I can track them.” Used the Linear skill. Then said: “I’m going to sleep—you finish all the tasks we discussed and mark them complete.” When he woke up, they were all done.
Alex:
On your point about the app’s simplicity: We designed it deliberately. Developers love building automation for themselves—so a key product trait is high configurability. Codex is like an open-source toolbox: users dig in and customize it.
Every time we launch a feature, some power users complain on Twitter—even before launch—because they’ve modified or forked the code. To me, that proves success: frontier users co-exploring the future with us and pushing progress.
Yet we recognize building only for high-end users isn’t enough—the product would become opaque. We must balance: serve advanced users *and* keep it simple for everyone. So we design core features with extreme care—ensuring they don’t obstruct users from the model, but instead make the model smarter and more autonomous.
Romain:
Then, we consider how to package it as config-richly as possible for advanced users to explore and use freely. Users have already built sub-agents—not by our design, but through experimentation. Watching how they use features teaches us immensely.
Next, we ask: How do we make these features trivial for others? The Codex app exemplifies this. Around GPT-5.2 Codex’s December launch, model capability stabilized—and crossed a threshold: users began delegating longer, more complex tasks, completed end-to-end.
We noticed users adopting tmuxing—splitting terminals to run parallel tasks. Social media showed wild examples: Peter Steinberger’s 18-terminal setup across three monitors—a “creative open claw.” Seeing elite users wield Codex this way was thrilling.
We kept optimizing task delegation in CLI basics—but realized only the top 1% of engineers work this way. So we asked: How do we make it intuitive? Enter the Codex app.
First launch looks like a simple chat window—just start typing. It works. Over time, you discover sidebars, multi-tasking, seamless switching—feeling super-productive. Then you spot the “skills” tab and explore. We want using Codex to feel like playing a game—uncovering new possibilities.
Romain:
Exactly. And this was our founding vision: coding will happen via “agentic delegation.” Even a year ago, as we began Codex, we envisioned this future—engineers juggling tasks while models handle intricate details.
Frankly, models weren’t ready then. We waited for GPT-5.2 Codex’s release—and that inflection point where models reliably worked for hours or days. Suddenly, the terminal UI felt obsolete. Opening dozens of tabs for hours is deeply unnatural. We needed a new interface—and the timing was perfect.
Alex:
Looking back, Codex had two major “vibe shifts.” The first was last August, with Codex Cloud—a brilliant idea users loved, though perhaps slightly premature. So we launched GPT-5, a stellar interactive coding model, and focused on problems it could solve *now*: Codex CLI and IDE plugins. User growth exploded 20–30x in months—amazing.
The second shift came December–January. We finally achieved our original vision: full task delegation. Models reached a new level—handling complex tasks independently—ushering in a new era.
We Plan Short-Term or Long-Term—Never Mid-Term
Host Peter: Curious how the Codex app was built. Did you draft an annual roadmap a year ago—e.g., “Launch Codex app by X date”? Or did you watch market signals and rapidly prototype ideas?
Alex:
Neither. I heard brilliant advice from our researcher Andre: “At OpenAI, we plan short-term or long-term—but never mid-term, because mid-term planning is too messy.”
Short-term means goals up to eight weeks out—our max horizon. Within that, we define a concrete goal and rally the team to crush it. This is OpenAI’s strength—we excel at aligning around clear objectives.
Long-term, we set visionary horizons—e.g., imagining models a year out: smarter, self-sufficient, no longer needing our machines or limited to single tasks. We envision infinite agents—autonomous, self-verifying, self-deploying, self-monitoring—no manual prompting required.
Mid-term planning feels awkward. It’s usually a detailed roadmap—which we simply don’t have. Instead, we anchor to long-term vision and focus on concrete tasks that drive progress.
Take the Codex app: One strategic goal was freeing users from rigid workspaces. Traditional tools (e.g., VS Code) bind to a specific workspace—a repo checkout or folder. Even git worktree supports only one directory at a time; CLI has similar limits.
Our vision: Users collaborate with cloud-based agents—fully autonomous. They should interact with multiple agents simultaneously—even have one agent coordinate others—naturally and intuitively.
We also realized full cloud dependency would frustrate developers—environment setup, manual intervention during execution, etc. So we built a local experience: seamless with local folders, yet connected to cloud agents.
When starting development, we had abstract “vision thoughts.” Engineers prototyped versions—saying, “We need an app!”—and built diverse iterations. We even held a “hack week” where engineers built different apps independently. You might’ve joined—I forget.
When the project launched, the only thing we wrote down was why we believed building an app was worthwhile. No product spec. Direction emerged through building.
Still, debate existed: Did we really need an app? Our IDE plugin was beloved—should we double down there? CLI had potential. So if we built an app, what was its purpose—and where should it go? These were our early questions.
Romain:
Yes—and luckily, we had a mature IDE plugin, deeply optimized. Users used it in VS Code, Cursor, Windsurf, and more. Plugin codebase experience gave Codex app a rock-solid foundation.
Alex:
Exactly. Codex app and IDE plugins share massive underlying code—both connect to the same core Codex harness (Rust-based, open-source), used by CLI too. We intentionally layered architecture for cross-tool code reuse and extensibility.
Host Peter: Regarding the decision to build the Codex app—looking back, it seems obvious: far more intuitive than dozens of terminals. But our rationale was twofold: beginner-friendliness *and* the best interface for managing multi-agent collaboration.
Alex:
I think our thinking is deeply shaped by the AGI vision. We constantly ask: What will work look like in the future?
Put differently: We knew we needed an interface that lets users naturally delegate tasks to multiple agents. We knew future models would enable this—and saw users already trying cross-agent delegation. We needed an interface making this feel effortless and scalable to the cloud.
We wanted ergonomic design—multi-agent collaboration feeling intuitive, not requiring tricks or complexity.
Romain:
Yes—and the app serves not just beginners. Even OpenAI’s top engineers—Peter, OpenClaw, Greg Brockman—now use Codex app as their primary dev tool. This shows our “agentic delegation” vision is becoming real.
Alex:
Yes. We mention Peter because he just joined OpenAI—we’re thrilled. Last October, walking Fort Mason in SF, I pitched him a new interface for natural delegation. He said he’d never use it.
But last weekend, he tweeted: “Actually, this app is pretty good—I like it now.”
Alex’s Daily Work as Codex Product Manager (PM)
Host Peter: Alex, you were once the sole PM on Codex, right? How big is the team now—~50–100 people?
Alex:
Close—within that range. In May, we were ~8 people—I forget exact numbers. Since then, rapid growth: now ~50–100.
Host Peter: How do you allocate time? What’s a typical day—or is there one?
Alex:
I’ve been reflecting on this—I struggle to answer. I realize my workflow is phase-based—personal, not universal.
For example, launching the Codex app, I was fully in execution mode. My focus was product quality—no detail missed, everything polished. I spent huge time using Codex tools.
We used Codex for feedback—summarizing Slack discussions and user input, logging to Linear. I analyzed code quality with Codex—and made minor code changes directly. Sometimes, fixing small issues with Codex was faster than coordinating others—especially with a two-week launch deadline.
Naturally, human work mattered too—motivating the team, staying critically engaged with the product. I notice execution mode by how much I use Twitter. No idea why—but when I need human connection, I tweet more.
Then there’s another mode, like now: I’m crystal-clear we’ve entered a new phase. Models like GPT-5.4 are superb. App experience exceeds expectations—cross-platform, including Windows. So now, it’s time to pivot back to the cloud—and invest there.
In this mode, I spend more time thinking “what’s next” and assessing current state—coordination mode. Time on Codex drops; I use it for communication, not coding. So at least two modes—and likely more.
Host Peter: How much cross-functional alignment do you need?
Alex:
We rarely need formal cross-functional alignment internally—we intentionally see ourselves as a “pirate ship” team. Even within Codex, only I and two recent PM hires exist. We have leads, but until recently, most reported directly to me—yet we pushed projects loosely, so internal alignment was minimal.
Now, it’s clearer: building Codex hinges on developing the coding agent—and it’s evident coding agents aren’t just for coding. They’re useful elsewhere.
We see users leveraging Codex app beyond coding—across the entire software lifecycle. Most OpenAI employees use it—even non-engineers. I see them daily.
This awareness forces us to ask: How do we make Codex valuable beyond developers? That demands more cross-functional alignment—since OpenAI has ChatGPT, widely used—requiring careful integration strategy.
Romain:
From my DevX perspective, our team functions as an extension of Codex. We focus heavily on Codex for several reasons.
First, it’s an exciting product developers love—and we want to make it even better. As Alex said, our workflow has phases: we join Codex team pre-launch—prepping assets, teaching devs to maximize Codex. Post-launch, we guide exploration across use cases.
Second, looking at OpenAI’s platform: millions of developers already use our API to build multimodal apps—images, voice, etc.
Today, the best dev path starts with Codex. A year ago—or even last summer at GPT-5 launch—we wrote extensive guides on prompting GPT-5. It’s a powerful reasoning model, vastly different from GPT-4. Now, we push devs to use Codex + skills even for those use cases.
Need to update an integration? We suggest Codex + skills. Result: Codex handles it almost entirely. So our team prioritizes cross-functional collaboration—and sees Codex as the bedrock of OpenAI’s developer platform.
Alex:
I find our Codex team’s workflow fascinating—community interaction is the best part. Whether online or at live events, community connection is central.
At launches, we’re release-oriented—clear timelines, deliverables; and feedback-oriented—acting fast on community input, fixing issues, communicating openly. We stay highly online—it’s critical.
Launching Codex app, we partnered closely with Dom and his team. They ran a large alpha test—massive user involvement in co-development. Their feedback improved the app, skills, documentation—everything.
I believe this is Codex’s unique edge: being open-source, we operate with radical transparency—and the community reciprocates with massive support and contribution.
Host Peter: Let’s talk Peter (OpenClaw founder). I’m an early OpenClaw user. How did you integrate him into the team? Is the personal agent vision tied to his work—and how did you plan it?
Alex:
Two angles. First, Peter is a heavy Codex user. OpenClaw was largely built with Codex. His usage yielded rich feedback—greatly improving Codex. Though “part-time,” he’s deeply invested—we’re thrilled.
Second, I can’t reveal details—but he’s helping build the next-gen personal agent, integrated directly into ChatGPT.
Romain:
What fascinates me about Peter’s work is that OpenClaw users sense the future—but Peter saw it years ago.
Reviewing 2025, he shipped 40+ open-source projects—all orbiting one vision: accessing personal tools (calendar, tweets, Gmail) via CLI. He turned skills + CLI vision into reality. Today’s coding agents stem from this.
Tomorrow, this agent won’t just code—it’ll be any personal agent. Peter provided invaluable feedback—he built tools now central to the open-source ecosystem.
Host Peter:
People like Peter—who build outstanding open-source communities—are admirable. His tools are so usable, I don’t want to open other apps—I just chat with my little robot.
Alex:
What systems is it connected to? Everything?
Host Peter:
Yes—banking, YouTube, voice assistants, calendar, Google services. In bed, my wife asks, “Who are you talking to?” I say, “My OpenClaw bot.”
Now, “speculators” charge $5,000 to set up OpenClaw. So making it mainstream and accessible would be huge—you’re clearly headed the right way.
Traditional Career Ladders Are Obsolete
Host Peter: I recall you saying something like “most teams don’t need many PMs anymore”?
Romain:
What astounds me about these tools isn’t just PMs—it’s that nearly every traditional career ladder is blurring. We used clear roles: designers design, engineers build, PMs manage—almost a “golden ratio.”
Now, engineers are vastly more productive. Designers gain superpowers—becoming more technical. PMs once wrote strategy docs—now they prototype. Not for billion-user features—but to build and showcase vision.
So what fascinates me is all role boundaries dissolving. We’re all “builders,” collaborating to build.
Alex:
I think I said somewhere—if a startup has a PM but <~20 engineers, it’s a red flag. I likely did.
As you said, roles are merging. Designers do more engineering; engineers dabble in design; PMs build. But engineers traditionally focused on coding—avoiding triage or PM-style project management.
Now, those tasks are easy. Ask Codex to analyze feedback/priorities—engineers free up time. Everyone can now do others’ jobs.
Scott Belsky coined “collapse the talent stack.” I love it—it’s happening. Fewer people in the room means smoother progress and clearer decisions.
So what’s left for PMs? Many should consider pivoting. If you’re a PM wanting to be an engineer—but stronger at people management than engineering—maybe become an engineering manager. With agents, that’s a clearer role. Some PMs may lean toward design—closer to building.
Ultimately, it’s about interest. For me, interest and agency are humanity’s most essential qualities in the AGI era. So if you love coding—but took PM because “someone had to”—you can now become an engineer and build the same things. Same for design.
But if you’re passionate about user interaction—even if it pulls you from building—understanding needs, spotting trends—then in large teams, PMs still matter.
Romain:
One more point: I still believe every problem needs a human owner—but that person needn’t be a PM. It depends heavily on product nature.
We’re lucky—building Codex, a dev tool. We’re our best users. Being open-source, we co-develop with community.
But ten years ago, at Stripe (250 people, zero PMs, no AI tools), why? Because Stripe is an API product—engineers intuitively understood great APIs. We built the elegant, few-lines-of-code solution we dreamed of.
But in domains where engineers lack intuition about user needs—PMs bridge the gap. Especially when serving industries misaligned with engineer intuition, PMs are vital. We’re lucky—building tools we ourselves want.
Alex:
In such environments, a PM is just a label for the person most interested in users—often an engineer close to users. So labels lose traditional meaning—messy, but not bad.
Host Peter:
I see similar patterns. Best engineers don’t ask, “What should we build next?” They talk to users, figure it out, then discuss with me—keeping goals aligned.
Romain:
That’s Codex’s workflow. Many Codex app features originated bottom-up from engineers—because they needed them.
Alex:
I’ll add: I love engineers who enjoy user conversations and thinking about features. They’re often excellent system builders—fast, skilled, clear-thinking. Others dislike user interaction entirely—focused solely on systems. They have huge upside too.
Again, my view of the AI era: We can all be more authentically ourselves. AI and teams help with tasks you dislike—freeing you to focus on interests and strengths.
Host Peter:
I strongly believe the “builder” label matters. Many PMs want leadership—but traditional ladders lead to VP roles where you stop building. You’re stuck in reviews, giving feedback—not shipping. Many PMs hate that—I want to stay close to users and ship products.
Alex:
I fully agree. I don’t see PM as a leadership role—I see it as a “gap-filling” role. Sometimes it requires leadership—but leadership here means aligning teams, not relying on one person’s genius.
One certainty: OpenAI’s best PMs dive deep into details. Joining OpenAI as a senior leader is tough—the culture still values detail obsession. So best practice is diving into details from day one.
What Does Codex Look for in Hiring? (Spoiler: Not Your Resume)
Host Peter: Beyond being heavy Codex users, what qualities do you seek when hiring for Codex?
Alex:
I emphasized “agency” earlier. We seek people who act—this is paramount.
At OpenAI—especially Codex—culture isn’t “Here are 12 progressively harder tasks.” It’s: “Welcome! Start exploring.”
We seek self-starters—people with initiative, ideas, clarity on goals, unafraid to challenge assumptions. Truth is, some assumptions may be wrong—mere accidents of history.
My ideal teammate takes extra ownership—even over unknown domains. These traits matter most. For skills, we prioritize strong technical/engineering profiles.
Romain:
I fully agree. In DevX, I seek high-agency individuals—technically strong, especially with tools like Codex. But crucially, I value passion for working with developers and builders—and sharing knowledge.
For example, Thomas just joined my team—he built the open-source Codex monitor. Highly creative, heavy Codex user, loves sharing how he builds tools with Codex.
We need such people—we’re guiding millions of developers toward Codex’s bright future. I believe agentic coding is transforming how we think about software, apps, and products. Our goal: show the world this possibility—and help developers learn to leverage these tools for their ideas. That’s what I seek.
Alex:
I’ll add: Ideal DevX candidates are “excellent engineers who also engage well with community via social media.”
Romain:
You’re partly right—but I’ll expand: We want candidates deeply responsible to community—and mindful of global social media habits. In some regions, devs prefer LinkedIn over Twitter. So “global social media fluency” matters. We especially value those who love community interaction, teaching, and knowledge sharing.
Host Peter:
Agency shows even before interviews—e.g., do they post work online? Have side projects?
Alex:
When someone DMs expressing interest, my first thought is: “Link?” If yes, I almost always click—to see what they’ve built.
Some attach cover letters explaining interest—or resumes—but I care more about their ideas and actual work. I recently realized: I have no idea which universities these people attended.
Host Peter: Who cares? I’m thrilled we live in an era where stupid degrees matter less—and seeing what you’ve built is enough.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
