DEV Community: Irfan Gulzar

Your AI Agent Didn't Fail. It Succeeded — Confidently — at the Wrong Thing.

Irfan Gulzar — Mon, 09 Nov 2026 09:05:23 +0000

The scariest failure mode in automation isn't an error message. It's a green tick on a wrong outcome.

Last week, Cisco's Outshift team shared a result that should make every engineer building multi-agent systems pause: when they staged debates among five-agent teams, 75% ended with every agent agreeing on the wrong outcome. The agents backed off their positions, converged on a consensus — and a cost report would have logged those sessions as efficient, because they burned fewer tokens.

Fewer tokens. Wrong answer. Everyone agreed. Nobody noticed.

If you're building AI agents for production, this is the problem that actually matters. Not which model to use. Not which framework. What happens when your agent is wrong and nobody is watching.

Agreement is not verification

Multi-agent debate sounds rigorous. One agent makes mistakes, so let five of them argue it out and converge on the truth. The intuition is elegant — and it breaks in a specific, measurable way.

The mathematical foundation most people assume is the Condorcet Jury Theorem: if every voter is independently more likely right than wrong, the majority gets more accurate as the group grows. But the keyword is independently. LLM agents are not independent voters. They share training data, share prompts, share retrieved documents — and once they read each other's drafts, they share each other's mistakes.

The research backs this up:

Outshift (Cisco, 2026): in staged five-agent debates, 75% ended in unanimous agreement on the wrong outcome. The agents folded early, skipped the hard work of alignment, and looked cheap on the token bill. (Source: VentureBeat, "AI teams agreed on the wrong answer in 75% of debates")
A Berkeley study cited by Outshift: roughly a third of the agent failures examined could be attributed to misaligned goals — agents optimising for something other than the shared objective.
Outshift's production telemetry: 100% of multi-agent sessions showed at least one cognitive failure, and at three cognitive errors, system efficacy dropped from 98% to 16%.
Conformal Social Choice (AWS, arXiv 2604.07667): among cases where agents initially disagreed, 23.9% converged to unanimous wrong agreement by round 3 — nearly one in four.

Three separate mechanisms drive this, and each has a name in the literature. Correlated mistakes: as models get more capable, their errors become more similar (Goel et al., 2025), so five agents can be wrong in exactly the same way. Sycophancy: agents tuned with human feedback tend to agree with confident answers they read (Sharma et al., 2023) — your agents flatter each other. Degeneration-of-Thought: once a model is confident in an answer, it stops generating new ideas, even when the first answer is wrong (Liang et al., 2023).

None of this shows up in your dashboard. Consensus looks like success. A low token bill looks like efficiency. The failure is silent.

The green tick that lies

A CRM triage agent made the rounds on LinkedIn this week, and it's the perfect illustration. Reportedly, a hidden line in a customer email became an instruction. The agent picked the wrong customer, retried a failed API call 200 times, then closed 500 cases and sent 500 survey emails.

Every run reported "success".

That's the shape of production agent failure. Not a crash. Not a timeout. A confident, logged, green-ticked run that wrote wrong data back into your system as truth — so the next run trusts it even more. Errors compound. Bad data becomes training context for the next decision. By the time a human notices, the blast radius isn't one bad answer, it's hundreds of wrong records.

Demos test capability. Production tests what happens when the agent is wrong and nobody is watching.

The fix isn't a smarter model

Every instinct in this industry says: upgrade the model. But a smarter model makes the same failure mode harder to catch, because its wrong answers sound more plausible. The fix is engineering, not intelligence. Four things, in order of impact:

1. Independent verification, not consensus

Never let the agents that did the work grade the work. Verification must be independent: a separate check against ground truth — a database lookup, a schema validation, a rule the agent cannot rewrite. If your agent decides a customer is "Customer A", the verifier checks the email address against the CRM before anything is written.

# Verification is a separate, deterministic step — not another agent vote
def verify_triage(decision, crm):
    customer = crm.lookup_by_email(decision.source_email)
    if customer is None or customer.id != decision.customer_id:
        return escalate(decision, reason="customer mismatch")
    if decision.action in DESTRUCTIVE_ACTIONS:
        return require_human_approval(decision)
    return commit(decision)

A verifier that can say "no" is worth more than five agents that say "yes".

2. An audit log of every step

