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.

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.

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.

The statistic is 16%, and it comes from Canaries in the Coal Mine?, a paper by Erik Brynjolfsson, Bharat Chandar and Ruyu Chen at the Stanford Digital Economy Lab. It has been quoted in every direction for months. It is a serious piece of work and the number is real. It just does not say what the reposts say it says.

I read the November 13, 2025 version end to end before writing this, because an earlier draft carried a different figure and that one is still circulating. What follows is the finding stated correctly, followed by the part of it I would actually change a plan over.

What the 16% Is

Here is the abstract, verbatim:

"Early-career workers (ages 22-25) in AI-exposed occupations experienced 16% relative employment declines, controlling for firm-level shocks, while employment for experienced workers remained stable."

Two words in that sentence do all the work, and both get dropped in the retelling.

Relative. The 16% is a comparison, not a count. It is the gap between young workers in the most AI-exposed occupations and comparable older workers at the same firms, after the model absorbs whatever else was happening to those firms. It is not "one in six entry-level jobs disappeared." Nobody lost 16% of anything.

Controlling. It is a regression estimate, conditioned on firm-time effects. That conditioning is the point — it is what rules out "this firm was just shrinking" — but it also means the number is a modelled contrast, not something you could count off a payroll.

If you want a figure you can hold in your hand, the paper has better ones, and they are unmodelled. From late 2022 to September 2025, in the most AI-exposed occupations, employment for 22-to-25-year-olds fell 6%, "compared to a 6-9% increase for older workers." In the three least-exposed quintiles, employment grew 5-13% for every age group, with no clear ordering by age.

Read those two sentences next to each other. That contrast is the entire finding. Where AI exposure is low, young and old grew together. Where it is high, the young line bends down while everyone else's keeps climbing.

And the number that will get screenshotted: by September 2025, employment for software developers aged 22-25 had declined nearly 20% from its peak in late 2022. True — with the caveat that late 2022 was a hiring bubble, so some of that fall is a bubble deflating rather than a job vanishing.

What the Authors Will Not Claim

This is where the honest version parts company with the viral version.

The paper does not say generative AI caused this. Its own words:

"While our main estimates may be influenced by factors other than generative AI, our results are consistent with the hypothesis that generative AI has begun to affect entry-level employment significantly."

And from the conclusion: "Future work would benefit from better firm-level AI adoption data, which would provide sharper variation for estimating plausible causal effects of AI on employment." The title is Six Facts, not six effects. That word choice is deliberate and it is the most-ignored thing in the paper.

Three more limits worth carrying, because they are the ones that will be quoted back at you:

The data is one payroll provider. ADP — large, administrative, real, and not a national sample.

Credible datasets disagree. The paper cites its own contradictors, which is a good sign about the paper. Hampole et al. (2025), using Revelio Labs job postings and LinkedIn profiles from 2011 to 2023, find limited employment impacts overall, with growing labour demand at firms offsetting relative declines in exposed occupations. Chandar (2025b) — the same Chandar — using CPS data finds little differential trend overall, while noting how hard young workers are to measure there. Two credible datasets, two different pictures.

Watch for the aggregator trap. You will see the "nearly 20% for young software developers" figure repeated in other 2026 reports. That is not corroboration. Those reports are citing this same paper. One study restated three times is still one study.

The Fact Worth Planning Around

Now the part that survives all of that, and the reason I think this paper matters to anyone running a company.

The declines are not spread evenly across "AI-exposed" work. They concentrate where AI automates a task, and go muted where it augments one.

The authors measure this using the Anthropic Economic Index, which classifies the share of real Claude queries per occupational task as automative or augmentative. Occupations with the highest automation shares show declining employment for the youngest workers. Occupations with the highest augmentation shares show no such pattern — the top augmentation quintile has among the fastest employment growth for young workers.

Disclose the proxy when you repeat this: query mix is a measure of how people use one AI model, not a measure of what firms have adopted. It is a good proxy. It is still a proxy.

But the mechanism it points at is intuitive enough that I believe it. The paper's framing is that AI is automating "the codifiable, checkable tasks that historically justified entry-level headcount," while complementing the judgment-, client- and process-heavy work that experienced people do. The entry-level job was always partly a training subsidy — you paid someone to do the checkable version of the work while they learned the unwritten version. When the checkable version gets cheap, that arrangement is the first thing to come under pressure.

Two more facts to file next to it.

It is showing up in headcount, not in pay. Compensation trends barely diverge by age or exposure; employment trends diverge a lot. The market is repricing whether the role exists, not what it pays. (The paper is careful here too — it offers offsetting wage effects or simple short-run wage stickiness as competing explanations.)

It is probably hiring, not firing — and that part is a hypothesis, not a measurement. The authors suggest reduced hiring is "the lowest-friction adjustment margin," and that firms "may primarily shrink junior inflows rather than displace incumbents." Note every "may." They did not measure inflows against separations; they proposed a mechanism that fits the shape of the data. Treat it as the best current guess, not a result.

Which, if it holds, means the adjustment is nearly invisible from inside a company. Nobody announces it. There is no layoff. A role just quietly stops being opened.

So What Do You Do With It

I run a company where agents do a large share of the checkable work. So I have to take this seriously rather than argue with it, and here is where I have landed.

Audit your roles by task, not by title. The unit of exposure in this data is the task, not the job. Take each role you were planning to hire and split it: which parts are codified and checkable, which need judgment, context or a relationship. If a role is mostly the first kind, you are not hiring a person, you are buying a workflow — and you should ask whether you want it as a workflow.

Do not read "automate" as "eliminate." The augmentation quintiles grew fastest. The instruction the data actually gives is to hire into the augmented shape: fewer people doing more leveraged work, earlier. That is a different plan from a hiring freeze, and it is a better one.

Notice that the cheap-to-check work was also the training ladder. If you automate every task a junior used to learn on, you have optimised this year and mortgaged your senior bench. Somebody has to still be growing into the judgment work, and it will not happen by accident. I wrote about the individual side of this in Own Your Career; the company side is the same problem viewed from the other end.

Stop measuring people by output volume. When the checkable output is nearly free, counting it tells you nothing about who is valuable. That was already true before this paper — it is the whole argument in The 10x Engineer Myth — and this data makes it expensive to keep getting wrong.

The Canary Is a Warning, Not a Verdict

The paper's title is the right metaphor and it is worth taking literally. A canary is an early indicator in a confined space. It tells you something about the air before you can feel it yourself. It does not tell you the mine has collapsed, and it does not tell you why.

That is roughly the epistemic state we are in. Something real is happening at the entry level of AI-exposed work. It is showing up in headcount rather than wages, in automated tasks rather than augmented ones, and most likely through hiring that quietly does not happen. Whether generative AI is the cause is not established, and the honest researchers on this are the ones saying so.

You do not need causality to act on it. You need to know which of your tasks are checkable, and what you plan to do with the people who used to check them.

That distinction used to be academic. It isn't anymore. In LangChain's State of Agent Engineering survey, 57.3% of respondents already had agents running in production, with another 30.4% actively building toward deployment. Whatever you believe about the hype cycle, the deployment happened. The measurement did not keep pace.

I've been reading the MAST paper — a failure taxonomy built from 1,642 annotated execution traces across seven multi-agent frameworks — and one number in it reorganized how I think about evals.

Failures sort into three categories. System design issues are the largest. Inter-agent misalignment is second, and that's the seam I wrote about last week. The third category is task verification, at 23.5% of everything observed.

Not "the agent was wrong." The process that was supposed to catch the agent being wrong didn't catch it.

Nearly a quarter of observed failures are failures of the checking layer. Which is to say: of the thing you built to tell you about the other failures.

The Three Ways Checking Fails

The 23.5% breaks into three named modes, and the breakdown is more useful than the total, because each one is a different thing your eval suite isn't doing:

Incorrect verification — 9.10%. Something was checked. The check was wrong.

No or incomplete verification — 8.20%. Nothing was checked, or only part of it was.

Premature termination — 6.20%. The system stopped before the work was actually done.

Sit with the ordering for a second. The most common verification failure is not the missing check. It's the check that ran and returned a pass.

That inverts how most teams think about eval coverage. The instinct is that reliability is a coverage problem — we haven't written enough tests yet, we'll get to it. But the largest single bucket here is code that executed, evaluated the output, and concluded it was fine. More coverage of that kind adds more surface for the same failure.

What a Superficial Check Looks Like

The paper is specific about why verifiers fail, and the answer is unglamorous. From the authors' analysis of the traces:

"We find that many existing verifiers perform only superficial checks, despite being prompted to perform thorough verification, such as checking if the code compiles or if there are leftover TODO comments."

Their worked example is a ChatDev-generated chess program. It compiles. It passes review. It has runtime bugs, because nothing validated it against the actual rules of chess. The output is unusable, and every check in the pipeline said it was fine.

Read that list of superficial checks again — does it compile, are there leftover TODOs — and ask how much of your own agent eval suite it describes. Did the code parse. Did the JSON validate. Did the response come back non-empty. Did it mention the keyword. These are all real checks. They are all checks on the shape of the output rather than its correctness, and shape is exactly what a fluent model gets right while getting the substance wrong.

The paper's own conclusion on this is blunt:

"Current verifier implementations are often insufficient; sole reliance on final-stage, low-level checks is inadequate."

Final-stage and low-level. That's a description of the median eval suite: one assertion, at the end, on the surface of the answer.

The Part That Should Actually Worry You

Here is the finding that changed my mind about something.

The authors split their traces by outcome — failures observed in runs that succeeded versus runs that failed — and the split is not uniform. Some failure modes appear almost exclusively in failed runs. Unaware of termination conditions, information withholding: when those show up, the task is usually going down with them.

Verification failures behave differently. Verbatim:

"In contrast, verification-related failures like 3.2 No or Incomplete Verification and 3.3 Incorrect Verification appear frequently even in successful runs. This suggests that while these systems can complete some tasks, their verification process still contains flaws."

Your broken verifier does not announce itself by breaking the task. It sits inside runs that came out fine.

This is the measured version of something I've argued from instinct before — that agents fail quietly, in ways that pass the checks you remembered to write. What I hadn't appreciated is that the quiet failure is often in the checking layer itself, and that it persists happily through green runs. The successful run and the broken verifier coexist, and one of them is visible to you.

So the green dashboard is not evidence the verification works. It's evidence the task succeeded, which is a different claim, and on this data those two things come apart routinely.

One honesty note: this success/failure split is a smaller, per-system analysis than the 1,642-trace headline, and the rounding in the published rates suggests roughly ten to a dozen successful traces per system. Treat the direction as the finding, not the magnitude.

What Actually Moved the Number

The paper doesn't stop at taxonomy. The authors ran interventions on ChatDev and measured them, and the verification-flavored one is the strongest result in the paper.

They changed the system's shape so that it terminates only when a designated agent confirms all reviews are properly satisfied, with an iteration cutoff to prevent infinite loops. Before, the pipeline ended when it reached the end of the pipeline. After, it ended when an explicit objective check passed.

On a custom 32-task benchmark the authors call ProgramDev-v0, success went from 25.0 to 40.6 points.

Three caveats, and I want to give them properly because this figure travels badly.

First, those are percentage points off a very low base. You will see this result quoted as "+15.6% improvement," which reads as relative and overstates it. The system went from failing three quarters of the time to failing three fifths of the time.

Second, the benchmark is 32 custom tasks — the paper explicitly distinguishes ProgramDev-v0 from the ProgramDev dataset it discusses elsewhere. On the second benchmark, HumanEval, the identical change moved success from 89.6 to 91.5. That's under two points, on a benchmark already near ceiling. This is not a general result and shouldn't be sold as one.

Third, the authors themselves decline to oversell it:

"Even though our interventions are successful in improving the performance of the framework in different tasks, they do not constitute substantial improvements."

I still think it's the most instructive number here, precisely because of how unspectacular it is. The mechanism is what matters: making termination conditional on an explicit objective check, rather than on having reached the end of the workflow. That is a one-line change in what "done" means, and on the benchmark where there was room to move, it moved more than anything else they tried.

Four Things to Measure Instead

I don't want to end on a checklist, so let me end on the smallest set of questions your current setup probably can't answer.

Can you make your verifier fail? Take a known-bad output — genuinely wrong, not malformed — and run it through your eval suite. If it passes, you've measured the thing you needed to measure. Mutation testing is old, unglamorous, and almost nobody applies it to agent evals, which is odd given that 9.10% is the single largest verification failure mode.

Do you distinguish "finished" from "stopped"? Premature termination is 6.20% on its own, and it's the mode with no artifact to inspect — there's no wrong answer sitting there, just less right answer than there should have been. If your telemetry records completion but not why the loop exited — objective satisfied, step budget exhausted, tool error swallowed — you cannot see this class at all.

