I got into venture through a blackjack table in Las Vegas.

A friend I was playing with mentioned an opportunity recruiting for venture-backed startups in San Francisco. I didn’t even know that was a job. I called him that Monday, flew to San Francisco that Friday, and moved two weeks later.

The job was commission-only, and I was making about $3,000 a month. It wasn’t exactly a comfortable start.

What I didn’t appreciate then was what it would ultimately give me: access.

Before long, I was sitting across from the founding teams at Cloudera, Zendesk, SumoLogic, and AngelList, before most people knew who they were.

One opportunity led to another. My next job recruiting at AppDirect taught me how companies scale. My time at Stripe taught me how exceptional teams are built. M&A taught me when it makes more sense to buy a team than build one.

Looking back, recruiting was actually my first investing job. It taught me how to read the market through people. Which companies were magnets for talent. Which leaders people would follow. Which engineering teams solved the hardest problems. Which organizations became the training grounds for the next generation of founders.

Every firm says venture is a talent and network business, but very few are organized like they believe it.

Most firms hire investors first and bolt an operating team. Recruiters, engineers, designers, and GTM leaders become a service organization that arrives after the investment.

We built TheGP around where founders spend their time. Long before a term sheet, founders work alongside our recruiters, engineers, designers, and operators. Those folks aren’t a service organization, but key to how we invest.

Every venture firm writes checks. But we believe talent should be part of the investment too.

That doesn’t mean every great recruiter should become an investor. Nor should every engineer or operator.

But when someone has spent years recognizing exceptional people, helping founders solve hard problems, and earning their trust, they’ve already developed one of the hardest skills in venture. The rest of the craft can be taught.

Most people think venture is a capital business. It isn’t. Capital is the commodity and judgment is scarce. The real edge is recognizing exceptional people before the company is obvious, which happens long before the company is legible to capital. Often before there’s even a company.

If venture is fundamentally a talent business, why do we organize firms as though it isn’t? Because we assume the only path to becoming a great investor starts in venture.

It doesn’t.

As a recruiter, you develop an intuition for people. You learn the difference between curiosity and rehearsed answers. You notice who gets better every year. Who becomes the person everyone else starts calling.

Market maps, cap tables, and term sheets can all be learned. Judgment about people is much harder.

That’s why we’re hiring two recruiters to work with the investment team.

That sentence probably sounds unusual today, but we think it will eventually sound obvious.

These roles aren’t operating roles with a path to investing; they are investing roles for people uniquely skilled at recognizing exceptional talent before the rest of the market does. And the remit is simple: build the best network of builders in the Valley.

That happens in two ways.

First, help our portfolio companies build exceptional teams. Not because recruiting is a service we offer, but because helping founders win is part of how we invest.

Second, spend time with the people who are still a year or two away from starting something. Often there isn’t a deck yet. Sometimes there isn’t even a company. That’s exactly when we want to know them.

Recruiting shaped the way I think about investing. It taught me to look for slope instead of pedigree, curiosity instead of polish, and the people who somehow leave you more impressed every time you meet them.

If that sounds like the way you’ve spent your career, we’d love to talk. You can reach out at ak@thegp.com.

There’s a weird duality in how teams are adopting coding agents right now. Some have leaned all the way in and moved to truly hands-off patterns, where the agent does the work and a human (occasionally) checks the result. Others have embraced the same tools but keep their engineers’ hands hovering over the wheel, eyes on the road, ready to take it back the second something looks wrong.

The second group tends to look at the first with a mix of envy and disbelief. They can see the end state, they just have a hard time seeing the path from where they are today. It’s often for good reasons, and completely understandable. Invisible complexity buried in codebases no single person fully understands. Compliance requirements or reputation risk that turns a bad change into a nightmare.

It’s a big leap going from a world where engineers drive everything, to one where code ships autonomously. But nobody sane onboards a person that way either. A new hire doesn’t get a production database migration in their first week. You start them on something small that can be undone, and then you give them more slack as you learn what they’re good at.

Autonomy should follow a similar trajectory—it’s more of a dial than a switch.

With several of TheGP’s portfolio companies, we’ve been layering autonomy one piece at a time.

The first layer doesn’t ship anything at all. When a bug report or feature request comes in, we have an agent enrich it. It has access to prod data and Sentry traces, and it does the root cause analysis a person would otherwise do by hand. The tedious part has been handed off and the blast radius is zero. A human operator picks up the issue, already jump-started. I’m notoriously bad at filing tickets, and I’ve even found myself filing tickets just to trigger the enrichment.

The next layer we add is a triaging step. Once the agent is good at that analysis, it can judge whether its own recommended fix is tightly scoped enough to open a PR right away. You can turn this dial as gently as you like. One-line changes. Changes that don’t touch the API surface. Wherever your own edge feels comfortable.

After that, it’s tuning. As the agent proves itself on one type of work, you widen its scope. When it gets something wrong, you don’t rip the whole thing out. You add a guardrail and keep going. The dial can also turn backward.

On the back end of a change, there’s a second dial. Once code starts being written automatically and reviewed automatically, you start to realize not everything needs a person to approve it. Again, you start small. Auto-approve one-line copy changes. Then the low-risk fixes that arrive with tests proving they work. The two ends move on their own: you can be bold about what the agent is allowed to attempt and cautious about what merges unseen, or the other way round.

For the teams worried about compliance and reputation, this is the part that should settle them rather than scare them. The dials are essentially a boundary you can audit. You can specify exactly what the agent is allowed to touch, point to the check that clears each kind of change, and widen that surface deliberately instead of all at once. And in practice many of the checks and gates are deterministic and predictable.

That predictability is imperative. What buys the next notch on a dial is a cheaper, surer check. A cleverer agent isn’t really more trustworthy. A contract test, a trace, a fixture that turns “I think this worked” into “I can see this worked” is.

This is also where the invisible complexity from the start turns into a to-do list. Old systems are hard because you often can’t tell what they’ll do at runtime by reading the code. And you can’t safely hand off work you can’t cheaply check. So a lot of earning autonomy in a legacy system is unglamorous: making what it does at runtime visible, one test and trace at a time, until a check is cheap enough to trust. In reality it’s actually quite boring work. But the outcome is pretty cool.

What tends to surprise cautious teams is that none of it looked like the leap they were bracing for. There’s no day you flip to autonomous delivery. There’s a Tuesday when you notice a whole class of change has been shipping without you for weeks, and nothing caught fire.

The teams that are hands-off today aren’t braver than the ones with their hands hovering over the wheel. They started turning a dial, watched what their checks could carry, and turned it again. The end state the second group envies is often the same company a few notches further along, on the kind of work they took the time to make cheap to check.

So you don’t need permission to get there. You need a first layer that ships nothing, and the patience to turn the dial only as fast as your checks will hold.

Dan Pupius is CTO at The General Partnership, where he leads engineering work across the firm and with our portfolio companies.

To cap off season one of The General Podcast, we asked long-time friends and collaborators— and John Lilly—to sit down for a wide-ranging conversation about networks, company-building, investing, AI, and the relationships that shape a life’s work.

Reid is the co-founder of LinkedIn, a longtime partner at Greylock, and one of the most influential builders and investors in technology. He recently co-founded Manas AI with Pulitzer-Prize-winning author and oncologist Siddhartha Mukherjee, an AI company focused on drug development. John was CEO of Mozilla, where he helped scale Firefox into one of the most important public-interest technology projects of the modern web, and later became a partner at Greylock.

They start with the fortuitous story of how they first met—through a one-line introduction from a mutual friend that turned into breakfast at Hobee’s, and then into years of a never-ending conversation. At the time, Reid was coming out of PayPal and beginning to think about what would become LinkedIn. John was building Reactivity and later trying to understand what Mozilla could become.

Their early breakfasts quickly became a ritual. They’d each bring a list of ideas, and then leave with a longer one. They’d trade names in their respective networks through stacks of physical business cards (LinkedIn didn’t exist yet!). At the time, John was one of the first people Reid told about LinkedIn (and also one of the first to tell him he didn’t think it would work).

From there, they get into the deeper question of what makes Silicon Valley run. They agree that it’s not capital or even ambition, but the constant movement of people, trust, references and introductions across companies. Reid and John then get into how founders should build networks intentionally and how to think about the people whose “team” you want to be on over the course of your entire career.

They also talk about AI—whether it will make entrepreneurship more lonely, whether one-person trillion-dollar companies are realistic, and why Reid believes the future is less about all-AI companies and more about every person bringing a team of AI agents with them.

In this conversation, you’ll also learn:

1. Why great relationships often start with “who else should I talk to?”

2. How to build a network intentionally without making it feel transactional

3. Reid’s favorite reference-checking tactics

4. Why every CEO should spend time with extraordinary people outside their company

5. How to use board seats as a way to expand your judgment

6. How AI agents may reshape work without replacing human relationships

7. What Reid + John have each learned from founders like Bret Taylor and Dylan Field

8. How to think about building “the house you want to live in” as a founder

9. Why “AI as a friend” misses something essential about friendship

Enjoy!

- The General Podcast team

Listen: Spotify - Apple - YouTube

This one’s for the designers.

Brian Lovin is a designer at Notion, where he arrived after founding Campsite, a communication tool for distributed teams. Before that, he co-founded Spectrum, a community platform built for developer communities that was acquired by GitHub.

Joey Flynn co-founded Global Illumination, a studio that leveraged AI to build creative tools and games, which was acquired by OpenAI. Before OpenAI, he spent formative years at Facebook and Instagram, and worked on everything from iOS games to multiplayer worlds in the browser.

Before this conversation, Brian and Joey had never actually met, but they had surprisingly parallel careers. Both spent early years at Facebook, both started multiple companies, both found their way into some of the most design-forward product orgs, and both were nominated to come on the show by legendary design leader, Soleio.

Together, they chat about what it really means to be a “design founder” and whether that label even makes sense. They get into the strange pull of starting something new versus the relief of joining a company that already has distribution. Then they go deep on what it means to design right now, how AI changed the feedback loop, their prototyping stacks, and even the amount of control a designer can expect to have over the final product today.

In this conversation, you’ll learn:

1. What Brian and Joey miss (and don’t miss) about being founders

2. Why joining a company with distribution can feel creatively freeing

3. Why vibe coding can feel like a superpower and still make you feel less in flow

4. What it’s like to design for AI while the product category is still forming

5. The new designer stack

Enjoy!

- The General Podcast team

My first day in Taiwan working for AND 1 taught me a ton. It was 1998, and I flew from Philadelphia to Taipei, and then drove to Taichung. I met my boss for the first time and handed over a tube of blueprints I’d carried from the U.S. as if they were the Dead Sea Scrolls. He spread them out on the table, made a few edits and rolled them back into the tube. He handed it to me along with an address. With a member of our local development team, we drove to the address, which dropped us in front of a metal roll up door in an alley in the middle of the city. Inside, there was an older man dressed in coveralls and a white undershirt, cigarette dangling from his fingers, a Dremel tool on the bench next to him.

