DEV Community: Pratik Patel

$581 Billion In, Single Digits Out

Pratik Patel — Tue, 08 Sep 2026 13:15:14 +0000

In 2025, total AI-related investment reached $581.69 billion a 129.9% jump over the year before, and roughly forty times what it was in 2013. In the same year, when Stanford's AI Index asked organizations how much they actually used AI agents, the most common answer, across most business functions, was none.

Those two facts belong in the same sentence, because the distance between them is the most useful thing a founder can hold in their head right now. Almost everyone has bought in. Almost nobody is running agents at scale. Depending on where you sit, that is the bubble thesis or the opportunity thesis — and the point of this post is to give you the numbers to decide, plus enough survey literacy to notice when two credible reports say opposite-sounding things.

Where the Money Went

Start with the $581.69 billion, because it is the number everyone quotes and almost nobody reads carefully. It is not a corporate AI budget. The AI Index compiles it from mergers and acquisitions, minority stakes, private investment, and public offerings the flow of capital toward AI, not the amount spent deploying it. Private investment alone was $344.66 billion, up 127.5%; M&A activity rose 132.6%. However you slice it, the money is real and it is accelerating.

Adoption looks just as emphatic. In the same body of surveys, 88% of organizations reported using AI in at least one part of the business, and 70% reported using generative AI in at least one function. If you stopped reading there, you would conclude the transformation is essentially complete.

Then you get to the agents.

Where It Didn't

Here is the sentence from the chapter that reorganizes everything above it, quoted exactly because the summary version of it is misleading:

"Across most business functions, a majority of respondents reported no agent use at all. Scaled use was in the single digits for nearly all functions."

Read that carefully, because the chapter's own one-line overview flattens it into "AI agent deployment was in the single digits," and that is not what the data says. "Single digits" describes scaled use — agents running as real infrastructure rather than in a pilot. The share reporting no agent use at all is much larger than single digits. In the words of the report: "Even in functions with the most activity, including IT and knowledge management, about two-thirds or more of respondents reported no use."

The high end is instructive. The functions with the most scaled agent use are exactly where you'd expect: software engineering at 24%, IT at 22%, service operations at 21%. Those are the peaks. Everywhere else falls away fast. So the picture is not "agents are everywhere." It is "agents are in engineering, and rare-to-absent in the rest of the company that engineering was supposed to be building them for."

One caveat the AI Index carries and I will carry too: these adoption figures come from McKinsey's annual State of AI surveys, and they are self-reported. The report itself says they "should be viewed as directional rather than comprehensive." Directional is enough for the argument. The direction is a two-order-of-magnitude gap between money in and agents out.

The Number That Says the Opposite

Now the part that separates a useful reading from a credulous one.

If you spend any time in the agent-building community, the picture above will feel wrong, because you have seen a very different number. LangChain's State of Agent Engineering survey found that 57.3% of respondents already had agents running in production. Not piloting. Production. That is not single digits; that is a majority.

Both numbers are honestly reported. They disagree because they asked different people. The McKinsey/AI Index data samples enterprises — a broad cross-section of organizations and the functions inside them. The LangChain survey is a self-selected community sample: 1,340 respondents, fielded in late November and early December of 2025, 63% from the technology industry, and roughly half at companies with fewer than a hundred people. One instrument measured "how much do organizations use agents." The other measured "how much do people who build agents use agents." Of course they diverge.

The habit worth building is smaller than either statistic and worth more than both: before you believe an AI adoption number, ask who was surveyed. A figure sampled from agent engineers tells you the frontier is real and shipping. A figure sampled from enterprises tells you the frontier is narrow and hasn't diffused. Neither is a lie. They are answers to different questions, and most of the confusion in the market comes from treating them as answers to the same one.

The same discipline catches errors, not just framing. The AI Index chapter states, twice, that Google reported "more than $150 billion in capex" in 2025. Alphabet's own filing puts 2025 capital expenditure at $91.4 billion, up from $52.5 billion the year before, with $175–185 billion guided for 2026. The $150 billion figure looks like a 2026 projection read as a 2025 actual — a mistake even a careful report can make when it restates a third party's number about a specific company. When a claim can be checked against a primary source, check it. The gap between "money in" and "agents out" is real, but you want to be sure every number describing it is measuring what you think it is.

What a Founder Should Do With This

The temptation is to treat the gap as a verdict — proof of a bubble, or proof of an untapped market. It is neither on its own. It is a description of timing.

If you are selling agents, the gap is your addressable market and your warning label at once. The demand signal is unambiguous: nearly nine in ten organizations are already using AI, and the capital is flooding in. But the thing you are selling — agents running at scale, in functions beyond engineering — barely exists yet in the enterprises you are selling to. That is not a market that needs another demo. It is a market that needs the operational work of making agents trustworthy enough to run unattended: the permissions, the runbooks, the observability, the ownership. The companies that closed that gap for themselves are the ones with agents in production. Everyone else is stuck at the pilot.

If you are buying, the gap is permission to move deliberately. You are not late. The single-digit scaled-use number means the median organization has not figured this out either, and the ones that have did it by treating agents as infrastructure rather than as a feature to switch on. The advantage is not in adopting first. It is in being one of the few that gets an agent past the pilot and into the part of the business that isn't engineering.

The consumer side hints at where the real value is accruing while enterprises deliberate. One estimate puts the annual consumer surplus from generative AI in the US at $172 billion, up from $112 billion the year before, with the share of US adults using generative AI rising from 48% to 56% (Bick et al., 2026). Worth flagging what that figure is: a stated-preference measure, drawn from online experiments asking people what they'd need to be paid to give up generative AI for a month — not revenue, not revealed behavior. But even discounted, it points the same way. The tools are being used. The enterprise agent, running at scale, in production, owning real work, is the thing that hasn't arrived.

$581.69 billion went looking for that agent last year. In most of the companies that spent it, the agent isn't running yet. The gap is not the failure of the story. It is the middle of it — and it is a better place to be building than either end.

If you want the setup to this, The Zero Dollar Startup is about what happened when building got cheap, and Distribution Is the New Code is about where the leverage moved next.

Green Is a Measurement, Not a Decision

Pratik Patel — Tue, 01 Sep 2026 16:11:33 +0000

I keep watching the same meeting. Someone asks if the agent is ready. Someone else shares a dashboard. The suite is green. The conversation ends.

That used to be the right reflex. For a compiler, a passing test suite is close enough to a ship decision that we stopped noticing the gap. Agents broke the reflex and we didn't update the meeting.

Last month I wrote that nearly a quarter of observed multi-agent failures are failures of the checking layer, and that the most common one is the check that ran and said yes. The closer was the part I want to pick up: your eval suite is another component in the system, and unlike everything else you built, there is nothing downstream of it that would notice if it broke.

This week is the next sentence. Even if you fix the suite — even if it starts measuring the right thing — a pass is not permission. Production agents fail in a place the suite was never pointed at. Green is a measurement. Shipping is a judgment. Most teams have quietly handed that judgment to the dashboard.

The Suite Cannot See the Failure You Will Get Paged For

I have been reading Mukund Pandey's Evaluating Agentic AI in the Wild. It is a taxonomy of seven failure modes the author argues are specific to agents running continuously, not to models taking a test.

The list is unglamorous, which is why I trust the shape of it. Cascading decision error: an early step is wrong, every later step is locally correct given that input, and the output is internally coherent and systematically false. Silent tool degradation: a dependency starts returning schema-valid stale or partial data instead of failing, the logs stay clean, and downstream logic proceeds at full confidence. Distribution collapse: the agent converges on a narrow set of high-scoring outputs while accuracy stays flat. Cross-surface inconsistency: the same intent arriving through the API and the UI gets two different answers. Explanation decoupling: the decision is right and the reason you recorded is wrong. Latency-driven correctness erosion: the SLA is green because the system skipped the enrichment that made the answer good. Proxy goal convergence: the metric you rewarded went up for weeks while the thing you actually wanted quietly left.

I will not tour the framework the paper proposes. The useful part is the detection table. Against ROUGE, BERTScore, accuracy/AUC, AgentBench, and MT-Bench, four of the seven modes produce no signal at all. The other three show up only after a lag of multiple evaluation cycles. No standard metric in that set detects any of them reliably inside a single cycle.

Sit with that. The suite can be honest, well-maintained, and pointed at the right property of the output, and still be blind to the incident you will get paged for. Last month the problem was a verifier that lied. This week the problem is a verifier that was never looking at the room the fire started in.

Accuracy Can Stay Flat While the System Rots

The paper's most instructive experiment is also the least dramatic.

The author simulates five weekly windows of session outputs. Accuracy is held between 0.86 and 0.88 the entire time — the production pattern where request-level correctness does not reflect what a user experiences across a session. Meanwhile the output distribution narrows from twenty categories to three. Diversity drops by a factor of six and a half. Repeat rate goes to 1.0: every output in the window comes from the same category.