Does anything check the coverage of the check? No-or-incomplete verification is 8.20%, and "incomplete" is the operative word. A verifier that inspects three of the seven things that had to be true will report success four sevenths of the time it shouldn't.

Are you looking at the successful runs? This is the one that follows directly from the split above, and it's the cheapest. Sample runs that passed. Read the traces. Verification flaws live there, and by definition no alert will ever route you to them.

The Honest Caveat

MAST is a taxonomy paper built on annotated traces, and the annotation is human judgment applied at scale — the authors report strong inter-annotator agreement, but on a small labelled sample that was then extended by an LLM judge. The intervention results are one system, two benchmarks, one of which is 32 tasks. And the LangChain production figure comes from a self-selected community survey — 63% technology industry, roughly half at companies under a hundred people — so read it as "people who build agents" rather than "enterprises."

None of that changes the shape of the argument, because the argument doesn't need the numbers to be precise. It needs them to be the right kind of number, and they are: an independent look at what actually goes wrong, which found that the checking layer is a first-class source of failure rather than the neutral instrument everyone treats it as.

Your eval suite is not a measuring device pointed at your agent. It is another component in the system, written with the same care as the rest of it, failing in the same ways, and — unlike everything else you built — there is nothing downstream of it that would notice if it broke.

Everyone measures whether the agent works.

Start measuring whether you'd know if it stopped.

So you open the last agent's trace. You read its prompt, its reasoning, its tool calls. And the frustrating part is that none of it looks broken. Given what it was told, it did something reasonable. You swap in a better model. Same class of failure. You rewrite the prompt. Same class of failure.

The agent was fine. The brief it received wasn't.

This is the thing that surprises people about running more than one agent: the failures stop living inside the agents and start living in the space between them. We wrote about that shift when you go from one agent to two. This post is about the part that comes after the realization — actually engineering that space.

The Failure Rates Are Worse Than the Demos Suggest

There is now real data on this, and it is bracing.

Researchers behind the MAST taxonomy annotated 1,642 execution traces across seven state-of-the-art open-source multi-agent systems. It is worth knowing exactly how, because the how is what makes it usable: six human experts read 150+ traces to build the taxonomy, three of them then labeled independently until they reached 0.88 Cohen's kappa, and the full 1,642-trace dataset was labeled by an LLM-as-judge pipeline calibrated against those human annotations (94% accuracy, 0.77 kappa).

So it is not 1,642 hand-reads, and anyone citing it should say so. What it is, is a human-built and human-validated taxonomy applied at a scale humans could not reach — the closest thing the field has to a failure epidemiology.

Their headline: 41% to 86.7% failure rates. The six systems the paper breaks out individually: AppWorld failed 86.7% of the time, HyperAgent 74.7%, ChatDev 66.7%, Magentic-One 62.0%, MetaGPT 60.0%, AG2 41.0%.

One honest caveat before anyone quotes that range at a standup, and it is the paper's own: these systems were measured on different benchmarks, so the numbers are not directly comparable to each other. It is not a leaderboard. What it is, is a floor-level observation that serious multi-agent systems built by serious people fail a lot, and the good ones still fail more than you would guess from a demo video.

A Third of It Is the Seam

Here is the number this post is actually about.

MAST sorts every failure into three categories. Inter-agent misalignment accounts for 32.3% of them. Not the model being incapable. Not the task being impossible. Roughly a third of failures are agents failing to communicate correctly with each other.

Break that category open — all six sub-modes, so the arithmetic is checkable — and they are painfully recognizable:

• ▸Reasoning-action mismatch — 13.2%. The agent's stated reasoning and its actual action diverge. It says it will check the schema, then doesn't.
• ▸Task derailment — 7.4%. The work drifts from what was asked. Each handoff nudges it slightly, and no single step looks wrong.
• ▸Failure to ask for clarification — 6.8%. The agent receives an ambiguous brief and resolves the ambiguity by guessing, silently.
• ▸Conversation reset — 2.2%. The thread restarts and everything established up to that point is gone.
• ▸Ignoring another agent's input — 1.9%. The information arrived. It was not used.
• ▸Information withholding — 0.85%. An agent knows something relevant and does not pass it on.

Look at that list as a whole and a pattern falls out. Almost none of these are intelligence failures. They are protocol failures. The receiving agent was never told what it needed, never told what it was allowed to assume, and never given a way to say "this brief is underspecified."

One thing worth being precise about, because the sloppy version of this argument is everywhere: the 41–86.7% range is an overall failure rate, not a coordination-failure rate. The paper does not claim coordination causes most failures. It measures that inter-agent misalignment is 32.3% of them. The argument that this is the most fixable third is mine, not theirs.

Why the Seam Is Invisible

Every agent in the chain looks locally correct. That is the whole problem.

When you debug a single agent, you have a clean pair: the input you gave it, the output it produced. When you debug a chain, the input to agent three is an artifact produced by agent two, which was itself working from agent one's artifact. By the time you inspect the failure, the original intent has been paraphrased twice.

Paraphrasing is lossy. Not dramatically — that would be easy to catch. It is lossy at the edges, in exactly the places that turn out to matter: the constraint that was mentioned once, the exception the user flagged in passing, the "don't touch the billing table" that agent one understood as context and agent two reasonably summarized away.

This is why "just use a better model" doesn't fix it. A better model paraphrases more fluently. It does not know which edge case you were going to care about, because that information was destroyed one hop upstream.

Engineer the Seam Like an API

The fix is not more intelligence. It is treating the handoff as an interface with a contract, the same way you would treat a service boundary between two teams.

Pass structure, not prose. The single highest-leverage change is to stop letting agents hand each other paragraphs. A paragraph invites paraphrase; a schema doesn't. If agent two must produce { file, change, constraints[], unresolved[] }, then constraints cannot get quietly dropped in a rewrite — a missing field is a visible, checkable error rather than an absence nobody notices.

Make "I don't know" a first-class value. The 6.8% clarification-failure mode exists because the schema had no slot for uncertainty. Give every handoff an explicit unresolved list, and make it legal — expected, even — for an agent to hand back work with three open questions instead of a confidently guessed answer. An agent that guesses silently is not being helpful; it is failing quietly, and quiet failure is the expensive kind.

Validate at the boundary, not at the end. Check the handoff artifact the moment it is produced, against the contract, before the next agent starts. A malformed brief caught at the seam costs one retry. The same brief caught after three more agents have built on it costs the whole run — and by then the evidence of what went wrong has been paraphrased out of existence.

Carry provenance forward. Every constraint in a handoff should say where it came from: the user, an upstream agent, or the agent's own inference. This one line of metadata is what lets a downstream agent — or you, reading the trace — tell the difference between a hard requirement and a guess that has been repeated so many times it looks like one.

Keep the original brief reachable. Don't let the user's actual words disappear behind two layers of summary. Pass a pointer to the source alongside the summary, so any agent in the chain can go check the original instead of trusting the paraphrase. This is the cheapest possible fix and it is skipped constantly.

The Boring Discipline

None of this is exotic. It is schema validation, explicit nullability, provenance, and error handling — the same things we learned to do at service boundaries twenty years ago, applied to a boundary we have been pretending is a conversation.

That pretense is the root of it. We describe agents as "talking to each other," and that framing quietly imports every assumption we make about human conversation: that context is shared, that ambiguity gets resolved by asking, that the listener will flag something that sounds off. None of that is true by default here. It is true only if you build it.

The good news is that this is the tractable third. You cannot make the model smarter this quarter. You can absolutely make the message between agent two and agent three a validated object with a slot for "here is what I wasn't sure about."

Start there. The next time an agent produces something confidently wrong, before you touch its prompt, go read what it was handed. The bug is upstream more often than it has any right to be.

Cognition published Don't Build Multi-Agents, arguing that splitting work across parallel agents is fragile by construction. Anthropic published its multi-agent research system, reporting that an orchestrator with parallel subagents beat a single strong model by 90.2 percent on their internal research eval.

Both teams are serious. Both are describing real systems. And most people reading them treat the disagreement as a matter of taste, or of who had the better framework.

It isn't. They're describing two different kinds of work, and the difference between those two kinds is the single most useful thing I know about scaling from one agent to a fleet.

The First Agent Is an Engineering Problem

Everything I've written about agent reliability so far assumes a boundary around one agent. Decide what it's allowed to touch. Give it a runbook instead of a better prompt. Notice when it fails quietly. Make its mistakes cheap to take back. Teach it when to stop and ask. Keep a trace of what it did.

Every one of those controls is scoped to a single actor. The permission set belongs to an agent. The undo button unwinds one agent's actions. The escalation gate pauses one agent's decision. The trace reconstructs one agent's run.

Add a second agent and none of those controls break in an obvious way. They just stop covering the interesting part, because the interesting part is now between the two of them.

Who owns the shared file when both agents want to write it? When agent A assumes the API returns cents and agent B assumes dollars, whose trace shows the bug? When the run goes wrong at step nine of a forty-step plan spread across five agents, which agent gets the pause? Nothing in a single-agent design answers these. Each one is a question about authority: who owns what, and who decides when two agents disagree.

That's the actual shape of the jump. The first agent is a systems problem you can solve with better tools. The second agent is a coordination problem you solve with better contracts, and coordination problems have never been solved by making the individual participants smarter.

The Failures Are Boring, Which Is the Bad News

There's now real data on how these systems fail. A team from Berkeley and collaborators read 150 execution traces closely enough, and agreed with each other closely enough (Cohen's kappa of 0.88), to build a taxonomy of what actually goes wrong. It has fourteen distinct failure modes in three buckets: system design issues, inter-agent misalignment, and task verification. They then built an LLM annotator against that taxonomy and ran it over more than 1,600 traces from seven popular multi-agent frameworks, which is how we know the taxonomy holds beyond the traces that produced it.

Read that list again and notice what isn't on it. Not "the model wasn't capable enough." Not "reasoning was too shallow." The failures are specification, coordination, and checking the work. If you replaced every agent in those traces with a smarter model, most of those traces would still fail, which is roughly what the authors concluded when they said the failures they found demand more sophisticated solutions than surface-level fixes.

I find this genuinely clarifying, and a little deflating. We're rediscovering, at great expense, that a team of capable individuals with unclear ownership and no shared definition of done produces worse work than one competent person. Gartner's forecast that over 40 percent of agentic AI projects will be canceled by the end of 2027 blames escalating cost, unclear value, and inadequate risk controls. All three are management failures.

Cognition names the mechanism precisely. Actions carry implicit decisions, and conflicting decisions carry bad results. Their example is a Flappy Bird clone split between two subagents: one renders a background in the style of Super Mario Bros., the other builds a bird that doesn't match anything, and the orchestrator is left holding two incompatible halves. Neither subagent did anything wrong by its own lights. They just each made a silent decision the other never saw.

Parallelize Reading. Serialize Writing.

So why did Anthropic's fleet work?

Look at what those subagents were doing. Searching. Reading. Exploring independent branches of a research question, then handing back findings that get synthesized by a lead agent. Nothing any subagent does changes what another subagent sees. The context each one gathers is additive. When two agents turn up the same source, the worst thing that happens is you paid twice for it. And the cost of that architecture was roughly fifteen times the tokens of a normal chat, which is a fine trade when the alternative is a question that doesn't fit in one context window at all.

Now look at the Flappy Bird case. Both subagents were writing to one artifact. Every choice one made silently constrained the other. Their outputs collide.

That's the variable. It isn't framework, orchestration topology, or prompt quality:

Parallelize reading. Serialize writing.

Fan out as widely as you like across work that only reads. Search, retrieval, analysis, exploring five approaches to see which is viable, reviewing a diff from six angles. The results combine cleanly because nothing contended for shared state. This is exactly the workload where a fleet pays for itself, because you're buying breadth that a single context window can't hold.

Then narrow to one writer for anything that mutates shared state. One agent holds the pen for a given artifact. Not one agent for the whole system. One agent per thing that can be written.

Most multi-agent designs I see get this backwards. They parallelize the writes, because that's where the wall-clock time is, and then spend the savings debugging conflicts that never had to exist.

Contracts, Not Conversations

Once you accept that constraint, the rest of a fleet design falls out of it.

Make handoffs artifacts, not chat. Agents passing messages recreates every ambiguity of a hallway conversation, and current models are bad at the social reasoning that makes hallway conversations work. Have agents produce structured, inspectable outputs that the next agent consumes as input. A file, a diff, a typed result. Something you can look at afterward and say: this was correct when it left agent A, and agent B mishandled it. Chat transcripts don't let you say that.

Pass the full trace, not the summary. Cognition's first principle is to share complete agent traces rather than individual messages, and it's the right call. A subagent that receives a one-line task description will invent everything the description left out. The invented parts are where conflicts come from.

Give shared state an owner. For every resource two agents can touch, name the one that writes. The others read. If two agents genuinely must write the same thing, that's not a coordination problem to solve with better prompts. That's a design smell telling you the work was split along the wrong seam.