At the instruction of my colleague, I handed him the tube of blueprints. He pinned them to the wall above the bench, put the cigarette to his lips, grabbed a balsa wood blank of a midsole and fired up the Dremel. In a few minutes, a scale 3D model of the midsole/outsole design was complete. He repeated this process three times. Each time, pausing just long enough to light a new cigarette.

My mind was blown at the accuracy of his hand. He also understood the engineering of a shoe and would make adjustments to the two dimensional design that accounted for construction methods, manufacturing process at scale and durability of the overall end product. He would note these modifications after the 3D model was carved.

We took digital pictures, emailed them back to our designers in the U.S. and iterated on the design over a week or two. Once the design was finalized, our factory partners created sample molds and FedExed midsole/outsole combinations back to the product team in the U.S. for review. The design edits were done with masking tape and pencils on the 3D samples, shipped back to Asia for mold modifications and the process repeated until the sample was approved. From there, production molds were carved in aluminum and production samples were built in China. I would travel there, via Hong Kong, and review the production version before final costing and duty engineering were complete.

About two years after I started making these trips, I was between Guangzhou and Dongguan at a factory, speaking with a production manager when the CNC machine behind me sprang to life, carving metal. After I recovered from the jump scare, I asked what happened. They told me that NIKE’s design team back in Oregon had pressed “print.”

The evolution from craft to automation immediately hit home for me. And with that, I felt the fear of being on the wrong side. NIKE had compressed its design timelines by using CAD software, building deeper factory partnerships and investing in the ability to carve production-grade aluminum molds earlier in the iteration process. Technology allowed them to define a spec, deliver it to the factory and have a production ready product back in a matter of days.

As production became faster, more precise, and more abstracted, the value in sneakers moved away from the hands that made the product and toward the people who knew what should exist, who it was for, and how to sell it. The best sneaker brands did not ultimately win because they owned every step of production. They won because they understood the customer, defined the product, shaped the taste, and then built demand. The factories became more capable and more specialized, while the brands moved closer to the market.

Historically, when a craft evolves into mass production, sources of value creation shift.

For decades, code was treated as the core asset in technology. Companies that wrote the software also owned the production process, the customer relationship, and the product vision inside one organization. AI is beginning to pull those pieces apart. Code is easier to generate, cheaper to modify, and less defensible as a standalone advantage. The scarce work is shifting upstream and downstream. Knowing what to build, specifying it clearly, evaluating whether it works, and getting it into customers’ hands is becoming the new core asset class.

In sneakers, production became commodity. It moved to third-party factories overseas, and the brands that won poured their energy into product vision, taste, and distribution. I ultimately think software will be built just like this. The best brands will deeply understand exactly what to build (define the product) and how to get it into people’s hands (own the customer), and then outsource to “factories” to to run and maintain the software.

The sneaker playbook has three parts

The sneaker industry eventually settled into a clear division of labor.

The customer buys the shoes.

The brand — Nike, Adidas, New Balance — designs the product, invests in R&D, owns the customer relationship, and defines what gets built.

The factory — Pou Chen, Feng Tay, Chang Shin — prototypes, produces, and ships to meet the spec delivered by the brand and the SLA contracted for delivery dates and quality.

The role of the brand shifted from the craft of building a product to evaluating the output of a factory. AI will drive the software industry toward the same three-player structure.

Most people imagine an AI future where every end user talks directly to an AI and gets custom software. That’s the Nike By You version — it’ll exist but i don’t think it’s the majority of software. Most people don’t want to create software. They want to use it.

Software vendors realize their value was never in the code and become brands. They understand the user’s needs, curate the experience, make opinionated design choices, and own the customer relationship. The code is just the fulfillment mechanism — and it is the most expensive, slowest, most error-prone part of the entire operation. It should be outsourced.

In this new model, software vendors stop employing large engineering orgs and start pointing factories at customer problems. Their competitive advantage shifts from engineering capacity to customer insight, domain expertise, and product taste. They become like Nike — they design, they do R&D, they own the customer. The factory builds, tests, ships, monitors, maintains, and is accountable to the brand’s requirements, continuously.

The factory owns production end to end. Build cost and timeline. Scalability, reliability, maintenance. Performance spec and infrastructure efficiency. Security. The expertise required to run a high-functioning software factory — the harnesses, the testing frameworks, the deployment pipelines, the production monitoring — becomes its own deep specialization. Just as a handful of contract manufacturers produce most of the world’s sneakers, a small number of software factories will serve the vast majority of demand.

The customer just uses the product. But the product is better now, because the brand isn’t constrained by engineering capacity anymore. When building is cheap and fast, the brand can customize deeply instead of building for the average. It can ship more frequently and consistently. The customer doesn’t know or care that a factory built it. They just know the product works.

Why now

Three engineers at OpenAI just built a million-line production system in five months. Zero hand-written code. Cloudflare rewrote Next.js in a week for $1,100 in tokens. Coinbase found that engineers using agents heavily are 16x more productive than light users. StrongDM built digital twins of Okta, Slack, and Jira so agents could test at scale without touching production, operating under two rules: code must not be written by humans, and code must not be reviewed by humans.

These are the beginnings of software factories. They just don’t call themselves that yet. The emerging behavior from teams actually running these systems: if your codebase doesn’t work with agents, don’t make agents work with your codebase. Reduce it to specifications and let agents rebuild it from scratch. When a full rewrite costs $1,100 and produces a codebase purpose-built for agent maintenance, the calculus changes for everyone.

The entire installed base of software in the world was written by humans, for humans to maintain. That assumption has been invalidated. A new company architecture is needed.

The brands that move first — that swap their engineering orgs for factory relationships — will be able to build faster, customize more efficiently, and iterate continuously while their competitors are still managing sprint planning and customer tickets.

Who builds the factory? Who builds the brand?

The natural assumption is that OpenAI, Anthropic, or Google will be the factory. They have the models. They have the agents. They have the money.

But go back to the sneaker analogy. The model companies are the material suppliers — the companies that make the yarns and polymers. Essential inputs, but not the factory and definitely not the brand. The winning software factory will be model-agnostic, sourcing the best intelligence at the best price from whoever makes it, swapping models in and out as capabilities shift without customers ever knowing.

The factory of the future isn’t a coding agent, an IDE plugin, or a model API. It’s a full-stack service that accepts a spec from a brand and delivers running software continuously. That means model orchestration, code creation, hosting, implementation, testing, deployment, monitoring, maintenance, evolution. End to end.

Nobody has built this yet. But the pieces are falling into place fast. A factory isn’t a demo you vibe code in a weekend. It’s harnesses and production ownership — deep, compounding infrastructure that becomes exponentially harder to compete with once it’s running.

Nike started as Blue Ribbon Sports — a distributor of Tiger running shoes from Japan. Phil Knight’s advantage was understanding the American runner better than a Japanese factory could. Over time, the relationship evolved: from distributing product designed and built by a third party, to influencing design based on customer knowledge, to a full brand-factory relationship where Nike’s customer and market insight defined the product and the spec was delivered to the factory to build to order.

Software brands will follow the same arc and soon a founder with deep domain expertise and customer insight will be able to point a factory at a problem and ship product. If the factory builds the code and hosts it and maintains it, the brand just needs taste and the customer relationship.

The factory opportunity is equally large but fundamentally different. Factory founders are experts in every aspect of scaling software from code to physical infrastructure, cloud deployment, and optimization. They serve both existing brands making the transition and new brands emerging native to this model. Their competitive advantage compounds: every spec they fulfill, every system they maintain, every deployment they optimize makes the next one better and cheaper.

The sneaker industry proved that brands and factories are both massive, generational businesses, but they are fundamentally different companies. Nike owns demand. Pou Chen owns production at scale. Both won.

The same split is about to happen in software. Both sides of the value chain are up for grabs.

The founders who see this — who understand that the opportunity isn’t building better coding tools but building either the first true software factory or the brand layer that specs, sells, and owns the customer — are going to build some of the most important companies of the next decade.

The workflows we’re automating with AI today were never designed to be optimal. They were designed around the limits of humans doing the work. A software team has a product manager, a designer, and an engineer not because the work inherently requires three people, but because no single person could hold all of that context simultaneously. The Apollo program employed rooms full of human computers because no single mind could run the calculations. The division of labor in knowledge work is, to a significant degree, a workaround for cognitive constraints.

Every major tool shift makes old processes faster, but also tends to unlock new processes. Spreadsheets didn’t just help ledger clerks move quicker; they made whole new kinds of analysis possible. The internet didn’t simply speed up the mail; it changed how people found each other, worked together, and built things. When the worker’s capabilities change, the work itself changes too.

AI should follow the same pattern. But most of what’s being built today still asks AI to do the human’s job the way the human used to do it. Because we don’t fully trust it yet, we demand granular observability and benchmarks for performance. And the easiest benchmark is the old one: can it produce the same work a human produced, by following the same process a human followed?

That’s why so much AI lives as copilots inside existing interfaces. It makes the current process faster, but leaves the process itself intact. The bigger opportunity is to give agents objectives instead of instructions, and let them reshape software around how agents actually work. The real question isn’t “How many tokens can I burn in my work?” It’s “How must my work look different now that intelligence is abundant and judgment is the scarce resource? If we can answer that, the work itself will actually change.

Judgment sold separately

When working with AI, the scarcest resource is judgment. AI can ingest every data point, surface every pattern, run every scenario. What it can’t do is decide what matters in contexts that are ambiguous, high-stakes, and novel. Intelligence can be purchased as a utility — you can buy reasoning by the token from a half-dozen providers, and the price drops every quarter. Judgment can’t be purchased. It has to be built, captured, and compounded over time.

This is good news for application builders, because it clarifies where value actually lives. It’s not in the intelligence. It’s in how you apply that intelligence to scale the judgment of the person using it. Intelligence tells you what’s in the data. Judgment decides what to do about it — what to prioritize, what tradeoff to accept, what outcome to optimize for. Intelligence is general. Judgment is specific to a domain, a context, a set of goals defined by a human.

This reframes the role of software entirely. The job of the application isn’t to present data for a human to interpret (the old workflow). It’s to do the interpretation, make a recommendation, and then capture what the human does with that recommendation — accept it, override it, modify it — and tie that decision to the eventual outcome. A system of judgment is software that treats the human decision as the most valuable data point in the entire pipeline, and builds a learning loop around it. And judgment compounds. Every decision made inside that system becomes training data for the next recommendation.

What a system of judgment actually does

A system of judgment does four things, in a loop:

It ingests domain context and makes a recommendation. It captures the human’s actual decision — did they accept, modify, or reject the recommendation, and why. It observes the outcome. And it uses that complete cycle to make the next recommendation better.

The critical design insight is that the human decision is the most valuable signal in the entire pipeline. Not the input data. Not the model’s interpretation. The moment where an expert, with full context, chooses to override or refine the system’s suggestion — that’s where institutional knowledge gets created. And if you capture it, you can learn from it.

