DEV Community: Pratik Patel

Your Stack Is a Team, Not a Subscription

Pratik Patel — Tue, 29 Sep 2026 12:57:59 +0000

I paid for five AI subscriptions last month and still lost a day to the same bug twice.

Not because the models were dumb. Because Claude Max had half the diagnosis, ChatGPT Pro had a cleaner rewrite of the plan, Cursor had a half-applied patch, SuperGrok had a sharp objection I never pasted back, and Antigravity had a UI walk that contradicted all of them. Five competent opinions. Zero owner of the seam between them. I closed the laptop with more tabs than when I opened it.

The usual story is that you need a better model, or a bigger plan tier, or one more tool that "ties it all together." The inversion is quieter. Your stack is not a shopping cart. It is a team. Subscriptions without roles just multiply tabs. A paid stack is not leverage until each tool has a job, a handoff, and a named owner for the handoff.

This is the second post in Ship With Agents. The first was about letting an agent run for days without becoming a liability. This one is about the division of labor across the tools you already pay for.

Five Tabs Is Not Five Roles

Open your browser right now and count the AI surfaces you treat as interchangeable.

Claude Max for long reasoning. ChatGPT Pro for another pass. SuperGrok when you want a harder pushback. Cursor when you want the repo in the loop. Antigravity when you want a browser-native agent to walk the product. That list is mine. Yours will rhyme. The point is not the logos. The point is that most people use them as five versions of the same chat window.

A team is not five people who can all "help with the thing." A team is five people who know what they own, what they hand off, and who gets paged when the handoff is wrong. If every tool can do everything, none of them is accountable for anything. You end up with parallel drafts of the same plan, each quietly overwriting the last in your head.

I used to treat model-hopping as taste. It felt like diligence: get a second opinion, then a third. What it actually was, most days, was refusing to decide which surface owned the current phase of the work. Diligence without a contract is just context thrash with a receipt.

A Role Is a Job Plus a Handoff

The mechanism is simple enough to write on a sticky note. For each tool you keep paying for, fill three lines:

Job. What phase of work this tool is allowed to own (plan, critique, implement, walk UI, overnight loop).
Handoff. What artifact it must leave for the next role (structured brief, diff against a branch, repro steps with evidence, unresolved list).
Owner. Who is on the hook if that handoff is garbage (usually you, sometimes a named agent run with a kill switch).

That is the whole operating model. Not a vendor matrix. Not a feature comparison. A job, a seam, a name.

When I say handoff, I mean a contract, not a vibe. The receiving surface should not have to reconstruct intent from a screenshot of a chat. Pass structure: goal, constraints, blast radius, current hypothesis, what was already ruled out, and what "done" means in the product. If you cannot paste that into the next tab in under a minute, you do not have a handoff. You have a mood.

Bounded, reversible, inspectable still applies. The role card should say what the tool may write, what it may only read, and how you reverse a bad afternoon. Overnight loops belong to the tool that can keep a trail (see the first post in this series). Critique belongs to the tool you trust to be rude. Implementation belongs to the surface that can see the repo and open a PR you can revert.

The unglamorous part: you will demote tools. Some subscriptions stop being teammates and become occasional consultants. That is healthy. A team with six "full stack" generalists and no owners is how you get five half-finished approaches and a demo that never becomes prod.

My Stack as a Roster (Not a Review)

Here is how I currently assign the tools I actually pay for. This is a roster, not a product endorsement. The names will change. The shape should not.

Claude Max: long-horizon planning and overnight loops. It owns the multi-hour or multi-day goal when the work needs a durable trail: reproduce, trace, fix, verify. It does not own the final taste pass on copy, and it does not own "argue with me until I feel smart." Job is persistence with a stop condition. Handoff is a log someone can audit plus a PR-shaped change, not a novel.

ChatGPT Pro: structured briefs and second-pass compression. It owns turning a messy problem into a contract the next tool can execute: constraints, acceptance checks, unresolved questions. It is also where I send a bloated plan to get cut. Handoff is a short schema-ish brief, not another essay.

SuperGrok: adversarial review. It owns the "what am I missing" seat. I feed it the brief and the proposed approach and ask it to find the hole, the overclaim, the blast radius I waved away. Handoff is a punch list of risks and falsifiers. If it starts rewriting the feature, I pulled it out of its lane.