Trace across the fleet, not per agent. A per-agent trace tells you what each one did. It won't tell you that agent B's correct action was based on agent A's wrong assumption. You need spans that link, so the causal chain survives the hop between agents. Reconstruction was already the foundation of trust in a single agent. In a fleet it's the only thing standing between you and a bug that no single trace contains.

Escalate at the seams. The most valuable place for a human pause isn't inside an agent's reasoning. It's at the handoff, where one agent's output becomes another's assumption, and where a wrong assumption is still cheap to catch.

Ask What They'll Contend Over

The question to ask before adding an agent isn't "could a second agent do this in parallel." It almost always could. The question is what the two of them will contend over, and who decides when they disagree.

If the answer is nothing, they contend over nothing, then fan out. Run ten. The read-only fleet is one of the genuinely good deals in this technology, and it's why the research-agent results are real.

If the answer involves shared state, a shared artifact, or a decision that has to be consistent across both, then a second agent doesn't split the work. It splits the ownership, and hands you a distributed-systems problem you now have to solve in natural language, with participants that don't reliably remember what they agreed to.

One agent that reads widely and writes carefully will beat five that all think they're holding the pen.

Your second agent isn't a second worker. It's the first day your agents needed a manager.

And you still have no idea why it did what it did.

That is the gap I want to talk about. Not "did the agent fail," which you can often catch. Something harder. "The agent did something surprising, and I cannot reconstruct the path it took to get there."

I have written about bounding what an agent can touch, measuring when it fails quietly, giving it an undo button, and teaching it when to ask a human. Each of those makes the agent's mistakes smaller or more survivable. None of them tells you why a specific run went the way it did. For that you need to be able to replay the decision. And most teams cannot.

A Log Says What Happened. It Does Not Say Why.

Traditional monitoring was built for deterministic services. The same input produces the same output, every request follows a known code path, and a 200 is a strong signal that things went right. Agents break all three assumptions. The same prompt can produce different tool calls on different runs, the path branches on model output, and a 200 can wrap a confidently wrong answer.

So the usual stack shows you the outside of the run and none of the inside. It can tell you the request returned successfully. It cannot tell you that the agent looped twice, called the wrong tool, and hallucinated a billing policy on the way to that successful-looking answer. The most dangerous agent failures are the ones that look like success: well-formed but wrong outputs, redundant tool calls, semantically invalid actions. A binary up-or-down check waves all of those through.

The uncomfortable part is how few teams have anything better. Gartner puts spending on LLM observability at 15% of GenAI deployments today, and expects it to reach 50% by 2028. The direction of travel is obvious, but the baseline is the part worth sitting with: most agents in production right now are black boxes to the people who run them.

A Trace Is the Inside of the Decision

The fix is not more logs. It is a different shape of record: a trace.

A log is a flat list of events. A trace is the causal tree. Every reasoning step, every tool call, every retrieval, every decision branch becomes a nested span linked to the step that caused it. Open one and you can walk the whole path from the initial request to the final action: what the agent saw, what it decided, which tool it reached for, what came back, and what it did next.

That is the difference between "the ticket got closed" and "the agent read the ticket, retrieved the wrong policy doc, concluded the issue was resolved, and closed it without checking the account flag." The first is a log line. The second is a trace, and it is the only one of the two you can actually learn from.

Concretely, a trace worth keeping captures three things for every run:

• ▸Every model call, with the prompt, the context it was given, and the raw response. Not a summary. The actual input and output, because that is where wrong decisions are born.
• ▸Every tool call and retrieval, with arguments and results, linked to the reasoning step that triggered it. This is where you catch the wrong tool, the malformed argument, the stale document.
• ▸Every decision branch, so a non-deterministic run is still reconstructable after the fact. When the same prompt could have gone three ways, you want to know which way this run went and what tipped it.

Get those and a surprising run stops being a mystery. It becomes a recording you can scrub through.

You Do Not Have to Build This From Scratch

The good news is that this is standardizing. OpenTelemetry, the same tracing standard most backends already use, formed a GenAI group to define spans for LLM calls, agent orchestration, and MCP tool calls. The conventions are still moving, so treat attribute names as not-yet-frozen, but the shape is real and you can adopt it today. Most agent frameworks and observability platforms can emit and read agent traces without you hand-rolling the plumbing.

If you want a place to start, start small and specific:

Instrument the model call and the tool call first. Those two spans explain the majority of surprising behavior, because that is where the agent's intent turns into an action against the real world.

Keep the raw inputs and outputs, not summaries. The moment you compress a trace down to "called billing tool, got result," you have thrown away the exact detail you will need at 2am.

Make one real run replayable end to end before you scale. If you can open a single production run and narrate every step out loud from the trace alone, the instrumentation is working. If there is a gap you have to guess across, fix that gap before you add more agents.

Observability Is How Trust Gets Earned

There is a strategic reason this matters beyond debugging. The thing keeping most agent pilots from graduating to production is not capability. It is trust. Leaders will not hand real authority to a system whose decisions they cannot inspect. Gartner frames the same dynamic from the other side: as enterprises scale GenAI, "the trust requirement grows faster than the technology itself" — which is exactly why observability spend is forecast to triple as a share of deployments.

That is the quiet payoff. A trace is not only how you debug a bad run. It is how you show a skeptical stakeholder exactly what the agent did and why, how you satisfy an auditor, how you prove after an incident that you can explain the machine you are running. An agent you can replay is an agent you can defend. An agent you cannot replay is one you are asking everyone to take on faith, and faith does not survive the first surprising ticket.

The Bottom Line

We spend enormous effort trying to make agents make the right decision. We spend almost none making sure we can see the decision after the fact. That is backwards, because the agent will occasionally be surprising no matter how good it gets, and the only question that matters in that moment is whether you can reconstruct what it did.

Bounding limits the damage. Detection catches the miss. An undo button takes it back. Escalation routes the hard calls to a human. But all four assume you can eventually understand what happened. Observability is the layer that makes that assumption true.

So before you give your agent more to do, ask the plain question. When this does something I did not expect, can I replay exactly how it got there? If the answer is no, the problem is not that the agent needs a better prompt.

It is that you cannot see it think.

The demos that get shared are the ones where the agent does everything itself. No hand-offs, no pauses, no human touching the keyboard. Full autonomy, start to finish. It looks like the future.

Then you put that same agent on real work, and the trait you were cheering for becomes the thing that scares you. An agent that never stops is an agent that will confidently do the one thing you would have told it not to.

The skill that actually matters in production is the opposite of what the demos reward. It's not "how much can the agent do alone." It's "does the agent know when to stop and ask."

Autonomy Is Not the Prize

There is a quiet assumption baked into most agent projects: more autonomy is better, and any moment where a human has to step in is a failure we will eventually engineer away.

The teams running agents on things that matter have stopped believing that. In Okta's 2026 survey of the agentic enterprise, 95 percent of executives said they were confident in their organization's ability to detect an agent acting outside its intended scope. Read that again. The headline number is about detection, not prevention. Everyone is investing in catching the agent after it steps out of bounds. Far fewer are designing the moment where the agent stops itself before it does.

That gap is the whole game. Detection tells you something went wrong. A well-placed pause stops it from going wrong in the first place.

Regulators are already treating the pause as mandatory. The EU AI Act's oversight requirements, in force from August 2026, make demonstrable human intervention points a legal condition for high-risk autonomous systems, not a nice-to-have. "The model was very capable" isn't a defense. "A human approved the consequential action" is.

Not Every Action Deserves the Same Trust

The mistake is treating autonomy as a single dial you turn up or down for the whole agent. It's not one dial. It's a decision you make per action.

The way we sort it: every action an agent can take falls into one of four tiers, ranked by reversibility and blast radius.

Tier 1. Read-only. Queries, searches, analysis. Nothing changes in the outside world. Let the agent run. Gating these just manufactures friction and trains your reviewers to rubber-stamp.

Tier 2. Reversible. Drafts, internal state, anything that can be cleanly undone. Let the agent act, but log everything so you can walk it back. This is where an undo button earns its keep.

Tier 3. External or third-party. Actions that touch systems you don't fully control. Route these to a review queue instead of firing them off. The cost of being wrong just left your building.

Tier 4. High-risk and irreversible. Production deploys, financial transactions, deleting data, changing permissions, sending external messages. These require a human approval, regardless of how confident the agent claims to be.

The last clause is the important one. The agent's confidence isn't a signal you can trust at Tier 4, because confidence and correctness come apart exactly when the stakes are highest.

The Agent's Confidence Is Not Evidence

Here is the arithmetic that should end the "just let it decide" argument. Chain three agents together, each reporting 90 percent confidence but actually running around 75 percent accurate. Every step has to land for the chain to land, so the accuracies multiply: 0.75 × 0.75 × 0.75, which is just over 0.42. Three steps in, real end-to-end reliability is roughly 42 percent.

The agent will tell you it's 90 percent sure. The system is a coin flip. And it will report that 90 percent with exactly the same fluent, self-assured tone whether it's right or catastrophically wrong.

This is why "ask the agent how confident it is and gate on that" quietly fails. You're gating on a number the agent isn't qualified to produce. The trigger for a pause can't be the agent's feeling about the action. It has to be the category of the action. Deleting a database is Tier 4 whether the agent is nervous or serene about it.

Design the Pause Like a Feature

The good news is that a pause isn't a design failure to apologize for. It's a feature to build well. The teams doing this treat the hand-off as a first-class part of the system, not an error path.

A few principles that hold up:

Gate on categories, not vibes. Pick the handful of action types that are genuinely irreversible or high-blast-radius and require a human every time. A widely used default: pause for production deploys, external communications, financial transactions above a set threshold (often as low as $100), data deletion, and privilege changes. Everything else runs.

Make the pause cheap to answer. An approval request that dumps raw JSON on a reviewer is a bottleneck, not oversight. Give the human a plain-language summary: what the agent wants to do, what changes, whether it's reversible, and the estimated impact. The goal is a confident decision in seconds, not an archaeology project.

Freeze the state, don't restart it. When the agent pauses, it should serialize its state and resume cleanly on approval, not re-run from the top. Hash the proposed action at the moment of the pause and re-check it before executing, so nothing drifts during the approval window.

Set a timeout, and make it a kill switch. An approval request that hangs forever is its own failure. Give it a window. Thirty minutes is a common default. After that the action is cancelled, not silently executed. The safe default when a human never answers is stop, not proceed.

Asking for Help Is the Advanced Move

There is a version of this that reads as a limitation: the agent isn't good enough to be trusted, so we bolt a human onto the risky parts. That framing is backwards.

An agent that barrels through every decision isn't more advanced. It's less aware. The genuinely capable behavior is the thing we struggle to get juniors to do: recognize the edge of your own competence and escalate before you cross it, not after. An agent that stops at the right moment and says "this one is above my pay grade, confirm before I proceed" is showing more judgment, not less.

The counterargument is worth taking seriously. In April 2026, MIT Technology Review argued that human-in-the-loop oversight has quietly become an illusion in some systems, because a reviewer can't actually verify what a model reasoned about internally before it acted. That's a real risk, and it's a warning about lazy oversight: the rubber-stamp, the ten-thousand-alert queue nobody reads. It isn't an argument against oversight. It's an argument for the kind you can actually perform: few gates, high stakes, clear summaries, real decisions.

The Bottom Line

Stop optimizing for how much your agent can do without you. Start optimizing for whether it stops in the right places.

The reliability arc bends the same way every time. You limit what the agent can do. You give it repeatable procedures. You measure whether it actually worked. You make its mistakes reversible. And then you draw the last line: the short list of actions where no amount of agent confidence is enough, and a human has to say yes.

Full autonomy makes a better demo. Knowing when to ask for help makes an agent you can leave running.

Build the pause. Make it fast. And put it exactly where being wrong is expensive.

The part that stuck with me was not the deletion. It was what happened next. The backups were gone too. The most recent thing left to restore from was three months old. Three months of customer data, wiped by a single confident action, with nothing behind it.

The agent did not get hacked. It used valid credentials, a valid endpoint, and a permitted operation. Every individual step was allowed. The problem was that the most destructive thing it could do was also one of the easiest, and there was no way to take it back.

That is the failure mode I keep seeing under all the others. Not "the agent did something it was not allowed to do." Something quieter. "The agent did something allowed, and it could not be undone."

Prevention and Detection Are Not Enough

I have written before about the two obvious levers. Decide what the agent is allowed to touch. Measure whether its work is actually correct. Both matter. Both are necessary.

Neither one helps you at 2am when a permitted action has already landed and it was wrong.

Prevention narrows the set of things that can go wrong. Detection tells you when one of them did. But there is always a gap between the moment a bad action executes and the moment you notice. In that gap, the only thing that saves you is whether the action can be reversed.