The shift isn’t “AI does the old job faster.” It’s “the work is redesigned so humans do the part that only humans can do — decide — and the system captures that decision and learns from it.” In this world the most important decision is which choices humans need to make and what can be handled by the AI.

Product has always been the game

None of this is new in principle. Machine learning has always worked this way. The difference between a good ML system and a bad one has never been the model, but the feedback loop. And the quality of a feedback loop has always been a product design problem, not a model architecture problem.

You need people to actually use the system. You need their usage to generate observable outcomes. You need those outcomes to feed back into the model. The tightness of that loop — how clean the signal is, how naturally it integrates into the workflow — is what determines whether the system compounds or stagnates.

This is why product matters more in the AI era, not less. The best systems won’t feel like “AI tools.” They’ll feel like better ways to work. And the judgment data will accumulate invisibly, because the product was designed so that doing your job is training the system.

Building a vertical judgment system

When I learn about an AI company, there’s one question that separates a system of judgment from a smarter dashboard: what happens after the user acts on the recommendation?

If the answer is “nothing” — if the recommendation is delivered and the system moves on — it’s a dashboard with a language interface. The intelligence is there, but it’s not learning. There’s no loop.

If the answer is “we capture the decision, track the outcome, and use both to improve” — now you have something that compounds. You have a system where usage makes the product better in ways that can’t be replicated by a competitor starting from zero.

These systems will be vertical, because judgment is domain-specific. What counts as a good outcome in clinical care is different from commercial underwriting is different from legal negotiation. The feedback loops are different, the outcome horizons are different, the regulatory constraints are different. You can’t build a general-purpose judgment system any more than you can build a general-purpose expert. This is why durable value lives in the application layer, not the model layer. Foundation models provide the reasoning. The application provides the domain-specific loop — recommend, capture the human decision, observe the outcome, improve. That loop, and the decision history it generates, is valuable.

For builders reorienting toward this model, the starting point is discovering the highest-stakes judgment call that a domain expert makes repeatedly. Design the entire product around capturing that decision in context and tying it to outcomes. Everything else — the data ingestion, the model, the interface — is in service of making that loop work.

The window

Judgment loops compound so the first system to reach flywheel velocity in a domain becomes very hard to displace. Not because of switching costs in the traditional sense, but because a competitor starting from zero has no decision history. They’re starting the learning loop from scratch while the incumbent’s is already spinning on customer specific context. Thousands of recommendation-decision-outcome cycles that only exist inside the system that captured them.

The founders who get this right won’t be the ones who built the best model or the most sophisticated agent. They’ll be the ones who understood the customer well enough to know which decisions matter most, designed a workflow that humans actually wanted to use, and quietly turned every judgment call into training data for what comes next.

Jensen Huang recently described the AI economy as a five-layer cake: energy, chips, infrastructure, models, applications. He used this to sell NVIDIA’s position in the stack. But if you stare at the economics of each layer long enough, a more interesting pattern emerges.

Software now has a marginal cost for each user. There are only two margin levers in the entire AI economy, and they apply at every layer.

Each layer will have to converge on the same business model: usage-based pricing with cost-plus margins. And the size of the “plus” — the margin you get to keep — is determined by exactly two things:

1. How differentiated your offering is vs. everyone else selling the same underlying commodity unit in their own brand wrapper.

2. How much you can drive down the cost of producing that commodity unit of value without your customer noticing any change in quality.

The Commodity Unit at Every Layer

Each layer of the stack has an atomic unit of value. Each has a cost driven by usage. Each is, at its core, a commodity.

• Energy: The commodity unit is an electron, priced per kilowatt-hour. Utility-scale solar PPAs run $0.04-0.06/kWh depending on region. Retail rates for data centers run $0.10-0.17+/kWh. The spread between those numbers is where margin lives.

• Chips: The commodity unit is a processor, priced per chip. An NVIDIA H100 costs ~$3,320 to manufacture and sells for $25,000-$40,000. That’s an 88% gross margin on the chip itself, 75% at the company level (the fattest in the stack right now).

• Infrastructure: The commodity unit is a GPU-hour, priced per hour of compute—but increasingly measured in “goodput,” or the amount of usable work delivered. H100 cloud rates have crashed from $8-12/hr at peak to $1.49-3.90/hr today — a 44-75% decline depending on provider. The perception of supply uncertainty and market certainty of insatiable demand makes this layer attractive in the near term, with plenty of opportunity for differentiation.

• Models: The commodity unit is a token, priced per million tokens. GPT-4-equivalent performance went from ~$36/million tokens at GPT-4’s launch in early 2023 to $0.40/million tokens today via GPT-4.1 mini. A ~1,000x cost decline in three years when you factor in blended rates and efficiency gains.

• Applications: The commodity unit is now intelligence measured in tokens. Pricing is still messy — 61% of SaaS companies now use hybrid models blending seats with usage — but it’s migrating toward consumption-based pricing because, for the first time in software history, the marginal cost of serving a user is non-trivial.

Traditional SaaS had near-zero marginal cost. Every new user was almost pure margin. AI applications burn tokens on every interaction. The economics are fundamentally different, and the pricing has to follow. Applications are not dead, they just have to be more compelling to buy than build and be priced on usage not subscription.

The Two-Axis Framework

Margin in this stack comes down to two variables: how much customers are willing to pay up (driven by differentiation), and how low you can push your costs down (driven by infrastructure innovation). So then the interesting question for each layer is: how much room is there to move on each axis?

Some layers have enormous room for product differentiation. Others are stuck selling something indistinguishable. Some layers have wide-open opportunities for cost innovation. Others are constrained by physics or regulation.

Map every layer on these two axes and you get a clear picture of where durable margin will live and where it won’t.

The Bookends Win

When I do this analysis, it seems the two layers with the most durable margin potential are the bookends of the stack—energy and applications. The bottom and the top. The dumbest commodity and the smartest one.

Energy

Energy is the only regulated layer in the stack. No one needs government permission to build a model or launch an app, but you need permits, interconnection agreements, and regulatory approval to generate and transmit electrons. That regulatory layer is a moat that doesn’t exist anywhere else in the stack (for now).

Changes in demand drive opportunity and the energy market is fully in flux. Human electricity demand is variable — it peaks on hot afternoons, dips at 3am, surges in winter and summer. The entire grid, and the entire business model of power generation, is built around this variability.

AI demand is different. Data centers run 24/7 at near-constant load. A power provider who can optimize generation for a flat, high-utilization, baseload demand has a structurally different cost curve than one built to absorb the peaks and valleys of human consumption. The provider who figures out how to serve AI’s specific demand profile cheaply and reliably earns a durable margin that isn’t easily competed away — because it’s protected by atoms, regulation, and multi-year capital cycles.

Applications

At the other end of the stack, applications have the most room for differentiation because they’re the hardest to compare. An electron is an electron. Chips have specific performance characteristics that are objectively measurable and a model token is roughly a token. But “how well does this tool fit my workflow” is a judgment call that varies by customer, use case, and taste.

Applications build behavioral lock-in through workflow and data moats, and in some cases network effects. They are the largest and most malleable value creation layer for the end customer. And the gap between “wrapping an API” and “building a genuinely valuable AI-native workflow” is where the margin opportunity lives.

Today, application margins are “terrible” — 20-60% gross margins vs. 70-90% for traditional SaaS. But the current margin compression is driven by temporary conditions:

1. Binary model dependence

Most AI applications have been hostage to a single frontier model provider for any meaningful intelligence. But as all models get smarter and the open-source and local architecture landscape expands, model choice widens. An application built exclusively on the latest frontier model from OpenAI will lose to one that delivers the same customer value using open-source, small models — because the cost structure is fundamentally different.

2. Lack of sophistication

Most AI applications so far have been “model wrappers” — thin UIs over an API call. Model wrappers don’t deserve thick margins and won’t earn them. But as founders learn how to build high-value, AI-native applications with real workflow intelligence, the value gap between wrapper and product will widen.

3. Legacy pricing models

AI-native applications have inherited per-seat and per-month pricing from traditional SaaS. But that pricing model doesn’t work when input costs per use are meaningful for the first time in the history of the software application industry. Usage-based pricing is inevitable not because it’s trendy, but because the cost structure of this new, intelligent, proactive software world demands it.

The Middle Layers Get Squeezed

If the bookends have durable margin, the middle layers—chips, infrastructure, models—face a harder road ahead.

Chips

NVIDIA’s 75-88% gross margins are extraordinary. But they’re not structural to the chip layer. They were earned through a specific set of innovations: supply chain lock-up, CUDA’s software ecosystem, and a capability lead in memory, efficiency, and latency.

Capital intensity is not a moat in this market. Every serious competitor — AMD, Google, Amazon, Microsoft — has the money to invest. What’s scarce is innovation.

The chip layer offers a rich set of innovation opportunities — energy efficiency, heat management, time-to-first-token, memory architecture — that can earn thick margins for whoever leads. But the layer itself doesn’t protect you. The innovation does. And innovation advantages are temporary unless you can keep compounding them. NVIDIA has done this in spades and there’s a trillion and 1 reasons to believe this continues for awhile.

Infrastructure

Cloud GPU infrastructure is in a brutal price war. Rates have dropped 44-75% in a year. The service is increasingly commodity. The differentiation vectors—scale, reliability, security—are real but narrow.

Right now, we live in a world of “more inference, more better.” Demand vastly exceeds supply, so infrastructure providers can charge premium prices. But supply will catch up. And when it does, infrastructure follows the same arc as electricity markets and oil markets: build out massive capacity, experience wild price volatility, then develop spot markets, futures, capacity auctions, and financial instruments to manage it all.

The financialization of compute is coming. When it arrives, the only advantages in this layer will be economies of scale and cost innovation. The winners will look more like airlines than tech companies—capital-intensive, operationally complex, competing on route efficiency and load factor while customers choose almost entirely on price and availability.

Models

The model layer can earn thick margins through breakthrough innovation — a new architecture, a new capability, a new modality. But it can’t keep them. The pattern is already clear: a breakthrough creates a temporary window of enormous pricing power, then gets replicated, open sourced, or leapfrogged within 12-18 months.

There’s one exception. If someone figures out true continuous learning — where inference informs training, where every API call makes the model smarter — that would create genuine network effects at the model layer. It would turn usage into a compounding advantage rather than just a revenue event. But that doesn’t exist yet.

Until it does, the model layer is a treadmill. You have to keep innovating just to maintain your margin. And it’s telling that the model companies themselves — OpenAI, Anthropic, Google — are all racing to build applications. They’re fleeing upward in the stack to find durable margin because they know the model layer alone won’t sustain it.

Note: I can see a world where the middle three layers—chips, infrastructure, models—start collapsing into each other. Google is already there with TPU plus GCP plus Gemini, and NVIDIA is pushing in that direction with CUDA and its full-stack ambitions. OpenAI and Anthropic could limit access to their most powerful models to applications hosted and managed on their proprietary infrastructure.

The Specialists Win

If every layer converges on usage-based pricing with cost-plus margins, and those margins thin as commoditization accelerates, then the “plus” that makes a good product a great business has to be earned. Continuously. This creates a market dynamic where the specialists will win.