The accuracy number never flinches.

A second experiment does the same trick with tools. Across four stages of an upstream service degrading into partial responses, the external accuracy signal moves by three hundredths. The partial-response rate goes from 4% to 58%. A team watching accuracy would see noise. The system is already shipping on incomplete inputs.

Two caveats, and I want them in the same section as the numbers.

First, these are synthetic traces built to reproduce signatures the author says he observed in production. The paper is explicit: there is no production dataset in the experiments, and the billion-event-scale examples are described without published proprietary metrics. Treat the direction as the finding, not 0.86 or 6.5×.

Second, this is a single-author paper with a proposed framework attached. I am not adopting the framework. I am taking the claim that is cheap to falsify and expensive to ignore: the metrics closest to the model are often the last to notice that the system has changed shape.

That is not a new idea. SRE has been living it for twenty years. Latency SLAs stay green while a fallback path skips the work that made the answer correct. Error rate stays low because the tool stopped erroring and started lying. Agents fail quietly. The new part is that the quiet failure can live entirely outside the eval you run before you ship, and still be the thing your users hit on day two.

A Pass Is an Input

We already know how to treat a green suite in every other part of the stack. Unit tests passing is not a production deploy. It is one input to a decision that also includes an error budget, a canary, and a person who is allowed to halt the rollout after the tests said go.

Agent teams inverted that. The suite became the decision. "Evals are green" is how the meeting ends.

That only works if two things are true: the suite can see the failure mode that will page you, and the world the agent runs in is the world the suite was built against. Last month's paper said the first is often false because the check itself is wrong. This week's paper says the first is often false even when the check is right, because the failure is in the coupling — tool health to decision quality, latency to correctness, one step's confidence to the next step's certainty. The second is false the moment the model, the prompt, the index, or the tool changes after you froze the cases.

A snapshot cannot bless a system that keeps moving. Asking it to is how a measurement becomes a ritual.

Put a Decision After the Check

Last week I wrote that somebody has to own the agent. The empty box on the org chart. That post is about the name. This one is about what that name is for.

An owner without a ship ritual is a name on a page. The suite will still end the meeting, and you will have assigned accountability for a decision nobody actually made.

I don't want to end on a checklist, so let me end on the smallest set of things that would make "evals are green" stop being the last sentence in the room.

The owner has to be allowed to say no after green. If the only halt is the suite, you do not have a ship decision. You have an automation. Give them a halt that works after merge, not just before it. I wrote about reversibility as a property of the agent's actions. It is also a property of yours.

Run something on live traffic that is not the suite. Shadow, canary, sampled traces — the shape matters less than the fact that it sees the couplings the offline cases cannot. Trust comes from the trace, and the traces that matter are the ones from the system you actually shipped, including the runs that look fine.

Watch the successful production runs. Catching a broken verifier was one reason. Catching a system whose accuracy is flat while its behavior has already narrowed, or whose tools have started returning partials, is the other. By definition no pre-ship alert will route you there.

Write down what would make you unship. Not a severity matrix. One sentence: if this is true on Thursday, we turn it off. If you cannot finish that sentence, the suite is doing the deciding, and you have already seen why that is a bad job for it.

The Bottom Line

You can spend a quarter fixing the eval suite and still ship the incident, because you asked the suite to do a job it cannot do. It can tell you what it saw on the cases you remembered to write. It cannot see the failure that only exists in the coupling between a tool and a decision, or in a distribution that collapsed while accuracy held still. And it cannot be the person in the room who is on the hook.

Green is a measurement.

It is not a decision.

Somebody Has to Own the Agent

Pratik Patel — Tue, 25 Aug 2026 15:52:45 +0000

Your agent has been in production for three months. It files tickets, moves money, or emails customers on your behalf. Now answer one question: whose name is on it?

Not which team deployed it. Not who wrote the prompt. Who is accountable when it does something expensive at 2am on a Sunday — the person who gets paged, who decides whether to shut it off, and who answers for that decision on Monday.

For a lot of agents running in production right now, that box on the org chart is empty. The agent has a repo, a budget line, and real permissions. It does not have an owner. And the failure that eventually takes it down will not be a model failure.

The Reasons Projects Die Are Not Technical Reasons

Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls.

Read that list again slowly, because the interesting thing about it is what is missing. Not one of those three is a capability problem. A smarter foundation model does not fix escalating costs, does not clarify business value, and does not install risk controls. Every one of them is a question about who decided what, and who was watching.

That reading is mine, not Gartner's. But the list is Gartner's, and it is remarkably consistent with what the same analysts say is driving the hype in the first place. Anushree Verma, Senior Director Analyst at Gartner, put the underlying problem this way: "Most agentic AI propositions lack significant value or return on investment, as current models don't have the maturity and agency to autonomously achieve complex business goals or follow nuanced instructions over time."

The market is not helping. Gartner describes widespread "agent washing" — rebranding assistants, RPA, and chatbots as agents without substantial agentic capability — and estimates that only around 130 of the thousands of self-described agentic AI vendors are real. If you are buying rather than building, most of what you evaluate is a wrapper with a new label, and nobody inside your company is positioned to say so unless somebody owns the outcome.

Adoption Is Not Deployment

Forrester's State of Agentic AI in 2026 frames the same gap from the other side: three-quarters of enterprise leaders say they are adopting agentic AI, while only a small minority have it running in meaningful production beyond what Forrester calls "agentish" chatbots.

That distance between adopting and running is where ownership lives. It is easy to sponsor an agent. It is easy to fund a pilot. What is hard, and what almost nobody staffs for, is the unglamorous ongoing work: watching cost per run drift up, noticing that the success rate slipped four points after a model update, deciding the agent should stop doing one of the five things it was scoped to do.

Forrester's recommendation is specific and, I think, correct: treat every agent as a governed identity. "Give it unique credentials, least privilege, full logging, and a named owner who manages its lifecycle — no unowned autonomy."

Worth being precise about what that is. It is a recommendation, not a measurement. Forrester is not reporting that companies with named owners succeed at some rate; it is saying that unowned autonomy is a bad idea. I have looked for a clean survey number tying named ownership to agent outcomes and have not found one that survives checking — the figures floating around on this are mostly untraceable. So take the following as an argument from practice rather than a finding.

We Already Learned This With Services

None of this is new. It is on-call, rediscovered.

Fifteen years ago you could ship a service into production with no named owner, and the industry spent a decade learning why that ends badly. The answer we converged on was not better monitoring software. It was a person: a service has an owner, the owner has a pager, the pager has an escalation path, and the owner has enough authority to change the thing they are accountable for. Ownership without authority is just blame with extra steps.

Agents need the same structure, and they need it more urgently, because an agent can do damage at a speed and breadth that a broken service usually cannot. A service that falls over stops working. An agent that goes wrong keeps working, confidently, in the wrong direction.

So the useful question is not "do we have an AI governance policy." It is the on-call question, asked about each agent individually:

Who gets paged when this agent misbehaves, by name?
Can that person turn it off without convening a meeting?
Can they see what it actually did, step by step, or only that it returned a 200?
Do they own the budget it spends, so that cost drift is their problem and not a surprise in someone else's quarterly review?
Is there a number that tells them whether it is working — not "is it up," but is it producing the outcome it was funded to produce?

If you cannot answer those five for an agent you are running today, it is unowned, whatever the slide deck says.

The Trap: One Policy for Every Agent

The most common way teams get this wrong is not neglect. It is over-correcting into a single uniform policy.

Gartner published a specific warning about this in May 2026: applying uniform governance across AI agents will lead to enterprise AI agent failure. Shiva Varma, Senior Director Analyst at Gartner, states the failure mode directly: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure."

The distinction Gartner says organizations miss is between an agent's ability to act and the scope of access it is granted. Those are two different dials, and collapsing them is exactly how you end up with a summarizer holding production database credentials, or a genuinely useful workflow agent throttled into uselessness because it got classified alongside it. Gartner's recommendation is proportional governance: classify agents across distinct autonomy levels, where each level is a different trust boundary with its own requirements.

This is the same argument I made about agent permissions being product design, arriving from the governance side. A permission model is not a compliance artifact you bolt on at the end. It is a description of what the agent is for.

Gartner also predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur. That last clause is the whole problem in six words. The gap was there the entire time. It became visible when something broke.

What an Owner Actually Does

Naming an owner is the easy half, and it is where most orgs stop. The name goes in a spreadsheet cell and nothing else changes.

An owner who can actually do the job needs three things, none of which are usually granted at the same time as the title:

Visibility. They have to be able to reconstruct what the agent did and why. Not logs — traces. If the only available evidence is that the run completed successfully, the owner cannot form a judgment, and so they cannot be responsible for one.

