DEV Community: Hunter G

YC CEO Demonstrates GStack: Why Your AI Agent Framework is Built Wrong

Hunter G — Wed, 29 Apr 2026 21:09:27 +0000

Y Combinator CEO Garry Tan recently dropped a bombshell demonstration video that shook the tech community. As an early core engineer at Palantir and a star founder who sold his startup to Twitter, Garry spent the last two months using Agents to rewrite his former startup project—a project that originally cost $10 million and took 10 engineers two years to build.

More importantly, he open-sourced a framework called GStack and threw out a highly disruptive architectural thesis: "Thin Harness, Fat Skills."

In this article, we will deeply deconstruct the "New Silicon Valley AI R&D Paradigm" shown in the video and see how a human commands a top-tier product development fleet composed entirely of digital lifeforms.

1. The Awakening: AI is No Longer a Tool, But a Regular Army

Garry Tan's sigh at the beginning of the video probably represents the voice of all top hackers right now: "I've coded more in the past two months than I did in all of 2013."

Before this, the industry's perception of AI programming generally stayed at the "Copilot" stage—you write some logic, and AI helps you complete the rest; you encounter a bug, and you paste the error log to AI for analysis.

But in Garry's demonstration, this dialog-box-based "outsourced" collaboration has been completely eliminated.
He astutely pointed out the fatal flaw of current monolithic large models: Because they lack deep contextual memory of your private codebase, if you ask it to directly write a complex system, it will start to "reasonably guess." In the face of a massive codebase, this guessing leads to catastrophic crashes that look perfect but fail on execution.

Since the AI's intelligence is already high enough, why does it still crash?
Garry's answer is deafening: "Humans have never built software by relying on one person. Humans build software through teams, role division, standard operating procedures (SOPs), and code review. Since LLMs are now replacing human work, we must make them follow human team collaboration logic."

This is the background of GStack's birth. It's not a plugin that teaches LLMs how to write code; it's a "Digital Human Organizational Architecture System." It virtualizes product managers, architects, frontend designers, and hardcore backend developers in the terminal, letting LLMs work for you in a team format.

2. Architectural Subversion: Thin Harness, Fat Skills

To achieve this "team-based" collaboration, the traditional approach is to write an extremely massive, rigid Agent framework (Fat Framework). But Garry explicitly points out this is a huge mistake: "LLMs are already smart enough; overly heavy scaffolding will only constrain their potential."

GStack proposes a completely new design philosophy: "Thin Harness, Fat Skills."

Thin Harness: The underlying scheduler of the system is very lightweight. It only does one thing—maintains the current context in the terminal and hands over the task to the next role at the right time.
Fat Skills: The real magic lies in the "skill packages" mounted on it. In Garry's demo, each Skill is not a simple API call, but a Domain Specialist with an independent persona and massive internal logic.

This loosely coupled architecture allows you to hot-plug different "digital employees" into the terminal at any time according to your needs.