At every layer, the bar for differentiation is rising and the vectors of competitive advantage are known. You have to be better at discovering cost advantages that scale. You have to be better at meeting customer needs in an N-of-1 way. You have to be better at navigating regulation, building workflow lock-in and compounding data advantages.

As margins get thinner and harder to defend, the winners will be the best operators with the deepest domain expertise and the strongest bias to action. Because as every layer gets cheaper, faster and more available by the quarter, what justifies your margin—your “plus”—is the judgment you layer on top.

Incredible founders with a clear north star and burning urgency will have an advantage precisely when it’s harder to build a sustainable business. Because in a commodity world, the hardest thing to commoditize is the human who knows exactly what to build, for whom, and why it matters.

Listen: Spotify - Apple - YouTube

In this episode of The General Podcast, Erica Galos Alioto (Chief People Officer at Retool, formerly at Grammarly) and Anna Binder (former Chief People Officer at Asana) sit down for a candid conversation about what it actually felt like to lead through the last six years of work, from the chaos of the pandemic to the whiplash of DEI to the existential questions raised by AI.

They start with the “supper club.” It was a small, trusted group of HR leaders who became each other’s professional lifelines during COVID, and use that foundation as a lens to unpack how the role of HR fundamentally changed since then.

From there, they get into the uncomfortable parts: the performative rise (and retreat) of DEI, the growing fear and ambiguity leaders are navigating today, and the tension between AI as a productivity unlock vs. a job disruptor.

It’s a conversation about what it means to be a people leader when the rules keep changing.

In this conversation, you’ll learn:

1. Why the best Chief People Officers are business leaders first, HR leaders second

2. Why the best AI adoption strategies come from the edges of an organization

3. Why hackathons and internal tooling beat top-down AI mandates

4. How macro fear and politics are shaping CEO behavior more than most admit

5. How the best DEI programs got embedded into business operations

6. The shift from knowledge work to question-asking as a core skill

7. How “open-sourcing” internal comms can be a survival tactic for leaders

8. How founders can best partner with a great Chief People Officer

Where to find Erica:

• https://www.linkedin.com/in/erica-galos-alioto-9140832

• https://retool.com/

Where to find Anna:

• https://www.linkedin.com/in/annabinder

Where to find The General Partnership:

• Website: thegp.com

• LinkedIn: The General Partnership

• X (Twitter): @thegp

Enjoy!

Subscribe now

Kudos to Anthropic. Last month, the company released new security controls as part of Claude Opus 4.6, a powerful model that can now quickly find and analyze previously unknown security vulnerabilities. The move was significant enough to rattle the markets—cybersecurity stocks dropped last week with the rising fear that AI services like Claude, Google’s Big Sleep and OpenAI’s Aardvark will displace traditional cybersecurity software companies.

So as cybersecurity professionals, is that it for us? The robots can do our jobs better than we can and we should just pack it up?

To cut right to it—no. This won’t end cybersecurity jobs. But it will end human-speed security.

As we’re already seeing, the defensive use case for AI security controls is clear. Defenders can use these tools to build more secure software and proactively surface vulnerabilities. But attackers can also use these tools to find new flaws and exploit them before they are patched. After all, the attackers only have to be right once. Defenders have to find and address every single flaw.

Case in point, we saw this dynamic play out in late 2025, when China used Anthropic’s Claude LLMs to orchestrate a cyber attack across hundreds of targets (leading to Anthropic, Google, Quantum Xchange and yours truly testifying to Homeland Security on the rising threats of AI and cybersecurity).

An important piece of that testimony was Anthropic’s dual commitment to equipping defenders to advanced tools while also working to detect and remove adversarial use of these models by malicious actors.

Which raises an important question: are these tools restructured to the “good guys”?

We don’t know exactly how these controls are implemented, or whether they’re tied to information about the trustworthiness of your account, geo location data or other. But I can tell you this. When Anthropic’s new security update came out, I marched right over to Claude and asked it to assess an open source library to “discover any new security vulnerabilities I should be aware of.” And guess what - it sure did! It located 10 previously unreported vulnerabilities including one critical issue and three high risk findings complete with full descriptions and attack paths in an open source library.

I tried again on two other libraries and received similarly robust security analysis. This is not a testament to my cyber abilities but rather a realization of what is possible with these powerful tools, if simply someone asks. We should also acknowledge that the tools aren’t perfect. Some of these vulnerabilities will end up being false positives, but that’s not the point. The issue is the full capability of frontier Anthropic models are available to a wide range of users, not just trusted defenders.

While it is admirable that Anthropic is intending to prevent adversarial use of these tools, we have to accept as defenders that this will not be foolproof. Even if the model catches the most egregious and blatant of attackers, we can expect concerted cybercriminals or individual hacktivists to be able to use these tools under the radar. Which brings us to another question.

What should enterprise defenders do now?

First, enterprises should recognize that these powerful tools are in the hands of their adversaries and shift quickly. They must accept the reality that these tools change the game and the landscape. It is easier, faster and more accessible to a wider range of adversaries to launch sophisticated attacks against enterprises and small businesses alike. Period. Just like I shared in my congressional testimony, AI is shrinking the time window for attackers. Human defenders operate in hours. And this was fine when all we faced was human attackers. But AI powered attackers can identify flaws, exploit them and extract data at frighteningly fast speeds.

The defense posture of an organization must upgrade from tool-assisted humans investigating and responding in hours, to fully autonomous defensive systems that assess, interdict and disrupt attacks in microseconds. Further, this is not just an incident detection and prevention challenge—the elephant in the room is the looming challenge of vulnerability prioritization and efficient change management. And while the threat of a newly discovered zero-day through AI analysis may make for a glitzy headline, the reality is that many corporations aren’t even patching the existing known flaws. If AI is this powerful — meaning it can assess and synthesize software targets at lightning speeds—the attacker will mop the floor with the modern day, porous enterprise.

In sum, it’s imperative that enterprise founders move to autonomous defense systems and recognize that vulnerability and patch management can no longer operate in days or weeks. It should move in minutes and hours. More specifically I recommend adopting two strategies immediately:

1. Automate high fidelity intrusion detection and response flows end to end. Too many intrusion detection workstreams still operate with humans in the loop. Begin adopting fully autonomous patterns now.

2. Similarly, identify portions of your corporate or production stack where automatic updates can be enabled. This is a purposeful shift in perspective from manual processes to automated ones, with the addition of monitoring and automatic rollback. The goal is to begin leaning into this automatic patching pattern in controlled areas of low risk and then expand that strategy as confidence in the approach grows.

The future is coming fast, and businesses that rapidly adjust will thrive. Those that don’t will slowly be relegated to the sideline under the threat of adversaries and the tax of cybersecurity breaches and data theft.

Michael Coates was previously the first Chief Information Security Officer at Twitter, head of security at Mozilla, and Chairman of the OWASP Foundation. He is the founding partner of Seven Hill Ventures and TheGP’s first Investor in Residence.

We hear from founders constantly that the most helpful investors have real domain knowledge. These investors take the time to understand the founder and their unique approach. They’re experienced and focused enough to actually make a difference. We built an entire firm to deliver on this principle—embedding seasoned recruiters, engineers, designers and GTM leaders alongside founders at the most critical inflection points.

Now we’re extending that same model of depth to specific industries through our Investor in Residence Program.

The Investor in Residence Program brings domain experts into our firm to lead investments in their space. When you’re building in cybersecurity, you don’t want a generalist VC who needs to call their CISO friend for every architecture question. You want someone who was actually a CISO. These domain experts are often already running smaller funds or active as angels with strong track records, but they’re constrained by scale.

At TheGP, Investors in Residence can continue running their own funds or angel investing while working alongside us day in and day out. They’re a key part of our investment team and compete to build partnerships with the best founders. They also get to engage founders through our services model, helping folks move faster with dedicated senior operators across recruiting, product, engineering and GTM. They are compensated with carry in TheGP funds and budget to support their independent firms as they scale.

Welcome Michael Coates, TheGP’s first Investor in Residence

Our first Investor in Residence is Michael Coates, former CISO at Twitter and founder of Seven Hill Ventures, an early-stage cybersecurity-focused firm.

Michael joins at a moment when security has never mattered more. AI is reshaping enterprise infrastructure, and with it, the entire security landscape, with new attack surfaces, new detection capabilities and new categories of vulnerability that didn’t exist three years ago. Michael has spent his career building security for high-growth companies, most recently testifying before Congress on AI, cybersecurity, and quantum encryption.

We’ve been co-investing with Michael for years. Any time we see a cybersecurity company, we call him, because he works with CISOs and early-stage founders in this space every day. He knows what works at scale, understands the enterprise buying process from the inside, and can make introductions that matter because he’s earned the credibility to do so.

What’s next

Security is our first focus, but not our only one. We’re exploring IIR partnerships in AI research, healthcare, energy, bio, crypto and robotics—anywhere deep domain expertise separates signal from noise and there’s opportunity for generational companies to emerge.

Our mission is to be the firm the most talented people turn to when they want to discover the best opportunities. We think the IIR program represents an incredible opportunity for some of the most talented investors in the world and we’re excited to build this program at The General Partnership.

Conventional wisdom has it that AI excels at greenfield work. It’s great at writing new code without the drag of legacy baggage. Brownfield development—when AI touches established systems—is where things get dangerous. That belief is understandable. And not entirely wrong.

A couple of months ago, I spoke with an engineering lead who’d nearly given up on AI tooling. Her team had experimented with Claude to help refactor an 8-year-old Django monolith. Nothing dramatic—but the agent produced clean, confident patches that quietly broke integrations with a couple of external services. After a few rollbacks, chasing subtle regressions, and unwinding overly optimistic changes, the team shelved the experiment and went back to a manual approach.

“I’m not anti-AI,” she told me. “But real systems carry a lot of invisible context.”

She’s not wrong, and you’ll find many similar stories on r/vibecoding.

Some people see this as evidence of limitations in the models. And while I do expect the next generation of models to perform significantly better, I suspect the real problem is that many legacy systems lack the structure agents need to operate safely.

Greenfield codebases start with clear boundaries, minimal hidden dependencies and no accumulated quirks. Legacy systems often have the opposite. Without guardrails, agents can only see the code in front of them—not the invisible contracts holding the system together.

This creates a bind. Agent autonomy requires structure, but legacy systems don’t have it. And adding structure to a messy codebase is exactly the kind of slow, careful work you want agents to help with.

The way out is to build structure incrementally. Start with heavy oversight and let agent autonomy increase as the system becomes more legible. After several production migrations—including a recent medical visualization tool that moved from vanilla JavaScript to React—a pattern is emerging for how to do this without destabilizing what already works.

Here are three principles that I’ve found useful:

Tests as System Boundaries

Before touching production code, linting, type-checking, and E2E tests serve as the system boundary that makes everything else possible. This is about creating feedback loops that allow the agent to verify its work.

