Memex — general‑purpose agentic vibe coding platform

Seth frames Memex as a middle ground between easy, hosted builders like Lovable and full IDEs like Cursor—powerful and flexible, but still approachable. He highlights that it’s language‑agnostic (build in Python, JS, etc.) and it runs on your computer. The agent writes and executes code locally, but you can still sync to GitHub / deploy to the cloud. That matters for ownership, privacy, and the ability to build beyond “just a web app.”

Similar to tools like Replit, Memex has a Plan Mode (like an AI product‑manager that helps scope and de‑risk before building) and a Build Mode. Memex was also recently shortlisted by Digital Ocean and Zapier as one of the best vibe coding tools in 2025.

[Disclaimer: I am a founder of Memex, so I tried to keep it to the points Seth made to avoid too much bias!]

Base44 — integrated, all‑in‑one stack (now part of Wix)

Seth frames Base44 as the easiest tool for beginners. Its backend (database) and auth are integrated, so you can sign in, describe what you want, and get something working with minimal setup. That “everything in one place” lowers activation energy for first‑time builders, though it can mean less flexibility if you prefer full control over your data layer.

Wix acquired Base44 in summer 2025, and thus far the M&A dynamics don’t seem to have impacted the product direction too much. Having been acquired in the past, I know from experience it can be quite disruptive–but the Base44 team seems to be shipping well throughout the integration.

Bolt (bolt.new) — integrations first, token‑metered usage

Bolt leans into Figma and GitHub from the jump: import a design file, round‑trip with your repo, and iterate from there. If your workflow starts in design or lives in GitHub, that orientation feels natural.

Pricing is token‑based: complexity and project size drive cost more than sheer message count, which is different from some message‑credit systems. You’ll typically connect an external database (often Supabase) rather than using an integrated backend. They recently launched an update to their agent that embeds Claude Code and OpenAI’s Codex coding agents directly into Bolt. That in itself is an interesting development–the AI model companies have released many frameworks for building agents on their models, but this is one of the more high-profile adoptions of such tools. Whether that will be a lasting trend or not is to be determined.

Lovable — popular, with a new agent mode

Lovable is a crowd favorite with a familiar chat‑to‑build experience. The recent Agent Mode moved pricing toward usage‑based billing (cost scales with task complexity), which aligns with what Seth mentions about evolving models. On the backend, many users pair Lovable with Supabase for database, auth, and edge functions. (Lovable, Lovable Documentation)

If you’re comparing Bolt vs. Lovable: both support GitHub and Supabase; the right choice often comes down to which editor flow you vibe with. That’s exactly Seth’s advice—try both on a small build and see which one “clicks.” (YouTube)

Emergent — very agentic, one‑prompt end‑to‑end

Seth calls Emergent out for being highly agentic: you describe what you want and it coordinates multiple agents to scaffold, debug, and ship with minimal back‑and‑forth. If you like the idea of a one‑prompt build experience and can live within that system’s conventions, it’s worth a spin.

Emergent’s own positioning matches that: “think it, describe it, ship it,” with agents handling full‑stack tasks (frontend, backend, auth, deploy).

Replit — popular, and now with integrated database options

Replit remains a go‑to for many builders because everything’s in one browser workspace. Seth notes he’s personally gotten “stuck” more here than with the others, but also that these tools improve fast—so your mileage may vary. If you want a hosted environment with an integrated SQL database (and recent improvements to separate dev/prod DBs), Replit’s worth a look.

Bonus: Cursor (and Windsurf) — the IDE route if you’re more technical

Seth suggests you might start with an app builder, then “graduate” to a developer IDE like Cursor (or Windsurf) for more control and typically lower per‑unit costs at scale. Cursor’s model is familiar to engineers: a VS Code–style IDE with chat, refactors, and multi‑file edits, plus straightforward plans. Windsurf is a similar, agent‑forward IDE. If you’re comfortable in code, either can feel like home.

Sources: Seth’s video overview and official docs/pricing pages for each tool were used to ground the details above. (YouTube, Memex, TechCrunch, bolt.new, Bolt Help Center, Lovable, Lovable Documentation, Emergent, Y Combinator, Replit Docs, Replit Blog, Cursor, Windsurf)

What began as an idea to give an engineering partner to every scientific professional has evolved into a desktop-native, general AI agent for vibe coding.

For an indie dev, $10k MRR is a huge goalpost. For a venture-scale business, it’s the very beginning. And in my former life selling to enterprises, I wouldn’t even do a POC for less than $25k. But this is my first rodeo creating a product-led business. And while we’re not satisfied with our progress, we nonetheless celebrate the milestone of having users that champion us and having a product we feel proud to work on every day.

We’ve all heard the adage “overnight success, long in the making“. Nevertheless, we almost always over-index on the “overnight success” and not as much on the “long in the making”. Thinking about how to share the news of our recent milestone, I was confronted by the decision “how should I position it?”.

The enterprise sales entrepreneur in me wants to say “Memex hits $120k annualized revenue 30 days after launch“. That is technically true … but it’s just narrative. In the early days of fundraising, selling to enterprises, and hiring, you’re constantly looking for the positive narratives you can tell to recruit people to your vision. Finding ways to turn bland reality into sexier narratives is an art.

But what I love about product-led entrepreneurship is that you can cut the bullshit. Either people love your product, or they don’t. In that spirit, I decided to tell a different narrative in this post. The bland, grueling, unsexy one. The one about “long in the making”.

For those of you building, creating, crafting, and making out there, I hope it may be of some use.

Long in the making

First - the unsexiest line of all:

Memex hits 120k annualized revenue 30 days after launch
It took 2 years and 2 months to hit $10k MRR after David left his last job to start a company

We incorporated in June of 2023, but I left to start a new company in March of 2023. Often times founders are working on their idea far before they even incorporate. But we often don’t talk about that …

Well - there you have it: for me it took 26 months from standing start to get to something that starts to look like a good business if you squint at it.

We pivoted twice before landing on the idea to build an agentic coding tool for scientific professionals last May (I’ll spare you the details of the other two ideas). For those close to the evolution of LLMs, that was when GPT4-Turbo was still the G.O.A.T. coding model — feels like 5-years ago in the LLM timeline.

We started with self-service prototypes using Figma and Supademo. This is one of our first, non-functional prototypes. We did several iterations. For each version of the prototype, we'd DM it to hundreds of people. We got responses from ~150 people and had 1:1 google meet convos with >50 in the first ~30 days.

Let that sink in. We were working our asses off rapidly iterating on the prototype and DMing people that roughly fit our contrived ICP for a vague idea we had. At the time, agentic coding tools were either a joke or non-existent. And we were 14 months and two pivots in. That’s the thing about starting a company and finding an idea/traction — you have to keep grinding even when it’s not working. And along the way you have to kill your darlings, and keep up an aggressive pace even if it feels like you’re marching nowhere.

The self-serve prototypes gave us a clearer picture of users' wants, needs, and willingness to pay. Keep in mind that this was before Clade Code, or before Cursor or Windsurf had agents. Scoping an agentic engineering tool was not obvious.

We built an MVP in ~6 weeks and gave it to some early users. We didn't charge them - building a billing system was premature until we had a clearer picture how to charge and validation that we had something people wanted to pay for.

We spent the next 3 months trying to get the agent to a point that it was actually helpful to users. It was during this time we expanded from just scientific professionals to “tech saavy professionals”, because users were using it for a broad swath of use cases. But from June through September of 2024 it couldn’t hit the bar for quality to keep users using it. We were paying ~$10/day on ads to find alpha users.

Then in October we started getting an uptick in usage. People would discover the product, onboard, and then use it ... A LOT.

Finding traction

In November we realized through diagnostic errors that one user was hacking people with it - successfully. We cut him off. He spent the next 2 weeks trying to hack US to keep using it. He then emailed us begging to use it. That's when we realized we had something we could charge for.

On December 6th we released a beta version that had billing. We got our first paying customer four days later. He remains one of our most active today!