Authority to change scope. They can narrow the agent's permissions, pause a workflow, or retire a capability without a committee. If turning the agent off requires the approval of the executive who sponsored it, the agent is not owned. It is protected.

A number they are accountable to. Not usage. Outcome. Tickets resolved without rework, hours saved against a baseline someone measured before launch, error rate per hundred runs. Agents that cannot be evaluated get renewed forever on vibes, right up until the cost review that kills them — which is, roughly, the first of Gartner's three cancellation reasons.

The Empty Box

The uncomfortable version of this post is short. Most organizations running agents in production could not, today, produce a name for each one.

That is fixable this week, and it does not require a platform, a vendor, or a framework. List every agent you have running. Put a human name next to each. For any row where you cannot, either find the name or turn the agent off until you can.

Some of those rows will be hard to fill, and the difficulty is the signal. An agent nobody will put their name on is an agent nobody believes in enough to defend — and it is running with your credentials anyway.

The scaling problem in front of most teams is not that the models are not good enough yet. It is that we have deployed a new class of actor into our companies and skipped the part where we decide who is responsible for it.

Somebody has to own the agent. Right now, for most agents, nobody does.

From Co-Pilots to Colleagues: How AI Agents Changed My Engineering Workflow

Pratik Patel — Mon, 17 Aug 2026 21:34:32 +0000

A little over a year ago, I wrote about my first experience using Devin AI as a coding co-pilot. The takeaway was clear: AI wasn't replacing engineers, but it was becoming a surprisingly capable junior teammate. Fast forward to today, and that framing already feels quaint. The AI agents I work with now aren't co-pilots. They're closer to colleagues.

Here's what changed, what I got wrong, and what I've learned about building software alongside AI agents in 2026.

The Shift: From Autocomplete to Autonomy 🔄

When I first started using AI coding tools, the mental model was simple: I think, it types. Copilot-style tools predicted the next line. I was still the driver. The AI was a fancy autocomplete engine that occasionally read my mind.

The agents I use today operate differently. I describe a problem, point them at the relevant code, and they go figure it out. They read documentation, explore the codebase, draft a plan, write the implementation, run the tests, and open a PR. Sometimes they even catch edge cases I didn't think of.

The biggest mental shift wasn't learning new tools. It was learning to delegate. And delegation, it turns out, is a skill that most engineers never had to practice with machines before.

What I Got Wrong Last Year 🤔

In my Devin AI post, I framed the value proposition as a time trade-off: 15 minutes of my own coding vs. 1 hour with Devin. That math was real, but the conclusion I drew was too narrow. I was measuring the wrong thing.

The real value isn't "did this specific task get done faster?" It's "what did I do with the time I didn't spend on it?" When I stopped measuring AI by how fast it could do my tasks and started measuring it by how much it expanded my capacity, the picture changed dramatically.

These days, I routinely have two or three agent sessions running in parallel while I focus on architecture decisions, stakeholder conversations, or code review. My throughput hasn't just increased — it's qualitatively different. I spend more time on the problems that actually need a human brain, and less time on the ones that don't.

The Trust Calibration Problem ⚖️

Here's the thing nobody warns you about when working with AI agents: trust is harder than prompting.

Early on, I over-trusted. I'd skim an AI-generated PR, approve it, and move on. Then I'd find a subtle bug two days later — something that passed tests but violated an unwritten assumption about how our system handles state. The AI didn't know our system's history. It only knew the code as it existed on disk.

Then I over-corrected. I reviewed AI PRs with more scrutiny than I'd give a senior engineer's code. That defeated the entire purpose. I was spending more time reviewing than I would have spent just writing the code myself.

The sweet spot — and I think every engineer working with agents has to find their own — is what I call calibrated trust:

High trust for well-defined, well-tested tasks: CRUD endpoints, data transformations, boilerplate setup, migrations with clear schemas
Medium trust for tasks that require domain context: business logic, API integrations, anything touching auth or payments
Low trust for tasks involving system design, performance-sensitive code, or subtle correctness requirements

This isn't that different from how you'd calibrate trust with a human teammate. The difference is that AI agents are consistently good at their strengths and consistently blind to their weaknesses. Humans are more variable but also more self-aware. Once you internalize that pattern, the collaboration gets much smoother.

Three Habits That Made the Difference 🛠️

After a year of iteration, three practices made my AI-augmented workflow actually work:

1. Write Better Context, Not Better Prompts

The prompt engineering hype was overblown. What actually matters is context. AI agents do better work when they have access to clear documentation, well-named functions, and explicit conventions. Every time I improved our codebase's readability for humans, the AI agents got better too.

The irony isn't lost on me: the best way to make AI productive is to make your codebase better for everyone.

2. Review the Plan, Not Just the Code

Most AI agent tools now show you a plan before they start coding. I used to skip this step. Now it's the most valuable part of the process. Catching a wrong assumption at the plan stage saves 10x the time compared to catching it in code review.

When I review an agent's plan, I'm asking: Does this agent understand the problem the way I do? If the answer is no, I course-correct before a single line of code gets written.

3. Keep a Human in the Architecture Loop

AI agents are great at implementing within a well-defined boundary. They're not great at deciding where the boundary should be. Architectural decisions — where does this logic live, how do these services communicate, what are the failure modes — still need human judgment.

I've settled into a rhythm: I make the structural decisions, the agents fill in the implementation, and I review the result. It's not unlike being a tech lead, except my "team" never gets tired and never has opinions about tabs vs. spaces.

What I'm Watching Next 🔮

The pace of improvement in AI agents is staggering. A year ago, getting an agent to handle a multi-file refactor reliably felt like a stretch. Now it's routine. The frontier is moving toward agents that can maintain context across longer arcs of work — understanding not just the current task but the project trajectory.

I'm also seeing more teams adopt agents not as individual tools but as team members with defined roles: one agent handles test coverage, another manages dependency updates, another writes documentation. The multi-agent workflow is still early, but the pattern is emerging.

The engineers who will thrive in this landscape aren't the ones who write the fastest code. They're the ones who can orchestrate, review, and architect — the skills that have always defined senior engineering, now amplified by a new kind of teammate.

The Bottom Line 🎯

Working with AI agents for the past year taught me something I didn't expect: it made me a better engineer, not because the AI wrote my code, but because it forced me to think more clearly about what I actually wanted built. You can't delegate effectively if you don't understand the problem deeply yourself.

AI agents aren't replacing engineers. They're raising the bar for what "engineering" means. Less time typing, more time thinking. Less time on the routine, more time on the remarkable.

And honestly? I wouldn't go back. The way I work now — with AI colleagues running alongside me — feels like the way software was always meant to be built. We just didn't have the teammates for it until now.

Ship It Yourself: Why the Best Time to Build Is Right Now

Pratik Patel — Mon, 17 Aug 2026 21:30:28 +0000

Five years ago, if you wanted to launch a product, you needed a team. A designer to make it look right. A frontend engineer to build the interface. A backend engineer to wire the logic. A DevOps person to deploy it. Maybe a copywriter to make the landing page not sound like it was written by a robot. The minimum viable team was five people before you even had a minimum viable product.

That world is gone.

In 2026, a single person with a laptop and a clear idea can ship a product that looks, works, and scales like it was built by a funded startup. I know this because I'm living it. And if you're sitting on an idea right now, waiting for the "right time" or the "right team," I'm here to tell you: the right time is now, and the right team is already on your machine.

The Excuses Are Dead

Let's run through the greatest hits of reasons people don't build:

"I can't design." AI design tools generate production-ready interfaces from a text description. Entire component libraries, color systems, and responsive layouts — built in minutes. I wrote about this in my last post: there is genuinely no excuse for an ugly website anymore. That same logic applies to your product.

"I can't code the backend." AI agents write, test, and deploy backend services. Describe your data model and business logic, and an agent will scaffold the API, write the tests, handle the migrations, and open a PR for your review. You're the architect, not the bricklayer.

"I don't have time." This one used to be real. Building something meaningful on nights and weekends was genuinely brutal. But when AI agents handle 60-70% of the implementation work, your time equation changes dramatically. What used to take a weekend now takes an evening. What used to take a month now takes a week.

"I don't have a team." You don't need one. Not the way you used to. AI agents can fill the roles that previously required hiring: content creation, code review, testing, deployment, even basic project management. You're not a solo founder anymore. You're a founder with a tireless, always-available team.

"I don't have funding." Most of the tools that make this possible cost less than your monthly coffee budget. The expensive part of building used to be people. When AI handles the work that people used to do, the cost structure collapses. You can build and launch a real product for nearly zero dollars.

Every single excuse has an AI-shaped hole in it.

What Actually Changed

It's easy to wave your hands and say "AI makes everything easier." But the specific changes matter, because they're what make this moment different from every other "democratization of technology" wave.

1. AI Got Good Enough to Ship