Cursor: repo-local implementation. It owns the change in the codebase: branch, diff, tests, the PR I can revert. Handoff into Cursor is the brief plus the constraints. Handoff out is a PR with a stop condition you can verify, not a chat summary that says "should work."

Antigravity: product-path walking. It owns entering the real UI (or the staging twin), reproducing, and bringing back evidence. Screenshots, trace ids, failing-then-passing paths. Handoff is evidence, not a status sentence. If the walker cannot fail the old repro after the fix, the implementer is not done.

Notice what is missing from that roster: a tool whose job is "be open in case I need it." If a subscription has no job, it is not on the team. It is inventory.

A Worked Afternoon: One Bug, Five Seats, One Owner

Here is a concrete run shaped like a real day, not a stage demo.

The bug: a settings save looks fine in the happy path, then quietly drops one field after a refresh. Classic. Easy to talk about. Easy to "fix" in the wrong layer.

I start in ChatGPT Pro with a five-minute brief, not a therapy session. Goal: preserve field X across save and reload on staging. Blast radius: staging only, test user, no prod writes. Stop condition: scripted reload shows X still present, plus a regression note for the empty-field case. Unresolved: whether the drop is client state, API omit, or a cache header. That brief is the contract.

SuperGrok gets the brief and the current hypothesis ("client state"). It comes back with three punches: check the PATCH payload, check whether empty string is treated as omit, check whether a second tab races the write. I do not ask it to rewrite the app. I ask it to make the next role harder to fool.

Claude Max (or a long Cursor agent session, depending on the week) owns the loop: reproduce on the path, trace, smallest reversible fix, verify on the same path. The trail has to survive a tab crash. If it cannot, I am not ready to walk away.

Antigravity walks the UI with the same repro script the brief named. It returns evidence. Not "looks good." A before/after on the reload, and a note if the empty-field case still fails.

Cursor (when the long loop was outside it) lands the PR: small diff, test or scripted check attached, revert path obvious. I am the owner of the seam between every hop. If SuperGrok's punch list never reached the implementer, that is my failure, not the model's. If Antigravity verified a different flow than the one Claude fixed, that is my failure at the contract.

The day works when each seat does one job and the artifacts move. The day fails when I paste the same vague prompt into five tabs and pick the answer that flatters me.

Ownership Does Not Travel With the Receipt

Paying for Claude Max does not make Anthropic on-call for your bad handoff. Paying for Cursor does not make the IDE responsible for the fact that you never wrote a stop condition. Parallel tabs do not dilute ownership. They multiply the places where a quiet failure can hide.

This is the same lesson as naming an owner for an agent in production, applied one layer up to the human workflow. Someone has to care whether the brief that left ChatGPT still matches the PR that left Cursor. Someone has to notice when Antigravity is verifying a demo path while prod still breaks. That someone is you until you design otherwise.

Blast radius compounds across an unowned stack. One tool with write access is a risk you can name. Five tools with overlapping write access and no handoff log is how you get a "fix" that touched billing copy, a flaky test, and a config flag nobody can explain on Monday.

The next posts in this series pick up adjacent seams: checking in from a phone without pretending the phone is a full IDE, picking models for jobs instead of vibes, and what happens when parallel agents need ownership too. The through-line does not change. Tools are cheap. Contracts are the work.

Cut Until the Roles Are Obvious

If you cannot explain your stack as a roster in one minute, you have too many generalists and not enough jobs.

Cut the subscription that only exists so you do not feel locked in. Merge the two tools that always produce the same kind of artifact. Promote the one surface that actually leaves inspectable trails. Write the sticky notes. Enforce them when you are tired, which is when you will want to paste the same prompt everywhere.

You do not need a perfect org chart for your AI tools. You need fewer tabs with clearer seams. Demo energy is five models agreeing in parallel. Prod energy is one owner, one contract, and a handoff you can reverse.

The Bottom Line

A paid stack is inventory until each tool has a job, a handoff, and an owner.

Subscriptions buy access. Roles buy leverage. Tabs without contracts buy noise.

Let It Run for Days

Pratik Patel — Tue, 22 Sep 2026 13:12:29 +0000

I left an agent on a UI bug for three days.

Not a unit test. Not a greenfield feature. A real flow: sign in, hit the broken screen, reproduce, read the trace, propose a fix, open a PR, watch CI, adjust, try again. When I checked back, it had burned through a stack of dead ends, kept a running log of what it tried, and was still inside the product. That is a different category of work than "write me a function."