We hit $1k MRR in the first 30 days of our closed beta, mainly through spending lots of time engaging on X and some ads. But we had issues: the agent was extremely inefficient, people weren't using version control and were losing work, and some were racking up huge charges and then cancelling their credit cards to avoid payment.

We decided to stay heads down and fix these issues that were plaguing us. We made the agent twice as token efficient, added checkpoints to automatically version our users’ work, changed to a pre-pay model, and fixed a long list of bugs.

Our launch was pretty simple:

• We made a high quality video (on a budget)

• Posted on our social accounts

• Launched on Show HN (see my previous post about that)

• Asked friends to post

• Paid for placement in 2 newsletters

• Increased activity on social media

That got us up to $10k MRR in 30 days.

What’s next?

We have lots to improve on the product. Our users want Memex to be an MCP Client, we’re working on a "Team" plan with specific features with a development partner, and we need to make it generally easier to use for less technical people.

We need to do all this and spend more time on growth.

We are still experimenting a lot with our distribution channels. But here's what we've learned thus far and we expect to continue on our path to $100k MRR and beyond.

👥 Community

We spend lots of time investing in our Discord community. We work hard to help users, and in return they're more likely to share feedback, support each other, and invite others. Half of our new users yesterday were referrals.

It's also a ton of fun and rewarding. The Discord increasingly feels like an extension of our team Slack channel where we are working along our users to build great stuff.

🛠️ Building in Public

I've spent my career selling to execs. I have little experience on social media. I've learned the hard way that anything "salesy" is either lambasted or worse - ignored.

Authentic content performs best, and building in public is the best version of that.

💁 Influencer marketing

I often hear about growth without ads. But looking at YouTube's ad library is revealing: A TON of videos on YT are paid promo by startups (add `&sv=1` to the end of search queries on YT).

We won't rely on paid promo, but we'll use them as we grow.

Back to building

Hope this is helpful to others also building 💪 This is my first product-led journey, and I'd love feedback! 🙏

If you liked this post, follow me here for more about our journey!

That's it for now — I’m off to vibe code something 😎

• A Taiwan conflict's primary tragedy would be the immense human cost, eclipsing any industrial impact.

• If TSMC (critical AI chip supplier) output goes to zero ("TSMC-Zero"):

  • Asymmetric AI Impact: Simpler, unimodal AI (reasoning, coding) would likely be more resilient due to distillation & efficiency, while complex multimodal AI (vision, robotics) would suffer more.

  • Winners: Open-source AI, on-device AI, and startups focused on compute efficiency.

  • Losers: Autonomous hardware (self-driving cars, humanoid robots … Tesla), intensive multimodal applications (video generation), and API-dependent apps relying on frontier models.

• Big Tech is Stockpiling: Massive GPU spending by cloud giants isn't just for current AI growth; it suggests a degree of strategic stockpiling to hedge against TSMC disruption.

• The convergence of AI's chip dependency and Taiwan's geopolitical risk is a critical, under-discussed global vulnerability.

The world is grappling with two colossal, simultaneous shifts: a changing world order and AI.

First, the decades-old, US-led geopolitical order is cracking. China is actively pushing for a new global structure, and Taiwan is a central flashpoint. Forecasting communities like Metaculus put the odds of a Chinese attempt to blockade Taiwan by 2030 at 40%, invade Taiwan by 2030 at around 30%, and invade Taiwan by 2050 at 68%. This geopolitical instability alone is immense.

For context, in the lead up to the Ukraine conflict, the Metaculus community prediction of a Russian invasion of Ukraine was just 35% only 2 months before the invasion happened.

Second, Artificial Intelligence is exploding. It's not just another technology; it's a foundational force promising to reshape everything from labor and science to warfare and governance, with scenarios like those in "AI 2027" projecting superhuman capabilities within years.

It is paramount to state upfront that the most devastating consequence of a kinetic conflict over Taiwan would be the horrific human cost—the loss of life and suffering in Taiwan and potentially far beyond. That human tragedy would eclipse any industrial or economic fallout.

As we consider the multifaceted global risks, the deep entanglement of AI's future with Taiwan's fate also warrants attention.

Individually, either of these dynamics would define an era. But they are deeply entwined with one another, and I find the intersection of AI and Taiwan oddly under-discussed. TSMC is the near-monopolistic producer of the advanced chips powering the AI revolution, holding roughly 67% of global foundry capacity and over 90% of 3nm capacity. This makes AI's future dangerously contingent on a geopolitical fault line.

I've been trying to reason through the cascading risks. Here's how I'm thinking about it.

1. Imagining "TSMC-Zero": What's the baseline for impact?

If geopolitical tensions escalate and TSMC's output drops to zero, what happens to the AI industry? TSMC isn't just a major player; it's foundational, accounting for roughly 67% of global foundry market share by revenue in Q4 2024 and an even more dominant portion of advanced nodes—around 70-80% of 5nm and 90% of 3nm production.

While “TSMC-Zero” would be unprecedented, there are at least some historical examples of semi-conductor supply shocks that could be useful analogs.

Huawei Cutoff (2020)

U.S. export controls cutoff Huawei's access to TSMC's leading-edge chips in mid-2020. Huawei had represented about 23% of TSMC's revenue in 2019, and subsequently saw its smartphone shipments drop from over 240 million units in 2019 to under 31 million by 2024. While TSMC adeptly reallocated capacity and maintained growth, Huawei's device business was crippled.

Huawei survived the shock, but largely due to its diversification. Many companies whose growth depends on expanding GPU capacity would stuggle to fare so well in a TSMC-Zero scenario.

Renesas Naka Plant Fire (2021)

A fire at Renesas's Naka plant, a supplier for nearly one-third of global automotive microcontrollers (MCUs), temporarily reduced its output to 88% of pre-fire levels for weeks. This single-plant incident forced major automakers to idle plants globally.

Many industries are increasingly reliant on chips. This example brings to mind the impact of TSMC-Zero on the automotive industry … Tesla, for example, has largely staked itself on autonomy with both self-driving cars and humanoid robots, increasing its exposure to geopolitical risk over Taiwan.

These events, devastating as they were, would be dwarfed by a complete cessation of TSMC's output. The current U.S. CHIPS Act, while aiming to diversify supply chains, also highlights the strategic importance of these components by, in part, limiting China's access to leading-edge technology—an ongoing experiment with its own set of cascading consequences. A "TSMC-Zero" scenario implies a multi-year paralysis for industries deeply reliant on advanced semiconductors, with AI at the forefront of vulnerability.

2. Asymmetric AI Impact: Will some capabilities suffer more?

China has had restricted access to leading-edge AI chips since October 2022, due to U.S. export controls. Despite these limitations—forcing reliance on downgraded chips like Nvidia's H20 variant for China or necessitating complex workarounds—Chinese labs have demonstrated impressive progress nonetheless. DeepSeek took the world by storm with its R1 reasoning model—the product of aggressively distilling larger models. It achieved competitive performance on math and coding benchmarks with relatively smaller parameter counts (e.g., 14B-32B variants).

Despite the impressive reasoning progress, Deepseek’s model has no multimodal capabilities.

This observation supports my theory of asymmetric impact:

a widespread chip supply shock might hit some AI capabilities harder than others, depending on their reliance on raw compute versus the efficacy of distillation and efficiency techniques.

The question becomes, which AI use cases are more resilient to TSMC-Zero and which are more vulnerable?

More Resilient Areas (Reasoning & Coding)

Unimodal tasks like text-only reasoning or code generation exhibit shallower loss-versus-compute power laws. Neural scaling exponents (α) for text can be as low as 0.037-0.24, meaning performance degrades more gracefully with reduced compute.

Techniques like distilling step-by-step or program-aided distillation can effectively transfer reasoning and coding capabilities from large, powerful models to much smaller, more efficient ones. Microsoft's Phi-4-reasoning-plus, a smaller model, outperforms larger 70B models on certain math and logic tasks, and frameworks like CodePLAN have shown smaller models can rival or exceed few-shot LLMs on coding benchmarks.