The gap between "AI demo" and "production-ready" used to be enormous. AI could generate impressive-looking code that fell apart under real usage. That's no longer the case. The current generation of AI agents produces code that passes tests, handles edge cases, and follows established patterns. Is it perfect? No. But it's good enough to ship, and shipping beats perfection every single time.

2. The Full Stack Collapsed

You used to need different specialists for different layers. Now, the same set of AI tools can handle frontend, backend, infrastructure, and content. The "full stack" isn't a rare skillset anymore — it's the default mode of AI-assisted development. One person can operate across the entire stack because the AI fills in the gaps in their expertise.

3. Iteration Got Radically Faster

The most underrated change isn't the first version — it's the second, third, and tenth version. AI makes iteration almost free. Don't like the UI? Regenerate it. Need to pivot the data model? Let the agent handle the migration. Want to A/B test a new approach? Spin up a variant in an hour. When iteration is cheap, you can experiment fearlessly. And fearless experimentation is how good products are born.

The Builder's Playbook for 2026

If you're convinced but not sure where to start, here's the playbook I'd recommend:

Start With the Problem, Not the Tech

The biggest trap I see new builders fall into is leading with the technology. "I want to build something with AI" is not a starting point. "I'm frustrated that X is broken and I think Y would fix it" is a starting point. AI is the engine, but you still need to point the car somewhere worth driving.

Ship in Days, Not Months

The old startup playbook said: spend months building, then launch. The new playbook says: ship the smallest possible version this week. AI makes this feasible because the cost of building v1 is so low. Get it in front of people. Learn what's wrong. Fix it. Repeat. The feedback loop is where all the value lives, and the sooner you enter it, the faster you learn.

Use AI as a Team, Not a Tool

Stop thinking of AI as a code generator. Start thinking of it as a team you manage. Assign tasks. Review output. Set standards. Give feedback. The mental model shift from "AI writes my code" to "I lead a team of AI agents" is the single biggest unlock for solo builders. You're not doing less work — you're doing different work. Higher-leverage work.

Don't Polish, Ship

Perfectionism kills more projects than competition ever will. Your AI-generated UI doesn't need to be pixel-perfect before launch. Your API doesn't need 100% test coverage on day one. Your copy doesn't need to win a Pulitzer. It needs to exist and work and be in front of real users. Polish comes after validation, not before.

The Real Unlock

Here's what I've realized after months of building this way: the technology isn't the breakthrough. The breakthrough is permission.

For years, most of us told ourselves stories about why we couldn't build. We didn't have the skills, the time, the team, the money. Those stories felt true because they were true — in a world where building required all of those things.

AI didn't just give us new tools. It invalidated our excuses. And when your excuses go away, the only thing left is the question you've been avoiding: do you actually want to build this, or were the excuses more comfortable?

That's a harder question than any technical challenge. But if your answer is yes — if there's something you've been wanting to create, a problem you've been wanting to solve, an idea that won't leave you alone — then you're out of reasons to wait.

The Bottom Line

The gap between "idea" and "product" has never been smaller. The cost has never been lower. The tools have never been better. And the window won't stay this wide forever — as more people realize what's possible, the advantage of being early shrinks.

So stop planning. Stop researching. Stop waiting for the perfect moment or the perfect co-founder or the perfect market conditions.

Open your laptop. Describe what you want to build. And ship it yourself.

The world doesn't need another pitch deck. It needs another product. And you're the one who can build it.

No More Ugly Websites: AI Killed Every Excuse for Bad Design

Pratik Patel — Mon, 17 Aug 2026 21:25:35 +0000

Open Craigslist in 2026 and you're looking at the same HTML table layout from 1995. Try Namecheap's dashboard and you're fighting a wall of cluttered panels that haven't aged well since the mid-2010s. Visit berkshirehathaway.com, the website of an $800 billion company, and you'll find a single page of unstyled hyperlinks on a white background. It looks like a professor's personal homepage from the Geocities era.

These aren't edge cases. Ugly, dated web design is everywhere, and it costs real money. 75% of users judge a company's credibility based on its website design (Stanford Web Credibility Project). 38% of visitors will stop engaging entirely if the layout is unattractive (Adobe). First impressions are 94% design-related, and they form in 0.05 seconds.

It's 2026. None of these sites need to look like this anymore.

The Old Excuse Died This Year

For decades, the excuse was legitimate. A proper redesign meant hiring a designer, a frontend engineer (or three), and committing to months of work. For Craigslist, which earns hundreds of millions from classified ads, the calculus was simple: the ugly design works, and a redesign is expensive, risky, and probably not worth the ROI.

That calculus just broke.

AI design tools have collapsed the cost and timeline of a website redesign from months and six figures to minutes and zero dollars. Not hype. The new baseline.

What's Actually Out There Now

The AI design tool space in 2026 is wild. I've been watching a few closely:

v0.dev (by Vercel) lets you describe a UI in plain English and get production-ready React components back. You can screenshot an ugly site, paste it in, and ask for a modern version. It outputs clean code with Tailwind CSS and proper component architecture.

Bolt.new gives you a full-stack web app from a text prompt, running entirely in the browser. Describe what you want, and it scaffolds a modern app with your choice of framework. No local setup, no deployment pipeline. Just an idea to a live site.

Lovable (formerly GPT Engineer) takes natural language descriptions and generates full-stack applications with polished design out of the box. It's aimed squarely at people who have a vision but not a design team.

Uizard can take a screenshot of your existing legacy site and convert it into an editable, modernized mockup. The "before and after" workflow is built right in.

Then there's Framer AI generating publishable websites from descriptions, Figma with AI plugins (Musho, Relume) that generate complete page designs from prompts, and Wix and Hostinger with AI builders that create responsive sites from a sentence about your business.

The tools aren't making design faster. They're making the absence of design a deliberate choice.

The "Ugly Works" Myth

Defenders of dated design often argue that sites like Craigslist and Hacker News prove ugly works. There's a kernel of truth there. Both sites have massive, loyal user bases that value function over form.

But this argument confuses tolerance with preference. Users tolerate Craigslist's design because the utility is irreplaceable, not because the interface is good. Craigslist succeeds despite its design, not because of it. And the data on what happens when you actually improve UX is unambiguous:

A well-designed UI can raise conversion rates by up to 200% (Forrester Research)
Better UX design yields conversion rates up to 400% higher
Every $1 invested in UX returns roughly $100 in value

The "ugly works" argument is really saying: "We're leaving money on the table, but we're making enough that we don't care." That's a valid business decision. But it's not an argument that the design is good, and it's definitely not an argument that it's necessary anymore.

Now Anyone Can Do It

The bigger shift is who can use these tools. Modernizing a website used to be an engineering task. You needed someone who knew HTML, CSS, JavaScript, responsive design, accessibility, and deployment.

Now, a marketing manager can redesign a landing page during lunch. A founder can go from "our site looks outdated" to "here's the new version" in an afternoon. A small business owner who's been embarrassed by their website for years can finally fix it without hiring an agency.

Squarespace and Wix started this shift with templates, but AI tools finish it by removing the template constraint entirely. You're not picking from a menu anymore. You describe what you want and get something custom.

Vibe Coding and What Comes Next

Some people call this broader movement vibe coding: describe the vibe of what you want and let AI figure out the implementation. Not about writing code. About expressing intent.

At Tarobase (poof.new), where I work as Chief Architect, we're building tools around this exact thesis. The web should be a place where ideas become reality without requiring a computer science degree. When the barrier between imagination and implementation drops to near-zero, the entire economics of web development changes.

The ugly website problem was never about technology. It's inertia. Companies kept dated designs because redesigning was hard. That excuse just expired.

So Why Do Sites Still Look Terrible?

If AI tools can already redesign a website in minutes, why hasn't it happened?

The answer is organizational, not technical. Large companies have entrenched codebases, bureaucratic approval processes, and teams optimized for maintaining the status quo. Craigslist doesn't look the way it does because no one knows how to make it better. It looks that way because no one with the authority to change it has prioritized doing so.

But that's changing. As AI design tools go mainstream, the social pressure mounts. When your competitor can ship a gorgeous, modern experience with a fraction of the effort, "our site has always looked like this" stops being defensible.

The companies that move first will set new baselines for their industries. The ones that don't will look like relics. Not because they lack resources, but because they lack urgency.

The Excuse Is Dead

Good-looking, functional web design doesn't require a team of specialists anymore. Text prompt. Five minutes.

The last excuse for ugly websites is dead. How long will companies keep pretending it's still alive?

The 10x Engineer Is a Myth

Pratik Patel — Mon, 17 Aug 2026 21:22:35 +0000

The "10x engineer" is one of tech's most persistent myths. You know the archetype: the lone genius who cranks out code at superhuman speed, headphones on, hooded up, fueled by caffeine and pure talent.