Historically, I’ve tried to avoid writing integration tests whenever I can—they’re slow to write and annoying to maintain. But AI changes the maths and in a recent migration, I was able to write 120+ Playwright tests against a vanilla JavaScript application quickly. Claude inspected the HTML and JavaScript, identified important structural markers and actions, then used Playwright to determine what the side effects of clicking links and buttons should be. This essentially became a functional spec the agent could test against.

AI agents excel at local transformations but lack global context. Tests provide the negative feedback that prevents drift. Without them, an AI can confidently break authentication while fixing a linting issue.

The tests are a primary safety mechanism for the migration. They won’t catch every invariant or performance regression, but they dramatically reduce the risk of silent breakage while the system is in flux.

Documentation as Context

Tests tell the agent when something breaks. Documentation tells it why things are built the way they are.

Most legacy systems carry invisible contracts—assumptions about data flow, integration quirks, business rules encoded in code nobody remembers writing. Agents often can’t infer these. And when they make guesses, things go off the rails.

We’ve started maintaining agent-focused documentation alongside the codebase: architecture overviews, integration maps, the kind of context a new team member would need but rarely gets written down. The standard CLAUDE.md or AGENTS.md files help, but for brownfield work, you often need more—explanations of why the auth flow is weird, which external services are sensitive to timing, where the bodies are buried.

The documentation doesn’t have to be perfect upfront. We use a /learn command so that when the agent struggles with something, it analyzes the failure and proposes updates to the docs. The system gets smarter as we go. It becomes institutional memory that compounds.

Incrementalism as Risk Management

Complex systems resist wholesale change. Effective approaches break migrations into discrete, reversible phases. For this recent project, I moved through tooling introduction (build systems, linting, testing), then structural extraction (deduplication, modularization), then framework migration (component by component), and finally design system integration for visual consistency.

Each phase leaves the system in a working state. You might not ship every step to users—feature flags can hide visual inconsistencies while the migration progresses—but you maintain the ability to stop, assess, or roll back at any point. No phase depends on completing the next one to function.

Agents perform best with bounded problems and clear success criteria. “Migrate the upload modal to React” is tractable. “Modernize the application” is not.

There’s a related point worth making here: AI’s speed doesn’t replace refactoring discipline. Just because you’re moving significantly faster doesn’t mean you should abandon what works. Martin Fowler’s refactoring patterns and Kent Beck’s small steps—these remain essential.

This is run-of-the-mill, good refactoring hygiene and is what keeps agent-driven changes small enough that failures are understandable, reversible, and cheap. (Turns out the fundamentals remain annoyingly fundamental.)

Compromise as Strategy

Technical debt isn’t uniformly toxic. In brownfield contexts, the trick lies in distinguishing between compromises that enable progress and those that cause long-term pain.

// Exposing functions globally. Inelegant but functional
window.handleUpload = handleUpload;
// Wrapping legacy visualizations. Imperfect but stable
import LegacyChartRenderer from './legacy/charts';
// BLOCKER: Security issue flagged for fix before merge
// TODO: Replace with proper authentication
if (user === 'admin') { ... }

These were conscious tradeoffs that the agent actually identified during the planning phase for one of the migration steps. The hierarchy I instructed the agent to follow: “Security issues and data integrity are non-negotiable—fix them or flag them, no exceptions. Don’t break existing functionality while making changes. Ugly patterns and tech debt are fine temporarily, between steps.”

The challenge with AI assistance is that models default to “best practices” when you need “what actually works.” They’ll often suggest comprehensive refactors that balloon and become impossible to land. What you really need is surgical changes that unlock the next step. The skill is in directing AI toward pragmatic solutions rather than theoretical ideals.

Structure as Enabler

Tests become the living specification. Phases provide the substrate for safe experimentation. An explicit compromise hierarchy tells the agent what invisible context to preserve. Once these boundaries are in place, the same agent that might have wrecked your system becomes capable of evolving it safely.

The process may look heavy on paper, but it actually speeds things up. A React migration that might have taken a week by hand was completed in a day. There’s also something counterintuitive about speed here: the faster you can fix things, the bolder you can be about breaking them. You spend less time in the grey zone between working states, and recovery costs drop. The structure that seems like overhead becomes the thing that enables both speed and confidence.

One caveat: AI will help you no matter what, but it’s not magic. What I’m talking about here assumes your core architecture is still conceptually valid—the data model mostly fits the business, invariants exist even if they’re implicit, and ownership boundaries haven’t completely collapsed—even if the implementation is outdated and crufty. If your core data model no longer fits what the business needs, things are going to be hard no matter what, you are going to need to take a very careful and systematic approach.

Second caveat: structure enables AI assistance, but it doesn’t necessarily automate it. We’re starting to track “agent autonomy” across projects—the ratio of agent turns to human prompts. Some hit 95%; others sit at 60%. The gap comes down to how well you communicate intent and how much context the agent can access without you.

Legacy codebases carry tacit knowledge that agents can’t reach on their own. Miss the right moment to inject it and you get a 4000-line change full of subtle bugs. The work is more like managing a fast-moving team than running a script. The real skill is systems thinking—holding the whole in your head while the agent works on the parts.

Both caveats point in the same direction: AI can absolutely help with brownfield work. But it won’t rescue a broken architecture, and it won’t supervise itself. Set up the conditions, stay engaged, and it’s remarkably effective. Skip the setup, and you’ll probably end up like that Django team.

I built something recently that was surprisingly delightful.

It’s a simple GitHub integration. Open an issue, and Claude automatically triages it, deciding whether it needs clarification or contains enough detail to implement. The outcome is either a mini spec with open questions or a working pull request. My role in this loop isn’t writing code, but deciding what gets merged. Though I still open the issue—I’m still the one initiating.

What’s coming next is stranger: systems that don’t wait for the issue to be filed. They watch how users struggle, infer what’s missing, and make the fix. The human role shifts again, from initiation to governance.

When code stops being the bottleneck, a lot of what we built our organizations around stops making sense. And this shift won’t be incremental.

The Bottleneck Has Moved

For decades, engineering time was the constraint software teams planned around. We built entire methodologies around this scarcity. Backlogs were prioritization queues for limited developer time. Sprints were commitment devices to protect focus. Story points were a currency for negotiating what could fit into the constraint. The whole apparatus assumed that building was the hard part.

That assumption is evaporating.

The theory of constraints tells us that optimizing anything other than the bottleneck is a waste. When code generation becomes cheap—and it’s getting cheap fast—the bottleneck doesn’t disappear, but relocates. The constraint shifts from “what can we build” to “what should we build” and, more pressingly, “what should we release.”

Consider what happens when you can auto-generate a working POC from a feature idea mentioned in Slack. The PM role doesn’t disappear, but it transforms. It becomes almost editorial—deciding what makes contact with users, not what gets approved for development. Evaluation speed matters more than execution speed

This has implications for how teams are structured. There will be fewer pure coders and more editors. Value will shift toward people with product sense, taste, and architectural judgment. The mythical “10x coder” gives way to something like a “10x clarifier”—someone who can specify intent precisely enough for generation and evaluate output quickly enough to keep pace.

I suspect most organizations aren’t ready for this. In practice, most organizations handle judgment today through people, not systems: senior engineers, PMs, and leaders applying tacit standards case by case. The backlog, in its current form, becomes a judgment queue. And judgment doesn’t scale the same way execution does.

The Explore/Exploit Bifurcation

There’s a useful framework from organizational theory—the explore/exploit tradeoff—that becomes newly relevant here. In exploit mode, you’re optimizing a known system. In explore mode, you’re searching for new possibilities without clear signal about what’s valuable. Most product work sits somewhere on this spectrum.

These two modes will require fundamentally different operating models.

Exploit mode collapses into automated loops. When you’re optimizing against known metrics—conversion rates, engagement, error rates—the feedback signal is already defined. Agents can observe user behavior, generate hypotheses, implement fixes, and measure results. Humans set the frameworks and criteria; agents apply them continuously. Traditional PM work in this mode dissolves into the system itself.

Explore mode stays human-intensive, but augmented. Here, there’s no user signal to optimize against—you’re inventing the criteria. This looks more like research or venture incubation. Higher tolerance for ambiguity. More room for intuition and taste.

The military’s OODA loop offers a useful lens of comparison. In exploit mode, the “Orient” phase can be largely pre-set, encoded in frameworks and principles. The loop runs without humans. In explore mode, Orient is still the work—constantly reframing, building the worldview, deciding what matters. You can’t automate orientation when you don’t know what you’re orienting toward.

The messy implication is that most organizations will need to run both modes simultaneously, with different processes, different metrics, and possibly different people. That’s hard. And I think it explains why the transition will be rougher for some companies than others. This is a classic Innovator’s Dilemma pattern: organizations optimized for execution struggle when exploration becomes the constraint.

Building the AI-Native Organization

“Cloud native” wasn’t just about where your code runs. It changed the economics of software delivery, favoring microservices, CI/CD, and DevOps as a discipline. An organizational shape then evolved in response to those new economics—not all at once, but iteratively, as teams discovered what the new infrastructure made possible and what it demanded.

“AI native” will follow a similar pattern.

The shift isn’t “we use Copilot” or “we have agents in production.” It’s the transition from Software Delivery to Value Delivery—where every well-specified intent can get implemented, and human judgment relocates to where it actually matters. In exploit mode, that’s downstream: not “can we build this” but “what does releasable look like.” In explore mode, it’s upstream: “what’s worth trying before we have signal.”

Code becomes an implementation detail. The organization restructures around judgment at both ends. Here’s what else will change:

Product work. The real human output becomes the scoring criteria, the architectural principles, the articulation of “what good looks like.” These artifacts describe what value needs to be delivered; code is generated downstream from them. It’s analogous to investment theses or editorial style guides—they govern what gets through. The frameworks become the product, in a sense.

Process. Continuous governance replaces periodic planning. The stage-gate methodology gets repurposed: gates protect integration cost, user attention, and product coherence—not build cost. Automated checkpoints run continuously against codified criteria. The Software Delivery Lifecycle becomes one step in a broader Value Delivery Lifecycle that manages flow from intent to user impact.

People. Hiring shifts toward product sense, taste, and architectural judgment. Explore roles look more like researchers or venture investors,with a tolerance for high ambiguity and the ability to pattern match across domains. Exploit roles look more like editors or portfolio managers—people who can consistently apply defined criteria under time pressure.

The Context Window Problem

There’s a practical constraint that makes all of this concrete: the context window is effectively the new bottleneck on judgment.

It started with code. Which files? Which functions? What’s relevant to this task? As AI capabilities have grown, so has what fits in the window. But the context window will keep expanding, and it will start to include things that used to live only in someone’s head. Product principles. Architectural criteria. The judgment calls that a senior engineer makes instinctively.

In exploit mode, that context will be what governs the automated loops. In explore mode, articulating it clearly enough to include will be the work itself.

Either way, the implication is the same: what stays tacit stays outside the window. And what’s outside the window won’t scale.