Because of these trends and the anecdotal evidence of Deepseek performing well despite the CHIPS Act, I think it’s likely we would see reasoning and coding be more resilient as AI use cases .

More Vulnerable Areas (Complex Multimodal AI)

Multimodal applications (integrating vision, audio, video) inherently require larger parameter counts and significantly more compute to achieve state-of-the-art performance. Adding vision or audio tokens raises the compute-optimal parameter count considerably. Studies show that even with fusion techniques, multimodal systems need substantially more compute than text-only models for similar loss reduction.

Even when unimodal baselines are strong, integrating multiple modalities adds significant overhead. For instance, visual question-answering can see up to 29% gains from a strong text-only baseline, but the multimodal integration itself is compute-intensive.

Therefore, a scarcity of leading-edge chips would likely disproportionately impact the development and deployment of advanced multimodal AI. Progress in reasoning and code generation might prove more robust, sustained by innovations in software, model architecture, and distillation. Labs facing chip shortages would likely prioritize these unimodal advancements, while breakthroughs in rich multimodal experiences would hinge more directly on access to large-scale, high-end silicon or significant advancements in domestic hardware capabilities, like Baidu's Kunlun clusters. Autonomous hardware use cases would be hit hard.

3. Hyperscalers are hedging

It bears repeating: forecasting communities like Metaculus assign a significant probability—around 30-40%—to a Chinese attempt to invade or blockade Taiwan by 2030, with similar markets on Manifold showing a 42% chance of a full-scale invasion before then. Such a conflict would directly threaten TSMC's production, which accounts for about 67% of global pure-play foundry revenue and is the exclusive supplier for most advanced 3nm and 5nm GPUs. Advanced packaging, like TSMC's CoWoS, also remains a critical bottleneck for AI GPUs. A halt here would freeze the global deployment of cutting-edge AI hardware.

Against this backdrop of non-trivial geopolitical risk, the major hyperscalers (Microsoft, Amazon, Alphabet, Meta) are pouring unprecedented capital into GPUs and data centers. Their combined capital expenditure is skyrocketing, projected to hit $320 billion in 2025—a 13-fold increase in a decade. This has prompted some to question the return from such staggering investments.

Global data center capex alone surged to $455 billion in 2024, with the top ten hyperscalers comprising over half of this. Microsoft is planning an $80 billion AI data center expansion this year, while Google reaffirmed a $75 billion AI infrastructure push, and AWS is investing $15.2 billion in Japan by 2027 for its AI backbone and $4 billion in a new Chilean cloud region for generative AI.

For me, this raises a critical question:

Is this explosive spending solely to meet the current surge in AI demand, or does it also represent a strategic hedge against a potential TSMC supply shock?

My take? The evidence points to both …

On the one hand, I expect the primary driver is the growth in AI model complexity and widespread demand for inference, which together dictate huge computational requirements. And its plausible that all the big tech leaders are “AGI pilled” believing they can achieve systems capable of recursive self-improvement using these capital investments.

But on the other hand, the economic climate suggests that the supply of AI could outpace the demand for it if consumer spending drops, prices go up, and interest rates stay high. Nevertheless, Big Tech is doubling down on its capital investments.

Stockpiling is not unprecedented. ByteDance, Alibaba, and Tencent reportedly stockpiled approximately ~1 million Nvidia H20 GPUs before the export curbs took full effect, demonstrating a clear precedent for front-loading supply in anticipation of restrictions. Of course, the export curbs were an acute situation. Nevertheless, if I’m Satya Nadella looking at the geopolitical situation, and my growth bet is on AI—the downside risk from over-investing in GPUs is mitigated when weighing the likelihood that their value could suddenly double in the likely event of a conflict over Taiwan.

So, while the overwhelming demand for AI compute is the primary catalyst for this capex boom, the sheer scale of these investments suggest to me a concurrent strategy. Hyperscalers appear to be not only racing to meet current demand but also actively front-loading capacity and building resilience against a potential, and increasingly plausible, disruption to the critical TSMC supply chain originating from Taiwan.

4. Who would be the winners and losers post-shock?

To me, this is the question I continue to wrestle with. I’m highly uncertain who the winners and losers may be, but I have some general thoughts:

Potential Winner: Open source AI

Open source models have a lower cost structure than proprietary models, largely because the ecosystem creates a rich environment for distillation. TSMC-Zero would drive more innovation into increasingly compute efficient models.

Potential Winner: On-device AI

Desktop, mobile, and edge based applications that don’t rely on a cloud-hosted GPU for model inference may have accelerated adoption as cloud-hosted models become less reliable.

Potential Loser: Autonomous hardware

From self-driving cars to humanoid robots, the impact of taking the next generation of leading edge chips would be nothing short of the crushing blow to Huwawei’s device business when it was banned.

Potential Loser: API-Dependent apps relying on frontier models

Businesses building heavily on APIs from major model providers (e.g., coding tools powered by Anthropic) could face throttled access, higher API call costs, or degraded service as underlying providers ration their own constrained GPU resources, prioritizing premium customers or internal needs. Startups with smaller capital reserves may be forced to pivot or shut down.

A TSMC supply shock would act as an intense evolutionary pressure on the AI app layer. Companies that have proactively engineered for efficiency, diversified their compute sources, and adopted flexible infrastructure strategies will be best positioned to survive and potentially thrive. Those tethered to high-cost, monolithic compute paradigms without significant capital buffers will face a harsh reality.

Navigating the Wafer's Edge

The convergence of escalating geopolitical risk around Taiwan and AI's foundational dependence on TSMC creates a precarious situation. The future of AI isn't just about algorithms and data; it's deeply enmeshed with semiconductor manufacturing and the stability of a single region. Understanding these interdependencies – from historical supply shocks and asymmetric impacts on AI capabilities to hyperscaler strategies and the app-layer fallout – is crucial for anyone building or investing in this transformative technology. We are navigating on a wafer's edge.

Look at my calendar and propose some time blocks for me to meet with my friend given his availability and mine …

A query like that would require connecting with the calendar — a service. There are millions of services that could be connected to AI Agents via MCP, like your calendar.

This post shows how I “vibe coded” an MCP server for accessing Hacker News in three prompts.

The above video shows me creating an MCP Server to expose the Hacker News API in one prompt, then deploying it to Netlify in a second, and using it in a third. There are no speedups other than my typing, but I cut the LLM generations out (original uncut is 10 minutes long).

Specifically:

Prompt 1: Memex creating an MCP server for interacting with the Hacker News API

Create a Hacker News MCP server that allows me to fetch HN posts. Reference these API docs: https://raw.githubusercontent.com/HackerNews/API/refs/heads/master/README.md

Prompt 2: Deploying it to Netlify

great! now deploy this to netlify

[Copied and pasted from terminal output]

Site Created

Admin URL: https://app.netlify.com/sites/hn-mcp-server

URL: https://hn-mcp-server.netlify.app

Site ID: ff8e810e-3ec6-4583-8d9b-6a07df94c376

Linked to hn-mcp-server

Prompt 3: Using it to return the latest Show HN posts

Great! Tell me the last 5 Show HN posts

You can see a full view of the user messages in the conversation here (agent replies are collapsed):

If you want to check it out, the GitHub repo is here, and you can try it yourself here.

How it works

tl;dr - we combined an agentic coding loop with a templating system in Memex so users can go from prompt to a working MCP server quickly.

Longer answer …

All coding apps leverage the same underlying models; what sets them apart is how they wield them. Though there are many ways to slice the market, I find it useful to draw a distinction between App Builders and Agentic Coding Tools.

Agentic Coding Tools are inherently general-purpose. Their system prompts focus on leveraging the full suite of tools and structuring problem-solving workflows. They often inject rule files into context and empower the agent to search the web, execute commands, and create or modify files.