3. Stage One: The Office Hours Skill (Reshaping the Product's Soul)

In the demo, Garry wants to build a small app to "automatically extract 1099 tax forms from Gmail for users during tax season."
If we followed the old way, we would throw this requirement directly to Claude and let it start writing Gmail API scraping code.

But in GStack, Garry first calls a skill named Office Hours.

This is the most mind-blowing part of the entire video. This skill package encapsulates the soul of 16 top Y Combinator partners coaching founders for tens of thousands of hours. It doesn't start writing code at all; instead, like a picky investor, it continuously throws 6 oppressive "Forcing Questions" at Garry:

"What is your strongest evidence that anyone actually wants this?"
"TurboTax already exists, and Plaid can connect directly to banks. Why do you think they need your little tool?"

It doesn't just ask questions; it actively helps the founder iterate the business model.
After multiple rounds of dialogue, this virtual YC partner proposes: "Don't just build a tool to help people download files. We need to use 'finding tax forms' as a Wedge Strategy. The real business model is to funnel the users who have downloaded their tax forms to professional CPAs (CPA Marketplace) and take a cut from it!"

This is the power of "Fat Skills." At this stage, the LLM is not a code generator at all; it is a co-founder with extremely high business Taste. It helps you elevate a tool that can only be sold for $2 into a commercial platform that can charge 10x commission.

4. Stage Two: Adversarial Review

After the business model is finalized, the system enters the phase of writing the Product Requirements Document (PRD).
GStack once again demonstrates the essence of human team collaboration—Code Review and QA.

After generating the initial design document, the system automatically triggers multiple rounds of "Adversarial Review." Another Agent acting as a reviewer starts looking for flaws with a magnifying glass:

"Your design makes no mention of how to handle the 2FA (Two-Factor Authentication) callback."
"Missing privacy policy and sensitive data handling statement."
"Failure handling mechanism is missing."

The most terrifying thing is that after discovering the problems, the two LLMs start to fight each other in the terminal, automatically fixing these 16 pointed-out architectural vulnerabilities. Watching the two code streams flashing alternately in the terminal, a rough idea that originally only scored 6/10 points was forcefully polished into an 8/10 professional-grade technical specification without any human intervention.

5. Stage Three: The LLM Matrix (ADHD CEO and Autistic CTO)

In the visual UI design stage, GStack calls another skill named Design Shotgun.
Here, Garry throws out an extremely vivid and precise metaphor, revealing the true meaning of the LLM matrix:

"You can think of Claude Opus 4.6 as a creative CEO with ADHD. You'd love to grab a beer with him, and his head is full of a billion brilliant ideas and product definitions. But when it's time to actually bite the bullet on the extremely hardcore, boring code implementation, you have to call in the hardcore autistic CTO—and that's OpenAI's Codex model."

This is precisely the essence of GStack's underlying scheduling: No single model can do everything.
When discussing business models and user pain points, call Claude Opus, which is extremely good at empathy and product logic; and when generating specific UI components and underlying hardcore algorithms, the system will instantly and smoothly switch to OpenAI's model.

This practice of perfectly binding the personality traits (Persona) of different LLMs with specific development stages is the ultimate modularity we have always pursued when building the Agent OS.

6. Conclusion: The Age of Discovery for Solo-Founders

After watching Garry Tan's sci-fi-movie-like demonstration, we must admit a fact: The era of the monolithic engineer is over, and the Age of Discovery for Solo-Founders has officially begun.

When you can use a single command to instantly summon a top YC product partner, an extremely demanding QA architect, and a full-stack engineer who works all night without getting tired in the terminal, the marginal cost of software development has infinitely approached zero.

In this cruel dimensional strike, you don't need to write more elegant loop statements than others. The only things you need to possess are the Taste, Vision, and the Audacity to reshape all old rules as the supreme commander.

The CLAUDE.md File That 10x'd My Output

Hunter G — Wed, 29 Apr 2026 20:57:07 +0000

Why do some developers feel like they have superpowers when using AI coding tools, while others feel like they are babysitting an intern?

If you use Cursor or Claude Code, you've probably noticed a frustrating pattern. One day the AI writes brilliant code. The next day, it forgets your project's architecture, uses the wrong UI library, and writes messy boilerplate code that you explicitly hate.

You end up wasting hours correcting the AI. This is because LLMs are not lacking intelligence. They are lacking "Project Memory."

The Hidden Ground Truth

In the underlying mechanics of Claude Code, there is a powerful, almost tyrannical design feature. Every single time you start a new session, before you type your first prompt, the AI quietly looks for a hidden file in your root directory.

That file is CLAUDE.md.

For normal developers, this is just a readme file. But for top 1% hackers, this is a neural link to force-feed an entire persona and project memory into the LLM.
This file acts as the absolute Ground Truth. Let's break down exactly how to construct a 10x CLAUDE.md file.

1. Persona and Vibe

Do not let the AI act like a generic, polite assistant. Set the stage immediately:
"You are a Senior Principal Engineer at a top-tier tech company. You write incredibly elegant, high-cohesion code. You despise boilerplate. Always prioritize performance."

2. Unbreakable Tech Stack Rules

Turn your team's development standards into unbreakable laws.
"Our frontend strictly uses React 18 functional components and Tailwind CSS. NEVER write a Class Component. NEVER write inline CSS. Our backend is locked to PostgreSQL."
With these hard limits, the AI will stop polluting your codebase with random, outdated libraries.

3. Global Architecture Map

Don't let the AI burn tokens blindly searching your folders. Tell it exactly where things live.
"All core orchestration logic lives in the /agents directory. State management is restricted to the /memory folder."

4. Hard-Learned Lessons

This is the most valuable section. Take your team's blood, sweat, and tears, and hardcode them into the AI's muscle memory.
"We tried using standard LangChain for memory, but it caused severe latency spikes. NEVER import LangChain. Always use our custom MemoryStore class."

Conclusion

In the Agent OS era, the boundary between human and machine is shifting. Writing a perfect CLAUDE.md is not just writing a prompt. You are compiling a digital brain.

Stop fighting with your AI over syntax errors. Build a CLAUDE.md file, inject your soul into it, and watch the AI dominate your codebase.

My Claude Code Can INSTANTLY Watch Any Video (Here's How)

Hunter G — Wed, 29 Apr 2026 19:58:26 +0000

Most AI video summary tools are completely blind. When you give them a 45-minute tech talk, they only extract the transcript.

If the speaker points to a retention graph and says "This is where startups die," the AI has no idea what "this" is. It misses the charts, the UI bugs, and the code snippets. In a multi-modal era, summarizing without visual context is useless.

The Local Hacker Solution

Anthropic doesn't have a native video model yet, and Gemini 1.5 Pro is expensive and hard to wire into Claude.

But a video is just two things: Frames (Images) + A Transcript (Text).

We can build an unstoppable pipeline using two battle-tested CLI tools:

yt-dlp: Instantly downloads the video stream and official free subtitles from over 1,000 sites.
ffmpeg: Silently extracts high-res frames every few seconds.

If a video lacks captions, we use Grok or OpenAI's Whisper API to transcribe the audio for pennies.

How it works

The script extracts roughly 100 keyframes from the video (dynamically scaling the interval so it never blows up your token window). It pairs these frames with the timestamped transcript and feeds it all into Claude.

Within 2 minutes, Claude has "watched" the entire video. The total token cost for a 45-minute video? About $1.

3 Killer Use Cases

Content Research: Drop a competitor's viral video and ask Claude to analyze the visual hook and script simultaneously.
UI Debugging: Feed a 30s screen recording of a frontend crash and ask Claude to pinpoint the exact frame the Z-index state changed.
Automating the Second Brain: Run this over industry podcasts and push structured, charted notes directly into your Obsidian vault.

Stop paying for expensive AI wrappers. Wire up your CLI and let your LLM grow eyes.

YC CEO Rebuilt a $10M Startup in 3 Weeks: Why Your Agent Framework is Wrong

Hunter G — Fri, 24 Apr 2026 18:21:00 +0000

Y Combinator CEO Garry Tan recently dropped a bombshell demonstration. Using his open-source GStack framework, he single-handedly rebuilt a startup that originally took 2 years and 10 engineers to build—in just 3 weeks.

If you are building AI Agents, you need to pay attention. He proposed a radical architectural philosophy: "Thin Harness, Fat Skills."

1. The Myth of the "Fat Framework"

Most developers try to build massive, rigid Agent frameworks. Garry argues this is a mistake. The underlying LLMs are already smart; heavy scaffolding only constrains them.

Instead, GStack uses a "Thin Harness": A lightweight CLI that simply maintains terminal context and orchestrates handoffs.
The magic lies in "Fat Skills": High-context, persona-driven domain experts that you plug into the terminal.

2. The "Office Hours" Skill: AI as a Co-Founder

Before writing a single line of code, GStack runs the Office Hours skill. This agent encapsulates the soul of YC partners. It interrogates the founder with forcing questions:

"What is your strongest evidence that anyone wants this?"
"TurboTax already exists. Why you?"

In the demo, the AI actively pushed Garry to pivot his business model from a $2 tool into a highly profitable CPA marketplace funnel. The AI wasn't a code generator; it was a co-founder with elite business Taste.

3. Adversarial Review: Machines Arguing

Once the PRD is drafted, two agents engage in an "Adversarial Review". They ruthless debate the architecture.

"You missed 2FA handling."
"There is no failure handling here."

Watching the terminal blink as two models automatically catch and patch 16 architectural vulnerabilities without human intervention is the ultimate display of the Agent OS.

Conclusion: The Solo-Founder Era

The marginal cost of software development is approaching zero. You no longer need to be the best syntax writer. To win in this new era, you only need three things: Taste, Vision, and Audacity.

Stop Fighting Amazon Captchas: We Open-Sourced a Billion-Row Data Plugin

Hunter G — Sun, 19 Apr 2026 17:30:52 +0000

In today's e-commerce landscape, the true barrier to AI is no longer the model itself—it's access to clean, comprehensive data.

Over the last year, Amazon's anti-scraping and captcha mechanisms have become incredibly strict. Whether you are writing a custom scraper or paying for expensive monitoring SaaS, everyone faces the same issue: IP bans, missing data, and polluted datasets.

If your data source is blocked or compromised, even the best Prompt Engineering is useless.

The Industry's Exclusive Data Vault

To solve the problem of data scarcity, we have accumulated billions of real, structured Amazon reviews across all categories over the years.

This isn't just a database; it's a massive, cleaned, and labeled "Data Goldmine". If you can access this vault, every buyer pain point, product defect, and usage scenario is laid bare.

1-Click Deployment: The Open Source VOC AI Plugin

Today, we are handing you the keys to the vault. We have officially open-sourced our voc-amazon-reviews plugin.

This isn't a complex scraper that requires you to buy expensive proxy pools. It's an incredibly lightweight, easy-to-deploy CLI plugin.

Installation

You can install it directly from GitHub with one line:

clawhub install mguozhen/voc-amazon-reviews

Accessing the Billion-Row Vault

Once installed, just run:

clawhub run voc-amazon-reviews --asin B099Z93WD9

The plugin bypasses the entire scraping process. It connects directly to our underlying data vault and outputs clean JSON and deep LLM semantic insights within 5 seconds.

👉 GitHub Repo: voc-amazon-reviews

Stop fighting captchas. Tap into the industry's most exclusive data artery today.

The Agent OS: Why Building 'Role Agents' is Better Than Empowering Individuals

Hunter G — Sat, 18 Apr 2026 10:06:29 +0000

A16Z recently published an incredibly harsh reality check: AI made every individual 10x more productive, but no company became 10x more valuable as a result.

Why? Because we are treating AI like a faster electric motor in a 19th-century steam engine factory. We swapped the engine, but we haven't redesigned the assembly line.

If you want to build an AI-Native Organization, you must shift from "Individual AI" to "Institutional AI".

1. Package "Role Agents", Don't Just Empower "Individuals"

This is the fundamental difference. The old instinct was "give everyone a ChatGPT." This creates massive organizational chaos—everyone uses different prompts and formats, leading to disastrous bottlenecks when aggregating data.

True organizational capability comes from building a matrix of "Role Agents," rather than just giving everyone an assistant.

A qualified Role Agent must encapsulate three elements:

Taste: The aesthetic and quality standard of the role.
Skill: Private toolkits and execution capabilities.
Memory: The company-level historical context of that position.

When you deploy a digital employee matrix built on these three pillars, they coordinate natively. You are upgrading the "Standard Asset of the Position", instead of relying on an employee's extraordinary performance.

2. Find Signal, Stop Generating Noise

Generating a 10,000-word report now costs nothing. This means "Information Slop" is rising exponentially.
Institutional AI is not a generator; it is a filter. It acts as a cold auditor, picking out the one critical data point from 1,000 logs that impacts tomorrow's revenue.

3. Scale Revenue, Don't Just Save Time

Saving an employee 2 hours a day is not an asset. Institutional AI scales the revenue ceiling. It shifts employees from "executors" to "reviewers."

Organization is not managed; it is designed. Are you going to keep installing faster motors, or are you ready to redesign the factory?

Why 10x Engineers Don't Make a 10x Company: The AI Native Org Blueprint

Hunter G — Sat, 18 Apr 2026 07:34:43 +0000

A16Z recently published an incredibly harsh reality check: AI made every individual 10x more productive, but no company became 10x more valuable as a result.

Why? Because we are treating AI like a faster electric motor in a 19th-century steam engine factory. We swapped the engine, but we haven't redesigned the assembly line.

At Solvea, we radically redesigned the factory. Here is how we shifted from Individual AI to Institutional AI.

Individual AI vs. Institutional AI

Individual AI is the ChatGPT Plus account on an employee's desk. Institutional AI is an operating system that reshapes the entire workflow.

1. Creating Coordination, Not Chaos

Individual AI creates friction. Everyone writes their own prompts, resulting in varied formats and a massive jam when aggregating data.
Institutional AI enforces a unified context (Harnessing). Our Agents are not chat windows; they are mounted directly to our core databases, sharing the same Memory and Taste.

2. Finding Signal, Not Generating Noise

3. Scaling Revenue, Not Just Saving Time

Most AI SaaS pitches focus on saving an employee 2 hours a day. But 2 hours saved is not an asset.
Institutional AI scales the revenue ceiling. If an Agent scrapes Yelp reviews at 3 AM and autonomously closes a lead, it's driving incremental revenue, not just localized efficiency.

Our MVP: Breaking the Scale Ceiling

Previously, we had 20 Customer Success Managers (CSMs). One person's limit was 5 enterprise clients. To scale to 100 new clients, we had to hire 20 more people and endure massive communication overhead.

We completely rewrote the "Role & Protocol." We deployed a multi-agent matrix.
Our employees no longer "execute"—they "Review."
Now, one CSM handles nearly 50 enterprise clients. The service capacity is tied to compute, not headcount. Our team shrank from 100 to 50, but our efficiency multiplied.

The Pitfall: Same Workflow, New Tools

The biggest mistake founders make is buying AI tools but keeping the 5-step human approval chain. If code is written 10 minutes faster, but sits in review for 9 days, you haven't transformed anything.

Organization is not managed; it is designed. Stop measuring new paradigms with old rulers.

Figma and Adobe's Doomsday: How Claude Design Shatters the Handoff Wall

Hunter G — Sat, 18 Apr 2026 07:33:29 +0000

If you audit the engineering efficiency of a typical software company, you’ll find an absurd phenomenon:
Developers are using Copilot and Claude Code, writing code 5x faster. But a new feature still takes weeks to ship.

Why? Because the real bottleneck isn't writing code. It's the "translation tax" between Product, Design, and Frontend.
Today, Anthropic smashed that wall with Claude Design.

Not a Canvas, an Execution Harness

Many see Claude Design and think it's just another v0.dev. That's a massive underestimation.
Claude Design is an LLM harnessing your production UI layer.

1. Production-Aware

It doesn’t generate fake Tailwind divs. It connects to your GitHub repository. Every button it renders on the canvas is your company's actual production React/Vue component.

2. The Handoff to Claude Code

This is the killer feature. You don't write PRDs anymore. When the PM finishes iterating the UI, they click a button. The structure flows directly to Claude Code in the background, which autonomously writes the backend logic, updates the database schema, and opens a full-stack PR.

The Pitfall

If your company doesn't have a standardized component library (Design System), Claude Design is a gun without bullets. It will only generate generic UI. The more powerful the tool, the more severely you are punished for lacking foundational engineering standards.

The relay race is dead. The future belongs to Product Managers with high "Taste" acting as one-person special ops teams.

Claude Code routines turn AI coding from an assistant into an execution layer

Hunter G — Wed, 15 Apr 2026 01:30:42 +0000

Claude Code routines turn AI coding from an assistant into an execution layer

Anthropic’s new Claude Code routines look like a scheduling feature.

That reading is technically correct.
But it misses the more important shift.

Claude Code is moving from an interactive coding assistant toward an always-on execution layer for engineering work.

Source announcement:
https://claude.com/blog/introducing-routines-in-claude-code

What launched

Claude Code routines can now be triggered in three ways:

on a schedule
from an API call
from GitHub repository events

A routine bundles a prompt, repo, and connectors into a reusable automation unit that runs on Claude Code’s web infrastructure.

That last detail matters.
The system no longer depends on a developer’s laptop staying open.

Why this matters more than a cron replacement

Most development teams do not have a shortage of AI demos.
They have a shortage of attention for repetitive but necessary work.

Think about the tasks that constantly get deferred:

issue triage
docs drift checks
deploy verification
alert investigation
bespoke pull-request review

These workflows are not glamorous.
But they are where a lot of engineering time goes.

Claude Code routines aim directly at that layer.

The real product shift

Once prompts, repos, connectors, triggers, and session continuity are bundled together, the product is no longer just helping someone type faster in a terminal.

It is becoming part of the system around the codebase.

That changes how teams should evaluate coding AI.

The question becomes less:

"How smart is the model in a single session?"

And more:

"How much recurring engineering work can this reliably absorb every week?"

That is a more operational benchmark.
It is also a more useful one.

Where teams should start

The best first routines are not the most ambitious ones.

Start with bounded jobs that already have a clear success criterion:

nightly issue triage
post-deploy smoke checks
docs consistency checks after merged PRs
review rules for a specific module or policy

These are good candidates because the cost of experimentation is low, and the feedback loop is fast.

Final thought

The next strong engineering teams may not be the ones that write code the fastest.

They may be the ones that offload routine engineering actions to always-on agents first.

Claude Code routines are an early sign of that shift.

Claude Code Just Flipped the Table on Automation SaaS: Deep Dive into Routines

Hunter G — Wed, 15 Apr 2026 01:18:10 +0000

A few hours ago, Anthropic released an epic update: Claude Code Routines.

Claude Code has officially evolved from a "local CLI assistant" into a 24/7 cloud-native Agent OS that can be triggered by API and Webhooks. Traditional automation SaaS and CI/CD tools are facing a dimensional strike from the foundational model.

The Collapse of the Execution Layer

Yesterday, our team open-sourced dingtalk-bridge. We wrote complex WebSocket daemon threads and exponential backoff reconnection logic just so Claude Code could listen to enterprise IMs and run 24/7 without a laptop open.

Today, Anthropic natively solved this.

You configure a prompt, connect a repo, and set up triggers. It runs on Claude's cloud infrastructure.

1. Scheduled Routines

"Every night at 2 AM: Pull the top priority bug from Linear, attempt to fix it, and open a draft PR."
AI isn't just writing code anymore; it's clearing your tech debt while you sleep.

2. API Routines

Each routine gets a unique Endpoint URL and Auth Token.
When Datadog triggers a production alert, a webhook sends it to Claude. Before the On-call engineer even opens their laptop, Claude has already pulled the Trace, correlated it with recent deployments, and drafted a triage summary in Slack.

3. Webhook Routines (GitHub)

"Intercept all PRs modifying the /auth-provider core module. Read the changes, summarize security risks, and post to the #security channel."

The Pitfalls: Quota Constraints

The capability is god-tier, but the execution requires caution.

Strict Limits: Pro users get 5 daily runs; Max gets 15; Team/Enterprise gets 25. You cannot use this for high-frequency dumb piping (like syncing messages every minute). Use it for "high cognitive density tasks."
Cold Start Context Costs: Each routine run is an isolated session. If your repo is massive, frequent triggers will drain your token quota. You must use Context Caching and strict permissions.deny blocklists.

When a foundational model can write code, configure its own cron jobs, expose API endpoints, and listen to GitHub webhooks, the moat for "wrapper SaaS" building pretty UIs on top of APIs is completely drained.

If you have a Pro subscription, type claude /schedule in your terminal today and start building your 24/7 phantom engineering team.

AI Made Building Cheap. Distribution Is the New Moat

Hunter G — Sun, 12 Apr 2026 21:33:35 +0000

Stop Vibe Coding. Start Getting Customers.

AI is making product building cheaper every month.

That sounds like great news for founders.

It is. But it also creates a brutal new problem.

If almost anyone can ship a decent product quickly, then product creation stops being the main bottleneck. The scarce skill shifts to distribution. The hard question is no longer "can you build this?" but "can anyone find it?"

That is the core reason Greg Isenberg's recent video landed so well. The real takeaway is not anti building. It is anti delusion. Shipping is easier. Attention is not.

Video source: https://www.youtube.com/watch?v=YeoGehNsrLc

The old startup loop is breaking

A very common founder workflow now looks like this.

open Claude Code or Cursor
ship a demo in one weekend
post a launch link
wait for users
hear nothing
add more features
relaunch
hear nothing again

This is not a product problem.

It is a distribution problem.

The old belief was that if you build something good enough, demand will eventually show up. In the AI era, that belief gets more dangerous because the cost of building has fallen so much. You can now build faster than you can learn whether anyone actually cares.

That is why the strongest line from the whole video is this:

Distribution first. Product second.

Founders should start with the channel, the audience, the search surface, or the repeated question. Then they should build directly into that demand.

Why distribution becomes the new moat

When product creation becomes easier, differentiation moves elsewhere.

It moves into:

trust
audience ownership
search visibility
consistent distribution
repeatable conversion systems

This is why some solo founders keep compounding while others keep shipping in silence.

The gap is often not product quality. It is whether the founder has already built a route to the customer.

Three growth ideas that matter right now

Greg lists seven tactics in the video, but three stand out because they are immediately actionable.

1. Free tools are now marketing

One of the strongest ideas in the video is that the tool itself can be the marketing.

A lightweight free analyzer, calculator, grader, or checker can do several jobs at once.

give the user instant value
create a reason to share
capture leads
qualify demand
pull the user toward the paid product

This used to be expensive to build.

Now it is often a one day project.

That changes the economics of top of funnel growth.

2. AEO matters as much as SEO

Search is no longer only about ranking in Google.

Founders now need to ask a different question.

Can ChatGPT, Claude, and Perplexity parse my content and cite it?

That means more structured answers, more direct definitions, more comparison tables, better FAQ design, and cleaner page architecture. The winners will not just optimize for clicks. They will optimize to become the answer source.

3. MCP can become a distribution surface

This is an underrated point.

If your product can be exposed as an MCP service, then AI clients may become a new acquisition channel.

The user asks a question.
The AI discovers your MCP service.
The AI calls your product.
The user gets the result.

That is not just a technical integration. It is a new entry point.

Founders who understand this early are not just building features. They are competing for AI native distribution.

What founders should do next

You do not need to apply every tactic at once.

A better approach is to pick two or three and execute hard.

My practical shortlist would be this.

build one useful free tool
turn your top customer questions into AEO friendly pages
create one mother asset and repurpose it into multiple channels every week

If you are building an AI or agent product, I would add one more.

seriously explore MCP as a future distribution layer

Final thought

The future does not belong to the founder who can ship one more feature faster than everyone else.

It belongs to the founder who can turn one product into traffic, leads, conversion, and revenue.

That is the real shift.

Code is getting cheaper.

Distribution is getting more valuable.

Stop Vibe Coding. Start Getting Customers: Distribution Is the New AI Moat

Hunter G — Sun, 12 Apr 2026 21:06:53 +0000

Stop Vibe Coding. Start Getting Customers: Distribution Is the New AI Moat

Most AI founders are solving the wrong bottleneck first.

They are asking how fast they can build.
They should be asking how customers will discover what they build.

That was the clearest lesson from Greg Isenberg’s video, Stop Vibe Coding. Start Getting Customers. The title sounds blunt, but the underlying argument is stronger than the slogan: AI has dramatically lowered the cost of making software, which means distribution is becoming the new point of scarcity.

In other words, the hard part is no longer turning an idea into a product. The hard part is turning a product into a predictable customer pipeline.

Building is getting commoditized

AI coding tools have changed the economics of software creation.

A solo founder can now prototype a workflow app, an internal tool, or even a lightweight agent product in days instead of months. That is good news for builders, but it also removes a lot of the natural scarcity that used to protect them. If more people can ship, more products will look “good enough” on day one.

That shift matters because product quality alone is no longer enough to guarantee attention.

The market is now filling up with AI products that technically work but never find distribution. They launch, get a few likes, then disappear. Not because the founders are lazy. Not because the interface is ugly. Because discovery was never designed into the product in the first place.

Distribution-first is the new founder advantage

Greg’s strongest point is that smart builders should stop treating marketing as a post-launch task. Distribution has to be part of the product strategy from the beginning.

That means asking questions like:

Where will the first qualified users find this?
What problem are they already searching for?
What asset would make them share the result?
What channel compounds if it works?

This is a better founder lens than simply asking what feature to add next.

In practice, the best AI companies are likely to be built around a distribution wedge first and a product second. They will not just launch into the void and hope for virality. They will design an acquisition path that fits the product from day one.

Seven growth plays that matter in the AI era

The video offers seven practical growth strategies. Together, they form a good framework for founders building in AI.

1. MCP as a distribution channel

If your product can expose useful functionality through MCP, AI assistants themselves can become a discovery layer. Instead of only buying traffic, you are giving large-language-model interfaces a way to surface your product to users at the moment of intent.

2. Programmatic SEO still works

Search is not dead. It is just getting more competitive and more structured. Programmatic SEO still matters when it is built around real query patterns, clean data, and pages that genuinely answer narrow user intent.

3. Free tools can be the funnel

A grader, analyzer, calculator, or benchmark tool can act as the top of funnel. It gives users an immediate result, captures intent, and often creates a natural bridge into the paid product.

4. AEO is becoming as important as SEO

If users increasingly rely on ChatGPT, Claude, and Perplexity to answer questions directly, founders need to think beyond search rankings. They need content that AI systems can cite.

5. Make product outputs shareable

If your product creates a milestone, score, report, or artifact that makes the user look smart, productive, or ahead of the curve, that output can become a distribution asset.

6. Buy audience instead of starting from zero

Rather than spending a year trying to grow a niche newsletter from scratch, a founder can sometimes acquire a small but relevant one. That can be a faster path to trust than renting reach from social platforms.

7. Repurpose one strong idea across many channels

One strong piece of content should not live once. A founder insight can become an X post, a LinkedIn post, a newsletter, a blog article, short-form video clips, quote cards, and email nurture copy.

What this means for AI startups

The biggest takeaway is simple: code is becoming abundant, but trust and distribution are not.

The moat is no longer just the ability to build a feature faster than everyone else. It is the ability to connect that feature to discoverability, trust, repetition, and revenue. Distribution now includes SEO, AEO, audience ownership, AI-native discovery, and shareable outputs.

This is especially relevant for AI companies serving mainstream businesses. Customers rarely buy because the model is impressive. They buy because the solution is visible, understandable, credible, and easy to act on.

That is why Solvea’s category is interesting. Businesses do not need another abstract AI demo. They need AI that shows up where work already happens and turns attention into action. In customer communication, that means handling calls, messages, and inquiries reliably enough that the business actually feels the result.

Final thought

The AI era did not make growth less important. It made growth more central.

When building gets easier, distribution becomes harder by comparison.

So the question for founders is no longer just, “What can we ship this week?”

It is, “How will customers find us next week, next month, and six months from now?”

That is the better question.

And it may be the one that separates clever demos from durable companies.