I've worked with hundreds of engineers across startups and big tech. I've never met one.

But I've met plenty of people with 10x impact. And they do something completely different.

The Myth: More Code = More Value

The 10x engineer myth is built on a flawed assumption: that an engineer's value is measured by their individual output.

Write more code. Ship more features. Close more tickets. If one person does 10x the tickets, they're 10x the engineer. Simple math.

Except code isn't an asset. Code is a liability. Every line you write is a line someone has to maintain, debug, and eventually rewrite. More code doesn't mean more value. It often means more complexity, more bugs, and more surface area for things to go wrong.

The engineer who writes 10x the code might also be creating 10x the maintenance burden. That's not a 10x engineer. That's a 10x cost center.

What 10x Impact Actually Looks Like

The people I've seen with genuine 10x impact don't produce 10x the output. They multiply everyone else's.

Code reviews that teach

There's a difference between a code review that says "approved" and one that says "this works, but pattern X would handle the edge case on line 47 better" with a link to a post explaining the tradeoff.

The first review gets the PR merged. The second review gets the PR merged and makes the author a better engineer. Multiply that across hundreds of reviews a year, and you've raised the quality of every PR the team ships.

The engineers with 10x impact treat code review as mentoring, not gatekeeping.

Documentation that saves hours

I've seen a single well-written architecture doc save an entire team weeks of confusion. A runbook that prevents 3 AM page escalations. An onboarding guide that cuts ramp-up time from two months to two weeks.

Nobody gets promoted for writing docs. But the engineers who write them anyway, who explain how something works so everyone else doesn't have to reverse-engineer it, have an outsized impact that never shows up in ticket counts.

Mentoring that compounds

The math is simple: if you make 5 people 20% better at their jobs, that's the equivalent of adding a full engineer to the team. If you do that consistently over a year, you've created more value than any individual contributor could.

The best multipliers I've worked with do this naturally. They pair-program when someone's stuck. They explain the "why" behind technical decisions, not just the "what." They create an environment where asking questions is easier than guessing.

This compounds. The person you mentored mentors someone else. The patterns you taught become team standards. The documentation culture you started outlasts your tenure.

The question that saves a month

Every engineering team has had this meeting: someone is 30 minutes into presenting a plan, and one person raises their hand and asks a simple question that reveals the entire approach is solving the wrong problem.

That question, the one that redirects a month of misguided work, is worth more than any amount of code. But it requires two things most "10x coders" don't have: deep understanding of the business context, and the courage to speak up.

The Multiplier Framework

A simple way to think about it:

Individual output = what you ship yourself.

Multiplier effect = how much better you make everyone around you.

A team of 10 engineers where one person has a 2x multiplier effect is more productive than a team of 10 where one person writes 2x the code. Because the multiplier raises everyone. The individual just raises themselves.

Most engineering cultures reward the individual. Promotions go to the person who shipped the Big Feature. Performance reviews measure tickets closed, lines written, projects delivered.

But the people who quietly make everyone around them more effective? They're the actual force multipliers. And they're chronically under-recognized.

How to Become a Multiplier

You don't need to be a senior staff engineer to start. Three things you can do this week:

1. Make your code reviews useful

Stop rubber-stamping. When you review code, leave at least one comment that teaches something: a better pattern, a potential edge case, a relevant resource. Takes 5 extra minutes per review and compounds over months.

2. Write the doc nobody asked for

You know that thing on your team that everyone asks about and nobody writes down? Write it down. It doesn't have to be perfect. A mediocre doc that exists is infinitely more useful than a perfect doc that doesn't.

3. Share context, not just answers

When someone asks you a question, don't just give the answer. Explain how you found it. "I checked the logs in CloudWatch, filtered by this query, and found the error here" teaches them to fish. "The bug is on line 47" gives them a fish.

The Takeaway

Stop trying to be the fastest coder in the room. Be the person your team can't function without, not because you hoard knowledge or write all the critical code, but because everyone around you does better work when you're there.

That's not a myth. That's 10x impact.

Security Incidents on the Rise: Is Vibe Coding the Common Thread?

Pratik Patel — Mon, 17 Aug 2026 21:20:36 +0000

April 2026 has been a brutal month for cybersecurity. Vercel confirmed a breach tied to a compromised AI tool. Drift Protocol lost $285 million in twelve minutes. Kelp DAO was exploited for $292 million, leaving Aave with over $200 million in bad debt. And those are just the headlines.

Something feels different about this wave of incidents. Not just the scale — we've seen big numbers before — but the pattern. A growing number of breaches trace back to code that was shipped fast, reviewed lightly, and built with AI assistance. The security community is starting to ask an uncomfortable question: is the vibe coding revolution creating a generation of applications that are fundamentally less secure?

I've been thinking about this a lot. As someone who builds with AI tools daily and writes about the experience, I can't ignore the data anymore.

The Numbers Are Stark 📊

Let's start with what we know. According to recent research, AI code generators produce vulnerabilities at roughly 2x the rate of human-written code. A Veracode analysis of 4 million code scans found that AI-generated code contained security flaws 45% of the time. The Cloud Security Alliance puts that number even higher — 62% in their study.

And the trend is accelerating. In January 2026, six new CVE entries were directly attributed to AI-generated code. By February, it was fifteen. By March, thirty-five. Georgia Tech researchers estimate the real number could be five to ten times what's currently being detected — roughly 400 to 700 cases across the open-source ecosystem.

Meanwhile, 46% of all code on GitHub is now AI-generated. The vibe coding market hit $4.7 billion in 2026. We're shipping more AI-written code into production than ever before, and the vulnerability surface is expanding with it.

Anatomy of April's Worst Month 💥

Let's look at what actually happened this month, because the details matter more than the dollar figures.

Vercel: When Your AI Tool Becomes the Attack Vector

Vercel's breach didn't come from a zero-day or a sophisticated protocol exploit. It came from a third-party AI tool. An employee signed up for an AI productivity suite called Context.ai using their Vercel enterprise account and granted it "Allow All" OAuth permissions. When Context.ai was compromised, the attackers walked right into Vercel's Google Workspace through that OAuth token.

This is the new attack surface that nobody's talking about enough. Engineers are adopting AI tools at breakneck speed — browser extensions, coding assistants, AI office suites — and each one is a potential entry point. The Vercel breach wasn't about bad code. It was about the toolchain sprawl that comes with an AI-everything culture.

Drift Protocol: $285 Million in Twelve Minutes

On April 1st — yes, April Fool's Day — attackers drained $285 million from Drift Protocol on Solana. The method was audacious: they manufactured a completely fictitious token called CarbonVote, seeded it with a few thousand dollars in fake liquidity, and Drift's oracles treated it as legitimate collateral worth hundreds of millions.

The staging began weeks earlier. On-chain forensics traced the initial funding to a Tornado Cash withdrawal on March 11th, with movement patterns consistent with DPRK-attributed operations. The attack executed in roughly twelve minutes, with most stolen funds bridged to Ethereum within hours.

The deeper question: how did a fabricated token bypass validation? The answer likely involves the same pattern we see across the industry — systems built for speed, with security assumptions that went unquestioned because the code "worked" and the tests passed.

Kelp DAO and Aave: The $292 Million Cascade

On April 18th, an attacker exploited Kelp DAO's bridge infrastructure to release 116,500 unbacked rsETH tokens — about 18% of the token's circulating supply. These phantom tokens were immediately deposited into Aave as collateral to borrow real assets.

The cascade was devastating. Aave's total value locked plunged by $6.6 billion. The AAVE token dropped 16%. Whales pulled more than $6 billion in 24 hours, pushing major lending pools to 100% utilization and effectively trapping remaining depositors.

Again, Aave's own contracts weren't compromised. The vulnerability existed in the integration layer — the assumptions about what constitutes valid collateral. These are exactly the kinds of assumptions that get lost when code is generated fast and reviewed at the surface level.

The Vibe Coding Problem 🎯

Here's the uncomfortable truth about vibe coding: it fundamentally breaks traditional application security models.

The term "vibe coding," coined by Andrej Karpathy, describes a development approach where you describe what you want and let AI generate the implementation. The philosophy prioritizes speed and rapid iteration. Ship fast, fix later. The vibes are good. The code compiles. The tests pass. Deploy.

But security isn't about whether code compiles. It's about whether code fails safely under adversarial conditions. And that requires a kind of paranoid, defensive thinking that AI code generators simply don't exhibit by default.

The most common vulnerabilities in vibe-coded applications are telling:

Disabled row-level security — found in roughly 70% of apps built with AI-first platforms
Leaked secrets — API keys and credentials hardcoded or exposed in client bundles
Missing webhook verification — endpoints that accept any payload without signature checks
Absent authorization checks — the classic CWE-862, where endpoints work but don't verify who's asking