App Builders, by contrast, prescribe how the agent must build. Their prompts are narrowly scoped to a specific tech stack, and the interaction is less free-form. With templates and pre-built components, they reliably deliver a solid first version in response to a single prompt—the quintessential “prompt-to-app” use case.

Supporting prompt-to-app use cases with an Agentic Coding Tool

Memex is fundamentally an Agentic Coding Tool. Its toolset, prompting, loop, and UX are all designed to support anyone learning and building anything—embodying the idea of a “general AI agent.”

Many users—primarily professional developers who could code these tasks themselves—turn to Memex for a productivity boost, whether it’s spinning up an internal tool, writing a script, or creating an integration. At the same time, we also have a large cohort of users who want to build something outside of their area of expertise: developers tackling unfamiliar languages and non-technical users building websites, web apps, or iPhone apps.

Implementing something like an authentication flow can be notoriously cumbersome, demanding precise prompts to guide an LLM effectively. For those working outside their domain, crafting and refining those prompts through iterative exchanges can add significant overhead before everything works smoothly.

Memex’s templates aim to bridge the gap between flexibility and convenience, helping users scaffold complex projects quickly without sacrificing its general-purpose nature—essentially delivering prompt-to-app capabilities within a versatile platform.

Behind the scenes, each template lives in a GitHub repo. When you invoke a template, Memex automatically clones that repo locally (no Git setup required), detects a .memex/rules.md file containing project-specific prompts, and injects those rules into the agent’s context. From there, the agent obeys the template’s instructions, effectively turning each template into a bespoke App Builder.

So in this case, I created a template (using Memex) that had a barebones MCP server implemented and deployed to Netlify. By including a .memex/rules.md with targeted prompts in the repo, the agent knows to treat any MCP-server request as an enhancement of that working scaffold. The result? Token usage drops by a factor of ten, success rates are higher, and users need far less prompting expertise to get up and running.

Next steps

Memex can build MCP servers, and it can also build RESTful MCP clients so it can interact with them. But Memex is not itself an MCP client. But stay tuned — we’ll be supporting it very shortly!

If you have any feedback on this post or Memex, I’d love to hear it! We’re eager to improve.

We've all been there. Locked in a debate – about product strategy, a technical approach, market direction, maybe even the existential risk of AI – where you and the other person stare at the exact same evidence and arrive at wildly different conclusions. It feels like you're speaking different languages, inhabiting different realities. More data gets thrown on the fire, arguments are rehashed, voices might get raised, but the gap remains stubbornly wide, often paralyzing action. This isn't always about flawed logic or missing information. It's frequently about something deeper, more foundational …

Our priors.

Understanding this dynamic is crucial, especially in the chaotic, high-stakes world of building technology companies. Recognizing when a conflict is "priors-driven" doesn't magically solve it, but it highlights *why* waiting for consensus can be fatal and why clear, decisive leadership is paramount.

Bayes & Beliefs: The Root of Disagreement

Think of Bayes' theorem not just as a mathematical formula, but as a formalization of how rational minds *should* update their beliefs. In essence:

Prior Belief: What you believe about something before seeing new evidence. (P(H))

Evidence: The new data or observation. (E)

Likelihood: How likely is this evidence if your hypothesis is true? (P(E|H))

Posterior Belief: Your updated belief after considering the evidence. (P(H|E))

The formula:

P(H|E) ∝ P(E|H) · P(H)

The crucial insight for disagreements is the P(H), the prior. If two people start with vastly different P(H), even if they agree perfectly on the likelihood (P(E|H) – how the evidence connects to the hypothesis), they will inevitably arrive at different posteriors (P(H|E)). They look at the same facts and update their beliefs, but because their starting points were miles apart, their destinations remain distant.

Consider the classic AI risk debate. Alice, deeply read in alignment theory, might have a high prior (say, 30%) that unaligned superintelligence poses an existential threat (H). Bob, focused on current capabilities, might have a very low prior (say, 1%). Now, new evidence (E) emerges: a breakthrough in model architecture. Both might agree on the likelihood – "Given a future existential threat (H), seeing this breakthrough (E) is quite likely (e.g., P(E|H) = 0.9)", and "Even without a threat (¬H), such breakthroughs are plausible (e.g., P(E|¬H) = 0.5)".

They plug the same evidence and same likelihoods into their Bayesian updates. Alice's belief might jump significantly (e.g., to 43.5%). Bob's belief increases but remains tiny (e.g., 1.8%). They both processed the same information rationally, yet their conclusions ("Alarming!" vs. "Interesting progress") remain poles apart. They aren't arguing about the breakthrough; they're arguing from different underlying models of the world, different priors.

Startup Battlegrounds: Where Priors Collide

This isn't just academic. It's the daily reality of startups, manifesting in critical decisions:

Hiring & Burn: Should we hire aggressively to capture perceived opportunity, ramping up burn? One leader's prior might be "Speed is life; capture the market now," while another's is "Conserve cash; default alive is paramount." The same market signals (e.g., competitor growth, macro trends) feed into starkly different conclusions based on these priors about risk tolerance and growth strategy.

Fundraising: Is now the right time to raise? Does the current traction data (E) justify the valuation (H)? An optimistic founder (high prior on future growth) sees strong signal; a more cautious board member (lower prior) sees noise. They look at the same metrics but disagree fundamentally on readiness.

Positioning: Should we latch onto an existing, understood category (H₁) or attempt to define a new one (H₂)? Evidence (E) like early customer feedback or analyst reports can be interpreted either way. A prior favoring clear comparisons leads to H₁; a prior favoring differentiation leads to H₂.

Product Strategy: At DataFleets (privacy tech, sales-led), our priors favored roadmap selling and enterprise features. Building Memex (PLG), we constantly fight priors. Is user churn (E) because of missing features (H_sales-led) or a flawed core loop (H_PLG)? Different priors lead to prioritizing entirely different work.

In all these cases, the disagreement isn't necessarily about the evidence itself, but its interpretation through the lens of pre-existing beliefs.

Action Over Argument: Why Leaders Must Decide

Recognizing these dynamics leads to a critical insight for startups: Consensus is often impossible or fatally slow precisely because of differing priors.

Priors are sticky. They are built from experience, intuition, and deeply held beliefs. Shifting someone's priors often requires overwhelming, unambiguous evidence. But startups operate in high uncertainty; overwhelming evidence is a luxury they rarely have before making a decision. You lack the time and resources to run every experiment needed to definitively update everyone's core beliefs.

Waiting for alignment when priors diverge leads to paralysis. The market moves, competitors act, opportunities vanish. This is why clear decision-making authority is non-negotiable.

1. Acknowledge the Priors: Surface the underlying beliefs. "Okay, it sounds like Alice believes X is the primary risk, and Bob believes Y is. Is that right?"

2. Seek Prior-Informing Data (Efficiently): Gather the most critical data points that might shift priors, but don't boil the ocean. Timebox the analysis. For an early stage company this needs to happen in the meeting …

3. The Decider Decides: The designated leader listens to all perspectives, weighs the arguments (understanding the priors influencing them if possible), considers the available (imperfect) evidence, and *makes the call*.

4. Commit and Execute: The team, even those whose priors differed, must commit to the chosen path. Velocity and learning from action are more valuable than finding the "perfect" consensus beforehand.

5. Iterate: If the decision proves wrong based on subsequent evidence, the team course-corrects. The cost of acting on a suboptimal decision is often far lower than the cost of inaction due to stalemated disagreement.

Understanding priors doesn't guarantee harmony. But it explains why smart, well-intentioned people can look at the same world and see different realities. It underscores the need for humility about our own beliefs and, crucially for any fast-moving organization, the need for leaders willing to make decisions under uncertainty and teams willing to execute with conviction, even before everyone's priors fully align. In the fog of innovation, decisive action, informed by (but not captive to) diverse priors, is the only way forward.

From December last year until April 29th, we were heads-down at Memex in a closed-beta. Our focus was singular: get the core product to a point where it helped users get to value. We kept things low-key, iterating based on feedback from our early users.