This is probably somewhat obvious once you say it out loud, but I think it has real consequences for how teams operate today. The organizations that will thrive in an AI-native world are the ones building the muscle now—getting explicit about their product principles, their quality criteria, their architectural constraints. Not because agents need documentation (they’ll work with whatever you give them) but because you need to know what you actually believe in order to govern what gets built without your direct involvement.

The Problems Point the Way

This is all highly speculative territory. Did anyone in 2010 fully anticipate what “cloud native” would mean by 2025? The organizational implications emerged through experimentation, failure, and iteration.

And today, people are experiencing real problems. AI slop. Hidden bugs that pass cursory review. A creeping sense that something is being lost when you’re no longer close to the code. The idea of more autonomy—hands-free coding, agents shipping without human initiation—can feel somewhere between reckless and absurd given what teams are actually dealing with.

I don’t think that’s wrong, exactly. But I think it’s pointing at the wrong problem.

The slop and the hidden bugs aren’t evidence that we should pump the brakes on autonomy. They’re evidence that we’ve been scaling generation without scaling governance. We got better at producing code before we got better at evaluating it. The bottleneck moved and we didn’t move with it.

Which means the path to healthy autonomy runs directly through what we’ve been talking about here. You don’t get there by having humans manually review every line of code indefinitely. That doesn’t scale, and it’s not where humans add the most value anyway. You get there by building the judgment infrastructure: the explicit criteria, the architectural guardrails, the product principles clear enough that they can govern without you in the loop.

The variance in what teams can do right now is enormous. Some are already running autonomous loops. Others are drowning in slop. But what separates them is rarely the AI capability. It’s whether the team knows what good looks like, and whether that understanding of ‘good’ is shared and explicit, rather than living only in individual intuition.

We’re moving from Software Delivery to Value Delivery. Software becomes an implementation detail, and the organizations that thrive will be the ones structured around judgment, curation, and coherence.

The problems people are experiencing today aren’t a detour from that future. They’re the rough edge of the transition. And the only way through is to build the muscle that’s been missing all along.

Listen: Spotify - Apple - YouTube

News! Graphite was acquired by Cursor today. We caught up with Graphite CEO and co-founder Merrill Lutsky a few weeks ago at TheGP’s studio, where he sat down with Zach Lloyd, the CEO and founder of Warp.

Zach and Merrill go way back—they worked together on Zach’s previous company. In this conversation, they get candid about what it takes to build core infrastructure for modern engineering teams, and swap notes on facing the same challenges from different sides of development.

In this episode, you’ll hear what’s actually changing inside engineering orgs right now: why code review is becoming the real bottleneck as agents generate more code, why ‘vibe coding’ doesn’t work on production code, and why humans still have to stay accountable for agent-written code. Zach and Merrill also get into the business side of developer tools - why power users break flat pricing, why ‘cheap AI’ creates a winner’s curse, and what it really takes to market to famously skeptical developers (controversial billboards and a launch video on a horse).

Enjoy!

Throughout 2025, we hosted bi-weekly AI meetings to provide a forum for TheGP’s engineers, founders, and technical leaders in our community to debate the future of AI. While plenty of time was spent on recent releases and benchmark results, the more interesting moments came when the conversation turned speculative. The fact that some of these speculations now seem obvious reflects how fast things moved this year. Here’s a look at some of the most provocative ideas that emerged:

Winter

January to March Highlights

“The Telnet days of AI interfaces”: That’s how Figma’s Head of AI Products David Kossnick framed the moment in January; back to the command line, not quite knowing what will happen until we hit enter. Chat interfaces lower the floor for beginners, but engineers and designers in the meeting wanted higher-resolution interfaces to raise the ceiling for experts.

The code editor is dead: In February, Charlie Labs founder Riley Tomasek predicted a hasty end to editor-based coding. Soon, he noted, there would be “very little time spent actually editing characters, and a high number of things running in parallel asynchronously.” Releases from Charlie and others have since pulled that future closer, with many engineers already spending less time in traditional editors.

MCP’s uncertain ascent: In March, only a handful of companies like Cloudflare had launched first-party MCP servers. We discussed its takeoff potential and whether it would suffer a similar fate to earlier ecosystem plays from the frontier labs. TheGP’s Alec Flett called it correctly, arguing that being “MCP-first” would soon be equivalent to being “API-first.” MCP has since exploded, with over 10,000 public servers and 97 million SDK downloads.

Spring

April to June Highlights

Claude’s context victory: Southbridge founder Hrishi Olickel joined us to break down his decompilation of Claude Code, arguing that superior context management gives Claude Code an edge. It treats conversation history as mutable, and “the fact that you think you’re having a conversation with the model is almost an illusion.” His takeaway: “Model intelligence has been good enough for a while. It’s tooling that needs to get better.”

Slopsquatting: As vibe coding took off, a new attack vector emerged: AI assistants hallucinate predictable package names, and attackers register those phantoms with malware inside. Agentic tools that auto-install packages compound the risk. As one participant noted: “Once the agent is doing it for you, you’re like sure, go install it.” Engineers should mind the gap between “it works” and “it’s safe.”

Voice agents in healthcare: When Syllable rebuilt their voice platform with LLMs, they eliminated 99% of their codebase, from hundreds of lines of code down to a lightweight core. “The prompt is the guardrail,” their VP Product Ibrahim Cotran said in the meeting. “We’ve done millions of calls now, and we haven’t had a problem.” Industry-wide, the momentum is in solutions like Syllable’s: administrative, fast to deploy, and far from patient risk.

Summer

July to September Highlights

Coding agents eat the market: An agent that can write great software can do a lot more. Participants described using coding agents for tasks beyond coding: product planning, task management, marketing, internal documentation. The question might not be whether specialized agents will emerge for each domain. It’s whether coding agents will simply subsume them all.

Gold medals without the crutch: OpenAI and Google both claimed gold-medal performance for the 2025 International Math Olympiad—this time without translating problems to formal proof languages like Lean. If models can skip formal language scaffolding to solve IMO problems, how many other multi-step processes can be collapsed?

The RL economy’s half-life: The infrastructure fueling reinforcement learning (RL), from Mercor to RL environment startups, faces a durability question. Once an agent masters a skill, the training data’s value declines, along with the humans who generated it. One participant put it bluntly: “The value of the labor pool will depreciate. No question. Will it depreciate too fast so that they can’t get an acquisition beforehand?”

Fall

October to December Highlights

Don’t reinforce, iterate: RL dominated the conversation this year, but it remains difficult to execute. One participant asked, “Can we skip all that infrastructure buildout and PhDs and instead just ask it to make its instructions more aligned with our desires?” This approach doesn’t always work, but participants noted success with tools like Claude Skills, which self-modify instructions based on feedback.

Coding agent failure modes: Engineers in the meeting who embraced async coding agents are now facing a review bottleneck. Alongside review tools, they often rely on a growing intuition of where certain agents struggle. TheGP’s Dan Pupius noted he now spends the majority of review time on the small fraction of AI-generated code he knows is most likely to contain errors.

Revealed intelligence: Most AI assistant products first engage users with polite, professional interactions. Poke took the opposite approach. In onboarding, it might goad a user into granting it data access, then wield that data in price negotiation. Reactions ranged from beguiled to repulsed, but everyone agreed that Poke’s sardonic style did a much better job exposing its smarts than a more buttoned-up approach.

These bi-weekly conversations are always a highlight at TheGP. We want to thank all our guest attendees, including David Kossnick, Riley Tomasek, Hrishi Olickel, Ibrahim Cotran, Tyler Fonda, Mike Adams, Sami Torbey, John Smart, and Michael Magan for joining. If you’re a founder or builder working on AI and would like to join these debates in the new year, please reach out.

And thank you to our team at TheGP for always keeping these timely debates lively and thoughtful: Alec Flett, David Watson, Mikey Wakerly, Stas Baranov, Justin Rosenthal, Marcus Gosling, and Ted Mao.

Listen: Spotify - Apple - YouTube

The General Podcast is back! And what an appropriate week for this episode, as “storytelling” has become the skillset du jour among startups and tech companies alike, according to the Wall Street Journal. This episode brings together two founders who have totally reimagined storytelling formats throughout their careers: Bing Gordon and Stephen Piron.

Bing joined Electronic Arts in its earliest days as Chief Creative Officer and helped build it into the gaming powerhouse it is today. He was one of the first believers that interactive media could be a true art form, and over his career he shaped iconic games like The Sims, Madden, and Farmville. Few people have thought harder about what makes a story truly work.

Stephen is the founder of Pickford, a new kind of studio where the audience drives the plot in real time. His big idea is that if you scream at the TV, the TV “should scream back.” Before Pickford, Stephen built the world’s first deepfake (the Joe Rogan one) while working on his previous startup, Dessa, which was eventually acquired by Square.

Right off the bat, you’ll hear them dive into one of the most famous ad campaigns in tech history—EA’s “Can a Computer Make You Cry?” Bing shares the story behind that ad and Stephen admits he has it framed on his office wall.

From there, they get into the multiple reinventions of Hollywood, how you build character bibles and narrative arcs in the age of AI and why hits are always flukes until they’re not.

It’s a conversation about what it really takes to build an interactive platform that changes the way stories get made. You’ll learn:

1. The origin story of the iconic “Can a computer make you cry?” ad and why it mattered more than any product marketing

2. Why Electronic Arts once believed it would become “the new Hollywood” and what that taught Bing about storytelling

3. Why most AI storytelling efforts fail by trying to make old stories cheaper instead of inventing new formats

4. Why character bibles and narrative guardrails matter more than prompts

5. How Pickford is borrowing from centuries-old storytelling structures and updating them for real-time interaction

6. Why hits still matter more than platforms (and why every platform eventually needs one)

7. How AI might actually create more work for storytellers, not less

8. How Pickford worked with SAG to design a new, AI-era compensation model for voice actors

Referenced in this episode:

• The “Can a Computer Make You Cry?” ad campaign

• United Artists and Mary Pickford

• Adventures in the Screen Trade by William Goldman

• The Sims and SimCity

• EA Sports

• World of Warcraft

• Wattpad

• Steve Jobs and the “reality distortion field”

• The Startup of You by Reid Hoffman

• SAG (Screen Actors Guild)

Where to find Bing Gordon:

• X (Twitter): @bingfish

Where to find Stephen Piron:

• Pickford: pickford.ai

Where to find The General Partnership:

• Website: thegp.com

• LinkedIn: The General Partnership

• X (Twitter): @thegp

• Substack: The General Partnership

Something shifted in engineering hiring this year.

The surface story is simple: after two years of companies fighting AI use in interviews, some gave up and started allowing it. Canva, Shopify, parts of Meta. The takes write themselves—”AI is transforming interviews!” etc.

But the more interesting shift beyond the policy change is the philosophical split it revealed. Some teams still treat interviews as verification. Others are redesigning them as simulations of real work.

What Interviewers Are Actually Seeing

What I’m hearing from engineering managers who’ve run AI-enabled interview pilots: the gap between candidates widened, not narrowed.