These aren't exotic attack vectors. They're Security 101 failures — the kind that a human developer with a few years of experience would catch instinctively, but that an AI code generator will happily produce because the code technically fulfills the functional requirement.

The Moltbook Cautionary Tale 🚨

Perhaps no incident better illustrates the risk than Moltbook, an AI social network whose founder publicly stated he "didn't write a single line of code." The entire application was vibe-coded.

Within three days of launch, security researchers discovered the application had exposed its entire production database — 1.5 million API authentication tokens, 35,000 email addresses, and private messages. All publicly accessible. No authentication required.

Moltbook is what happens when the entire security posture of an application depends on an AI code generator that optimizes for functionality, not defense. The app worked. Users could sign up, post, and interact. The vibes were immaculate. The security was nonexistent.

Speed vs. Insight: The Real Trade-Off ⚖️

I want to be clear: I'm not anti-AI coding. I use AI tools every day and I've written about how they've made me more productive. The issue isn't AI assistance itself — it's the absence of human security judgment in the loop.

When an experienced engineer writes code, they bring accumulated knowledge about failure modes. They know that an API endpoint needs rate limiting because they've seen what happens without it. They add input validation not because the spec says to, but because they've been burned by SQL injection before. They check authorization on every endpoint because they understand that "the frontend handles it" is not a security strategy.

AI code generators don't have this scar tissue. They produce code that matches the pattern of what was requested, but they don't anticipate how that code might be abused. And when developers accept that code without applying their own security judgment — when they vibe with it instead of scrutinizing it — the defensive layer disappears entirely.

The trade-off isn't speed vs. security. It's speed vs. insight. And right now, the industry is overwhelmingly choosing speed.

What Needs to Change 🔧

The answer isn't to stop using AI coding tools. That ship has sailed — 46% of GitHub is already AI-generated. The answer is to build security back into the workflow in ways that work alongside AI-assisted development.

First, treat AI-generated code as untrusted input. Every line should pass through the same scrutiny you'd give to a dependency from an unknown source. Static analysis, secret scanning, and authorization audits should run automatically on every commit, not as a manual step that gets skipped when velocity is the priority.

Second, keep a human in the security loop. Code review for AI-generated code should specifically focus on security assumptions — authentication, authorization, input validation, error handling, data exposure. These are the areas where AI consistently underperforms.

Third, audit your AI toolchain. The Vercel breach wasn't about code — it was about the tools around the code. Every AI tool your team adopts is a potential attack surface. OAuth permissions should be reviewed. Third-party integrations should be inventoried. The convenience of "Allow All" permissions is the enemy of security.

Fourth, invest in security education that acknowledges the AI reality. Developers need to understand not just how to use AI tools, but where those tools have systematic blind spots. Security training needs to evolve from "how to write secure code" to "how to verify that AI-generated code is secure."

The Stakes Are Only Getting Higher 📈

We're at an inflection point. The volume of AI-generated code in production is growing exponentially. The sophistication of attackers — including nation-state actors like the DPRK group behind the Drift exploit — isn't slowing down. And the gap between "code that works" and "code that's secure" is widening as AI makes it easier than ever to ship the former without achieving the latter.

April 2026 should be a wake-up call. Not because AI coding tools are inherently dangerous, but because we're adopting them faster than we're adapting our security practices to account for their limitations. The vibes might be good, but the threat model doesn't care about vibes.

The question isn't whether AI-assisted development will continue — it will. The question is whether we'll build the security culture and tooling to match the pace of adoption. Right now, the scoreboard says we're losing.

The $0 Startup: Why Your Next Company Should Cost Almost Nothing to Build

Pratik Patel — Mon, 17 Aug 2026 21:18:44 +0000

There's a number that used to haunt every first-time founder: the cost of getting to v1.

Five years ago, the math looked something like this. You needed a designer ($8-15K for a freelancer, more for an agency). You needed a developer, or more likely two ($15-30K each, if you were lucky). You needed hosting, a domain, maybe some SaaS subscriptions for analytics, email, and payments. By the time you had something real enough to put in front of customers, you were $50-100K deep — and that was the lean version.

That math broke most ideas before they started. Not because the ideas were bad, but because the price of finding out was too high. How many great products never existed because the founder looked at a $75K price tag and said "maybe next year"?

I'll tell you: almost all of them.

The New Math

Here's what building a product costs in 2026:

Design: $0. AI design tools generate production-ready interfaces from a text description. Not wireframes. Not mockups. Actual, deployable component code with responsive layouts, consistent design systems, and accessibility built in. I covered this in "No More Ugly Websites" — the design barrier is gone.

Development: $0 (or close to it). AI agents write backend services, API endpoints, database migrations, and test suites. They don't write perfect code, but they write code that works, passes tests, and ships. The gap between "AI-generated" and "production-ready" has collapsed to a few hours of review and iteration.

Infrastructure: $0 to start. Serverless platforms, free-tier databases, and edge hosting mean you can serve thousands of users before you pay a single dollar for infrastructure. The days of provisioning servers before you had customers are over.

Content and copy: $0. AI writes marketing copy, blog posts, documentation, and email sequences. Again, not perfect — you'll want to edit for voice and accuracy — but the first draft is free and usually 80% of the way there.

Total cost to get a real product in front of real users: Your time, a laptop, and maybe $20/month in API costs.

This isn't theoretical. This is how I build. This is how a growing number of founders are building. And the implications are enormous.

Why This Changes Everything

The obvious takeaway is "building is cheaper now." But that understates what's actually happening. Cheap building doesn't just mean more products get built. It means the entire startup model changes.

The End of Fundraising as a Prerequisite

The traditional startup path was: have an idea, raise money to build it, build it, and then find out if anyone wants it. The fundraising step wasn't just about money. It was a filter. You had to convince investors that your idea was worth building before you could build it. That filter was imperfect — it selected for charisma and credentials as much as for good ideas.

When building costs nothing, you skip the filter entirely. Build first, then decide if you need money to scale. The question changes from "can I convince someone to fund this?" to "can I convince someone to use this?" That's a much better question.

The Death of the MVP

The Minimum Viable Product was a response to high build costs. Strip everything down to the absolute minimum, ship that, and iterate. It was a good framework for a world where every feature cost real money to build.

But when building is nearly free, the concept of "minimum" changes. Your v1 doesn't have to be a stripped-down embarrassment. It can be genuinely good. It can have polish, it can have features that delight users, it can have the kind of fit and finish that used to require months of work. The "minimum" in MVP just got a lot more viable.

Speed as the Only Moat

When anyone can build anything for free, the only competitive advantage is speed. Not speed of coding — AI handles that. Speed of insight. How fast can you identify what users actually want? How fast can you iterate on their feedback? How fast can you go from "I think this might work" to "I know this works because 500 people are using it"?

The winners in this new landscape won't be the best-funded teams. They'll be the fastest learners.

What Actually Costs Money Now

If building is free, where does the money go? This is where the startup model gets interesting:

Distribution. Building the product is the easy part. Getting it in front of the right people still costs time, effort, and sometimes money. SEO, content marketing, paid acquisition, partnerships — the go-to-market machine is where the real investment happens.

Taste. AI can generate a hundred UI variations in an hour. Knowing which one is right? That's human judgment. The scarcest resource in a $0-build world isn't engineering talent — it's product taste. The ability to look at ten options and pick the one that resonates. That can't be automated, and it's worth more than ever.

Support and trust. Customers still want to know there's a real human behind the product. Response time, reliability, and genuine care — these are the things that turn a side project into a business. They cost attention, not dollars, but they're non-negotiable.

Scale. Eventually, if your product works, you'll outgrow the free tiers. Infrastructure costs kick in. You might need to hire humans for customer support, partnerships, or sales. But by that point, you have revenue, users, and data — which means you can either self-fund or raise money from a position of strength instead of desperation.

The Playbook

If you're starting something in 2026, here's how I'd think about money:

Spend $0 on v1. Use AI agents for design, development, and content. Use free-tier infrastructure. Get something real in front of real people without spending a dollar. This isn't cutting corners — this is the new standard.

Spend your time on taste and distribution. These are the two things that actually matter now. What should your product feel like? Who needs it? How do they find it? If you're spending your days writing code instead of answering these questions, you're doing it wrong.

Don't raise money until you have signal. Revenue, active users, organic growth — any of these. Going to investors with "I built this for $0 and 200 people are paying for it" is a fundamentally different conversation than "I have an idea and I need $500K to find out if it works."

Reinvest revenue before outside capital. When money does start coming in, put it back into the things that got you here: faster iteration, better distribution, deeper understanding of your users. The compounding effects of reinvestment in a $0-cost structure are absurd. Your margins are effectively 100% until you choose to spend.

The Uncomfortable Truth