Then, on April 29th, we launched. Before launch, around 3,000 projects had been created during our ~5-month closed-beta. In the 72 hours *after* launch, that number surged past 10,000. The total project count more than tripled in just three days.

It's been exciting, validating, and … chaotic. The growth is strong, a signal that maybe this idea of "vibe coding" – enabling people to bring software ideas to life without actually writing code – has legs. My main question has been: “what are people building?”, which we’ll try to unpack some in this post.

I find startup journeys depicted online gloss over the less glamorous bits. In the spirit of leaving ego at the door and sharing the reality, so I’m also going to share the egg-in-our-face moments since launch.

What Are People Building?

Memex is designed as a general-purpose tool, so we’ve been very interested in what categories would have the highest demand. But Memex is also privacy-first. Unlike many of the app builders out there, we don’t ever see the user’s code— it always stays on their local machine or wherever they deploy it. This is core to our philosophy, but it presents a challenge: how do you understand what people are doing with your tool?

We used a combination of telemetry data and direct discussions with our users through Discord and Google Hangouts to get a sense of what use cases people are using Memex for. To make sense of this fuzzy data, I did the obvious: I used Memex itself to wrangle these disparate inputs and attempt to categorize the emerging use cases. The result is something like this visualization:

It's not perfect, but it paints a picture of emergent behavior. While I expected certain categories, other patterns have been a surprise.

Highlights from the 10,000+:

1. AI Apps: Given the current wave, AI applications are unsurprisingly a huge category. We’re seeing everything from RAG (Retrieval-Augmented Generation) Apps and AI Agents to Chat Apps and Image Generation tools. People are using Memex to prototype and build on top of the latest AI models, and this was expected.

2. Business Tools: I continue to be surprised by the breadth of tools needed for small businesses. Everyday I hear of use cases and think “yeah, that makes sense— but I would have never thought that was a need”. For example, a pastry chef used Memex to create an app for managing scheduling their team, managing inventory of ingredients and optimizing procurement. It makes sense: essentially an ERP tool. But a small bakery will get by without buying the off-the-shelf software for it. Yet when they can spend a weekend building it for themselves, it becomes a viable option for them.

3. Mobile Apps: We expected to see lots of people build mobile apps. But the segment I found surprising is that there are a significant amount of people who had apps developed by an outsourced developer, but now they can’t maintain the app, add features, fix bugs, etc. They’re using Memex to update and refine apps that are otherwise orphaned.

4. Model Context Protocol: Because we’re so deep in the world of agents, part of me thought even more people would be building MCP servers. But we’re thinking this segment might take off more in the coming months … We’ve been glad to see a non-trivial amount of activity here.

One meta point is that there’s quite a lot of variance in the number of projects per user. Of course, the majority of projects now are quite young, so there’s a limit to what we can know here. But from the closed-beta phase, we know that some users tend to work on the same project (or handful of projects) and evolve them over time. Whereas others are creating smaller projects daily—like internal tools and one-off data analyses.

The Egg on our Face

Okay, let's talk about the less shiny side. Scaling surfaces all the sharp edges you haven't sanded down yet.

Getting slammed on Hacker News and X

We were proud to be on the front page of Hacker News for a few hours on launch day.

The community was mostly very receptive … but we also got an earful about the things they didn’t like …

For one, we had an anti-competition clause in our Terms and Conditions. It was boilerplate from our lawyers that I should have caught. But I didn’t, and we heard LOUD AND CLEAR that it was unacceptable.

As you can see, we fixed that quickly. But nevertheless it remained the top comment.

Others went straight for the juggler. I got a bit sassy … still finding my feat when it comes to sparring over the internet — something I never imagined I would be doing!

And then, there was the name …

We heard about the name in 5 different comments (out of 86). None of them were positive! We also heard these same themes on Twitter.

Here are some themes we heard regarding the name:

1. Meme X? Some people hear "Meme X," assume it's related to internet memes, connect it to "Vibe Coding," and conclude we must be trolling them. I assure you, we are not.

2. The Indonesian Meaning: We discovered that "Memex" is slang for female genitalia in Indonesian. Facepalms were had. Apologies to my Indonesian friends; the coincidence is unfortunate and unintentional.

3. Cheapening something sacred: A lot of people respect Dr. Vannevar Bush and his contributions to science and engineering. He introduced the concept of the Memex in his essay As We May Think. The ethos of that essay is why we named our product after it. But many felt that (1) our product doesn’t live up to the name, (2) isn’t close enough to the original vision to be called Memex, or (3) is disrespectful to other projects already named Memex.

Honestly, I can understand/empathize with all of those points. You’re never going to get things perfect. But frankly—we don’t have any time to spend on the name right now … we will live and die by whether we make the product something love and continue to use over time. If we’re not doing that, none of it will matter anyways. And if we are doing that, we’ll either live up to the name or have the capacity to rebrand if we feel we should.

(for the record, I also got DMs from people who liked the name!)

The Inevitable Bugs

We knew we’d hit some bugs as we ramped capacity. That’s consumed most of the time since launch—squashing them to make sure all users are having good experiences. A couple of the notable ones:

Shell Issues: At launch we only supported Bash and Zsh, the most common shells. Turns out, a number of more technical users loves fish shell, and so we hustled to get support for it out ~36 hours after launch.

Out of sync admin panel: Our admin dashboard which (among other things) manages load balancing across Ant, GCP, and Bedrock had a bug where some of its data was out of sync with our database. So we were trying to fix other bugs with incorrect data.

Next Steps

Surpassing 10,000 projects is a small win to celebrate. More than that, it’s real usage for use cases from users that we will dig into to identify how we can help our users be more successful.

The concept of vibe coding is quite polarizing today. Some people are “all in”. Others are skeptical. My take is that there are many use cases for which it is a great option, and many use cases where it would be dangerous and/or unproductive to use. Our job with Memex is to zero in on those use cases where it is a great option, get it in front of users, and help them get to success.

Thanks

Finally: for all of you who has tried Memex, filed a bug report, shared what you're building, or just joined the vibe — thank you! We’re eager to improve and build alongside you.

I've spent years building companies, navigating the intricate dance of sales, fundraising, and building. My second venture, DataFleets, was born from grit, countless rejections (100 VCs said no!), and a relentless focus on closing deals, ultimately leading to a 9-figure acquisition. That journey was deeply rooted in a sales-led motion. We painted visions, showcased roadmaps, built relationships through compelling narratives and relentless hustle. And we built a ton of differentiated software too. Ultimately, it worked. But the truth is, even though we delivered software to our customers -- the product experience wasn't delightful. I wanted the challenge of creating something users truly love.

Now, I'm building Memex, the "Everything Builder for your Computer," inspired by Vannevar Bush's vision but aimed at augmenting human's ability to engineer systems, not just extend memory. With Memex, we're embracing a product-led growth (PLG) strategy.

The shift has been… humbling.

The Ego Check

One of the starkest transitions from sales-led to product-led entrepreneurship is the confrontation with your own ego.

In a sales-led world, especially early on, you are a significant part of the product. Your story, your conviction, the slick deck, the social proof – they can smooth over rough edges in the actual software. You're selling trust, a partnership, a roadmap. You can emphasize the groundbreaking tech (like the privacy-enhancing technologies we built at DataFleets) and the brilliant team behind it. Buyers are often signing up for a longer-term engagement, betting on your ability to deliver eventually. The more great names you have behind you, the more other great names want to join in.

Product-led? Forget it. Your pitch is the product. Right here, right now. Does it work? Does it solve the user's immediate pain? Does it deliver value today? Vision counts for maybe 1%. Social proof helps get a first look, but retention hinges purely on the utility derived.

If the product stumbles, if the UX is confusing, if it doesn't deliver on the core promise quickly, users churn. There's no smooth talk to save you. The product speaks for itself, brutally and honestly. It forces a level of humility, a stripping away of the founder ego, that sales-led motions can sometimes shield you from. You can't hide behind future promises; the present reality of the user experience is all that matters.