The assumption was that AI would be an equalizer: Give everyone Copilot, and coding speed stops mattering. The opposite happened. Strong engineers used AI to move faster through the boring parts and spent more time on architecture and edge cases. Interviewers describe a specific pattern—when AI generates the shape of a solution, weaker candidates lose the thread of the reasoning. They can’t reconstruct the decisions the AI implicitly made.

Candidates who prompt AI for a complete solution, and then can’t answer “what does this line do?” That’s an instant no-hire in every AI-enabled format I’ve heard about. But candidates who use AI to scaffold boilerplate while making their own architectural decisions are demonstrating exactly what the job requires now.

The Divide Isn’t Big Tech vs. Startups

The popular framing is that Big Tech is fighting AI in the interview process while startups embrace it. There’s something to that—Google and Amazon are definitely making things harder by using more advanced LeetCode challenges and adding mechanisms to detect ‘AI cheating—but it misses the deeper split.

The real divide is between companies that see interviews as verification and companies that see interviews as simulation.

Verification mindset: “We need to confirm this person has skills X, Y, Z. AI makes that harder to verify, so we need better detection or harder problems.”

Simulation mindset: “We need to see how this person actually works. They’ll use AI on the job, so let’s see how they use it.”

I think the simulation camp has the stronger position, and it’s how I’ve run interviews for some time. It’s not that verification is impossible with AI—you can still test fundamentals with follow-up questions. It’s that verification was always the wrong frame. The best predictor of job performance is watching someone do the job, or something as close to it as possible given interview constraints.

The companies that figured this out first happened to be startups, probably because they had less institutional inertia. But I’d bet the approach spreads regardless of company size.

Changes in the Skill Stack

People keep asking what skills matter now. The skills that matter always mattered, but the weighting shifted.

Design and architecture went up. Not because they’re newly important (they always were), but because AI makes implementation cheaper. When generating code takes seconds, the bottleneck moves upstream to deciding what code to generate.

An engineer who can break down an ambiguous problem, identify the right abstractions, and make sound tradeoff decisions is worth more relative to someone who just types fast.

Code review went way up. Engineers are spending more time reading and evaluating code than writing it from scratch. The ability to look at plausible code and spot the subtle bug, the security hole, the scalability problem—that’s the skill that actually matters.

Communication went up. Partly because pair programming and collaborative formats are more common. But also because explaining your reasoning is the main way interviewers verify that you actually understand what you built.

Algorithm implementation speed went down. Not to zero—you still need fundamentals—but relative to 2021, the ability to bang out a red-black tree from memory matters less. AI does that part faster than you will. What matters is knowing when you need one and how it’ll behave at scale.

Here’s my hot take: LeetCode grinding is less valuable than it used to be. Still not zero—Big Tech still uses it, and you need enough algorithmic fluency to evaluate AI output—but the ROI on memorizing 200 problems dropped.

What Good Looks Like in an AI-Enabled Interview

In collecting examples of what differentiates strong candidates in these new formats, I’ve seen a few patterns emerge:

Strong candidates externalize their mental model early. Weak candidates wait for the AI to give them one. Given an ambiguous problem, strong candidates figure out what’s actually being asked. “Who’s the intended audience?” “What’s the latency budget?” AI can generate solutions for any interpretation, but it can’t always choose the right interpretation.

They reject bad AI suggestions. One interviewer talked about a candidate who prompted Cursor for a caching layer, looked at the output, said “this doesn’t handle invalidation correctly,” and rewrote it manually. That’s signal. Though in this case maybe they could have re-prompted with better instruction.

They narrate their process. Even in AI-enabled formats, thinking out loud matters. Interviewers want to see how you decompose problems, not just the final solution. Candidates who prompt in silence give no signal, even if the results work.

They know when not to use AI. For a quick string manipulation? Sure, let AI write it. For the core business logic that the whole system depends on? Maybe think through it yourself first. Judgment about when AI helps versus hurts is itself a skill.

The Take-Home Paradox

Take-homes changed more than any other format.

The obvious change is that most companies gave up banning AI, because they couldn’t enforce it. But the interesting change is what happened to the problems themselves.

Good take-homes now give you a broken codebase and ask you to fix it. Or a working codebase and ask you to extend it. Or a real dataset with messy edge cases. The common thread is that they all require understanding a system, not just generating one.

For example, some startups are sending candidates a full-stack chat app with intentional bugs—authentication edge cases, race conditions, that kind of thing. They don’t care if you use AI to help find them. They care if you can trace the logic, identify root causes, and fix them correctly.

The old-style “build something from scratch in 4 hours” take-home is dying, and probably should. It tested who had the most free time as much as who had the most skill.

What This Means If You’re Hiring

Make your AI policy explicit. I’ve seen enough stories about candidates agonizing over whether to use Copilot—or using it and feeling guilty—that ambiguity clearly hurts everyone. Just say what’s allowed.

More importantly: design problems that require judgment, not just output. Complex, ambiguous scenarios that resist single-prompt solutions. Debugging and extension tasks, not greenfield implementation. Trade-off discussions, not just “does it work.”

And train your interviewers on what to look for. The evaluation criteria genuinely changed. Someone who learned to interview candidates in 2019 (or before!) needs to update their mental models.

What This Means If You’re Interviewing

Learn to use AI tools fluidly—Cursor, Claude, ChatGPT, whatever—so that when you’re in an AI-enabled interview, you’re not fumbling with the interface.

But also, don’t neglect the fundamentals. The follow-up questions are where you prove you actually understand what happened. If you can’t explain the time complexity of your solution, or why you chose this data structure over that one, the AI-generated code won’t save you.

Prepare for both worlds. Some companies embrace AI. Some are hardening against it. You’ll encounter both, and the preparation is different. And remember, these different approaches aren’t new. Not long ago, managers argued about whether candidates should be allowed to Google during coding interviews. Today, that question feels almost quaint, like an early version of the same verification-versus-simulation split playing out today on a much larger scale with AI.

So practice narrating your thinking. We’re in an era where how you got there matters the most. That’s always been true in senior interviews. It’s becoming true everywhere.

The teams that adapt fastest won’t be the ones that simply embrace AI, but the ones that redesign their hiring to reflect how engineering actually works now.

Dan Pupius is a member of TheGP’s engineering team. Previously, he was the co-founder and CEO of Range, head of engineering at Medium, and a staff engineer at Google.

Over the past few weeks, I’ve been reflecting on the venture capital industry and how my work at TheGP is fundamentally different than what’s happening inside larger multi-stage platform firms. We’re both called venture capitalists, but what we do and how we do it are so different, I think one of us (or perhaps both of us) needs a new name.

At large platform firms, market exposure is the goal and survival depends on achieving the required pace of annual deployment to support the fund’s scale. The metric that matters is dollars invested or deal count, which is a function of the number of founder meetings and the firm’s ability to deploy capital into the companies that fit the current thesis.

At TheGP, our approach is concentrated. Our returns and “sweat equity” model depend on finding rare founders with a distinct worldview, spending time understanding what shaped that worldview, and then helping them build. Each year, we form only a handful of deep partnerships—helping founders hire, ship, and find their first customers so they can do the best work of their careers. When that happens, a generational company can emerge.

A month ago, this was disputed as “contrarian vs consensus” investing. Historically, this conversation showed up in debates between stage-focused and multi-stage funds competing for founder attention, and again between industry specialists funds and platform teams as they expanded into new investment areas like crypto, bio, and defense.

A long-time friend and sophisticated LP originally shaped my thinking around this, which informed our approach to investing at TheGP. In 2021, as Dan and I were considering strategy for our new firm, this LP told me something that stuck: “No matter what size fund or the scale of the portfolio you create, the reality of a venture fund is the returns will be concentrated in one to three winners. As an LP, my job is to be diversified no matter how concentrated you are—so if a manager chooses to concentrate their portfolio, even investing the entire fund in a single company, it’s the manager’s risk, not mine. The more you think you’re right, the more you should be willing to concentrate, but know that if you’re wrong when you concentrate, subsequent funds will be hard to raise.”

In classic investing terms, “the more you think you’re right” is alpha—it’s the ability of a manager to outperform the market. If you believe your skill is picking assets within a market, you build your strategy to maximize alpha. You position yourself to earn exposure to desired assets within the market and optimize for deeper partnerships with smaller portfolios and scale capital to vertically fund this narrow subset of the market. Success is high multiples on invested capital.

If you believe your skill is not in being right, but in earning access to a desirable asset class or market segment as a whole, you build your strategy to lock in beta. Beta strategies seek broad access to investments that create coverage in the desired market. Beta strategies require diversification with larger portfolios and scale capital to lock in breadth of market coverage. Success is performance in line with the market benchmark.

There are three groups impacted by a firm’s alpha vs. beta strategy choice:

1. Founders

2. GPs

3. LPs

Success starts with knowing the game being played. For founders, investors and LPs, there are likely wins to be found in Alpha VC partnerships and Beta VC partnerships. The key will be knowing which one you’re dealing with and being sure the investment strategy and resulting tactical operating style fits your needs.

Alpha VC vs. Beta VC for founders

As a founder, you get to choose the investor you work with, and understanding their strategy is critical because it will shape the kind of partnership you’ll build with them.

Alpha investors will invest in beliefs, contrarians, and the misunderstood as the path to outlier returns. These investors believe that nothing can become something and something can become a 10,000x return that defines their career. Building small portfolios, Alpha VCs can be frustratingly curious, pushing deeper into details and demanding the time to fully understand the business. Strong points of view on approach and opportunity can lead to uncomfortable conversations around investment decisions, but also stronger alignment after a partnership is formed. Each investment is important to an Alpha VC and active engagement in the company’s success is a priority. Investors will market this as “deeply supportive,” but this type of partnership can be intense, even to the point of conflict with the founding team over time.

Beta investors follow a coverage model and navigate with market maps. They are seeking broad access to consensus opportunities, generating advantage with large funds and huge teams. Investors are deployed to efficiently identify opportunities that fit the firm’s narrative and can be strengthened through financing strategies where Beta VC has a distinct advantage. Founders get rapid decisions on large amounts of capital with limited sensitivity to price. Beta VC partners are navigating deals at high velocity and unlikely to be deeply engaged after an investment is made. “Partnership” looks like either handing support requests to a platform team or passively waiting for results as the founder builds. This limits their impact on your business, negative or positive.

However, the view of capital access as a competitive advantage will shape your company and can create an uncomfortable dependency on your investors as your organization scales ahead of your business traction. As a result, the DNA of your company wraps around capital as the primary solution to challenges.

Alpha VC vs Beta VC for GPs

GPs live within the systems that their firms create, and their work looks very different depending on whether success comes from generating alpha or accessing beta.

Alpha VC is great for idiosyncratic folks who are independent and refuse to be managed. These investors are self-motivated and not concerned with appearing wrong in the short term while they figure it out. Alpha VCs define their own focus, own their time and chase areas of interest driven by obsessive curiosity. To be clear, pursuing passion can lead to short careers of disastrous capital allocation decisions. Success is found in a few massive wins where an independent, contrarian view of the world becomes undeniably consensus fast enough to matter. Characterized by small, top heavy teams, Alpha VC is often impossible to break into, even for extremely talented people, and those interested in Alpha VC frequently start independent funds in response to this lack of opportunity.