Reliability people have a name for the worst version of this: the blast radius. How much damage can one wrong move cause before anything stops it? For traditional software, a bad deploy has a blast radius you can reason about. For an autonomous agent making its own decisions about what to do next, the blast radius gets wider and the rollback gets harder, because the agent can chain several allowed actions into one unplanned outcome faster than a human can react.

So the third lever is recovery. Design the system so that when the agent is wrong, and it will be, the mistake is cheap to take back.

Reversibility Is a Property You Design

The instinct is to treat reversibility as a backup problem. Take snapshots, keep copies, restore if something breaks. That is the exact assumption that failed in the nine-second story. The backups shared the same credentials and the same control plane as the thing they were protecting, so the same action that killed production killed the safety net.

Reversibility is not a copy you keep. It is a property of each action the agent can take.

The most useful thing I have started doing is boring: classify every tool the agent has by how hard it is to undo.

Green actions are reversible and cheap. Reading data, running a query, drafting a message, opening a pull request. If the agent gets these wrong, you close the tab and move on. Let them run.

Yellow actions are reversible but not free. Writing to a database with a soft delete, sending an internal notification, changing a config that has a known rollback. These are fine to automate if you have actually tested the path back, not just assumed it exists.

Red actions are irreversible or externally visible. Hard-deleting data, moving money, sending an email to a customer, deleting the backups. These are the ones that should never be one confident sentence away from execution.

Once you sort tools this way, a lot of design decisions make themselves. The stronger the approval, the smaller the blast radius, and the clearer the evidence you require, the more irreversible the action is. That single rule of thumb would have stopped the nine-second incident cold.

The Undo Button, In Practice

Giving an agent an undo button is less exotic than it sounds. It is mostly patterns engineers already know, applied one layer earlier.

Prefer soft deletes over hard deletes. A row marked deleted is an undo. A row that is gone is an incident. The agent should have to work much harder to do the second one.

Make destructive actions two-step. The agent proposes, something else confirms. That something can be a human for the truly irreversible stuff, or a separate check for the merely expensive stuff. The point is that no single call both decides and destroys.

Run in a copy first. Staging, a sandbox, a dry-run mode that shows the diff before it is applied. If the agent can rehearse the change against something that is not production, most bad plans reveal themselves before they touch anything real.

Keep the recovery path off the same switch. Backups that share credentials and storage with production are not backups. They are a second copy of the thing you are about to lose. Immutability and a separate control plane are the difference between a bad hour and a dead company.

Checkpoint the work. For multi-step workflows, save state between steps so you can roll back to the last good point instead of unwinding the entire run by hand. This is the recovery version of measuring the middle, and it is why teams increasingly treat reversible autonomy as its own layer of the stack rather than an afterthought.

None of this makes the agent smarter. It makes the agent's mistakes survivable, which is a different and more useful goal.

Save The Human For The Irreversible

There is a real cost to a confirmation step. Ask a person to approve everything and you have not built an agent, you have built a slow form. So spend the human attention where it actually pays off.

The trigger is irreversibility, not importance. A reversible action can be big and still run on its own, because if it is wrong you fix it. An irreversible action can be small and still deserve a human, because if it is wrong you cannot. Microsoft's guidance on autonomous agents lands in the same place. Let the low-risk, bounded, reversible work flow, and gate the actions whose worst case you could not walk back.

Done right, the human is not in the loop for everything. They are in the loop for exactly the handful of moves that cannot be undone. That is a load a person can actually carry, and it is where their judgment is worth the interruption.

The Bottom Line

We spend most of our agent-building energy trying to make the agent right. That is the wrong thing to optimize alone, because it will still be wrong sometimes, and the interesting question is what happens when it is.

An agent whose every action is reversible can be wrong all day and cost you a few minutes. An agent with one irreversible action wired to a confident decision can be right for months and then end you in nine seconds.

So before you widen what your agent can do, ask the unglamorous question. If this goes wrong, can I take it back? If the answer is no, that action does not need a better prompt.

It needs an undo button.

The demo runs clean. The test suite is green. The final answer reads well. And then the same agent, pointed at real work, quietly produces something wrong.

Not wrong in an obvious way. Wrong in a way that passes every check you thought to write.

This is the part of building with agents that nobody puts in the launch video.

The Demo Was the Easy Part

Every agent demo is built on the same foundation: clean inputs, a cooperative user, a defined scenario, and an environment where the agent's strengths are on display and its failure modes are conveniently out of frame.

Production is the opposite. Inputs are messy. Users ask for things the agent was never shaped to do. The scenario drifts halfway through. And the failure modes you kept off-screen in the demo are now the main event.

The numbers make this concrete. A March 2026 reliability report analyzed roughly 4.5 million tests across more than 6,000 production agents across ten regions. The aggregate end-to-end success rate was 56.6 percent.

These were not toy projects. They were real systems handling customer service, document processing, internal tooling, and workflow automation. Just over half of the runs actually worked.

That gap, between the demo and the deployment, is not a model problem you can prompt your way out of.

It is a measurement problem.

A Green Test Is Not a Working Agent

Traditional software has a comforting property: if the inputs are the same, the outputs are the same. A passing test means the code did what you asked.

Agents break that assumption.

An agent can pass a unit test and still fail the workflow. It can select the wrong tool. It can pass a malformed argument. It can hand off to the wrong sub-agent. It can take an unsafe path and then arrive at a plausible final answer that looks completely fine.

Here is the trap. Most checks look at the final state. The agent's mistakes happen in the middle.

Picture a research agent. It correctly retrieves competitor information in step one. It misattributes a feature to the wrong company in step three. It builds the rest of its analysis on that mistake. The final summary is well written, confident, and wrong, and it passes a surface-level check because the format is right and the conclusion sounds reasonable.

The error did not show up at the end.

It propagated from the middle and never announced itself.

This is what I mean by failing quietly. The agent does not crash. It does not throw an error. It hands you a clean, finished, incorrect result.

The Math Is Against Long Workflows

The reason this gets worse with ambition is simple arithmetic.

Say your agent is 85 percent reliable at each individual step. That sounds strong. Most people would ship it.

Now chain ten steps together. The end-to-end success rate is not 85 percent. It is 0.85 to the tenth power, which is roughly 20 percent.

Eighty-five percent per step. Twenty percent overall.

And real production workflows are often longer than ten steps. Every tool call, every handoff, every retrieval is another place for a small error to slip in and compound. Strong step-level performance can still produce cascading, end-to-end failure.

This is why "the model got better" rarely fixes a flaky agent. A better model raises per-step reliability a few points. The compounding math eats most of the gain. The fix is fewer steps, tighter scope, and a way to catch errors the moment they happen rather than at the finish line.

You cannot do any of that without measuring the middle.

Benchmarks Will Lie to You Too

The natural instinct is to reach for a benchmark. Run the agent against a standard suite, get a score, ship if the score is high.

Be careful there as well.

In April 2026, UC Berkeley researchers showed that every major AI agent benchmark could be exploited to reach near-perfect scores without actually solving a single task. The benchmark measured something. It just was not the thing you cared about.

A high benchmark score and a reliable production agent are not the same claim. One is a number on a leaderboard. The other is a system that behaves on the inputs your users actually send.

The benchmark is a starting point, not a verdict.

Build Evals Like You Mean It

So what actually works? Less hope, more measurement.

The teams shipping reliable agents in 2026 treat evaluation as core infrastructure, not an afterthought. A few principles I keep coming back to.

Measure steps, not just outcomes. Check the tool calls, the arguments, and the handoffs, not only the final answer. A workflow that gets the right answer for the wrong reason will eventually get the wrong answer.

Build evals from real failures. Every production incident is a test case you did not have yet. When an agent fails quietly, capture the trace and turn it into a permanent check. Your eval set should grow every week.

Run evals in CI. Treat an agent regression like a code regression. The point of CI tooling for agents is to catch the drop before users do, not to explain it afterward.

Score reliability, not vibes. "It feels smarter" is not a metric. End-to-end success rate, step-level accuracy, and tool-selection precision are. If you cannot put a number on it, you cannot tell whether your last change helped or hurt.

None of this is glamorous. It is the agent equivalent of writing tests and reading logs. But it is the difference between an agent that demos well and an agent you can actually leave running.

Quiet Failure Is a Trust Problem

The deeper issue is what quiet failure does to trust.

A loud failure is almost a gift. The agent crashes, you see the error, you fix it, you move on. You know exactly where you stand.

A quiet failure erodes something harder to rebuild. The agent hands you a confident, finished, wrong result, and you only find out later, after you have acted on it. Do that a few times and the user stops trusting any output, even the correct ones. They start re-checking everything by hand, which defeats the entire purpose of the agent.

An agent you have to fully re-verify is not saving you work. It is adding a step.

The whole value of an autonomous workflow is that you can trust the parts you did not watch. That trust is not earned by a good demo. It is earned by a system that catches its own mistakes and tells you when it is unsure.

The Bottom Line

The flashy part of agent building is the capability. Watch it browse, write code, call APIs, chain tools, finish the job.

The part that decides whether it survives contact with real work is quieter. It is the measurement underneath: the evals, the traces, the step-level checks, the honest reliability numbers.

Agents do not usually fail loudly. They fail in the middle, with a clean face, in a way that passes the checks you remembered to write.

So write the checks you would rather not think about. Measure the steps, not just the endings. Treat every quiet failure as the next test case.

The agents that win will not be the ones that demo best.

They will be the ones you can prove are right.

It is the boundary.

What can it read? What can it change? Which tools load by default? Which actions need approval? Which systems are simply not in scope?

That used to sound like security plumbing. Necessary, but boring. Something you handled after the product worked.

I think that is backwards now.

Agent permissions are becoming product design.

When a tool can write code, browse the web, operate a browser, run a terminal, call APIs, remember context, trigger workflows, and delegate work to other agents, the permission surface is no longer a back-office detail. It is the shape of the experience. It determines how much the user can trust the agent, how much the agent can do without asking, and how easy it is to understand what happened after the work is done.

This is why I found the recent Hermes Agent Blank Slate setup interesting. The feature starts from a minimal agent, then asks you to opt into capabilities instead of quietly loading everything. No web, browser, code execution, vision, memory, delegation, cron, skills, plugins, or MCP servers unless you choose them. The details are specific to Hermes, but the pattern is bigger than one tool.

The default future should be opt-in capability.

Not because agents are useless without access.

Because access is the product.

Every Tool Changes the Job

It is tempting to describe an agent by its intelligence.

This model is better at reasoning. That one is better at code. This setup has a longer context window. That one has lower latency.

All of that matters, but it misses the operational truth. An agent with no tools is mostly a thinking partner. An agent with file access is a reviewer. An agent with terminal access is a builder. An agent with browser control is a tester. An agent with production API credentials is an operator. An agent with scheduling, memory, and delegation is a process.

Each new permission changes the job you are assigning.

That means each permission should change the product surface too.

If the agent can only read files, the interface can be lightweight. If it can delete data, the interface needs stronger consent. If it can call payment APIs, the workflow needs clear policy and audit trails. If it can install MCP servers, the product needs to explain what those servers expose and what downstream systems they can reach.

The user should not have to reverse engineer the blast radius.

Good products make the boundary visible.

Defaults Teach Users What Is Safe

Defaults are not neutral.

When an agent ships with every tool enabled, it teaches the user that broad access is normal. When it starts locked down and asks for capabilities as the task needs them, it teaches a different habit: grant the smallest useful permission, then expand only when the work proves it needs more.

That is the AI version of progressive disclosure.

The product does not need to dump a security lecture on the user. It just needs to make the next safe step obvious.

Want the agent to summarize a repo? Read access is enough.

Want it to fix a bug? It needs write access and a test command.

Want it to verify a UI? It needs a browser and maybe a local server.

Want it to publish? That is a different level of trust.

Each step should feel like a deliberate escalation, not a hidden side effect of installing the tool.

This is also where the "power user" argument gets weak. Power users do want speed, but they also want predictability. They do not want to inspect a settings file after every update to see whether new tools appeared. They do not want an agent to gain browser, memory, or plugin access because a vendor decided the new default would be more impressive in a demo.

Fast is good.

Predictable is better.

MCP Makes This More Urgent

The Model Context Protocol made agent tooling feel composable. That is useful. It also means capability can spread quickly.

An MCP server can expose data, tools, prompts, and workflows through a standard interface. That makes it easier to connect agents to real systems. It also creates a new class of product question: when the agent connects to a server, what exactly did it gain?

The official MCP security guidance focuses on things like consent, token handling, confused deputy risks, session security, and scope minimization. The authorization draft also pushes clients toward least-privilege scope selection and step-up authorization when more access is needed.

That language sounds technical because the implementation is technical.

But the user experience problem is plain.

Do not make users approve a black box.

If an agent is connecting to a GitHub MCP server, the user should know whether the agent can read public repos, read private repos, open issues, create branches, push code, or trigger workflow runs. Those are different permissions. They deserve different consent, different defaults, and different review paths.