The Complicated Art of the Minimum Valuable Product

This leads directly to the second major shift: the ruthless focus on distilling value.

Sales-led allows, even encourages, showcasing a broad vision and an ambitious roadmap. You can sell the "platform," the grand architecture, the future integrations. Because the sales cycle is longer and the commitment deeper, the roadmap carries weight.

Product-led flips this entirely. Users are often evaluating multiple tools simultaneously with near-zero switching costs, especially in the AI-native tool space Memex occupies. They aren't signing a six-figure contract; they're trying your tool this afternoon.

This demands an almost fanatical obsession with the Minimum Viable Product (MVP) – or perhaps more accurately, the Minimum Valuable Product. What is the absolute smallest set of features that delivers a core piece of value, elegantly and immediately? How quickly can we ship that as fast as possible?

At Memex, we're helping users learn and build 10x faster. Developers, researchers, product managers, analysts, entrepreneurs – people who need to get stuff done and are only interested in a tool if it truly amplifies their productivity. They don't care about our five-year plan; they care if Memex can help them create that custom OCR workflow for their research project today, build that internal tool tomorrow, or finally get that side-project idea off the ground this weekend.

This forces incredibly stringent prioritization. You have to say "no" constantly, not just to bad ideas, but to good ideas that don't serve the immediate core value proposition. It's about depth and polish in a narrow scope, rather than breadth and ambition. It requires intense focus and a willingness to kill your darlings if they distract from the core user journey to value.

Great products are built on relationships: whether sales-led or product-led

Going into Memex, I carried a common misconception: "Sales-led is relationship-driven, but product-led is more about the numbers... funnel optimization, conversion rates, analytics."

I couldn't have been more wrong.

Yes, analytics are crucial. You live and die by activation rates, retention cohorts, and feature adoption metrics. But the foundation of a great product, especially an early-stage one navigating the messy path to product-market fit, is built on relationships. Just a different kind.

Instead of wining and dining prospects, you're deeply engaged with your user community. They aren't just data points in your funnel; they are your co-builders, your sharpest critics, your most valuable source of insight.

The key to a product-led strategy is a great product. And you can't do that without having great users that partner with you early on to help you fix the bugs, improve the UX, and prioritize the features that drive true value. Those partners ultimately become close knit relationships.

This quote, which I shared recently, captures my perspective. Building Memex has reinforced this daily. Our early users aren't passive consumers. They are active participants. They report bugs with precision, suggest UX improvements with passion, and champion the features that genuinely solve their problems. These interactions forge deep, collaborative relationships built on mutual respect and a shared goal: making the product better. The work is hard, but when our users recognize the effort, it means the world to us.

The Long Game

This transition isn't easy. It requires a different mindset, a different operating rhythm, and a constant check on the ego. But building Memex this way feels right. Minutes spent debugging issues for a user or deciphering their pain points to improve the product feel much more productive than the time spent perfecting a pitch deck to close a single account. It forces a clarity of purpose and a relentless focus on user value that is both challenging and deeply rewarding.

The journey from sales-led to product-led is less a change in destination and more a change in the vehicle and the terrain. The goal remains the same – building something impactful – but the path demands a different kind of resilience, humility, and a deep, abiding focus on the product as the ultimate expression of the vision. And perhaps surprisingly, it deepens, rather than diminishes, the human connection at the heart of building something new.

The concept of artificial intelligence has piqued our imaginations and challenged our sense of humanity since its conception over 70 years ago. For decades we have made predictions that intelligent machines will transform society. In some ways, they have. In others, they haven’t.

Instead of considering whether AI will be “transformative”, in this post I consider a specific question: when will AI outthink humans — in terms of volume of thought?

More specifically, I’m framing the concept of “outthinking” in two orthogonal dimensions: the volume of tokens and intelligence of tokens. And I only consider the former in this post.

In Part 1 of this post I introduce the concept of using thought-hours to reason about large scale token volumes. In Part 2, we’ll use that unit to reason about the volume of AI thought-hours.

Of course, this is a mental model with tons of assumptions. It’s bound to be wrong, but it might be useful. To do this analysis right would involve a significant time commitment … I’d love to see someone rip this post to shreds with much better analysis!

• Part 1: watt-hours → thought-hours

  • The “horsepower” of the cognitive revolution

  • Estimating tokens per thought-hour

  • Reasoning about utility-scale AI

  • Limits of the analogy to electricity

• Part 2: human vs AI thought-hours

  • Quantifying human thought in the global knowledge labor force

    • What has been the thought-hour capacity of the knowledge labor force over time?

  • Quantifying synthetic thought in the global AI labor force

    • What are synthetic thought-hours?

    • How fast are synthetic thought-hours?

    • How much do synthetic thought-hours cost?

    • What is the global GPU capacity for synthetic thought-hours today?

    • What is the CAGR of global GPU capacity for synthetic thought-hours?

  • Putting it all together

    • Comparative Analysis of Thought-Hours

    • Growth Trajectories

    • Projections for Human vs AI thought-hour capacity

• Implications

Part 1: watt-hours → thought-hours

In an interview with Patrick Collison, Jensen Huang juxtaposed the units of the industrial revolution ($/kWh) to the AI revolution ($/M tokens).

It’s thought provoking — $/M tokens is indeed useful for pricing AI. But couldn’t we improve on it?

“token” usage is useful as a pricing metric: its measurable, fairly predictable, scalable, and correlated with the provider’s costs. But it need not be the only unit we use for measuring LLM volumes.

The “horsepower” of the cognitive revolution

It’s not clear to most people how an LLM “token” correlates to value.

By analogy, in the early days of the steam engine there wasn’t a clear way for potential adopters to intuitively quantify its capabilities vs alternatives (e.g. horses). To quantify this for his new steam engine, James Watt developed the unit “horsepower”, which he and Matthew Boulton standardized at 33,000 foot-pounds in 1783.

By analogy to “horsepower”, AI can be measured in terms of “thought-hours”. Whereas horsepower quantifies physical work relative to horses, a thought-hour quantifies cognitive work relative to humans.

The core idea is that one “thought-hour” should be equivalent to the average number of tokens a person “thinks” in an hour, hence providing a mapping between LLM usage and human cognitive work. Of course, quantifying human cognitive work is non-trivial. Just like “horsepower”, a “thought-hour” is an imperfect mapping that trades complete precision to be intuitive. But when someone is using LLMs (especially in the context of agents), it’s clearer for them to see that their session has used three thought-hours of work instead of “30,000 tokens”. We’ll come back to the idea of “token quality” later.

The clear analogy between thought-hours and tokens is that of watt-hours to horsepower-hours. In hindsight, horsepower seems like a folksy approximation of manual power. But it was useful because it was intuitive and practical at the time.

Estimating tokens per thought-hour

To come up with an estimate for tokens per hour, let’s start with the assumption that humans read at an average rate of 200 words per minute, or roughly 250 tokens per minute. This would imply that one “thought-hour” is 12,000 tokens.

To support this, consider that audiobooks default to around 9,000 words per hour. Given a words-to-tokens ratio of approximately 3:4, this implies that audiobooks amount to 12,000 tokens per hour as well.

Humans are not 100% productive during their workday. Let’s make the conservative assumption that humans are 83.33% productive, so we can get a nice round estimate of 10,000 tokens per hour. This is quite arbitrary, but keep in mind that when James Watt standardized horsepower, there were millions of horses he could have measured, and he ended up using a round figure anyways.

So given these assumptions, 1 thought-hour (Th) equates to 10,000 tokens.

There’s a notable difference between how many tokens we can read/perceive (input) and how many we can speak/write/create (output) in an hour. And the distinction is meaningful for AI models. But its not necessary for the unit — we can distinguish output thought-hours from input thought-hours where appropriate.

Reasoning about utility-scale AI

As we see more adoption of AI models at near-utility scale, we’ll need some way to reason about the vast volumes of tokens consumed and produced, and thought-hours may be a way to juxtapose those volumes with the human cognitive labor force.