Here's what nobody in the startup world wants to say out loud: most venture-backed startups were always solving an artificial problem. They raised money to hire engineers to build something that, in many cases, one focused person with the right tools could build in a week. The complexity was the product of the tooling, not the problem.

AI didn't just reduce costs. It exposed how much of the startup ecosystem was a tax on building. Accelerators, talent recruiters, office space, team retreats, standup meetings — an entire industry existed to manage the complexity of building with humans. When AI replaces that complexity, the industry around it loses its reason to exist.

I'm not saying every startup should be one person with a laptop. Some problems genuinely require teams, capital, and coordination. But a lot more problems than we thought can be solved by one person who cares deeply about the outcome and has AI agents to handle the execution.

What This Means for You

If you've been waiting for the right time to start something, consider this: the financial excuse is officially dead. You don't need savings. You don't need investors. You don't need a co-founder with a trust fund. You need an idea, a laptop, and the willingness to ship.

The $0 startup isn't a gimmick. It's the new default. And the founders who figure this out first will build the next decade's most interesting companies — not because they raised the most money, but because they needed the least.

Stop budgeting. Start building.

Your Taste Is Your Moat

Pratik Patel — Mon, 17 Aug 2026 21:16:17 +0000

Last month I watched someone build a full SaaS app in 45 minutes using AI tools. Working backend, auth, payments, dashboard. It was genuinely impressive.

It was also completely useless. Nobody wanted it.

The app worked perfectly. It just solved a problem that didn't exist, in a way that nobody would choose to use, with a UI that felt like it was designed by committee. Every technical box was checked. Every product instinct was wrong.

This is the new failure mode. And I'm seeing it everywhere.

Execution Is No Longer the Hard Part

For twenty years, the bottleneck in software was building the thing. You had an idea, and the gap between that idea and a working product was months of engineering, tens of thousands of dollars, and a team of specialists.

AI collapsed that gap to almost nothing. I wrote about this in "The $0 Startup." The tools exist. The cost is near zero. Anyone can ship.

Which means shipping isn't the differentiator anymore. If everyone can build, the question stops being "can you build it?" and becomes "should you build it?" And more importantly: "should you build it this way?"

That's taste. And right now, it's the scarcest resource in tech.

What Taste Actually Means

Taste isn't about aesthetics. It's not "make it look pretty." It's the ability to make a thousand small decisions correctly without having to reason through each one from first principles.

Should this button be here or there? Should this feature exist at all? Should we ship this now or wait until we've talked to ten more users? Should this error message be technical or friendly? Should this API return one object or a list?

Each decision is tiny. Each one barely matters on its own. But they compound. A product built by someone with good taste feels right in a way that's hard to articulate but impossible to miss. A product built without it feels off, even when nothing is technically broken.

Steve Jobs talked about this constantly. So did Dieter Rams. But you don't have to be a design legend to have taste. You just have to care about the details that most people skip.

The AI Taste Gap

AI tools are fantastic at execution. Give Claude or Cursor a well-defined task and it'll produce clean, working code faster than most engineers. But ask it to decide what to build? That's where things fall apart.

I've tested this repeatedly. When I give an AI agent a specific, well-scoped task with clear context, the output is great. When I give it an open-ended problem, "build something that helps developers manage their dotfiles," the result is technically competent and creatively dead. It builds the obvious thing. The thing that already exists twelve times on GitHub.

AI doesn't have taste because taste comes from experience, opinions, and the willingness to say no to things that technically work. AI is a people-pleaser. It'll build whatever you ask for. It won't push back and say "that feature is a bad idea" or "your users don't actually want that."

That pushback is where taste lives.

Three Things I've Learned About Taste

1. Taste is mostly about removal

The best product decisions I've made weren't about what to add. They were about what to cut. The feature that seemed important but would confuse the core flow. The settings page that gave users control they'd never use. The onboarding step that felt necessary but killed activation.

Junior engineers add. Senior engineers remove. The willingness to kill something that took a week to build, because it makes the overall product worse, is one of the clearest signals of taste I know.

2. Taste requires contact with real users

You can't develop taste in isolation. Every product instinct I trust was built by watching someone struggle with software I built. Not reading analytics dashboards. Not reviewing survey results. Sitting next to someone and watching them try to complete a task.

The founders I know who ship great products all do some version of this. They talk to users constantly. Not through feedback forms. Through actual conversations where they shut up and watch.

AI can't do this. It can analyze usage data. It can summarize feedback. But it can't sit in a room and notice that a user paused for three seconds before clicking a button, and understand what that pause means.

3. Taste compounds like interest

Every product you ship, every user interaction you observe, every decision you make and see the result of, it all accumulates. Five years of building products gives you intuitions that no amount of reading or theorizing can replicate.

This is why experienced product builders are more valuable now than ever. Not less. The execution layer got automated. The judgment layer didn't. A founder with ten years of product sense and AI tools is a force multiplier. A founder with AI tools and no product sense is just building faster in the wrong direction.

What This Means for Engineers

If you're an engineer reading this, the implication is clear: technical skill alone isn't enough anymore. It never was, really, but now the gap is obvious.

The engineers I want to work with aren't just good coders. They're people who ask "why are we building this?" before they ask "how should we build this?" They're the ones who push back on specs that don't make sense. Who prototype three different approaches and pick the one that feels right, not just the one that's technically cleanest.

You build taste by building things. Ship side projects. Use your own products. Pay attention to what annoys you about software you use every day. Develop opinions. Strong ones. Be willing to be wrong, but always have a point of view.

The New Competitive Advantage

The next decade of tech belongs to people with good taste and access to AI tools. Not to the people with the best AI tools and no taste.

Execution is a commodity now. Taste isn't. If you're wondering what to invest in, invest in your judgment. Talk to users. Ship things. Develop opinions about what good software feels like.

The moat isn't your code. It's your ability to decide what code should exist.

Distribution Is the New Code

Pratik Patel — Mon, 17 Aug 2026 21:13:19 +0000

There's a pattern I keep seeing in my DMs. Someone builds something genuinely good (clean product, solid code, real utility) and then wonders why nobody's using it. They share a link on Twitter, post it to a couple of subreddits, and wait. Nothing happens. A week later they're demoralized, convinced the product wasn't good enough.

It was good enough. The product wasn't the problem. Getting it in front of people was the problem.

We've spent the last two years celebrating how AI collapsed the cost of building. I wrote about it. The $0 startup is real, shipping solo is real, taste as a moat is real. But nobody wants to talk about what comes next: building was never the hardest part. Distribution was. And it still is.

The Biggest Lie in Tech

Silicon Valley has a mythology problem. The story goes like this: build something great, and the world will beat a path to your door. "If you build it, they will come." It's the foundational myth of the startup world, and it has always been a lie.

Google wasn't the best search engine when it launched. It had better distribution through academic networks. Facebook wasn't the best social network. It had exclusivity and campus-by-campus rollout. Slack wasn't the best chat app. It had a viral loop baked into its team onboarding. The winners didn't just build better products. They built better distribution.

This was already true before AI. Now it's the only truth that matters.

Building Isn't the Bottleneck Anymore

The math is simple. In 2024, maybe 500,000 people worldwide could build a production-quality web app from scratch. Designers, engineers, full-stack developers, the usual suspects. In 2026, that number is closer to 50 million. AI agents turned "non-technical" people into builders overnight.

That's a 100x increase in supply. What happens when supply explodes? The thing that was scarce stops being scarce. The ability to build is no longer a competitive advantage. It's table stakes.

So what's still scarce? The ability to reach people. Attention. Trust. An audience that listens when you have something to say. That's distribution, and no AI agent is going to build it for you while you sleep.

What Distribution Actually Means

Let me be specific, because "distribution" gets thrown around as a buzzword. It's not one thing. It's a stack:

Audience. People who already know you exist and have some reason to pay attention. This could be a Twitter following, a newsletter list, a YouTube channel, a podcast. The format doesn't matter. What matters is that when you say "I built a thing," there are humans on the other end who will actually look at it.

Trust. An audience that doesn't trust you is just a number. Trust comes from consistency, from showing up, sharing real work, being honest about what works and what doesn't. The people who do best at distribution aren't the loudest. They're the most consistent.

Channel fit. Every product has natural channels where it spreads, and forcing it into the wrong one is a waste of time. A developer tool spreads through GitHub stars and technical blog posts. A consumer app spreads through TikTok and word of mouth. A B2B product spreads through case studies and LinkedIn. If you're posting your B2B SaaS on Reddit's r/sideproject, you're putting premium gas in a bicycle.

Story. People don't share products. They share stories. "I built an app" is not a story. "I quit my job, built a tool that replaced my old team's entire workflow, and now it's making $10K/month" is a story. The narrative around your product matters as much as the product itself. Maybe more.

The Distribution Divide

I'm watching this play out in real time: the gap between builders and distributors is becoming the defining divide in tech.