Beta VC organizations are shaped like asset managers. These organizations are multi-layered and often siloed with matrices of decision making and control. The most senior people are focused on firm building and often required to stop spending a lot of time with founders or junior investors. The world is broken into sectors and performance of each group is built on categories, themes and theses believed to represent veins of opportunity by the managing director. The role of an investor in Beta VC is to execute against the chosen areas of interest and surface companies that represent exposure to chosen themes. Success for a partner lies in volume of operational metrics like social media followers gained, blog post views, founder meetings taken and rolls up to capital deployed. There is a ladder to climb and a clear path to success with areas of contribution, goals and performance reviews for each.

In the best cases, the management structure in Beta VC can remove a lot of the politics around attribution by creating a clear narrative truth for contributions from less senior team members. This structure can create a faster path to recognized impact on firm-level metrics and opens the door to managing substantial capital earlier in one’s career, without waiting to generate the returns typically required to an earn an investment mandate at scale in Alpha VC firms.

Alpha VC vs Beta VC for LPs

As VC matures, managers are no longer competing for LP investment with other venture capital firms, but with every other available investment an LP can make to achieve their portfolio goal. The role of VC within an LP’s overall strategy—to create Alpha vs. Beta—will define the groups worth talking to, the details of manager selection and the fees worth paying to have exposure to specific investments.

Alpha VC provides concentrated exposure to investments within a narrow fund strategy. An LP has to assemble a group of Alpha VC managers to gain diversified exposure to the broader market and these choices can only be made if there is consistency in strategy, intensity in execution and transparency around operational performance. Investing in Alpha VC requires an LP that believes the job of diversification sits at the LP level of the capital stack, and relationships between LP and managers should answer the question: “Are you successfully delivering the fund product that I bought?”

Narrow strategies tend to be harder to scale, so as an endowment grows, adding managers to meet the desired VC allocation can be difficult. Manager selection is also more nuanced in Alpha VC and portfolio turnover (swapping a strategy that did not perform or that you believe will not perform in the future in exchange for a new Alpha VC manager) at some regular cadence is likely a permanent cost of choosing to allocate to the category. Teams at Alpha VC tend to be small and decision-making is concentrated. This can enable deeper partnership with LPs and managers, but it also creates significant risk to the continuity of performance when a star partner leaves or a generational transition occurs.

Another cost of pursuing the Alpha VC strategy comes with manager success. Alpha VCs running concentrated portfolios in funds of limited size are very likely to be oversubscribed and may choose to take advantage of this to charge higher carried interest percentages. In taking on the concentration risk of Alpha VC, success is defined by fund multiples and managers are primarily motivated by carried interest rather than fees.

Beta VC delivers broad access to the upside of private markets. Often packaged as multi-stage exposure through stapled funds or large commitments to diversified platforms, Beta VC allows LPs to allocate capital efficiently across broad segments of the innovation market. Large, brand name firms have significant staying power and little dependency on individual managers to drive performance, limiting the risk associated with departures on a team. The operating system of Beta VC is designed to mitigate risk in any individual investment, team member, technology, industry or market. High velocity investing at scale across broad sectors optimizes for market rate returns but may struggle to compete with correlated alternatives that offer similar market-level exposure. Further, depending on how an LP defines market exposure, Beta VC managers may find themselves competing not only with peers but also with QQQ or mid-market software buyout funds—or at a minimum, on total fee load—as LPs increasingly consider direct strategies to improve return profiles on a net basis.

Alpha VC vs Beta VC today

Beta VC is a new asset class rapidly aggregating capital. Alpha VC is an old strategy being pursued with new, open questions about competitive advantage and durability—forced to answer the question: “Don’t the big guys just win?”

To succeed with an alpha-seeking strategy, the VC product has to be differentiated enough for founders to notice. It also has to create enough value for founders to care more than they care about the very tangible benefits of higher prices, larger rounds and faster decision processes. As beta strategies scale, their pace of decision making, price insensitivity and coverage put pressure on the Alpha VC’s ability to capture founder attention (and cap table allocation).

Beta VC is too young to be considered durable and the firms practicing it the most intensely are more defined by constant change (and growth) rather than consistency of strategy or structure. This new group of asset managers has yet to show category level returns, durability or relevance to the best founders, the most talented investors and many LPs.

At TheGP, we see the best founders understand the difference between alpha and beta strategies and how the VC category you work with shapes partnerships, investment structures, and operating practices. As long as exceptional founders continue to choose the partner they believe will add the most value to their business—and not just those who offer the highest price fastest—we’ll keep building a differentiated product designed for the few inspired entrepreneurs capable of generating outlier returns.

What happens when the creator economy meets our AI moment?

, co-founder and CEO of Substack, and , the first prompt engineer at OpenAI, join forces in a conversation that cuts across technology, media, and the future of art.

They trace the path from the birth of ChatGPT to the wave of “slop” that flooded the internet long before AI, asking what authenticity looks like in a world where creating has never been easier. Best explains why Substack’s product philosophy—“do everything but the hard part”—continues to empower independent writers, and Mayne reflects on the creative challenges that come with making machines capable of writing back.

It’s a fast-paced discussion about the economics of culture: how frictionless design changes behavior, the gravity of end-user trust, building products that people actually want, and why authenticity remains one of the best competitive advantages.

In this conversation, you’ll learn:

1. The inside story of ChatGPT’s creation

2. Why frictionless product experiences matter more than technical breakthroughs

3. How Substack’s “do everything but the hard part” philosophy for building products empowers creators

4. What happens when business models consume products and how to resist that urge

5. How AI is accelerating Substack’s core bet: that authenticity will always outperform algorithms

6. Why AI-generated content won’t replace human stories

7. Why “all economics are downstream of culture”

8. Why Substack made subscribers portable and what that decision meant for trust

9. Why writers should see AI as an amplifier instead of a threat

10. The case for optimism: why artists, technologists, and media builders should embrace our emerging cultural renaissance.

Referenced in this episode:

• Brandon Sanderson’s record-breaking Kickstarter

• The Industrial Revolution

• India’s License Raj

• Avatar 2

• Reboot

• Mechanic’s Institute

• Mesopotamia and the invention of the plow

Where to find Andrew Mayne:

• Website: andrewmayne.com

• X (Twitter): @AndrewMayne

• Interdimensional: interdimensional.ai

Where to find Chris Best:

• Substack: cb.substack.com

• X (Twitter): @cjgbest

Where to find The General Partnership:

• Website: thegp.com

• LinkedIn: The General Partnership

• X (Twitter): @thegp

Claire Hughes Johnson (former COO at Stripe) and Gretchen Howard (former COO at Robinhood) join The General Podcast for a rare, candid conversation about what it really means to operate at the highest levels inside two of the most ambitious fintech companies of the past decade.

Both left safe jobs to take bets that looked “crazy” from the outside. Both joined hyper-growth startups without the COO title, built trust with founders in real time, and ended up shaping the companies from the inside out. In this episode, they dig into what the COO role actually is, how to avoid “organ rejection” when you’re the outsider, and why the people function is the most underrated lever for scaling.

You’ll hear Claire and Gretchen swap notes on why the hardest problems are often unglamorous—compliance, self-clearing, comp plans—and why the real work is about earning trust, building velocity, and protecting the integrity of the company as it grows.

In this conversation, you’ll learn:

1. Why Claire and Gretchen said yes to Stripe and Robinhood when everyone around them said no

2. Founder chemistry and how to know if you can actually work with someone

3. How to walk into a COO role without blowing up the culture

4. What founders get wrong when hiring their first COO

5. How Stripe and Robinhood scaled the ‘unsexy’ parts of business

6. How to build systems without adding bureaucracy

7. How to use the people function as a strategic weapon

8. Being okay with not being liked as your leadership evolves

9. Claire’s “full stack leader” framework

10. What great operators actually obsess over

Where to find Gretchen:

• LinkedIn

Where to find Claire:

• LinkedIn

• X: @chughesjohnson

• Book: Scaling People

Where to find TheGP:

• X: @thegp

• Website: thegp.com

Six months ago, we wrote about entering a deflationary era in software—of cost, of headcount, of talent. Fewer people doing more. Founders in builder mode. Lean teams with tall mandates. All of that still rings true.

And yet, something unexpected is happening: the most capitalized companies in the world are struggling to hire.

As with any arms race, it starts with the hardest to hire: engineers, research scientists, product minds. This race is already well underway. You’ve seen the headlines – Meta is poaching from OpenAI, offering founder-level equity to pull talent into its orbit. It’s not slowing down.

Even engineering management roles are making a return. Series A and B startups are hiring them faster than expected, as CEOs rediscover a simple law of organizational physics: you can’t manage scores of direct reports and still build, ship, sell, hire, and raise.

Despite two years of “founder mode” gospel, the truth holds—leadership scales through leverage, not load.

We’ve seen this before. It played out during ZIRP, and it's happening again, but faster. The wave always starts with technical talent, then moves systemically: to seasoned operators, to sales leaders who can package magic, to marketers who can translate frontier technology into the mainstream.

And then—perhaps most telling—it reaches recruiters.

When the best-capitalized companies begin prioritizing recruiter headcount, you’ll know it’s on. It means the market is moving too fast for inbound, too competitive for passive. It means the war for talent has reached every corner of the org chart.

We’re seeing the shift up close. At TheGP, well-funded, well-positioned startups are turning to us because the industrialized recruiting machine no longer delivers. The playbooks written for ZIRP-era growth companies—careers pages, junior sourcers, top-of-funnel volume—don’t hold up when you're competing against the world’s most resourced companies for top-tier talent.

The market has evolved. So must the method.

Here’s what will work:

1. Specialization. The most technical roles demand recruiters who’ve refined their craft—those who understand the difference between applied ML and foundational research. Vague job descriptions and templated pitches don’t land when the opportunity cost is OpenAI.
   

2. Relationship depth. Great recruiters don’t parachute in. They stay in orbit and build trust over time through regular check-ins, referrals, and high-leverage value before there’s a role to pitch. The pitch compounds well before the offer is written.
   

3. Quiet trust. Spam is still easy. Trust is not. This is where the best earn their edge: coaching candidates through nuanced decisions, gathering references quietly, offering honest feedback with confidentiality intact. Rather than just selling a job, they provide a point of view on the conditions in the field. Where talent is moving. Where the category is headed. And what kind of company is worth betting on next. Their edge is taste, not volume.

This is where we’ve invested at TheGP and where we continue to see the highest return on relationships.

As well-capitalized companies struggle to keep pace with the speed of the market, startups can’t afford hesitation. In an era defined by speed and deflationary software costs, your competition isn’t just the sleepy incumbent–it’s the incumbent in a new pair of running shoes.

When the recruiting machine breaks down, the companies that can still hire don’t just survive. They win.