It would be absurd to quantify the net generation of electricity generators in the U.S. in 2023 as “15.05 quintillion joules”. We have watt-hours for that (3,600 joules) and physics prefixes to quantify the orders of magnitude. So U.S. electricity generation in 2023 is “4.18 terawatt-hours (TWh)”.

Like watt-hours and other standard units, the thought-hour allows us to use physics prefixes to reason about orders of magnitude:

Limits of the analogy to electricity

We can take the analogy a bit further, thought its not perfect. For example, one watt is 1 joule / 1 second. By the same relationship, one “thought” would be 2 7/9th tokens / 1 second. That seems … a bit odd because thoughts don’t intuitively map to a number of tokens.

Part 2: human vs AI thought-hours

Quantifying human thought in the global knowledge labor force

Assume knowledge workers work 40 hours a week, 2,000 hours a year, and 95% of their time is thinking. Each knowledge worker produces 1,900 thought-hours (Th) each year. This implies the global knowledge labor force produces 1.9 terathought-hours (TTh) each year.

🧮

The global knowledge labor force produces 1.9 terathought-hours (TTh) each year

Assume the average knowledge worker makes $25k per year. And we’ll assume there are 1 billion knowledge workers globally. Hence, the global knowledge labor force costs $25 trillion each year, or roughly 25% of gross world product (GWP). That implies the average human thought-hour (Th) costs $25T/1.9TTh, or approximately $13 / Th.

🧮

The average human thought-hour (Th) costs $25T/1.9TTh, or approximately $13 / Th.

What has been the thought-hour capacity of the knowledge labor force over time?

McKinsey estimated that there were 230 million knowledge workers in 2012. And other reports cite one billion knowledge workers globally in 2021, implying a compound annual growth rate (CAGR) of 17%. I’m suspicious of the 1 billion figure, as I can’t find an original source for it, and the growth rate of 17% from such a high base seems nothing short of astounding. This is what the growth rate would look like:

If the 17% figure is sustained until 2024 (and the 2012 and 2021 estimates are correct), then nearly half of the global workforce is a knowledge worker. This seems implausible to me. But for the purposes of this exercise, let’s use the 1 billion figure from 2021, carry it forward to 2024, and assume the size of the knowledge labor force remains static over time, as if it hit a ceiling in 2021. That means human thought-hours would peak about now, at just over 2 TTh.

Quantifying synthetic thought in the global AI labor force

What are synthetic thought-hours?

To understand when AI might outthink humans, we need to first grasp the concept of synthetic thought-hours, or Th(s). Synthetic thought-hours quantify the cognitive output produced by artificial intelligence systems. In essence, this metric allows us to compare the intellectual labor performed by machines to that of humans, using a standardized unit of measurement—tokens.

How fast are synthetic thought-hours?

GPT-4o outputs tokens at a median rate of 67 tokens per second, meaning it can process 67*60*60 = 241,200 tokens per hour. This implies that synthetic thought-hours are 24 times faster than human thought-hours.

How much do synthetic thought-hours cost?

For simplicity, let’s focus solely on output tokens. GPT-4 costs $15 per million tokens, which translates to $15 per 100Th, or $0.15 per synthetic Th. At approximately $13 per Th for humans, synthetic thought-hours are 86 times cheaper than human Th.

What is the global GPU capacity for synthetic thought-hours today?

This section of the analysis is very rough. There are other analyses of compute trends in machine learning systems whose methodologies could likely be extended to get a clear picture. To get a back-of-the-envelope analysis, I simply look at H100 capacity and tokens per H100, given that (1) successive generations of frontier models often require leading/bleeding-edge chips, (2) H100 data is easier to collect, and (3) the methodology may get us within the correct order of magnitude.

Number of H100s deployed for inference

As a starting point, let’s look at the number of H100s sold in 2023:

• Microsoft Azure: 150,000

• Meta: 150,000

• Google Cloud: 50,000

• Oracle Cloud: 50,000

• Amazon (AWS): 50,000

• CoreWeave: 50,000

• AI Startups: 40,000

• Applied Digital: 30,000

• Lambda: 30,000

• Tesla: 20,000

• Crusoe: 20,000

Total: 640,000 units

Considerations:

• Chips are used for more than just LLM inference, such as training LLMs, powering other types of AI/ML systems, or doing simulations.

• H100s tend to be preferred for training, while other chips (e.g., A100s) are used for inference.

• Training:Inference ratio may be about 1:1.

Meta has 600,000 H100 equivalents, with their 2023 orders representing approximately 25% of their full capacity.

Based on these data points, I’ll assume there are one million H100 or equivalents deployed for LLMs, with half used for inference (500k). This is, of course, a rough estimate — #back_of_the_envelope

As a gut check: we know that OpenAI produces approximately 1 billion tokens a day on inference. 1 billion tokens a day = 36 trillion a year = 100KTh/day, 36GTh/year. This implies that OpenAI represents 42% of inference capacity globally. This is plausible given their reported 39% market share. Moreover, the H100 data shows Microsoft with 150k units — or 30% of our 500k figure — which aligns with Microsoft’s 30% market share in the same research report. This lends some credibility to our estimate, but nevertheless it should be taken with a salt lick.

Token Throughput for AI Inference per H100

To estimate the global capacity for AI inference, we'll use LLama2 70b as our benchmark. This choice is due to its well documented performance on Nvidia H100 GPUs, and because it is a rough midpoint for throughput. Caveat that this figure overestimates throughput for frontier models.

LLama2 70b operates at a rate of 3269 tokens per second (TPS). Note that we’re not measuring TPS from an inference provider, but on the bare metal because our multiplier is number of GPUs.

Breaking this down:

• Tokens per hour: 3269 TPS * 3600 seconds = 196,140 tokens per hour.

• Thought-hours per hour: 196,140 tokens / 10,000 tokens per Th = 19.6 Th per hour.

• Thought-hours per year: 19.6 Th/hour * 8760 hours/year ~= ~170 kTh / yr

Given our estimate of 500,000 H100 units dedicated to inference:

🧮

Total synthetic thought-hours per year: 170 kTh/year * 500,000 = 85 GTh per year.

What is the CAGR of global GPU capacity for synthetic thought-hours?

This is an important figure given that chips are a rate-limiting factor for AI today. To get to a napkin sketch, we’ll assume the CAGR of the data center spend on GPUs to be equivalent to the CAGR of the volume of GPUs.

Markets and Markets puts the growth of the GPU market at 36%, so we’ll use that figure as our estimate for CAGR in GPU units.

Putting it all together

When contemplating the future where AI outthinks humans, we must integrate both human and synthetic cognitive capacities. By quantifying the global knowledge labor force's thought-hours and juxtaposing them with the growing synthetic thought-hours powered by AI, we can begin to forecast trend lines for each.

Comparative Analysis of Thought-Hours

1. Human Thought-Hours:

   • Global Production: The global knowledge labor force produces approximately 1.9 trillion thought-hours (TTh) annually.

   • Cost Efficiency: Each human thought-hour costs around $13, culminating in a total annual cost of $25 trillion.

2. Synthetic Thought-Hours:

   • Global Capacity: With an estimated 500,000 H100 units dedicated to inference, the global AI systems produce around 85 gigathought-hours (GTh) annually.

   • Cost Efficiency: Each synthetic thought-hour costs approximately $0.15, drastically undercutting human thought-hour costs by a factor of 86.

Growth Trajectories

Considering the current CAGR of 36% for global GPU capacity, the synthetic thought-hour production could expand significantly. Even if the growth rate of the human knowledge labor force remains static, the rapid advancements in AI suggest a different trajectory for AI.

Projections for Human vs AI thought-hour capacity

To estimate when AI might outthink humans, we must project forward:

• Current State: AI currently produces 85 GTh annually, while humans produce 1.9 TTh.

• Future Growth: If the CAGR of 36% continues, AI’s capacity will double approximately every two years.