The NSA's May 2026 MCP security guidance makes the broader point: as MCP adoption spreads into production workflows, the security model needs implementation rigor and clearer boundaries. That is not just a warning for security teams. It is a design brief for everyone building agent products.

The product has to translate capability into judgment.

The Best Permission UI Is Operational

Most permission screens are bad because they are abstract.

They ask for access to "files" or "tools" or "workspace resources" without explaining what the user is actually trying to do. The result is a familiar consent problem: users click approve because the product blocks progress, not because the decision is meaningful.

Agent products can do better because the agent usually has a task.

Tie permissions to the task.

"To update this blog post, I need write access to src/data/blog-posts and permission to run the focused data test."

That is useful.

"To debug this failed checkout flow, I need browser control, local server access, and permission to edit files under src/pages and src/components."

That is useful too.

The permission request should name the outcome, the resources, the action level, and the proof the agent will leave behind. If the agent asks for more access later, it should explain what changed.

This turns permissioning from a modal into part of the workflow.

The boundary becomes inspectable.

Capability Should Expire

One subtle mistake in agent design is treating permissions as permanent identity.

Humans log into a tool and keep their access. That works because organizations have identity systems, managers, offboarding processes, and audit policies. Even then, stale access is a constant problem.

Agents make stale access worse because their work is often task-shaped.

An agent may need write access to a repo for one bug fix. It may need a browser for one QA pass. It may need a calendar integration for one scheduling task. That does not mean it should keep those capabilities forever.

The better default is task-scoped access.

Grant the capability for this run. Record why it was granted. Revoke it when the task completes. Ask again if the next task needs it.

That may sound slower, but it creates a cleaner mental model. The user stops thinking, "This agent has my environment." They start thinking, "This task has these capabilities."

That is a safer product.

It is also a clearer one.

Trust Comes From Boring Boundaries

The AI demos that get attention usually show an agent doing a lot.

It opens tools. It clicks around. It writes code. It sends messages. It books things. It looks alive.

The workflows that survive in real teams will be more boring.

They will show exactly what the agent can touch. They will keep destructive actions behind approval. They will separate read from write. They will make capability changes visible in review. They will log the actual tool calls. They will make it easy to replay why the agent did something.

That is not anti-autonomy.

That is how autonomy becomes usable.

If I cannot tell what an agent was allowed to do, I cannot trust what it did. If I cannot see when its permissions changed, I cannot review the work responsibly. If every task starts with broad access, I have to treat every task as high risk.

Good boundaries lower the review burden.

They make the agent's work smaller, clearer, and easier to approve.

Builders Should Design the Permission Ladder

If you are building agent workflows, I would start with a simple exercise.

Write down the permission ladder for your product.

Not the settings page. The ladder.

What can the agent do with no access? What can it do with read access? What can it do with write access? What requires browser control? What requires network access? What requires external credentials? What requires human approval every time?

Then design the product around those steps.

Make the first step useful. Make escalation contextual. Make dangerous capabilities rare and visible. Make revocation normal. Make the audit trail part of the happy path.

The goal is not to scare users away from powerful agents.

The goal is to make power legible.

The best agent products will not be the ones that ask for everything up front. They will be the ones that earn access as the work demands it.

The Bottom Line

Agents are becoming capable enough that permissions can no longer be treated as a checkbox in settings.

Permissions define the work. They shape the user's trust. They decide whether an agent feels like a helpful operator or an unpredictable process with too much reach.

The next generation of AI workflow tools will compete on models, speed, integrations, and UX polish. But underneath all of that, the real product question will be simple:

What can the agent touch, and why?

Answer that well, and the agent feels powerful.

Answer it poorly, and every new capability becomes another reason to hesitate.

Not because the model got smarter.

Because the work got less ambiguous.

Most people still treat agent delegation like prompt craft. They keep trying to find the perfect sentence, the magic wording, the clever instruction that makes the model behave. I get the instinct. When the interface is a text box, it is natural to believe the answer is a better text box input.

But that is not how real delegated work gets better.

If a human teammate kept making inconsistent decisions, you would not solve it by giving them a prettier paragraph every morning. You would give them context. You would show them the expected path. You would name the edge cases. You would define when to stop and ask. You would make the work inspectable.

That is a runbook.

And for agent workflows, runbooks are starting to matter more than prompts.

Prompts Are Not Enough

A prompt describes what you want right now.

A runbook describes how the work should be done every time.

That distinction matters because the biggest agent failures I see are not caused by a lack of raw intelligence. They are caused by missing operating context.

The agent changes the right file but verifies the wrong behavior. It fixes the visible bug but misses the product constraint. It keeps digging after the task is already complete. It treats a flaky test as a code problem. It stops at a plan when the task clearly needed implementation. It implements the request but forgets to leave a useful handoff.

These are not prompt wording problems.

They are workflow design problems.

The model needs to know more than the goal. It needs to know the local rules of the system it is operating inside. Which commands prove success. Which files are dangerous. Which tests are worth running. Which changes should stay out of scope. Which blocker is real enough to stop work.

That information does not belong in a one-off prompt.

It belongs in a reusable operating guide.

The Runbook Is the Interface

The more agents operate software environments, the more the runbook becomes the actual interface between human intent and machine work.

The codebase is not enough. The ticket is not enough. The chat history is not enough. Each one has pieces of the truth, but none of them reliably tells the agent how to move through the work.

A good runbook does.

It turns vague delegation into a bounded loop:

• ▸What is the outcome?
• ▸What context should be read first?
• ▸What is explicitly out of scope?
• ▸What is the smallest useful verification?
• ▸What counts as a blocker?
• ▸What evidence should be left behind?
• ▸Who owns the next step?

That sounds simple, but it changes the shape of the work.

Without a runbook, the agent has to infer the workflow from scattered clues. Sometimes it guesses well. Sometimes it confidently follows the wrong path.

With a runbook, the agent has a track to run on. It can still make mistakes, but the mistakes become easier to spot because you can compare what happened against an expected process.

That is the beginning of trust.

My Smallest Useful Runbook

The most useful runbooks I write are not long documents. They are usually small, sharp, and boring.

For a coding task, the skeleton looks something like this:

1. 1.Read the issue and the latest comment first.
2. 2.Inspect the existing code before proposing changes.
3. 3.Keep the edit scoped to the requested behavior.
4. 4.Use the repo's existing patterns unless there is a clear reason not to.
5. 5.Run the smallest verification that proves the change.
6. 6.Do not revert unrelated work.
7. 7.Leave a handoff with changed files, verification, and remaining risk.

That is not a prompt trick. It is an operating contract.

The exact details change by project. A frontend task might require screenshots. A database migration might require rollback notes. A security fix might require a test that proves the boundary fails closed. A content task might require checking the publish date field instead of trusting the PR description.

The point is not to write one universal agent manual.

The point is to make the repeatable parts of the work explicit.

Runbooks Create Better Stops

One of the underrated parts of delegation is knowing when work should stop.

Agents are good at continuing. That is useful until it is not.

An agent can keep refactoring because it sees adjacent cleanup. It can keep trying tests because the failure looks solvable. It can keep changing copy because there is always a smoother sentence. It can keep exploring because the repo has more context to read.

Humans do the same thing, but humans usually have more ambient judgment about when the extra motion is no longer worth it.

Runbooks give agents better stop conditions.

Stop when the focused test passes and the change is narrow. Stop when the blocker is outside this environment. Stop when the next action belongs to another agent. Stop when the task asks for a review and no code change is needed. Stop when the open PR already satisfies the issue and the remaining work is a reviewer decision.

This matters because productivity is not just about making agents move faster.

It is about making sure they stop in the right place.

The Proof Matters More Than the Claim

The best runbooks also define what proof looks like.

"I fixed it" is not proof.

"The blog post is added" is not proof.

"The PR is open" is closer, but still incomplete if the post was not wired into the index, the date is wrong, or the route is missing from prerendering.

Useful proof is specific:

• ▸The new file exists at the expected path.
• ▸The slug is exported in the post registry.
• ▸The dateISO is the next Tuesday.
• ▸The focused data test passes.
• ▸The PR URL is recorded.
• ▸The review owner has a real next action.

The proof changes by task, but the principle does not.

If you want agent work to become reliable, do not just ask for the outcome. Ask for the evidence that the outcome is real.

This is where a lot of AI workflows quietly fail. The agent produces plausible completion language, and the human has to reconstruct whether anything actually worked. That burns the time the agent was supposed to save.

Runbooks make the verification trail part of the work, not an optional afterthought.

Repetition Is Where Agents Get Useful

The first time you write a runbook, it can feel slower than just asking the agent to do the task.

That is true if the task will never happen again.

But most valuable work is repetitive. Not identical, but similar enough that the same operating shape appears over and over.

Write a weekly blog post. Review a PR. Fix a failing check. Generate a social calendar. Audit a permission boundary. Triage a bug report. Test a mobile flow. Prepare a release note. Verify a customer issue.

These are not one-off miracles. They are loops.

Loops deserve runbooks.

Once the loop is written down, every future task starts with better defaults. The agent reads less random context. It makes fewer avoidable decisions. It leaves a better handoff. You spend less time correcting process and more time reviewing judgment.

That is the compounding effect.

A prompt helps once.

A runbook improves the next hundred runs.

The Human Job Moves Upstream

The objection I hear is that this sounds like process overhead.

It can be, if you turn every agent task into a ceremony.

But the good version is lightweight. A useful runbook is not bureaucracy. It is compressed judgment.

You are taking the lessons you already learned the hard way and putting them where the agent can use them. Do not touch these files. Always check this field. Use this command first. Ask for approval before this class of action. Prefer a child issue over polling. Keep the final answer short but include verification.

That is not paperwork.

That is operational taste.

And it is one of the human skills that gets more important as agents get more capable. The better the agent is at moving, the more valuable it becomes to define the lane, the guardrails, and the finish line.

The future builder is not just a prompt writer.

The future builder is a workflow designer.

What I Would Start With

If you are using agents today, do not try to build a huge operating manual.

Start with the task that repeats and still annoys you.

Pick one. Write the tiny runbook. Include the context to read, the boundaries, the verification, and the stop conditions. Use it twice. After each run, add the one instruction that would have prevented the most recent mistake.

That is enough.

The document will get better because the work will teach you what it needs.

The agent will get better because the work will stop depending on hidden context in your head.

And you will get better because you will be forced to separate the outcome you want from the process that reliably produces it.

That separation is the whole game.

The Bottom Line

Better prompts can improve an agent task.

Better runbooks improve the agent system.

That is the shift I care about. AI agents are not just text generators anymore. They are software operators moving through repos, terminals, browsers, queues, and review paths. If we want that work to be useful, we have to give them more than a clever request.

We have to give them a way to work.

Tiny runbooks are how that starts.

It is that models can find more bugs than humans can responsibly process.

That is the part that changes how builders should think about software. For years, security work was constrained by discovery. Could someone find the vulnerability? Could they reproduce it? Could they build an exploit? Could a small team afford enough expert review to catch the important issues before attackers did?

Now that bottleneck is moving.

Anthropic's recent Project Glasswing update is the clearest signal yet. The company says Claude Mythos Preview and its partners found more than 10,000 high- or critical-severity vulnerabilities across major software systems. In open source alone, Anthropic says it scanned more than 1,000 projects and surfaced thousands of serious findings, with human triage becoming the slow part.

You do not have to take every number at face value to see the shape of the shift.

AI is making vulnerability discovery cheaper. That sounds like good news, and it is. But it also means every software team is about to face a harder question:

What happens when the scanner is faster than the organization?

The Patch Window Is the Product Now

Security used to have a familiar rhythm. A bug was found. A report was filed. A team reproduced it. Someone argued about severity. Someone wrote a patch. Users eventually upgraded.

That process was never fast enough, but it mostly matched the speed of human discovery.

AI breaks that balance.

If models can search codebases, reason about exploit paths, generate reports, and repeat that work across thousands of projects, then finding bugs stops being the scarce skill. The scarce skill becomes the system around the finding:

• ▸Can you tell which reports are real?
• ▸Can you prioritize the ones that actually matter?
• ▸Can you patch without breaking production?
• ▸Can you ship fixes before attackers learn the same thing?
• ▸Can you keep maintainers from drowning in low-quality reports?

That is the new security stack. Not just detection. Response capacity.

A vulnerability that sits untriaged for three weeks is not meaningfully safer because an AI found it. In some cases, it is riskier, because the same class of model may soon make the path to exploitation easier for everyone else.

The patch window is not an operational detail anymore. It is part of the product.

AI Does Not Remove Security Work

There is a lazy version of the story where AI agents make security easy.

Run the model. Get the report. Apply the patch. Done.

That is not how real systems work.