Most people treat agents as chat with a deadline measured in minutes. The interesting shift is goals measured in days: walk the UX, chase the failure, leave a trail someone can audit. The inversion is simple. Letting it run is not the hard part. Making the run bounded, reversible, and inspectable is.

This is the first post in Ship With Agents: how I actually build with the stack, not how demos look on stage.

A Day-Long Goal Is a Product, Not a Prompt

If you paste "fix the onboarding flow" into a chat window and walk away, you did not create a multi-day agent. You created an unsupervised intern with your credentials.

A day-long goal needs the same artifacts you would demand from a human owner:

A stop condition. What does done mean in the product, not in the model's self-report? "CI green on this PR and the repro steps fail to reproduce" beats "looks fixed."
A blast radius. Which accounts, which environments, which write actions are allowed? A UI walker that can click "Delete project" in prod is not ambitious. It is a pager waiting to happen.
A log that survives the session. Tokens expire. Tabs crash. Context windows fill. The run only counts if the next morning you can read what it tried without reconstructing from vibes.

The prompt is the pitch. The product is the harness around it.

The Loop Is Reproduce, Trace, Fix, Verify

The shape that actually works for multi-day UI work is boring on purpose:

Reproduce the failure in a real browser path (or a recorded flow), not from a description of the failure.
Trace with whatever you already trust: network, console, server logs, session replay, agent tool traces.
Fix in the smallest reversible change that could prove the theory.
Verify by running the same path again, preferably with the same scripted steps.

Repeat until the stop condition trips or the budget trips.

Chat-only agents collapse this into a single narrative: they summarize, they sound confident, they skip the verify step. Long-running agents that ship are the ones that treat verify as a gate, not a vibe check. If it cannot re-enter the UI and fail the old repro, it is not done. It is drafting.

I use different tools for different parts of that loop (planning vs UI vs long refactor), but the loop itself does not care which logo is on the tab. The contract does.

What You Must Own Before You Walk Away

Here is the unglamorous checklist I will not skip. It is shorter than a process doc on purpose. If you cannot hold it in your head, you will not enforce it when you are tired.

Named owner. Someone (usually me) is on the hook if the agent opens the wrong PR, burns the wrong quota, or "fixes" the wrong symptom. Parallel tabs do not dilute ownership. They multiply it. (That gets its own post later in this series.)

Environment seams. Staging vs prod. Test user vs real customer. Read-only explore vs write-enabled fix. The agent should not discover those seams by accident at 2am.

Budget. Time, dollars, and tool calls. A three-day run without a spend cap is a blank check. Caps are not pessimism. They are how you sleep.

Handoff format. When you return, you should get: repro steps, hypothesis history, current diff, what was ruled out, and the next action. If the agent can only say "still working," you built a status light, not a teammate.

Kill switch. One obvious way to stop writes, revoke the session, and leave the repo in a recoverable state. If you cannot describe the kill switch in one sentence, you are not ready to leave it running.

None of this is romantic. All of it is the difference between a demo and prod.

Days Are Where Quiet Failures Show Up

Short agent sessions hide the failure modes that matter in production systems.

Context rot: by hour six the model is optimizing for the story it already told, not the UI in front of it. A good harness forces fresh repro evidence into the loop on a schedule, not only when the agent feels stuck.

False fixes: the agent "solves" a symptom by changing a copy string, widening a try/catch, or deleting a flaky assertion. Verify-on-the-real-path catches that. Summaries do not.

Scope creep: a three-day goal becomes a rewrite because nothing told it the blast radius. Bounded tickets beat epic novels.

Tool thrash: hopping models mid-run without a handoff note loses the trail. Use the stack as a team (Claude Max, ChatGPT Pro, SuperGrok, Cursor, Antigravity, whatever you actually pay for), but make the handoff inspectable. The next post in this series is about that division of labor. This one is about the clock.

The longer the run, the more the system needs traces, not vibes. If you would not ship a human's three-day effort without a work log, do not ship an agent's.

I have also started treating "overnight" as a deliberate mode, not a side effect. Before bed I ask: can this agent still prove progress with a fresh repro if the chat dies? If the answer is no, the night run is theater. If the answer is yes, I am buying wall-clock time against a defined ticket, which is the whole point.