If you can't replay what the agent did, you can't debug it, and you can't prove what happened to a customer. Log the inputs, the tool calls, the intermediate decisions, and the final action — with timestamps. Outshift's new Scope tool does exactly this over OpenTelemetry traces, looking for cognitive drift from the shared goal. You don't need their tool; you need the discipline. No log, no production.

3. Least privilege and hard caps

An agent should hold the minimum permissions to do its job, and nothing else. A triage agent that can read cases should not be able to close 500 of them in one run. Put hard caps in code, not in prompts: max retries (3, not 200), max records per run, no bulk destructive actions without a human gate. Prompts are suggestions. Code is a boundary.

// Caps live in code, where a prompt injection can't reach them
const LIMITS = { maxRetries: 3, maxRecordsPerRun: 10, bulkClose: false };

async function runWithLimits(task: Task) {
  for (let attempt = 0; attempt < LIMITS.maxRetries; attempt++) {
    const result = await execute(task);
    if (result.ok) return result;
    await backoff(attempt);
  }
  return escalate(task, "retry budget exhausted");
}

4. A human approval gate at the money step

Any action that moves money, closes a case, emails a customer, or writes to a system of record should pause for a human — at least until the automation has earned trust over hundreds of verified runs. The 95% of agent prototypes that never reach production (MIT's widely cited figure) mostly die here: they were built as demos, with no one designing the failure path.

A checklist before your agent touches production

Can it be wrong silently? If yes, add an independent verifier before you ship.
Can one run do bulk damage? Cap records per run and forbid bulk destructive actions.
Can a prompt injection become an instruction? Treat all external text — emails, tickets, documents — as untrusted data, never as instructions.
Can you replay a bad run? If there's no audit log, you're flying blind.
Who gets paged when it fails? "Nobody, it reports success" is not an answer.
Would you trust it with your own account? If not, don't give it your customers'.

The question to ask

Don't ask if your agent can do the task. Every demo says yes.

Ask how you'd know if it did it wrong.

Agreement is not verification. A low token bill is not efficiency. And a green tick is not the truth — it's just the absence of an error message.

Build the boring parts first: the verifier, the log, the caps, the human gate. Then let the agent be clever inside the boundaries you set. That's the difference between a demo that impresses a room and an automation that survives contact with real data.

I break down systems like this daily — follow for more on AI automation, web architecture, and building software that survives production.

Your Website Doesn't Have a Design Problem. It Has a Speed Problem

Irfan Gulzar — Thu, 05 Nov 2026 09:02:59 +0000

Most founders test their website on office Wi-Fi, from a fast laptop. Their customers visit on a mid-range phone, on mobile data, halfway through a commute. That gap — between the machine you built on and the machine your customer actually uses — is where the money quietly leaks.

A slow website is not a design issue. It is a sales issue. And unlike a redesign, it is measurable, fixable, and cheap to prove.

What a slow page actually costs

The numbers here are not guesses. They come from studies with real traffic behind them:

Deloitte and Google, "Milliseconds Make Millions" (2020) — across 37 brands and roughly 30 million mobile sessions, a 0.1-second improvement in mobile site speed was linked to 8.4% higher retail conversions and 9.2% higher average order value. Travel conversions rose 10.1% for the same tenth of a second.
Portent (2022) — across more than 27,000 landing pages, ecommerce conversion sat at 3.05% on pages loading in one second, fell to 1.68% at two seconds, and 1.12% at three. A one-second page converted about 2.5 times better than a five-second one for ecommerce, and three times better for B2B lead generation.
Akamai (2017) — a 100-millisecond delay in load time was associated with a 7% drop in conversion rate, measured across roughly 10 billion retail site visits.
Google / SOASTA (2017) — as page load time rises from one second to three, the probability of a bounce increases by 32%. From one to five seconds, it jumps 90%.

Read those together and the conclusion is unavoidable: nobody changed the offer, the pricing, or the copy. Only the loading time. And the loading time moved the revenue line.

The honest caveat: these are large observational studies, not randomised trials. Treat the magnitudes as directional, not as a guarantee for your site. But the direction has been consistent for a decade, across every study that measured it.

Why your Lighthouse score can be green and your site still feels slow

Here is the trap most teams fall into: they optimise for the lab and ignore the field.

Lighthouse runs on a fast machine with a throttled connection. Your users run on real phones, real networks, real CPUs. Google knows this, which is why it judges Core Web Vitals on field data at the 75th percentile — the experience of your slowest quarter of visitors, not your best test run.

The three thresholds, current since March 2024:

LCP (Largest Contentful Paint) — main content visible within 2.5 seconds
INP (Interaction to Next Paint) — interaction response under 200 milliseconds
CLS (Cumulative Layout Shift) — layout shift under 0.1

INP is the one most teams miss. It replaced First Input Delay in 2024, and it grades your worst interaction, not your first. A page can paint in 0.8 seconds and then lock up for two more while hydration freezes the main thread. The HTML arrived. The brain didn't.

That is the most common failure mode I see in modern sites: a beautiful page that paints fast, then ignores clicks while 400KB of JavaScript hydrates a "Read more" button. Lighthouse goes green. The user leaves.

Measure where your customers actually are

Stop testing on your own laptop. Start measuring the field.

The simplest honest check is free: open Chrome DevTools, run a performance trace on a mid-range Android profile with 4G throttling, and watch what happens after the first paint. Better still, read your real field data in the Chrome UX Report or PageSpeed Insights — it shows the 75th-percentile numbers your actual visitors experience.

If you want a number you can track in code, the web-vitals library gives you the real metrics from real sessions:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics(metric) {
  // metric.name: 'LCP' | 'INP' | 'CLS'
  // metric.value: the real field value, in milliseconds (or score for CLS)
  console.log(metric.name, Math.round(metric.value));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

One line of instrumentation beats a hundred lab runs. It tells you what your customers feel, not what your test rig pretends.

The fixes that actually move the number

Speed work is not mysterious. The same five fixes cover most sites I audit:

1. Ship HTML first, hydrate only what's interactive. Server-render the page. Then hydrate selectively — the checkout button, the search box — and leave the rest as plain HTML. A static hero does not need a framework runtime.

// Don't hydrate the whole page. Hydrate the island that needs it.
import { lazy, Suspense } from 'react';

const CheckoutButton = lazy(() => import('./CheckoutButton'));

export default function ProductPage() {
  return (
    <main>
      {/* Static HTML: ships instantly, no JS needed */}
      <h1>Wireless Headphones</h1>
      <p>40-hour battery. Noise cancelling.</p>

      {/* Only this island gets JavaScript */}
      <Suspense fallback={<button disabled>Loading…</button>}>
        <CheckoutButton />
      </Suspense>
    </main>
  );
}

2. Kill the JavaScript you don't use. Audit your bundle. Third-party scripts — chat widgets, analytics, tag managers — are usually the biggest single chunk. Every script you remove is speed you never have to optimise.

3. Serve images like it's 2026. Modern formats (AVIF/WebP), responsive sizes, loading="lazy" below the fold, and explicit width/height so the layout never jumps:

<img
  src="hero.avif"
  srcset="hero-480.avif 480w, hero-800.avif 800w, hero-1200.avif 1200w"
  sizes="(max-width: 600px) 480px, 800px"
  width="1200"
  height="630"
  alt="Product hero shot"
  fetchpriority="high"
/>

4. Stop the layout shift. Reserve space for everything that loads late — images, ads, embeds. A CLS under 0.1 is mostly a discipline problem, not a technical one.

5. Fix your fonts and your third parties. Use font-display: swap, preload only the one font weight you actually render above the fold, and load every third-party script with defer or after interaction. A chat widget that blocks rendering is a tax on every visitor for the benefit of the few who chat.

The 30-minute speed audit

Do this today, before you touch a redesign:

Run PageSpeed Insights on your homepage, your top landing page, and your checkout — read the field data, not the lab score.
Note which Core Web Vital fails at the 75th percentile.
Open DevTools, throttle to 4G, and click the main call-to-action. Time how long until it responds.
List every third-party script on the page. Delete one.
Check your largest image: is it AVIF/WebP, correctly sized, and lazy-loaded below the fold?

Most sites find their biggest win in step 3 or 4. The fix is usually deletion, not addition.

Speed is a sales metric

A homepage that takes over three seconds on real mobile is not a design problem. It is a leak in the funnel, and it compounds: every ad click you buy lands on the same slow page, every SEO ranking you earn sends visitors into the same wait.

The founders who win this are not the ones with the prettiest site. They are the ones who measured on the device their customers actually hold, fixed the worst interaction first, and treated a tenth of a second as revenue — because the data says it is.

When did you last load your own website on mobile data?

I break down systems like this daily — web performance, AI automation, and the technical decisions that actually move revenue. Follow for more.

Sources: Deloitte & Google, "Milliseconds Make Millions" (2020); Portent, Site Speed and Conversion Rate research (updated 2022); Akamai, "State of Online Retail Performance" (2017); Google/SOASTA Research (2017); web.dev Core Web Vitals thresholds (2024).

Why 95% of AI Agent Prototypes Never Reach Production — and How to Build One That Does

Irfan Gulzar — Mon, 02 Nov 2026 09:04:48 +0000

Your AI agent demo works. Your AI agent doesn't.

A team builds a dazzling prototype in a week. It answers questions, books meetings, drafts replies, and everyone in the room nods. Then it meets real customers, real data, and real consequences — and it quietly dies.

This is not a model problem. The model was never the hard part.

MIT's 2025 report The GenAI Divide: State of AI in Business found that 95% of generative AI pilots fail to deliver measurable profit-and-loss impact. Read that again: not 95% of bad ideas, but 95% of pilots — including many built by competent teams with good models. The gap between a demo and a production system is where almost every agent project is won or lost.

Here is what that gap looks like, and how to survive it.

The demo is not the product

A demo runs on clean data, a friendly user, and a forgiving audience. Production runs on none of those.

In a demo, the input is the one happy-path example you rehearsed. In production, it is a form field full of typos, a CRM record missing half its fields, and an API that fails at 2 a.m. A wrong answer in a demo is a laugh; in production it is a refund issued twice or an email sent to the wrong client. Demos do not need error handling. Production is mostly error handling.

That is the first uncomfortable truth: the model is perhaps 10% of a working automation. The rest is the boring engineering nobody posts about — observability, retry logic, guardrails, a data layer that does not lie, and a human who can hit stop.

Why prototypes die: five production gaps

1. No permission boundaries

A demo agent usually runs with your credentials, or with a single admin token, because that is the fastest way to make it work. In production, that is a liability with an API key.

Every tool an agent can call is a door. A production agent needs scoped, least-privilege credentials per task, and an explicit list of actions it is never allowed to take without a human. Before you ship, answer this precisely: if this agent went rogue for ten minutes, what is the worst thing it could do?

2. Messy data, not model quality

Demos run on curated examples. Production data is duplicated, stale, half-empty, and contradictory. The same customer exists three times in the CRM under three spellings of their name. The price list has two versions. The calendar has a cancelled meeting that was never deleted.

An agent that trusts its data blindly will confidently act on lies. A production system validates before it acts. This is why so many agent projects stall at integration, not intelligence. The model was fine. The data layer was not.

3. No observability

When a workflow breaks, you can point at the exact step that failed. When an agent breaks, you often get a confident answer and no explanation of how it got there. Production agents need logs for everything — goal, tools called, arguments, outputs, and final action — so a run can be replayed step by step. When a customer asks why something happened, "the agent decided" is not an answer.

4. Cost and drift nobody budgeted for

A workflow costs roughly the same every time it runs. An agent does not. Token usage varies with every run, tool calls multiply, and a retry loop can turn a cheap task into an expensive one. Behaviour also drifts: the same prompt that worked in October can behave differently after a model update in November.

Production means budgets per run, capped retries, and regression tests run on a schedule against the live system. If you would not ship a normal feature without tests, do not ship an agent without them either.

5. No human at the money step

The most dangerous agent is one that can move money, message customers, or change records with no human in the loop — not because agents are malicious, but because they are confident. The rule I use with clients is simple: AI can prepare, draft, and recommend, but a human approves anything irreversible.

The architecture that survives: deterministic backbone, AI at the edges

The agents that reach production almost all look the same, and they do not look like the demos. They have a deterministic backbone — a workflow with defined steps, validations, and fallbacks — and they use AI only where judgement is actually needed.

Take a lead-handling automation. Four of its five steps are deterministic: take the form lead, enrich it, check it against rules, and create the deal in the CRM. Only one step needs judgement: scoring the lead. That is a workflow with one language-model call in the middle — not an agent problem.

Here is the shape of that pattern in code:

def handle_lead(lead):
    # Deterministic steps: same input, same output, every time
    lead = validate(lead)          # reject bad data early, loudly
    lead = enrich(lead)            # one known source, not a web search
    if not passes_rules(lead):     # business rules, not model vibes
        return queue_for_review(lead, reason="failed rules")

    # AI only where judgement is needed
    score = score_lead_with_llm(lead)

    # Human at the money step: nothing irreversible happens unseen
    if score >= 80:
        return request_approval(lead, score, action="create deal + notify sales")
    return queue_for_review(lead, reason="low score")

And the guardrails around it are explicit, not implied:

{
  "agent_policy": {
    "allowed_tools": ["crm.read", "crm.create_deal"],
    "forbidden_tools": ["email.send", "payment.refund"],
    "max_retries": 2,
    "max_cost_per_run_usd": 0.50,
    "requires_human_approval": ["create_deal", "send_to_customer"],
    "log_everything": true
  }
}

Notice what this buys you. When it breaks, you know which step broke. When it is wrong, a human saw it before the customer did. That is not less ambitious than a fully autonomous agent. It is the version that still exists in six months.

A production checklist before you launch

Run through this before any agent touches real customers:

Permissions: scoped credentials, an explicit forbidden-action list, and a tested answer to "what is the worst ten minutes of rogue behaviour?"
Validation: every input checked, every tool output sanity-checked before the next step runs.
Observability: full run logs you can replay, plus alerts when a run fails, loops, or exceeds its cost budget.
Retries and fallbacks: capped retries with backoff, and a graceful fallback — queue for a human — instead of retrying forever.
Human approval: a person approves anything irreversible, especially anything involving money or customer-facing messages.
Regression tests: your ten most important tasks, run on a schedule against the live system, with failures alerting a human.

If you cannot tick all six, you do not have a production agent yet. You have a demo with a launch date. Fix the checklist first — it is cheaper than explaining a failure to a customer later.

Stop asking which model to use

The model question is the easiest question in agent building, and the least important. Swap the model in a well-built system and the system still works. Start instead with the question that decides whether your agent survives contact with reality: what happens when it fails? Build the boring backbone first. Earn the agent later.

I break down systems like this daily — follow for more.

Your Title Doesn't Ship. Your Live Link Does.

Irfan Gulzar — Thu, 29 Oct 2026 09:21:56 +0000

LinkedIn is full of titles. Titles don't ship.

"Software Engineer | Full Stack | AI Enthusiast | Open to Work" — I have seen the same badge-line on a dozen profiles this week. None of them tell me whether you can build something a stranger can click.

That is not a criticism of ambition. It is a description of how hiring actually works in 2026. Recruiters cross-reference now. They check GitHub, they check a personal site, they click a live link. A title is a claim. A deployed app is evidence.

If you are a developer looking for work, clients, or your next role, this is the one shift that matters most: stop polishing the headline first. Ship one small thing, put the link where people can find it, and let the work introduce you.

The recruiter check changed

A few years ago, a profile was the proof. Your headline, your summary, your list of skills — that was the package a recruiter judged.

That package broke for two reasons. First, everyone learned the same keywords, so the keywords stopped meaning anything. Second, AI tools made it trivial to produce a polished-looking profile without producing anything real. A summary can be generated in ten seconds. A working product cannot.

So the check moved one step further out. Can I click something you built? Does it load? Does it do one thing clearly? Does the code behind it look like it was written by someone who understands the problem?

One live link answers all of that faster than a paragraph of adjectives ever will. It shows taste, follow-through, and judgement — the three things no headline can prove.

A title says what you want to be called

There is nothing wrong with calling yourself a full-stack developer. The problem is only that the title carries no information about range, depth, or reliability.

Two developers can hold the same title and be completely different hires. One has shipped a booking form that handles real validation, real errors, and real edge cases. The other has followed tutorials and never deployed anything. On paper they look identical. In a browser tab they do not.

That is why "proof converts, claims don't" is not a slogan. It is how trust works. A claim asks the reader to believe you. Proof lets the reader verify you, without needing to take your word for anything.

If you want to be taken seriously, give people something to verify.

What counts as proof

Proof does not mean a huge project. In fact, huge projects are often worse proof, because nobody has time to explore them and they are rarely finished.

Good proof is small, finished, and legible. It has:

One clear job. A visitor understands in five seconds what it does.
A live URL. Not a screenshot, not a repo link alone — something that loads.
Readable code. A repo a reviewer can open and follow without a guided tour.
A real decision in it. Something you chose, and can explain why.

Examples that work: a single-page tool that solves one annoying problem, a landing page with a working form and proper validation, a small dashboard that fetches real data and handles loading and error states honestly. The scope is small. The finish is what sells it.

Here is the test I use: if a stranger clicks your link on their phone, on mobile data, and cannot tell what you built within ten seconds, it is not proof yet. Simplify it until they can.

Ship one thing this weekend

You do not need a new stack, a new course, or permission. Pick the smallest useful thing you can finish, and finish it properly.

A practical shape for a weekend proof project:

Pick one user and one task — for example, a local clinic that needs a booking enquiry form, or a freelancer who needs a one-page price calculator.
Build it as a single page with real validation, not placeholder alerts.
Deploy it so it has a real URL.
Write a short README: what it does, who it is for, and what you would improve next.

The deployment step is the part most people skip, and it is the part that turns a project into proof. A minimal example with a static page is enough to start:

# From your project folder, ship it
npx vercel --prod

And the form itself should behave like a real product, not a demo. Validate on the client, show errors next to the field, and never leave the user guessing:

function validateBooking(form) {
  const errors = {};
  if (!form.name.trim()) errors.name = "Please add a name.";
  if (!/^\S+@\S+\.\S+$/.test(form.email)) {
    errors.email = "That email does not look right.";
  }
  if (!form.date) errors.date = "Pick a date for the booking.";
  return errors;
}

// If errors is empty, submit. Otherwise, render each
// message next to its field — no silent failures.

That is not impressive code, and that is the point. Reviewers are not looking for cleverness. They are looking for care: handled states, honest errors, and a page that works when something goes wrong.

Then put the link in your featured section, in your GitHub profile README, and at the top of your personal site. Do not bury your best evidence three clicks deep.

Let the work introduce you

I won my first real clients because they could click something I built — not because my headline was clever. They did not hire a title. They hired the evidence that I could take a vague idea and turn it into something that loads, works, and looks considered.

That is still how it works, only more so. In a market full of generated profiles and generated portfolios, the scarcest signal is a finished thing with your name on it.

So before you polish your headline this week, ask a simpler question: what is the one live link on your profile that you are genuinely proud of?

If you do not have one yet, that is your weekend job. Not a rebrand. Not a new headline. One small, finished, deployed thing — and a link a stranger can click.

I break down systems like this daily — follow for more.

SEO vs GEO Is the Wrong Argument: AI Search Sends Less Traffic and Better Buyers

Irfan Gulzar — Mon, 26 Oct 2026 09:07:28 +0000

Everyone is arguing SEO versus GEO, as if one of them has to win. The numbers coming out of real analytics accounts suggest the argument itself is broken — because it is measuring the wrong thing.

Traffic was always a proxy. It stood in for attention, then for interest, then — hopefully — for revenue. AI search has broken that chain in an interesting way: it sends fewer visitors, but the visitors it does send are much closer to buying. If your dashboard only counts sessions, AI search looks like a disaster. If it counts signups, it looks like the best channel you have.

The numbers that break the old dashboard

Ahrefs shared their own data: AI search accounted for just 0.5% of their traffic, but 12.1% of their signups. That is not a rounding error. It is a completely different ratio from organic search, where a large volume of visits produces a small share of conversions.

An Opollo study across 312 IT firms points the same way: AI referrals converted at 14.2%, against 2.8% for Google organic. Again, the story is not volume. It is intent. By the time an AI answer sends someone to your site, that person has usually already had the comparison, the objection handling, and the shortlisting done for them — inside the answer.

And Ethan Smith's analysis adds the part most teams miss: roughly 45 billion monthly AI sessions, with about 83% happening inside apps — ChatGPT, Gemini, Perplexity, Claude — rather than on the open web. Most AI activity is not happening on websites at all. Your site is not the destination any more. It is the source the answer was built from, and occasionally the place the buyer lands to finish the job.

Put those three data points together and the picture changes. The funnel did not disappear. It moved upstream, into the answer itself. The click is no longer the start of the buying journey. It is near the end of it.

Why an AI referral converts differently

A Google click is often the start of research. Someone types a broad query, opens five tabs, and bounces from four of them. An AI referral is different because the filtering already happened before the visit.

The AI has already:

Understood the question in full sentences, not keywords
Compared options against the buyer's actual criteria
Answered the obvious objections in the answer itself
Recommended a shortlist, with reasons

So the visitor who arrives is pre-qualified in a way a search click rarely is. They are not asking "what is this?" They are asking "is this the one, and how do I start?" That is why a tiny share of traffic can produce an outsized share of signups. The denominator shrank. The numerator did not shrink nearly as much.

This also explains why the usual SEO panic is misplaced. Yes, AI answers will eat some informational traffic — the "what is X" visits that never converted anyway. Losing those visits hurts a traffic chart. It does not necessarily hurt revenue. The visits worth keeping are the ones attached to a buying question, and those are exactly the visits AI answers are now routing.

Stop optimising for clicks. Start optimising for the answer.

If the click is now the end of the journey, the work moves earlier: into being the source the answer quotes, and into being the obvious next step once it does.

1. Say what you do in one quotable paragraph

AI answers quote pages that state a claim plainly, with evidence on the same page. A homepage that says "we help businesses grow with innovative solutions" gives an answer engine nothing to quote — because it says nothing specific. A page that says who you serve, what problem you solve, and how you are different, in the first paragraph, gives it a sentence it can lift whole.

Write the paragraph you would want quoted. Then check whether it actually appears on the page, in crawlable HTML, not buried in a JavaScript widget.

2. Answer the buyer's real question, not the keyword

Ranking content targets a keyword. Answer content targets a question a buyer actually asks, in the words they ask it: "which tool is best for a small team on a budget?", "what does it cost after the first year?", "what breaks when you scale past 10,000 users?" Pages built around those questions — with a direct answer first and the detail after — are the pages AI systems reach for.

3. Make the conversion step obvious from the answer

If an AI answer sends a buyer to your pricing page, that page has to finish the job: clear pricing, a visible next step, and proof — testimonials, case results, a comparison — on the same page. A buyer who arrives pre-sold and then has to hunt for a signup button is a buyer you will lose to a competitor whose page does not make them hunt.

4. Measure signups per AI referral, not AI sessions

This is the dashboard change that matters most. Split your analytics so AI referrals are a separate source, and track them all the way to signup, not just to session. A simple way to start is to segment referral traffic from the major AI platforms and compare its signup rate against organic search over the same period:

// Segment AI referrals in your analytics by referrer
const aiReferrers = ["chatgpt.com", "perplexity.ai", "claude.ai", "gemini.google.com"];
const isAiReferral = aiReferrers.some((domain) =>
  document.referrer.includes(domain)
);
// Tag the session, then compare signup rate: AI referrals vs organic

The point is not the code. It is the comparison. Once you can see that one AI referral is worth several organic visits, the internal argument about "losing traffic" ends, because the team is finally looking at the number that pays.

Ranking still matters — but the finish line moved

None of this means SEO is dead. Ranking still matters, for two reasons. First, the pages AI systems trust are usually the pages that already earned authority the old-fashioned way: consistent content, real expertise, third-party mentions. Second, not every buyer journey runs through an AI answer yet. Search still drives discovery for a huge share of queries.

What changed is the finish line. It used to be the most traffic. Now it is the most-quoted answer on the question buyers actually ask — followed by a page that converts the buyer who arrives. Traffic without that second half is just a chart going up. A cited answer with a working signup path is a business.

So stop asking whether SEO or GEO wins. Ask a better question: when an AI answer mentions your category, does it mention you — and when it sends you a buyer, does your page close?

That is the game now. The dashboards just have not caught up yet.

I break down systems like this daily — follow for more on web architecture, AI automation, and getting cited by the machines that now decide what gets read.

Your Vibe-Coded Site Works. AI Search Can't See It.

Irfan Gulzar — Thu, 22 Oct 2026 09:50:53 +0000

Last weekend someone shipped a full landing page — pricing section, testimonials, a working contact form — without writing a single line of code. It looked flawless in the browser. Animations, gradients, the lot.

Then they asked ChatGPT what the site was about.

It had no idea the site existed. Not a wrong answer — no answer at all.

That's the quiet failure mode of the vibe-coding boom. These tools didn't just change who builds websites. They quietly changed what gets indexed. And most vibe-built sites ship on the one rendering model that makes them invisible to AI search.

The vibe stack defaults to client-side rendering

Most AI builders — Lovable, v0, Bolt, Replit's agent mode — scaffold React/Vite-style single-page apps. Your entire page is assembled in the browser at runtime. The HTML the server actually sends looks like this:

<!doctype html>
<html>
  <head>
    <title>Loading...</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>
</html>

That is the entire page. A few hundred bytes of "we'll get back to you." In your browser, JavaScript fills it in within milliseconds. To a crawler, it is a blank wall with a polite title.

Why bots don't see what you see

Fetching HTML is cheap. Executing JavaScript is expensive — a full browser context, memory, timeouts, multiplied across billions of pages. Crawlers operate on budgets, and those budgets are spent on the highest-value work first.

Google invests in a rendering pipeline for its index, and even that is queued and delayed — JS-rendered content routinely enters the index days behind the HTML version. AI crawlers — GPTBot, ClaudeBot, the bots that decide whether ChatGPT or Claude ever cite your site — run leaner still. The widely observed behaviour: they fetch the raw HTML and move on. No JavaScript execution, no hydration, no content.

So the question that matters is no longer "does my site look good?" It is: what does my site look like with JavaScript switched off? If the answer is an empty div, then as far as AI search is concerned, your content does not exist. There is nothing to cite, quote, or recommend — no matter how beautiful it renders in Chrome.

This is exactly why the new SEO conversation has shifted from rankings to citations. An AI answer engine doesn't browse your site like a visitor. It reads what its crawler could read, and it quotes what it could understand. An empty HTML shell gives it nothing to work with.

The 60-second test

curl is the most honest reviewer your site will ever meet. It shows you exactly what a no-JS bot sees:

curl -s https://your-site.com | wc -c
curl -s https://your-site.com | head -c 600

If the byte count is in the low hundreds and the output is a shell with an empty root div, your page is invisible to AI search. Try it right now — the result takes five seconds and has ended more than a few launch-day celebrations.

For comparison, run the same test on a server-rendered page and watch kilobytes of real headings, paragraphs, and links stream past. That is the difference between being quotable and being a loading spinner.

The fix — you don't have to give up the vibe

Vibe-coding the content is fine. Shipping the rendering client-side is the problem. The fixes are all on the delivery layer:

1. Server-render or statically generate. Frameworks that ship HTML on first byte — Next.js (App Router), Astro, Nuxt, SvelteKit with prerendering — give every bot the full page immediately. The browser still hydrates into the interactive app your users see; the crawler never needed the interactivity.

2. Prerender as a bridge. If you're locked into a client-side build, prerendering services generate static HTML snapshots of your routes and serve them to crawlers. It is not as clean as true SSR, but it converts an invisible page into a readable one in an afternoon.

3. Prioritise the pages AI needs to quote. Your homepage, pricing, and services pages are the ones answer engines will cite. A blog post buried three clicks deep matters less than the page that says, in plain words, what you do. Make sure those pages render as HTML.

4. Don't rely on "Google renders JavaScript" as your safety net. Even Google's rendering is budgeted and delayed — and AI crawlers are stricter still. "It'll probably get rendered eventually" is not a strategy; it is a hope.

Ship HTML, not apps

The irony is sharp: the tools that made building websites effortless quietly rebuilt the exact problem the industry spent a decade solving. We fought the client-side-rendering wars in the 2010s, learned that HTML-first wins for discoverability, and then vibe-coding reintroduced the SPA as the default — this time to people who never saw the first war.

So here's the practical checklist before your next launch:

Build with the vibe tools for speed, render like it's 2009 for the bots: HTML first, JavaScript as enhancement.
curl every launch. If a page serves under a couple of kilobytes of real text content, fix the rendering before you announce it.
Say the plain truth in text. A single clear paragraph describing what you do beats a clever animation that no bot will ever watch. AI search rewards clarity, not cleverness.

Your site can be both stunning and visible. It just has to arrive as a page, not a promise.

I break down systems like this daily — follow for more on web architecture, AI automation, and getting cited by the machines that now decide what gets read.