If this growth rate were to remain constant, AI's synthetic thought-hours would surpass human thought-hours by volume in about 10 years.

This is likely a lower bound of the growth rate of synthetic thought-hours. Critically, it leaves out the observed 0.4 OOM improvements in algorithmic efficiency each year. If we factor these in, the synthetic thought-hour volume exceeds that of humans in less than half the time (4 years instead of 11.

What other factors might influence this trajectory? In short – many. Some top considerations that come to mind:

• Chips: When it comes to the volume of synthetic thought-hours in the labor force, the single biggest rate limiting factor (and biggest unknown) is chips. The biggest question on this front is the geopolitical situation around Taiwan and TSMC.

• Energy: Nearly every conversation about energy these days is about data center compute. I think energy is among the largest bottlenecks we face for training larger systems, but when it comes to inference, it seems the largest bottleneck will be chips. My main rationale for this is once we get frontier models, we typically find performance optimization strategies that allow those models (or derivatives thereof) to run on earlier generations of chips that are already deployed in data centers with sufficient energy supply.

• AI ROI: AI is extremely capital intensive. Success stories like Service Now suggest the the gold rush is warranted, but those wins will need to be sustained over time to keep the momentum in the industry and investor sentiment.

In case I haven’t already made it abundantly clear, this is a very rough napkin sketch. I would love to see someone make this analysis more detailed and robust. Let me know if you do!

Implications

If these even projections are directionally correct, what does that mean for society? If you also believe AI models are going to get “smarter” over this same time period, the impact can definitely be societal-scale. If the projections for the volume of thought-hours said otherwise — if they projected a tiny fraction of human thought-hours — societal-scale impact might be much less likely.

As someone who has worked in data and AI/ML for my entire career, I’m quite allergic to “AI hype”. But my conviction is that AI is like the internet in the 90s … full of hype, but nonetheless set to transform society in the coming years and decades.

When will AI outthink humans?

In 2023 I left my acquirer just two years into a three year contract – forfeiting millions.

Was it worth it?

First, a bit of context.

In 2021 my cofounder Nick Elledge and I sold DataFleets to LiveRamp for >$100mm. Within about a month of joining the acquirer, I realized the integration was going to be extremely difficult. Over the next two years, DataFleets relaunched within LiveRamp and found commercial success, but it was more painful than I had ever imagined. A portion of my compensation was paid out over a three year period, contingent on me staying with the company. But I left after two years – hence leaving a significant portion of it behind.

M&A integrations are hard. And of course, running a startup is also hard. But when running a startup you have complete control over (1) the people you hire, (2) the culture you build to glue those people into a team, and (3) the way you spend your time. When I was thrown into the world of M&A integration, I lost those three critical levers. I was unprepared for the challenge of integration, and though our integration fared better than most, it was taxing.

You may be thinking, "Boo hoo - you had an exit and the M&A integration was hard. Get over it."

I fully recognize the privilege I have and I'm grateful for the life changing outcome I experienced. Notwithstanding, walking away from a sizable portion of my compensation was a huge deal for me. It was compensation I felt I had earned through the risks I had taken, years of 80+ hour work weeks, and the value I created.

Ultimately, a combination of six factors motivated me to move on early.

👪 (1) Family

My wife and I were thrilled to welcome a baby boy to our family in 2022. Spending time with them is one of my greatest joys. But in corporate life, I felt my time with them was robbed. I had little control over my calendar at work, and despite being constantly busy we were moving a fraction of the pace I would find acceptable in a well functioning startup. I was sacrificing some of my most meaningful family moments on activities that were a poor use of time.

🧠 (2) Mental health

Though not diagnosed with it, I’m pretty sure I was depressed. I’m an inherently optimistic person. Even amidst 100 hour work weeks and near death experiences with DataFleets, I felt energized, driven, and optimistic. But my inherent optimism was waning. The vision I had for where our acquirer should go was different than where the company wanted to go, and watching the window of opportunity close for my vision to materialize made me frustrated, cynical, and irritable. No exaggeration – I felt like the worst version of myself I’ve ever been.

🚀 (3) Hunger for impact

About a year into our M&A integration I realized something: the thing I was most proud of in my career was not the company I had just sold. Instead, it was the work I had done at Digital Reasoning to get its healthcare vertical off the ground – which has since been spun out as Azra AI. That work helps save lives across the United States to this day, and though I aspired to multiply that level of impact with DataFleets, I had a greater commercial impact without the same level of societal impact. I had to try again.

⛏️ (4) I missed the grind

It seems counterintuitive– on the one hand, I wanted more time to spend with my family, but on the other hand I missed the “grind” of a startup. But for me, it’s not about the quantity of hours worked. It’s how those hours are spent and the flexibility of when those hours are worked that matter. Running a startup, I can aim to make a lasting impact on the world and bend consistent 60-80 hour work weeks around my family life ... e.g. making sure I’m there for bath + bed time before heading back to a long night of work.

🤝 (5) I missed setting the culture

If I were to summarize the type of culture I like to create, it’s one of deep thought, speed, peer-to-peer accountability, functional excellence, and ambition. Setting that culture has many levers: chief among them are hiring/firing, promotions, and intentional behaviors from leadership. There were cultural aspects of my acquirer I wanted to change, but changing such things from the middle of a company is a herculean task – and I failed.

🤖 (6) AI Opportunity

I first fell in love with AI while I was studying ancient greek in undergrad. I found myself spending more time learning computational linguistics to translate my homework than actually doing the work myself. Thereafter, I took a course on AI and felt for the first time I had found something I could spend my life working on. I read Russell and Norvig’s textbook cover-to-cover – I could hardly put it down. I subsequently spent the first half of my career researching, productizing, and selling deep learning solutions for analyzing unstructured data. I published on language models at ICML and productized them. The early days of DataFleets were all privacy-enhanced machine learning focused, but the market need was a privacy-enhanced SQL engine, so we pivoted to that instead. Then, when Stable Diffusion and ChatGPT were going viral in 2022, I felt like I was sitting on the sidelines as I watched AI take off.

❓Was it worth it ❓

Setting the foundation of a lifelong connection

Some dads speak of a near supernatural experience when their child is born – as if a bolt of lightning hits them and they immediately feel connected with their child. That was definitely not my experience. I felt a sense of duty to provide for my son, but I did not feel a sense of connection. He was like a little alien that pooped and cried. But now I feel deeply connected with my son – and I know he feels the same way towards me. That connection has taken a huge time investment to build, and I’m so proud and grateful that I was able to make that investment. What’s more, it’s allowed my wife and I to grow even closer after 8 years together. After I left, we traveled all across the US in our Airstream for two months straight – unplugged and spending time together as a family.

Finding fulfillment at work

It’s a challenge to have a toddler and start a company in a highly competitive market. Transitioning from a roadblock at work, to a meltdown at bath time, to a long night of more work is a grind. But having gone through the pain of a startup and the pain of an exit, I feel so lucky to be living through the former right now. I was speaking with my coach and advisor David Pann about how things are going. The best word I could find to describe it is “fulfilled”. It may sound cheesy, but since starting this next venture six months ago, I’ve reflected daily on the feeling of fulfillment I have and how grateful I am for it.

It’s not all gravy and roses. But the last few weeks in particular have been fulfilling and fun since we’ve transitioned our MVP to an alpha. Watching the uptick in companies using it over the past few weeks has been thrilling – and getting feedback on all the things users wished they could do feels like a mountain of (fulfilling) work …

Since launching our alpha, we've been pleased to see a number of companies start using it

The verdict

One year in, the decision to leave early and forfeit the money was one of the best I’ve made. The connection I’ve built with my son was well worth it in its own right. And the fulfillment I’ve found in jumping back into the unknown and aiming even higher with a new venture has been the icing on the cake.

If you’ve made it this far in the post – thanks for reading! And if you happen to be a data scientist (or any type of scientific professional), I'd love to chat! We're working on a product to help scientific professionals 10x their productivity.

Feel free to contact me directly or join our discord - we’d love your feedback!