Real systems are full of tradeoffs. The obvious fix can break an integration. The technically correct fix can create a migration problem. The most severe-looking vulnerability might be unreachable in production, while the boring one in a forgotten admin path is exposed to the internet.

AI can help find and explain these problems. It can write a first patch. It can generate a regression test. It can compare similar code paths and look for variants.

But someone still has to own the decision.

That is the same pattern I keep seeing across AI-assisted building. The manual work shrinks, but the judgment work expands. The operator has to decide what deserves attention, what can wait, what risk is acceptable, and what needs a deeper human review.

Security is just where this becomes impossible to ignore.

The Dangerous Middle

There is a period we are entering that feels especially unstable.

Eventually, AI should make software much safer. Every serious codebase should have agents continuously searching for vulnerabilities, proposing patches, generating tests, and checking whether fixes actually landed. That world is better than the one we have now.

But the transition is messy.

The discovery side is improving faster than the response side. That creates a gap. More findings, more reports, more possible attack paths, more pressure on teams that already do not have enough security capacity.

This is especially painful for open source.

A large company can assign security engineers, rotate incident response, and fund dedicated tooling. A maintainer with a popular library might be doing all of this after work, for free, while also reviewing feature requests and answering issue comments. Dumping hundreds of AI-generated reports into that maintainer's inbox does not automatically make the ecosystem safer.

It might make it worse unless the reports are high quality, reproducible, prioritized, and paired with patches that are easy to review.

AI security only works if it respects the human throughput on the other side.

What Builders Should Change Now

If you are building with AI agents, this is not just a cybersecurity industry story. It changes the default operating model for anyone shipping software.

The old advice was "move fast and break things." The AI-era version needs an asterisk:

Move fast, but build a system that can notice what broke.

That means security cannot be a quarterly cleanup pass. It has to live inside the same loop as product work.

1. Treat every AI-generated change as reviewable work

AI code should not feel like magic output. It should feel like a pull request from a very fast junior-to-mid-level engineer who sometimes has excellent instincts and sometimes misses the reason the system is shaped the way it is.

Review it. Ask what changed. Ask what assumptions it made. Ask what surfaces it touched. If a change affects auth, payments, permissions, file handling, secrets, user data, or external integrations, slow down.

Fast does not mean casual.

2. Make tests prove the risky behavior

AI is good at producing tests that increase coverage and bad at knowing which behavior deserves proof unless you tell it.

For security-sensitive changes, generic tests are not enough. Ask for tests that prove the boundary:

• ▸A user cannot access another user's data
• ▸A disabled feature cannot be invoked through an API path
• ▸A webhook cannot be replayed without detection
• ▸A malformed upload cannot escape its expected directory
• ▸A permission check fails closed, not open

These tests do more than catch regressions. They teach the agent what matters next time.

3. Keep a patch lane open

The teams that handle AI-era security well will not be the teams with the most findings. They will be the teams with the shortest path from confirmed issue to shipped fix.

That means knowing who can approve a security patch. Knowing which tests must run. Knowing how to ship a small hotfix without dragging in unrelated product work. Knowing how to communicate a change if users need to update.

If your process requires three meetings to patch a serious bug, AI did not solve your security problem. It just made the backlog visible.

4. Build less surface area

The most underrated security feature is not having the feature.

Every integration, admin panel, file parser, OAuth scope, background job, and public endpoint becomes another place where a model can find something interesting. AI makes it easier to build all of that. It also makes it easier to discover what you accidentally exposed.

This is another reason taste matters. Good builders cut surface area. They do not add settings because settings are easy. They do not expose APIs because the model can scaffold them. They ask whether the capability deserves to exist.

The safest code is still the code you never had to ship.

This Is Why Human Judgment Gets More Valuable

Every time AI makes a technical task cheaper, people assume the human role shrinks.

I think the opposite keeps happening.

When code generation gets cheaper, product judgment matters more. When content generation gets cheaper, taste and distribution matter more. When vulnerability discovery gets cheaper, triage and patch judgment matter more.

The bottleneck moves up the stack.

That is the lesson for builders. Do not measure your AI workflow by how much code it can produce or how many issues it can find. Measure it by how quickly it helps you make good decisions and ship the right fixes.

The future is not "AI finds every bug, so security is solved."

The future is closer to this:

AI finds more than you can handle. The winners are the teams that built the judgment, process, and restraint to handle the right things first.

The Bottom Line

Project Glasswing is a preview of a much larger shift. Software is entering an era where the cost of finding flaws drops dramatically, while the cost of responsibly fixing them remains stubbornly human.

That is uncomfortable, but it is also useful clarity.

If you are building with AI, do not wait for a security crisis to design your response loop. Review agent-written code like it matters. Test the boundaries. Keep patches small. Reduce surface area. Build a process that can absorb uncomfortable findings without freezing.

AI made bugs cheap to find.

Now the hard part is proving you can fix them.

It is that they are starting to operate computers.

That sounds like a small distinction until you feel it in the workflow. A code generator lives inside a text box. It waits for a prompt, returns a patch, and leaves the rest of the job to you. A software operator can inspect the app, click through the broken flow, read the console, run the server, reproduce the issue, change the code, and check whether the thing actually works.

That is a different kind of tool.

OpenAI's May 29 Codex update points in that direction. Codex now supports computer use on Windows in the Codex app for eligible users, so it can see, click, and type in Windows applications while testing and refining software. The same release also expands remote control, letting a user steer work from ChatGPT on mobile or Codex on Mac while the Windows machine remains the host for the project files, shell, app server, and local context.

I do not think the important part is Windows support by itself.

The important part is the new shape of work.

Coding Was Never Just Typing

For a while, the AI coding story was mostly about generation. Could the model write a component? Could it scaffold an API route? Could it refactor a file without losing the plot?

Useful, but narrow.

Real software work has always been messier than text generation. You open the app. You notice the layout is wrong. You click a button. Nothing happens. You check the terminal. The dev server crashed. You restart it. The page loads, but the empty state is off. You resize the browser. The mobile nav breaks. You skim the network tab. The request is fine, but the UI state is stale.

None of that is "write code" in the pure sense.

It is operating the system around the code.

That is why computer use matters. It gives the agent access to the loop that human engineers actually live in: observe, diagnose, change, verify. The text editor is only one stop in that loop.

The IDE Is Too Small

The IDE was a natural starting point for AI coding tools because code is text. Put the model near the text and it can help.

But the product surface of software is not the IDE. It is the browser, the terminal, the database, the logs, the design tool, the cloud dashboard, the test runner, the email preview, the mobile simulator, and sometimes a random desktop app that only exists because some enterprise workflow depends on it.

If the agent can only see the repository, it is always working from a partial truth.

It can infer what should happen. It can read tests. It can inspect types. It can even run commands if the environment allows it. But it cannot fully understand the gap between the code and the experience unless it can look at the experience.

This is why frontend work has been such a revealing test. A model can produce valid React and still ship an interface that feels wrong. It can pass tests and still overlap text on mobile. It can implement the requested behavior and miss that the loading state jumps the layout.

The browser catches what the diff cannot.

An agent that can look, click, and iterate has a better shot at closing that gap.

Remote Control Changes the Cadence

The remote-control part may end up being just as important as computer use.

When an agent can keep working on the host machine while you check in from somewhere else, the job starts to feel less like a chat session and more like delegated work. You do not need to sit there watching every command. You can let the agent run until it hits a decision point, then answer the question, redirect it, or approve the next step.

That changes the cadence of engineering.

The old cadence was synchronous. You were either coding or you were not. If you stepped away, the work stopped.

The new cadence is supervisory. You define the goal, give the agent enough context, and let it move through the loop. Your job is to keep the judgment layer alive. Is this still the right approach? Did it choose the right tradeoff? Is the patch too broad? Did it verify the thing that matters?

That is closer to managing a capable junior engineer than using autocomplete.

And like managing a junior engineer, the value depends on the quality of your delegation.

The Risk Moves Too

There is a tempting version of this story where more agent autonomy simply means more productivity.

That is not the full picture.

An agent with computer use has a wider action surface. It can click the wrong thing. It can misunderstand a modal. It can test against the wrong environment. It can mistake a locally cached state for a real fix. It can spend time polishing the visible symptom while missing the deeper bug.

More access is only useful when the workflow has boundaries.

That means you still need clear permissions, disposable environments, human approval for risky actions, and a review process that treats agent work like real work. Especially when the agent is touching systems outside the editor.

The mistake is assuming that because the agent can operate more of the computer, it should be allowed to operate everything.

Good delegation is scoped. Give the agent a sandbox. Give it the app server, the browser, the test suite, and enough project context to make progress. Keep production credentials, irreversible actions, billing changes, and sensitive user data behind a stronger gate.

The point is not to make the agent fearless.

The point is to make it useful without making it dangerous.

The Best Workflows Will Be Visible

As agents become more operational, the winning workflows will be the ones that make the agent's work easy to inspect.

I want to see what it tried. I want screenshots when the UI changes. I want terminal output when a test fails. I want a short explanation of why it chose one fix over another. I want the final diff to be boring and the verification trail to be clear.

This is the difference between autonomy and trust.

Autonomy means the agent can move. Trust means I can understand what happened after it moved.

That is also where many teams will get the first productivity gains. Not from letting agents do huge open-ended tasks, but from handing them bounded loops:

• ▸Reproduce this bug and propose the smallest fix
• ▸Run the app and check the empty states
• ▸Add the test that proves this permission boundary
• ▸Verify this onboarding flow on mobile
• ▸Compare the implementation to the design and list mismatches

Those are not glamorous tasks. They are exactly the tasks that slow teams down every day.

Computer use makes them more delegable.

What Builders Should Do Now

If you are building with AI agents, I would not wait for the perfect tool before changing your habits.

Start by making your work easier for an agent to operate.

Keep local setup simple. Document the command that runs the app. Make tests deterministic. Write down the flows that matter. Keep secrets out of default environments. Add screenshots or acceptance criteria when the task is visual. Ask the agent to verify behavior, not just change files.

Most of this is just good engineering hygiene.

That is the recurring pattern with AI tools. The better your system is for humans, the better it tends to be for agents. Clear docs, clear tests, clear boundaries, clear review paths. AI does not remove the need for that discipline. It makes the payoff more obvious.

The agent leaving the IDE does not mean engineers leave the process.

It means the process needs to be legible enough that an agent can participate in it.

The Bottom Line

The next phase of AI coding is not about prettier autocomplete.

It is about agents that can operate the software environment around the code. They will run apps, inspect interfaces, respond to prompts, test changes, and keep moving while humans supervise from the judgment layer.

That is a big shift.

The IDE was where AI coding started because it was the easiest surface to understand. But software does not live in the IDE. It lives in the messy loop between code, runtime, product, and user experience.

Now the agents are entering that loop.

The builders who benefit most will not be the ones who hand over everything. They will be the ones who design tight, visible, reviewable workflows where agents can do real operating work and humans still own the decisions that matter.

Not "I stopped building." The opposite. More shipped. More got reviewed. More ideas made it from vague note to working software. But the actual implementation work - the typing, wiring, scaffolding, renaming, fixing imports, chasing test failures - increasingly happened somewhere else.

AI agents handled it.

The honest reaction is not pure excitement. It is stranger than that. Part of me feels more effective than ever. Part of me wonders if I am getting worse at the craft I spent years sharpening. If you do not use the coding muscle, does it atrophy? Probably. But I also think that is the wrong question.

The better question is: what skill is replacing it?

The Work Did Not Disappear

When people talk about AI coding, they usually frame it as automation. The machine writes code, so the human does less work. That is technically true and practically misleading.

The work did not disappear. It changed shape.

I still have to know what good looks like. I still have to understand the system well enough to spot a bad abstraction, a leaky permission model, or a feature that technically works but should not exist. I still have to decide which problems are worth solving and which ones are distractions wearing a product costume.

What I am not doing as much is the mechanical part:

• ▸Creating the fifth version of the same CRUD flow
• ▸Moving state between components because the first pass guessed wrong
• ▸Writing boilerplate tests for behavior that is already clear
• ▸Updating copy across three files
• ▸Chasing TypeScript errors caused by a renamed prop
• ▸Reading docs for the third-party integration and translating them into glue code

That work still matters. It is just no longer the highest-leverage place for me to spend my attention.

I Am Not Coding Less. I Am Delegating More.

The mental model that finally clicked for me is delegation.

For most of my career, "building software" meant converting intent into code with my own hands. I would hold the product shape in my head, make a series of implementation decisions, and type the thing into existence.

Now the workflow feels closer to leading a small implementation team:

1. 1.Define the outcome clearly.
2. 2.Point the agent at the relevant context.
3. 3.Review the plan before it writes code.
4. 4.Let it implement.
5. 5.Review the diff, the tests, and the behavior.
6. 6.Push back where the work misses the intent.

That is not passive. It is a different kind of active.