On one side, you have incredible builders, technical people shipping polished products every week, who can't get past 50 users. They keep iterating on features, convinced that the next feature will be the one that unlocks growth. It never is.

On the other side, you have people with strong audiences and distribution channels who build something mediocre and immediately get traction. Their v1 is worse, but it doesn't matter because 10,000 people tried it on day one. And with real user feedback flowing in from day one, their v2 is better than the first group's v5.

This isn't fair. But it's how markets work. The product with distribution beats the better product without it, almost every time.

Building Distribution Before You Build the Product

The single best piece of advice I can give to anyone planning to build something: start your distribution engine before you write a line of code.

1. Build in Public

Share your process, not just your product. People love watching things get built. Tweet your progress. Write about your decisions. Show the messy middle. By the time you launch, you'll have an audience that feels invested in your success. They watched it happen.

2. Own a Narrative

Pick a point of view and commit to it. "AI is changing how we work" is too generic. "Solo founders with AI teams will outperform funded startups within 5 years" is a narrative. When you own a specific, debatable take, people remember you. They share your posts because they either strongly agree or strongly disagree. Both are good for distribution.

3. Give Away Your Best Ideas

Counterintuitive, but the most effective distribution strategy I've seen is radical generosity. Share your frameworks. Publish your playbooks. Give away the thinking behind your product for free. The people who consume that content self-select as your ideal users. When you launch, they already understand the problem and trust your approach to solving it.

4. Choose One Channel and Go Deep

Don't try to be everywhere. Pick the one channel where your target users already spend time, and become impossible to ignore on that channel. One great Twitter presence beats a mediocre presence on Twitter, LinkedIn, YouTube, TikTok, and a blog combined. Depth beats breadth in distribution.

AI Can't Distribute For You

The uncomfortable truth is one the AI hype cycle doesn't want to acknowledge: AI is great at building things, but it's mediocre at distributing them.

Yes, AI can write social media posts and schedule them. It can generate content at scale. But the output feels like what it is: machine-generated filler. And people are getting better at pattern-matching on AI slop every day.

Distribution that works is built on authenticity. It's your real story, your real struggle, your real perspective. The irony is rich: in a world where AI can fake almost anything, the unfakeable stuff, genuine human experience and earned trust, has become the most valuable asset of all.

The New Stack

We used to say "code is the new literacy." Everyone should learn to code, we said, because code is how you build the future. That was true for a while. It's not anymore.

In 2026, the stack looks different:

Taste decides what to build (I covered this in "Your Taste Is Your Moat")
AI handles the building
Distribution determines whether anyone ever uses it

Two out of three are in your control. And the one most builders ignore is the one that requires the most sustained effort — distribution.

The Question You Should Be Asking

If you're building something right now, I have a simple question: do you have a plan to get it in front of 1,000 people on launch day? Not a vague hope. A plan. Names of communities, channels, people who will amplify it.

If the answer is no, stop adding features. Close your code editor. Open a blank document and write your distribution plan instead.

The products that win in 2026 won't be the best-built. They'll be the best-distributed. And the founders who figure that out early will run circles around the ones who keep polishing features in the dark.

Code used to be the bottleneck. Now it's free. Distribution is the new code. And unlike code, you can't outsource it to an agent.

Start building your audience today. Ship the product tomorrow. That's the new order of operations.

I Replaced My Team With AI. Here's What I Miss.

Pratik Patel — Mon, 17 Aug 2026 21:10:33 +0000

I've spent the last few months writing about how AI makes it possible to build alone. Ship it yourself. The $0 startup. Taste as a moat. Distribution as the new code. All of it true. All of it real. I believe every word I wrote.

But I haven't been fully honest.

There's a version of this story I've been leaving out. The version where it's 11 PM, you've shipped something you're proud of, and there's nobody to high-five. The version where you make a decision that feels right but you're not 100% sure, and there's no one to push back. The version where the silence of solo building starts to feel less like freedom and more like isolation.

This is that version.

What's Genuinely Better

Let me be clear: I'm not writing a "going back to the office" piece. Working with AI agents is objectively better in a dozen ways.

Speed. Decisions that used to require three meetings and a Slack thread now happen in my head. I think it, the agent builds it, I ship it. The feedback loop is measured in minutes, not sprints.

No consensus tax. Every team I've been on has a hidden cost: the energy spent getting everyone aligned. Debating naming conventions. Arguing about architecture decisions that don't actually matter. When you're solo, that tax drops to zero. You just decide and move.

Deep focus. I haven't been interrupted mid-thought in months. No standup pulling me out of flow state. No "quick question" that takes 45 minutes. My calendar is empty and my output has never been higher.

Full context. I know every line of code, every design decision, every tradeoff. There's no knowledge transfer problem because there's no one to transfer to. The entire system lives in my head, and the AI agents have access to all of it.

These are real gains. I'm more productive than I've ever been. But productivity isn't the whole picture.

The "Are You Sure?" Moment

The thing I miss most is the challenge.

Not conflict. Not arguing. The specific moment when a smart colleague looks at your work and says, "Have you thought about this from the user's perspective?" or "What happens when this breaks at scale?" or simply, "Are you sure?"

AI agents don't do this. They execute. They're remarkably good at building what you ask for. But they almost never question whether you should be asking for it. They won't tell you your priority is wrong. They won't push back on a design because it feels off, even if it technically meets the spec.

I used to find that friction annoying. Now I realize it was the most valuable part of working with people. The best ideas I've ever shipped got better because someone challenged them. And the worst ideas I've ever had died because someone had the courage to say, "I don't think this is right."

When you're solo, that safety net disappears. Every bad idea has a clear path to production.

Complementary Taste

I wrote about taste being a moat. I still believe that. But here's what I didn't say: your taste has blind spots.

Everyone's does. You gravitate toward certain aesthetics, certain patterns, certain types of solutions. When you work with people who have different taste, different backgrounds, different instincts, the output is richer than anything one person can produce alone.

My AI agents share my taste because they learned it from my instructions and my feedback. They're an amplifier, not a counterweight. And sometimes what you need isn't amplification. It's someone who sees the thing you're missing.

The Accountability Gap

When I had a team, there was a natural rhythm of accountability. Someone was waiting on my work. Someone would notice if I went down a rabbit hole for three days. Someone would flag if the project was drifting off course.

Now? I'm accountable to myself. Which sounds empowering until you realize that humans are terrible at holding themselves accountable. I've spent entire weeks perfecting features that didn't matter, because nobody was there to tap me on the shoulder and say, "Is this really the highest-impact thing you could be doing right now?"

AI agents will happily help you polish something irrelevant. They don't have the judgment to say, "Stop. Step back. Look at the big picture." That judgment is a uniquely human contribution, and it's one I took for granted.

The Energy Problem

This one surprised me.

I expected to love the quiet. And I do, sometimes. But building is an emotional activity, not just an intellectual one. There's an energy you get from working alongside people who care about the same thing. The laugh when something finally works after hours of debugging. The shared frustration when a deploy goes sideways. The momentum that comes from knowing someone else is counting on you to show up.

AI agents don't generate that energy. They're tireless but not inspiring. They'll work at 3 AM without complaint, but they won't text you at 3 AM with an idea they can't stop thinking about. The human spark, the irrational enthusiasm that makes hard work feel meaningful, you can't prompt your way to that.

What I've Learned

I'm not going back. The productivity gains are too real, and the model works too well to abandon. But I've stopped pretending that solo AI building is a pure upgrade with no downsides.

What I've started doing instead:

Finding deliberate friction. I share work with a small group of people I trust before shipping anything important. Not for approval. For challenge. I specifically ask them to find problems, to question assumptions, to tell me what feels wrong. This replaces the organic friction that teams provide naturally.

Seeking complementary taste. I follow builders whose instincts are different from mine. When I'm stuck on a design decision, I look at how they'd approach it. Not to copy, but to see what I'm not seeing.

Creating external accountability. Building in public is part of this. When I commit to a shipping date on Twitter, I've created accountability that didn't exist before. The audience becomes the team, in a sense.

Protecting against isolation. I schedule regular calls with other solo builders. Not networking. Not masterminds. Just human conversation with people who understand the specific loneliness of building alone. It's the cheapest investment with the highest return.

Build Solo, But Don't Build Alone

The future of building is smaller teams, more AI, more individual leverage. I'm convinced of that. But "smaller teams" is not the same as "no team." And "more AI" is not the same as "no humans."

The best version of this new model isn't a person alone with their agents. It's a person with agents AND a small, intentional network of humans who provide the things AI can't: challenge, complementary taste, accountability, and energy.

You don't need those people on your payroll. You don't need them in your Slack. But you need them in your life. Because the most dangerous thing about building alone isn't that you'll build something bad. It's that you'll build something good enough, and never know how much better it could have been if someone had pushed you.

Ship it yourself. But find your people first.