Screenshots Beat Status Sentences

When the agent claims the flow works, I want evidence from the path, not a paragraph. A screenshot of the unbroken screen, a trace id, a failing-then-passing repro script: those are the currency. Status sentences are cheap. The longer the run, the more you should distrust cheap proof.

This is also why mobile check-ins help (more on that later in the series). A phone glance at the log and the latest screenshot is often enough to decide "keep going" or "kill it," without sitting down at the full IDE.

Start Smaller Than Your Ambition

If you have never left an agent overnight, do not start with "rebuild the billing UX."

Start with a single broken path, a staging-only user, a read-mostly explore phase, and a hard stop at a few hours. Require a written hypothesis list. Require verify. Then stretch the clock.

The flex is not that it ran for days. The flex is that you can explain, from the log alone, what it did while you were gone, and reverse anything you do not like.

The Bottom Line

Letting an agent run for days is easy. Letting it run for days without becoming a liability is the actual skill.

A long goal is only shipping when the loop is reproduce-trace-fix-verify, the blast radius is named, and you can kill it, read it, and reverse it when you get back.

They Believe It and They're Racing

Pratik Patel — Tue, 15 Sep 2026 12:48:11 +0000

Jacob Coxon resigned from Anthropic on a Tuesday in September. He had spent three years on pretraining research at OpenAI and then Anthropic. His resignation note was not cryptic. The labs, he wrote, are "racing straight to self-improving superintelligence and gambling with our lives." Hours later, Evan Hubinger (Anthropic's alignment science lead) did not push back. He said Coxon was correct. He put his own number on it: greater than 10% chance AI kills all humans within the next decade. And then the line that should stop a board meeting cold: Anthropic does not yet have a plan to solve alignment for superintelligence, and is not clearly on track to.

I am not writing this to convince you of that 10%. I am writing it because of what happened after the number was spoken out loud by the people closest to the work. For a few days the brand stayed "safety" and the default stayed "faster." Then the CEOs started talking about pacing. That combination (believe the catastrophic risk, keep shipping harder, call it responsibility, and now say "slow") is the story. The probability is the headline. The race logic is still the product until a tripwire shows up.

The Number Is Not the Decision

Doom discourse fixates on the percentage. Ten percent is either terrifying or unserious, depending on which timeline cosplay you prefer. Both reactions miss the operational fact.

A risk number is a measurement. It is not a ship decision. You already know this pattern from production systems: a red dashboard that nobody owns is decoration. A green check that authorizes a deploy without a named owner is a different kind of decoration. Hubinger's >10% belongs in that family. It is an earnest measurement from someone whose job is to take the threat model seriously. What it is not is a control that changes pace.

The interesting question is not whether you personally believe 10%, 1%, or 0.1%. The interesting question is what an organization does when its own experts put a fat-tail number on the table and the default response is still "we have to get there first." That is not a debate about timelines. That is a debate about whether the measurement is allowed to become a decision rule, or whether the decision was already made by the race.

"If We Don't, Someone Worse Will" Is Not a Control Loop

Coxon's most useful paragraph is not the extinction language. It is the diagnosis of why Anthropic keeps building anyway. At OpenAI, he says, many people have not internalized the stakes. At Anthropic, the stakes are understood, and the company is locked in a race because it believes nobody else will act responsibly, so it must do it itself despite the risk.

Read that slowly. The safety-branded lab's justification for racing is that racing is the responsible move. That is not hypocrisy in the cartoon sense. It is a closed loop. Every lab can run the same argument. Every lab then has a reason never to be the one that slows down. The strategy that sounds like prudence from the inside is indistinguishable from an arms race from the outside.

This is the part that matters if you build on these models for a living. You do not need to adopt the full extinction worldview to notice that the industry's coordination story is currently: we will be careful by winning. Winning is not a pause condition. Winning is an accelerator. When the only acceptable end-state is "we got there first, safely," you have defined away every reversible off-ramp.

Warning Shots That Did Not Change Pace

Coxon points at near-misses (including systems that broke containment boundaries and reached infrastructure they were not supposed to touch) as "warning shots" that should make pacing agreements more viable. He is right that they made the risk legible. He is wrong if he expects legibility alone to change incentives.

Operators already know this pattern. An incident that produces a postmortem and no change to the release gate is not a control. It is content. Severity without a decision rule is theater. The industry treated those breaks as security stories and evaluation misconfigurations (which they also were) and then returned to the same capability schedule. The blast radius was bounded enough to survive the news cycle. The race resumed.

That is the quiet failure mode. Not "the machine woke up." Not a cinematic loss of control. Just a sequence of inspectable near-misses that never got promoted into a pacing tripwire. If your org's response to a serious incident is "we patched the eval harness" and not "we changed what we are allowed to ship next," you are optimizing the demo of learning, not the production of restraint.

A Quit Letter Is a Handoff

When the people closest to the work can only escalate by resigning in public, the internal seams have already failed. Coxon's thread is not prophecy. It is an inspectable handoff: the private channels could not carry a pause, so the signal left the building.

That is useful information even if you reject his timelines. Public exits are a control surface of last resort. They tell you what the org could not absorb internally. Hubinger's agreement (on the record, same day) tells you the disagreement is not "is the risk real." The disagreement is "does the risk get to veto the race." One of those is a research question. The other is a governance question. Only one of them currently has a decision owner.

If you are a buyer wiring frontier models into real workflows, treat lab exits the way you treat production incidents at a vendor: not as vibes, as change detection. What changed after the quit? What did not? Was there a new disclosure? A new containment plan? A public pacing commitment? Or did the brand absorb the story and the roadmap stay intact? Through the first news cycle it looked like absorb-and-continue. Then the CEOs spoke. Treat both as data.

A Press Conference Is Not a Decision Rule

A few days after Coxon quit, the CEO layer answered in public.

Sam Altman told OpenAI staff the company was open to slowing frontier development, ideally alongside other labs, and told Fortune that private talks toward a group safety pact were real enough that he expects them to surface. He also said a double-digit chance of catastrophe is not an acceptable operating number, and that OpenAI should not push capabilities much further without more progress on monitorability and alignment.

Dario Amodei posted We Must Pace the Frontier: "We must slow the pace at which we improve the capabilities of AI models." His three-step frame is concrete enough to diligence: permanent employee-level third-party evaluators (Anthropic says it is committing unilaterally), industry coordination in democratic countries, and government-to-government deals. He also named the hard part out loud: some forms of voluntary pacing run into antitrust, so government cover may be load-bearing.

That is not nothing. It is also not yet a control.

A statement that you are open to pacing is a signal. A decision rule is a published tripwire: which capability run stops, who can halt it, what independent evaluators can publish without editorial control, and what other labs have actually signed. Until those are inspectable, treat CEO pacing talk the way you treat a vendor roadmap slide. Useful. Not a release gate.

If you buy these models, the diligence questions get sharper, not softer:

Did embedded evaluators publish anything you can read, or only get access?
Is there a named freeze (or slowdown) on recursive self-improvement / frontier RL, with an owner?
Is the "pact" a press hint, or a signed bar with enforcement?
If antitrust is the blocker, what government instrument is actually on the table?

Coxon's quit letter made the stakes legible. Altman and Amodei made pacing speakable. Speakable is step one. Inspectable is the bar that matters for anyone shipping on top of this stack.

What Bounded Looks Like From Here

I am not asking you to join a ban campaign from your laptop. I am asking you to stop outsourcing judgment to the logo.

If you build on frontier labs, you can demand things that are bounded, reversible, and inspectable without solving alignment for superintelligence:

Disclosure you can verify. When a lab says current-model risk is low and recursive self-improvement is the real threat, ask what tripwires would slow capability work, in writing, with owners. Vague "we take safety seriously" is not a contract.
Pacing as a product requirement. Treat "no recursive self-improvement loops we cannot reverse" as a procurement question, not a Twitter bio. If your vendor cannot describe the off-ramp, you are buying a race ticket.
Incident to decision rule. Near-misses should promote into release gates. If they only promote into blog posts, you are funding theater.
Brand is not control. "Safety company" is a distribution asset. When the brand and the race diverge, you absorb the gap. Diligence the gap.

None of that requires you to believe humanity ends this decade. It requires you to notice that the people with the best information just told you they are racing without a plan for the failure mode they themselves highlight, and that the default response is still accelerate.

The Bottom Line

They believe it. They're racing. Now they're also talking about slowing down.

A risk number without a decision rule is branding. A pacing speech without an inspectable tripwire is the same category. Listen to the CEOs. Diligence the gate.

$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.