The quality of the output is still a reflection of the quality of the input. If I give an agent a lazy task description, I get lazy work back. If I give it the actual constraints, the edge cases, the product intent, and the shape of the existing system, the result is usually good enough to review like a normal pull request.

The job moved from "write the code" to "create the conditions where good code is likely to emerge."

The Weird Skill Loss Is Real

There is a cost here, and I do not want to hand-wave it away.

I am probably worse at remembering exact APIs than I was a year ago. I am less practiced at grinding through implementation details from a blank file. I feel the friction when I do drop back into the code editor and have to rehydrate the local context myself.

That is real.

But it is not the same as getting worse at engineering. It is closer to what happens when a senior engineer stops being the person who personally writes every line and starts being the person who sets direction, reviews work, and keeps the system coherent.

Some skills fade. Other skills compound.

The skills that feel more important now:

• ▸Taste: knowing which version of the product should exist
• ▸Context design: giving AI the right boundaries, examples, and constraints
• ▸Review judgment: spotting the subtle wrongness in code that passes tests
• ▸Systems thinking: understanding where a change belongs before anyone implements it
• ▸Risk calibration: knowing when AI output is fine and when it needs deep scrutiny

Those are not softer skills. They are the skills that decide whether AI-generated work becomes leverage or liability.

The Dangerous Part Is Feeling Fast

The biggest risk in this workflow is not that AI writes bad code. Bad code can be reviewed, tested, and fixed.

The bigger risk is that AI makes bad decisions feel cheap.

When implementation is expensive, you naturally hesitate. You ask whether the feature is worth it. You think about maintenance. You negotiate scope because every extra requirement costs real time.

When implementation feels almost free, the discipline has to come from somewhere else. You need stronger taste, not weaker. You need to say no more often, not less. Otherwise you end up with a product full of features nobody needed, all shipped efficiently.

That is the operator lesson I keep coming back to: AI removes implementation friction, so judgment becomes the bottleneck.

This matters a lot for what we are building at poof.new. If someone can describe an app and get working software back, the scarce skill is no longer syntax. It is intent. The builder has to know what they want, why it matters, and how to tell whether the result is actually good.

AI can make software real. It cannot tell you whether that software deserves to exist.

What My Day Looks Like Now

A typical building day used to start with me opening the editor and finding the first file to change.

Now it starts with writing a better task.

I spend more time turning fuzzy ideas into crisp implementation briefs. I describe the user outcome, the current behavior, the desired behavior, the files that probably matter, the constraints that cannot be violated, and the tests that should pass when the work is done.

Then I review the plan.

This is the step I used to undervalue. Plan review is where most AI work succeeds or fails. If the plan reveals a wrong assumption, I would much rather catch it before the agent rewrites half the feature. A five-minute correction at the plan stage can save an hour of cleanup later.

Once the PR exists, I review it in layers:

• ▸Does the behavior match the intent?
• ▸Is the implementation consistent with the existing system?
• ▸Did it add unnecessary abstraction?
• ▸Are the tests proving the right thing?
• ▸Is there any security or data exposure risk?
• ▸Would I be comfortable owning this code six months from now?

That last question is the anchor. AI can write the code, but I still own the consequences.

The New Builder Is More Editor Than Typist

There is an old romantic version of programming where the builder sits alone, enters flow state, and produces perfect software through direct contact with the machine.

I still love that feeling. I do not think it is going away entirely. There will always be moments where the fastest path is to open the file and make the change yourself.

But for a growing slice of product work, the highest-leverage builder looks less like a typist and more like an editor:

They know what to ask for. They know what to cut. They know when the first draft is good enough and when it is structurally wrong. They can look at a pile of generated work and see the one decision that needs to change.

That is not less creative. It is more like the creativity moved earlier in the process.

The blank page is not the code editor anymore. The blank page is the instruction.

The Bottom Line

I have not touched much code in a month, and I am trying to be honest about both sides of that.

Yes, some hands-on sharpness fades when AI handles the implementation reps. If I had to sit down tomorrow and rebuild a feature entirely from scratch, I might feel slower than I used to.

But I am also shipping more, thinking more clearly, and spending more of my time on the parts of building that actually determine whether the work matters.

So no, I do not think AI made me dumber.

It made me more aware of which parts of my intelligence were being spent on low-leverage work.

The goal is not to never code again. The goal is to make code the last mile, not the whole journey. And once you experience that shift, it is hard to go back.

But I haven't been fully honest.

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

This is that version.

What's Genuinely Better

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

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

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

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

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

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

The "Are You Sure?" Moment

The thing I miss most is the challenge.

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

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

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

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

Complementary Taste

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

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

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

The Accountability Gap

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

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

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

The Energy Problem

This one surprised me.

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

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

What I've Learned

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

What I've started doing instead:

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

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

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

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

Build Solo, But Don't Build Alone

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

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

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

Ship it yourself. But find your people first.

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

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

The Biggest Lie in Tech

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

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

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

Building Isn't the Bottleneck Anymore

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

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

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

What Distribution Actually Means

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

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

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

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

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

The Distribution Divide

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

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

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

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

Building Distribution Before You Build the Product

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

1. Build in Public

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

2. Own a Narrative

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

3. Give Away Your Best Ideas

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

4. Choose One Channel and Go Deep

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

AI Can't Distribute For You

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

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

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

The New Stack

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

In 2026, the stack looks different:

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

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

The Question You Should Be Asking

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

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

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

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

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

It was also completely useless. Nobody wanted it.

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

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

Execution Is No Longer the Hard Part

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

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

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

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

What Taste Actually Means

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

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

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

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

The AI Taste Gap

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

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

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

That pushback is where taste lives.

Three Things I've Learned About Taste

1. Taste is mostly about removal

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

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

2. Taste requires contact with real users

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

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

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

3. Taste compounds like interest

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

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

What This Means for Engineers

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

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

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

The New Competitive Advantage

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

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

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

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.

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.

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.

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?

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.

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.

The Task & Initial Plan 🚀

My instruction to Devin was simple:

Implement the backend API based on this documentation [link to 3P website]. Add it to [microservice API name]. Utilize the existing CDK secrets logic to store the 3P API Key.

Devin's response was almost immediate:

• ▸Understanding the goal: It parsed my request and the service docs, and quickly outlined a plan to create the token-generation endpoint.
• ▸Collecting details: Devin identified required endpoints and data (thanks to the link I gave) and noted it would need to handle authentication, token storage, etc.
• ▸Generating a plan: Before writing code, Devin presented a high-level game plan. This included creating a new route in our backend, calling the third-party API for the token, and returning the result to our app. I was impressed – the plan was thorough and made sense given the task.

In essence, Devin did a great job figuring out what needed to be done without me hand-holding the requirements. It felt like I was working with an autonomous engineer who eagerly drafts a design spec after a short request.

From Prompt to Pull Request 💻

With the plan in place, I gave Devin the green light. It jumped into coding mode. Within minutes, Devin had opened a GitHub pull request on our repository with the new API implementation. I could follow its progress in real-time through Devin's interface. (The UI actually provides a step-by-step log of what the AI is doing – very cool!).

Watching Devin work was surreal. The UI/UX of the tool is amazing – it felt seamless and intuitive to use. As one early user noted, "Devin feels UI/UX first, not GenAI first," emphasizing that the surrounding experience is the star. I have to agree. In my case, giving instructions felt as easy as chatting with a colleague, and I could see Devin's thought process and actions clearly. The combination of a chat interface, an embedded code editor, and live updates made it feel like pair-programming with a supercharged junior dev.

Soon, the PR was ready for review. The code Devin produced was surprisingly solid for a first pass. It had set up the new API endpoint, made calls to the third-party service, and hooked everything into our backend. All of this happened while I was hands-off.

Hiccups and Iterations 🛠️

Of course, it wasn't perfect out of the box. Upon reviewing the pull request, I spotted a few issues that needed addressing before this code could go to production. Notably:

• ▸Missing API key logic: Devin forgot to include the authentication API key when calling the third-party service. A human engineer knows that's a must for the request to succeed, but the AI overlooked this detail on the first try.
• ▸Code style differences: Some of the naming conventions and formatting didn't match our project's style guidelines. (Minor issue, but something we'd fix in any code review – even with human contributors.)
• ▸Best practice tweaks: I noticed that the API logic for calling the 3P service should have been abstracted into our "clients" library. While Devin's solution was functional, integrating this logic into the shared library would improve maintainability and align with our standards.

The great thing was that, addressing these issues felt very natural. I went into the PR on GitHub and dropped comments exactly like I would for a human colleague. For example, I pointed out where the API key should be injected, suggested where to move code around, and reminded to clean up some unneeded additions.

Devin took this feedback in stride. It truly felt like collaborating with a keen junior developer: I'd leave a note, and Devin would go off to fix it. Devin was eager to improve and quickly pushed new commits to the PR, incorporating my suggestions.

We went through about 2-3 iterations like this. Each cycle, I'd review the updates, find fewer things to tweak, and comment on the remaining issues. Devin would promptly address them. After this iterative back-and-forth, the API code was production-ready. All tests passed, the style was consistent, and the integration worked flawlessly with the third-party service.

Time Trade-Off: 15 Minutes vs 1 Hour ⏱️

You might be wondering: Was using Devin worth it, time-wise? By the numbers, doing it myself would have been faster – roughly 15 minutes of coding versus about 1 hour to get it done via Devin (including the initial setup, waiting for the AI to do its work, reviewing the PR, and guiding the fixes). That's a 4x increase in wall-clock time for the task, which sounds like a loss in efficiency.

In fact, others have noted this current limitation of AI coding agents. The waiting and iterative feedback loop can indeed make the process longer than just writing the code yourself, especially for a simple task.

However, here's the catch: while Devin was working, I wasn't stuck waiting idly. During that 1 hour I was free to focus on other work. I answered a couple of messages, reviewed a different PR from a teammate, and even started brainstorming a design for an upcoming feature – all while Devin handled the heavy lifting for this task in the background.

In essence, that hour wasn't me twiddling my thumbs; it was more like delegating to a capable assistant. Yes, the calendar time was longer, but my personal time investment was much less than an hour of active coding. I probably spent only a few minutes giving instructions and about 5 minutes total reviewing and commenting. The rest of the time, Devin was on the job autonomously.

It's a trade-off: faster solo vs. parallelized teamwork. If I had 10 such small tasks in a sprint, I could theoretically assign them all to Devin and attend to bigger challenges, checking in occasionally for reviews. That ability to multitask is where a tool like this shows its value.

The UI/UX: A Smooth Ride 🎨

I have to come back to Devin's user experience, because it really enhanced the whole process. The interface made it super easy to interact with the AI:

• ▸I gave my instructions in a chat-like format (in our case, through Devin's Slack integration and then via GitHub PR comments). No complex setup or configuration; it was like talking to a teammate.
• ▸Devin kept me updated with a live log and even a "plan file" of notes. I could literally see what it was thinking – the steps it was taking, the commands it ran, files it created or modified, etc. This transparency is huge for trust when an AI is writing your code.
• ▸The pull request it opened was clear and well-structured. It included a description of what the change was and even referenced the task (just as a diligent dev would do).
• ▸When I left feedback, the UI (and GitHub integration) notified Devin immediately. It felt like the system was built around a smooth feedback loop, which is crucial. I commented and within a minute Devin's next update had the fix implemented.

The polish and thought put into Devin's UX did not go unnoticed. It didn't feel like using a clunky experimental tool; it felt like working in an environment built for developers' comfort. This level of refinement in developer tools is refreshing – it let me focus on the results rather than wrestling with the tool itself.

Final Thoughts: A Promising Co-Pilot, Not a Replacement 🚧

After this trial run, here's my reflection: Devin AI is not replacing engineers anytime soon, but it's certainly a promising co-pilot. The experience was akin to working with a supercharged junior engineer who can execute tasks and learn from feedback. It had its blind spots and needed guidance, but ultimately it delivered real value.

The limitations I encountered (missing a key detail, needing adjustments, slower turnaround) underscore that human expertise is still crucial. In real-world development, context and subtle requirements matter – things an experienced human developer intuitively catches, but an AI might miss without a proper prompt. I had to be the quality control, just like I would with a less-experienced team member. Devin isn't about to take over my job, and I wouldn't trust it to run completely unsupervised on anything critical just yet.

That said, the benefits were significant. By offloading a chunk of work to the AI, I freed up mental space and time. I found myself thinking more about what needed to be done, and less about the minute details of how to code it in the moment. It's a different way of working – more high-level orchestration, less in-the-trenches coding for certain tasks. As the creators of Devin intended, it's meant to be a collaborative helper rather than a threat.

For a first-gen AI developer agent, Devin exceeded my expectations in UX and autonomy. It felt like I had an eager intern who works blindingly fast and never gets tired, but occasionally needs me to double-check the work. I can live with that! The technology will only get better from here. With more polish and learning from each interaction, I imagine tools like Devin will handle bigger chunks of the development workload, and do so more reliably.

Bottom line: Devin AI isn't a replacement for an engineer – it's a new kind of teammate. Using it won't instantly halve your development time (yet), but it will change how you can allocate your time. I was able to focus on other priorities while it cranked out code. That kind of parallel productivity is game-changing if used right.

I'm excited to continue using Devin as a co-pilot for future projects. It's like having a junior dev in the background who speeds through the boring stuff and lets me concentrate on the fun and hard parts of engineering. Not perfect, but very promising. The future of development might not be "AI vs Human", but AI + Human, working in tandem – and my experience with Devin AI this week certainly makes me feel that way. 🚀👏

Wrong. 🚫

After waiting (and waiting… and waiting) for someone else to advocate for me, I realized I was approaching promotions all wrong. The truth is, no one will fight harder for your career growth than YOU. It's your responsibility to show your value, take ownership of your path, and create opportunities for yourself.

Here are the five biggest lessons I've learned about driving my career and earning my promotions.

1. You Own Your Career Path

It sounds obvious, but many professionals (my younger self included) mistakenly assume that their manager or team lead is responsible for charting their career progression. The truth? Nope. That's all on you. Your growth, development, and career path are in your hands. While managers can provide guidance, feedback, and opportunities, it's ultimately up to you to set goals, seek out learning experiences, and take the steps needed to advance.

That's not to say that some managers don't genuinely want to see you succeed—they absolutely do. But keep in mind, most managers are juggling their own set of responsibilities, goals, and ambitions. They may be focused on hitting deadlines, managing team performance, or achieving personal career milestones. As a result, even the most well-intentioned managers may not always have the time, resources, or bandwidth to give your career growth the dedicated attention it deserves. This is why it's crucial to take ownership of your own development.

Think of your career as a long-term project. You're the project manager. Success depends on setting goals, creating a roadmap, and consistently reviewing your progress. Want to move upward in your career? Ask yourself questions like:

• ▸What roles interest me in the next 2 or 5 years?
• ▸What skills do I need to develop to land those roles?
• ▸Who can help me achieve these goals?

The moment you adopt a proactive mindset, you start taking control of your trajectory. Don't wait for someone to hand you a blueprint. Draft one for yourself and take the lead.

2. Document Your Wins Religiously

People love a good story, and your career is no different—it's up to you to craft a compelling narrative. That narrative begins with documentation. Every single achievement, no matter how small, deserves a record.

Implemented a new software feature? Write it down. Resolved a high-stakes bug right before launch? Document it. Improved a process that saved your team time or reduced costs? Log it.

Why is this important? When promotion discussions happen (or interview panels for a new job roll around), you'll have concrete examples to prove your value:

• ▸Outline the problem you solved.
• ▸Highlight your actions.
• ▸Summarize the results (bonus points for measurable outcomes like percentage improvement or dollars saved).

Your wins demonstrate your growth and impact. They're your ultimate receipts. And when you bring them up in conversations, your contributions go from "implied" to undeniable.

3. Seek Out High-Impact Projects

Here's a truth bomb I wish someone had dropped on me earlier in my career: the work you do matters, but where you focus your energy matters even more. High-impact projects are your ticket to visibility and leadership opportunities.

What makes a project high-impact?

• ▸It solves a major pain point for your team or company.
• ▸It affects a large number of people.
• ▸It drives measurable results, like saving time, generating revenue, or improving efficiency.

Don't wait for these projects to come to you—volunteer for them. Offer to tackle that backlog no one wants to touch, spearhead a cross-functional initiative, or run an experiment that aligns with your company's top priorities.

Pro tip: High-impact projects also showcase your ability to handle bigger responsibilities, making it easier for decision-makers to envision you in advanced roles.

Relevant Aside: While high-impact projects often take center stage, it's important to recognize that in large companies, not all initiatives need to yield direct, measurable results to be valuable. A prime example of this lies in projects like redesigning or rewriting applications. These efforts, while not always critical in terms of immediate business outcomes, often become what's colloquially known as "promo projects." They give employees the opportunity to showcase their technical abilities, lead teams, or experiment with modern frameworks and tools — all of which can serve as stepping stones in career advancement.

The reality is, sometimes you have to play the game—it's about visibility and shaping the narrative. While redesigns or rewrites may not always yield clear, measurable ROI compared to maintenance or incremental updates, they capture attention. Being involved in these high-profile projects can position you as a forward-thinker, someone driving innovation or tackling significant challenges, even if the actual impact is more subtle. The key is finding a balance: embrace these promotional opportunities while also delivering meaningful, substantive work.

4. Build Relationships Across Teams

We've all heard the saying, "It's not what you know, but who you know." While skills and performance are crucial, relationships can play a big role in career growth.

Building relationships isn't about networking in the stereotypical sense (no one likes forced LinkedIn messages). It's about creating genuine connections with colleagues, managers, and leaders—within and beyond your immediate team.

Why does this matter?

• ▸Advocates and allies: People who see your potential can vouch for you during promotion or hiring discussions.
• ▸Opportunities: Opportunities often come from unexpected places, like collaborations or referrals from someone in another department.
• ▸Broader perspective: Understanding the challenges and goals of other teams enhances your ability to make a bigger impact in your role.
• ▸Promotion support during panels: Building relationships across teams can be crucial when promotion panels or reviews occur. Colleagues and leaders from other areas of the organization who know your work and value your contributions can provide key insights and endorsements.

Start simple. Attend cross-team meetings, schedule a coffee chat with someone who inspires you, or offer to help another department with your unique skillset. Relationships are the bridge between where you are and where you want to go.

5. Ask for Regular Feedback

Here's something I didn't realize early enough: Feedback isn't criticism; it's guidance. Regular feedback from managers and peers can help you refine your skills, avoid blind spots, and identify areas to improve before they become obstacles.

Don't wait for your annual performance review to ask, "How am I doing?" Instead, actively seek feedback throughout the year:

• ▸After delivering a major project or presentation, ask what went well and what could have been improved.
• ▸During 1-on-1 meetings, invite input on your performance and discuss how you can position yourself for growth.
• ▸Reach out to trusted colleagues for peer feedback on how you collaborate and contribute.

Remember, feedback is a dialogue, not a one-way street. Use it as a tool to learn, adapt, and grow continuously. Your willingness to evolve demonstrates maturity and leadership potential.

Bonus: Know Your Value and Advocate for Fair Compensation

Understanding your worth in the market is just as vital as pursuing career growth. Your skills, expertise, and contributions have tangible value, and recognizing this is the first step toward advocating for yourself. Research industry standards, salaries within your field, and the pay scales for your role to arm yourself with the knowledge needed to have open and constructive conversations about compensation.

While these discussions can feel daunting, they are necessary. Approach them with confidence and professionalism, outlining the impact you've made and why it merits fair recompense. Remember, advocating for your worth is not selfish—it's about ensuring a balanced exchange for your work and dedication.

Don't Wait—Own Your Narrative

Here's the truth no one (except maybe your most honest mentor) tells you: Career growth isn't just about being good at what you do. It's about showing your value, proving your contributions, and taking ownership of your narrative.

• ▸Advocate for yourself.
• ▸Showcase your skills and initiative.
• ▸Build relationships that bolster your career.
• ▸Seek opportunities to learn, improve, and grow.

Your next promotion? It's not a milestone in someone else's timeline. It's your achievement to claim. The moment you decide to take control of your career, you level up—a mindset, a skill, a role at a time.

Start now. Decide what's next for you, map your path, and show the world what you're capable of.

"Can you take on this extra feature?" Yes!

"Can we launch a week early?" Sure! Why not!

"Can you hop on a quick call at 9 PM?" Of course!

I thought saying yes to everything made me a team player—someone reliable, indispensable, and on-track for all the accolades. But more often than not, those yeses led me to tight deadlines, late nights, and some… creative technical workarounds (you know, the kind that makes future-you weep).

The turning point? Learning to say no. Or more often, the more diplomatic cousin of no:

• ▸"Yes, but we'll need to adjust the timeline."
• ▸"Yes, if we drop another lower-priority task."
• ▸"No, because that would introduce tech debt that will haunt us forever."

Turns out, strategic no's transformed me into a better engineer, a better teammate, and a much more effective professional overall. Here's why—and how you can harness the power of no to elevate your own work and sanity.

The Problem with Always Saying Yes

The tech world often glorifies the Yes Person. They're seen as flexible, eager, and a team player. But saying yes to everything has some hidden costs, particularly in fields like engineering and project management, where the stakes are consistently high.

Here's what unchecked yeses can lead to:

• ▸Burnout: Saying yes to more commitments than you have time for inevitably results in exhaustion. Constant late nights and rushed work don't lead to personal or professional growth—they just empty your tank.
• ▸Technical Debt: Agreeing to overly ambitious deadlines often means cutting corners. And what looks like success in the short term will leave your team paying interest on those decisions for years.
• ▸Chaos over Quality: When everything is a priority, nothing is a priority. Projects finished under the weight of "yes to everything" tend to lack the structure and finesse that truly stand out.

Ultimately, saying yes to everything doesn't make you a hero; it makes you a hazard—to yourself and your team.

Why Saying No is a Superpower

Saying no strategically isn't just about protecting your sanity (although, that's important too). It's about ensuring long-term success—for yourself, your projects, and your team.

Here's what saying no can do for you:

• ▸Prioritization: Establishing boundaries allows you to focus on the tasks that truly matter. Delivering one product milestone well beats delivering five poorly.
• ▸Preserving Quality: Fewer commitments mean more time to work thoughtfully and effectively on the things that count. Instead of sweating over quick fixes, you can build something to be proud of.
• ▸Realistic Planning: Pushing back helps prevent impossible timelines and stops burnout culture in its tracks. Deadlines grounded in reality are better for you, your team, and—surprise—for your leadership's trust in you.

The key lesson? Saying no isn't about being difficult or resistant; it's about ensuring decisions align with real constraints, shared goals, and long-term success.

How to Say No Without Burning Bridges

If the thought of saying no sends a wave of anxiety through your body, don't worry—you're not alone. Engineers, tech leads, and project managers alike often worry about how saying no might damage their reputation or relationships. But saying no doesn't have to come across as negative.

Here are practical ways you can say no while still being collaborative and solution-driven:

1. Frame It as a Yes-But

This is one of my go-to strategies. When a request lands on your plate, consider responding with a conditional yes. For example:

• ▸"Yes, I can take this on, but we'll need to extend the launch date by two weeks."
• ▸"Yes, but for this to be delivered on time, we'll have to postpone feature XYZ."

This shows you're being thoughtful and realistic while presenting solutions instead of obstacles.

2. Lean on Data

Pushback becomes a lot easier when it's backed by facts. For example:

• ▸"No, because adding this feature would introduce latency that exceeds our performance benchmarks."
• ▸"No, because we've already committed 12 developer hours to the sprint, and squeezing this in would put us over capacity."

Data makes the conversation less personal and more objective, which helps teammates and stakeholders understand your reasoning.

3. Prioritize Tech Debt

Get comfortable with saying things like:

• ▸"No, because rushing this will create tech debt that will haunt us down the line."
• ▸"No, because this violates our codebase standard and will slow development in future sprints."

Every tech lead or product owner encountering these perfectly logical reasons will breathe a secret sigh of relief (whether they admit it or not).

4. Practice Transparency

Don't just say no; explain the "why." Transparency builds trust. For instance:

• ▸"No, because I'm already loaded with task A and task B, and compromising quality isn't something I'm comfortable with."
• ▸"No, because this request requires resources we don't currently have allocated."

When people understand your reason, they're more likely to agree with your decision.

5. Default to Diplomacy

Sometimes, the classic "no" can feel abrupt. Instead, try softer alternatives that maintain rapport:

• ▸"That's a great idea, but I think we should revisit it after we finish XYZ."
• ▸"I wish I could help, but unfortunately, I can't commit right now."

You're upholding boundaries without creating friction.

Saying No is Saying Yes (to Better Things)

Every time you say no, you're simultaneously saying yes—to focus, quality, precision, and meaningful work. Balancing commitments isn't just healthier for you; it also strengthens your team dynamic and ensures your engineering output always shines.

The ironic truth? Learning to say no strategically makes you far more valuable—far more indispensable—than constant agreement ever could.

If you're reading this and thinking, "I am the Yes Person," don't worry. We've all been there. The beauty of this lesson is that it's never too late to start sprinkling in some thoughtful no's. The difference will amaze you.

Final Thoughts

Whether you're an engineer, a tech lead, or a project manager, mastering the art of saying no is one of the most powerful skills you can develop. Start small—be strategic—and watch how prioritizing quality over chaos transforms your career.

Remember, saying no isn't about shutting doors; it's about opening the right ones. Your best work—your truly impactful work—awaits on the other side.