DEV Community: Artur Pokładek

Five Times the Monster on the Client's Site Was Me

Artur Pokładek — Sat, 31 Oct 2026 20:24:15 +0000

Everyone posts haunted house stories today. Mine are less atmospheric. In every one of them, the thing that broke the client's site was me.

Here are five, in no particular order of shame.

1. "It's live, check it out"

I sent the client a message saying the changes were done. The client opened the site and saw the old version.

The cache was holding on to the old site, and I was holding on to the belief that I had deployed. Only one of us was right.

2. Lorem ipsum, live and in production

Placeholder text is supposed to be replaced before anyone sees it. Mine made it onto the live site.

3. It ran fine on my phone

I checked the mobile version on my own phone, saw it working, and moved on. The client opened it on an older phone and it fell apart. Turns out "works on my phone" is just "works on my machine" with a smaller screen.

4. The animation that ate the battery

It looked great on my laptop, smooth and exactly what I wanted.

On a phone it heated the device and drained the battery.

5. The environment variables that weren't there anymore

I overwrote the environment variables on production. Yes, the real ones.

None of these needed a full moon. Just me, convinced it was fine.

What's the scariest thing you've shipped yourself?

Things That Pass Every Check on a Client Site and Still Don't Work

Artur Pokładek — Thu, 29 Oct 2026 14:00:00 +0000

A client never opens Lighthouse. They open their inbox, and there are no enquiries in it.

I keep running into this on client sites and on sites I take over from someone else, one of them built with v0. The last one on the list I built myself.

1. The form says thank you

On a shop I took over, the contact form showed a green "Thank you". The email behind it never arrived.

Autofill can break a form too. One site had a honeypot field that the browser filled in on its own, and the real enquiries were thrown away as bot submissions. Elsewhere the enquiries did arrive, in the spam folder, because the domain had no SPF or DKIM records.

2. "What matters is that it works"

That's what the owner of a shop built with v0 told me. Row Level Security in Supabase was switched off, so the shop worked just as well for anyone who opened the browser console.

On another site the Supabase service role key sat in the client JS bundle. That key skips RLS entirely. Turning RLS on wouldn't have helped there anyway.

3. The noindex that shipped with the site

The site went live months ago with the noindex tag from staging still in the head. Google is very polite about this. It was asked not to index the pages, and for months it didn't.

A robots.txt that blocked /_next/ did the same job from a different angle. That folder is where Next.js keeps its scripts and styles. Googlebot couldn't fetch them, and on that site it rendered an empty page.

4. Lighthouse 100 on placeholders

The score was measured on placeholder images. Then the client started uploading photos straight from their phone, several megabytes each, and LCP went downhill from there.

The same perfect score sat on a site whose hero took seconds to show up on a real phone on 4G.

5. The cookie banner with two Accept buttons

The banner has a Reject button, and clicking it sets exactly the same cookies as Accept.

6. The pages that send Google somewhere else

Many subpages share the same title and the same canonical URL, and each one tells Google that the real page lives somewhere else. Google takes them at their word. One page stays in the index and the rest drop out.

Sometimes the sitemap joins in, full of localhost or vercel.app preview links.

7. 100vh on an iPhone

The hero is exactly one screen tall in Chrome's device emulator. On the phone itself, Safari's address bar covers the call to action.

svh or dvh fixes it, once somebody picks up an iPhone and checks.

8. The menu that needs a mouse

Subpages open on hover. Phones don't hover, and on a phone those pages can't be reached from the menu at all.

The phone number in the footer has no tel: link either. On the device that could actually call it, you can read the number and that's it.

9. alt="image"

Every image on the site has alt="image", and the accessibility audit is green. That audit checked that the attribute exists and stopped there.

10. The domain nobody owns

The domain expires, or the SSL certificate does, and only then does anyone ask whose account it's on.

One client's domain sat on my own account for a while. Handing it over took far more effort than it should have.

The same silence covers smaller things. The map on one site died when its API key expired, and nobody noticed. Somewhere there is a backup, too, and a restore has never been tested.

11. Me

I've sat looking at a green CI run while something on production was down.

I've also tested a contact form by sending it to my own inbox, watched the message arrive and called it done. At the client's end, the enquiries landed in spam. The only inbox that form ever worked for was mine.

That's eleven. Put your twelfth in the comments.

The Only Comment on My Post About Reviewing AI Was a Bot That Shipped Its Prompt

Artur Pokładek — Tue, 27 Oct 2026 14:00:00 +0000

Last week I published a post about AI-built client sites and the one step everybody skips: someone looking at the result before it goes live.

The next morning it had 4 readers, an average read time of 34 seconds and exactly one comment. The comment was a prompt.

What the account actually posted

An account pasted what is clearly a set of instructions for an LLM, in place of the comment those instructions were meant to produce. In short: write one or two casual sentences, start with a lowercase letter, no marketing, react to the video, ask a specific question, no hashtags, no links.

It even came with a sample comment, a question about whether I had noticed generic copy in the product descriptions. My post had no video and no product descriptions.

It also got one like, which is one more than the post itself had.

The line that made me laugh

Near the end the prompt says: ensure no em dash.

I follow the same rule. I take dashes out of my client emails, because people now read them as a sign that a machine wrote the text.

Whoever set this up knew the tells well enough to ban them. Nobody checked whether the output was a comment at all.

That is my previous post in one screenshot. The cosmetics were handled and the only check that mattered never happened.

I replied anyway

I thanked them for the support and pointed out that they had shipped the prompt instead of the output.

Full disclosure, since this whole thing is about review: Claude helped me draft that reply. I read it before it went out.

Why it bugs me more than it should

One bot on a post with 4 readers changes nothing. What bothers me is the version that works.

When the pipeline does its job, you get one casual lowercase sentence with a question at the end, and it looks like someone read your post. I would have answered it like I answer a person.

This one only got caught because it broke.

Where I stop

I have no idea how common this is on DEV. I have one example, and it is the one that failed.

I also have no reliable way to tell a well-made bot comment from a lazy human one. And I write my own posts with AI help, so I am in no position to demand purity from anyone.

Have you caught one?

Have you had a comment on your posts that you later realised came from a bot? How did you notice, and did you reply, report it or just leave it there?

Vibe Coding Is Not the Problem. Nobody Reviewing It Is.

Artur Pokładek — Fri, 23 Oct 2026 13:00:00 +0000

The owner of an online shop sent me a site to look at. He didn't know it was built with AI. I told him, and he didn't care.

If you think AI-built client sites are a mess, that shop proves you right. Someone had built it for him in v0. The Supabase tables were open, and the contact form quietly lost every message.

I still think vibe coding a small business website is fine, as long as someone looks at it before launch. Almost nobody does.

Console first

On someone else's site I always start in the same place: the browser console and the network tab.

The shop's database was Supabase, with Row Level Security switched off. It took me somewhere under an hour to spot it.

Supabase's own API keys guide says the key in the browser is public by design, and RLS is the thing that decides what that key can reach. Their Row Level Security page is blunter: leave RLS off on a table in an exposed schema, and any role holding a grant on that table can read it and write to it.

In this case the tables only held page content, with no customer data or enquiries in them. That was luck. If the next prompt adds a newsletter table the same way, real email addresses end up behind the same public key.

The contact form sent, and the messages never arrived anywhere. For a shop, customers writing in and hearing nothing back is the expensive bug on the list.

Then the boring part. There was no sitemap and no robots.txt, and the page titles were either missing or the same on every page, so Google had very little to work with.

The shrug

When I walked him through all of that, he shrugged and said that what matters is that it works.

So "it works" was the entire security review. To be fair, that's also how most of us test regex.

I get why he said it. From the outside, the form looked like it sent. I fixed the form, the database rules and the SEO anyway.

Who was supposed to check this?

The person who built it for him, before handing it over. Each item on my list is a check for someone who knows to look, and the owner of a shop has no reason to know what Row Level Security is.

Open the network tab and see what the public key returns, then send yourself a test message through the form. The SEO part is one look at the page source plus two URLs: /robots.txt and /sitemap.xml.

None of that happened before the handover. Whether the form delivers mail, or what the database hands to anyone who asks, never got tested.

I build with the same tools

I use Claude Code and Cursor on client sites. They cut my build time massively. The concept and the technical review are still mine, and I don't see that changing.

When a developer complains that AI builds broken sites but has never shipped a broken site themselves, I don't believe them.

I'm not here to roast v0

I have no verdict on v0 itself. A tired developer can ship an open database and a dead contact form just as easily.

I also don't tell clients to stop using AI.

If you've inherited an AI-built client site, what did you find first? And if you think a review wouldn't have saved it, tell me what would have.

AI Agents Write Code for My Client Sites. My Shaders and Canonical Tags Stay Off Limits.

Artur Pokładek — Wed, 21 Oct 2026 13:30:00 +0000

My AI agent rewrote one of my GLSL shaders. On a Samsung A-series phone the scene went from 60 FPS to about 20, and I went back to my own version.

Claude Code and Codex have lived in my terminal since early 2025 (Copilot in VS Code before that), and they write a lot of the code for my studio's client sites. Most days that's a good thing.

The agents handle the Next.js skeleton, types, routing, forms, tests and refactors, plus sitemaps, robots.txt, schema markup and translations. My starter repo runs on 10 to 20 skills pulled from other people's work and checked before they went in, and a second agent reviews my plans before anything gets built.

Design direction stays with me, and so does a short do-not-touch list. You could keep a list like that for the risky stuff only and let the agent run free on admin panels, internal tools and short landing pages. I keep the same list everywhere, and for most of it I can point to the moment an agent got it wrong.

Anything that has to run on a real phone

GSAP timelines and shaders are the first thing on the list. One section had a ScrollTrigger pin that kept jumping, and I handed it to the agent.

The agent fixed the jumping pin so well that on the phone there was nothing left to pin. I saw it during my own phone test, in the evening, and spent the next two to three hours putting the section back together. The shader from the top failed the same phone test.

Several pages, one canonical

On one project the agent gave several Next.js pages the same title and the same canonical. I only found it when I ran an SEO cannibalization skill on the project. Titles and canonicals I set myself.

Nothing loads before consent

The project used Consent Mode v2. The agent put GA4 and the Meta Pixel straight into the layout anyway, and they loaded before the user gave consent.

I spotted it myself, and it's one of the reasons I built my own analytics setup skill.

The package I didn't check, and the copy

The agent suggested an npm package and I accepted it without checking, so that one is on me. It pulled in dependencies I didn't want.

Copy is the one job I still hand over and then take back. The agent writes the draft, I correct it, and on Polish sites I sometimes run my own skill that checks the text for AI tells. A client doesn't pay for a site that sounds like "Discover the future."

Same rules for the admin panel

A site looks AI-made when nobody had the nerve to tell the agent no. That includes the screens only your client's staff will ever open, so the admin panel gets the same list as the homepage.

Where I might be wrong

Shaders and GSAP may stop being a problem within a year, and then the list gets shorter. For now I keep it in my head and nowhere else.

So that's my list. What's one thing your agent doesn't get to touch anymore, and what happened the day it went on the list? If you think the admin panel rule is overkill, tell me what you let slide there and how it went.

Stop asking AI if your site is accessible. Ask it what to test by hand.

Artur Pokładek — Sat, 17 Oct 2026 18:41:53 +0000

Give a current model a browser, a keyboard and axe, and it finds more accessibility bugs than axe does. It also flags plenty the human auditors never wrote down. In a September 2026 preprint that scored five models against human audit reports, the best agent setups caught 77% to 86% of known WCAG violations, where axe-core caught 36%. But 44% to 45% of what the agents flagged wasn't in the human reports, compared with 10% for axe. Some may be real bugs the auditors missed, but nearly half the flags need a person before anyone can act on them, while axe, wrong about one in ten, can fail a build on its own. So axe stays the gate, and a model sorts its output and tells me what to test by hand.

How much a scanner finds

The WebAIM Million 2026 found detectable WCAG 2 failures on 95.9% of the top million home pages, 56.1 errors per page on average. Low contrast text was on 83.9% of them and missing alt text on 53.1%. You don't need a language model to tell you an image has no alt text.

Deque, which makes axe, reported in 2021 that its automated tests covered 57% of issues by volume, from its own audits. In a 2017 GDS test on a page with 143 deliberate failures, 10 tools combined caught 71%, the best single tool about 40%.

The W3C's own guidance says "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so." A Lighthouse 100 only means its weighted automated audits passed.

Asking a model for an audit

The preprint, by Mishra and colleagues, isn't peer-reviewed. They took 24 pages from 11 scholarly platforms with existing Library Accessibility Alliance audit reports and checked each model's findings against them. The strongest setups were browser agents (GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro) with the DOM, screenshots, a keyboard and axe. Claude Opus 5 ran inside Claude Code, and Gemini 3.5 Flash and others got a single batch pass.

In the paper's terms, axe-core had precision 0.90 and recall 0.36. The reference browser-agent run (GPT-5.5) reached recall 0.86 at precision 0.56, a repeat run 0.88, and Claude Code 0.77 at 0.55 with the authors' parity prompt. The authors had seen 19 of the 24 pages while building the setup, so this isn't a clean held-out test, and a "correct" pass was inferred from what the human reports didn't mention.

A browser agent driving Playwright MCP can press Tab and tell you where focus landed, and in this preprint the browser agents caught 6 of 7 focus order failures from the human audits. The paper gives no false alarm rate per criterion and didn't test focus visibility at all. On navigation failures (focus, state, feedback), only 57.2% of the failures a DeepSeek V4 Flash browser agent reported in the A11yLTLNav preprint were confirmed, compared with 88.7% for the authors' rule-based checker, which uses no LLM, both on 31 generated clones of real sites. Nobody I found has measured a model judging what a screen reader announces. So focus order, focus visibility and screen reader output stay on the manual list. An agent may add to that list, never close it.

A six-step flow

Steps 1 and 6 run in CI. A model drafts the output of steps 2 and 5, and you check it. Steps 3 and 4 are done by hand. After a fix, go back to step 1.

1. Automated scan

Playwright with @axe-core/playwright, following the Playwright accessibility testing docs:

npm i -D @playwright/test @axe-core/playwright @types/node
npx playwright install chromium   # a fresh project has no browsers yet

page.goto('/') needs a baseURL, and a second project covers the mobile layout:

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  use: { baseURL: 'http://localhost:3000' },
  webServer: {
    command: 'npm run start',
    url: 'http://localhost:3000',
    reuseExistingServer: true,
  },
  projects: [
    { name: 'desktop', use: { ...devices['Desktop Chrome'] } },
    { name: 'mobile', use: { ...devices['Pixel 7'] } },
  ],
});

One shared helper holds the scan configuration:

// tests/axe.ts
import type { Page } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

export const scan = (page: Page) =>
  new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    // The chat widget is the vendor's code, so it's excluded to keep this build
    // independent of their releases. It still ships on our page: it stays on the
    // manual checklist and in a ticket with the vendor.
    .exclude('#third-party-chat-widget');

// tests/a11y.spec.ts
import { test, expect } from '@playwright/test';
import fs from 'node:fs';
import { scan } from './axe';

test('home: initial state', async ({ page }, testInfo) => {
  await page.goto('/');
  await expect(page.getByRole('main')).toBeVisible(); // let the UI settle first
  const results = await scan(page).analyze();

  const file = testInfo.outputPath('axe-results.json'); // input for step 2
  fs.writeFileSync(file, JSON.stringify(results, null, 2));
  await testInfo.attach('axe-results', { path: file, contentType: 'application/json' });

  expect(results.violations).toEqual([]);
});

test('home: menu open', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('button', { name: 'Open menu' }).click();
  await expect(page.locator('#menu')).toBeVisible();
  const results = await scan(page).include('#menu').analyze();
  expect(results.violations).toEqual([]);
});

Keep wcag21a. In axe-core 4.14 it holds one rule, label-content-name-mismatch (2.5.3 Label in Name), and it's easy to drop. The axe-core API docs list every tag, including EN-301-549.

analyze() scans the DOM as it is at that moment, so add a test per interactive state: an open menu, a modal, a form after a failed submit. Cover one URL per template, with the same tests in a for loop over ['/', '/products/example', '/cart', '/contact']. axe also returns an incomplete array for checks where it could not be certain. Those go on the manual list.

Starting from hundreds of violations?

On an existing site, toEqual([]) is a red build on day one, and red builds nobody can fix tend to get skipped. The Playwright docs suggest snapshotting violation fingerprints instead, so the test fails when the set changes. It replaces the two toEqual([]) tests above until the backlog is gone.

// tests/a11y-baseline.spec.ts
import { test, expect } from '@playwright/test';
import type { AxeResults } from 'axe-core';
import { scan } from './axe';

const fingerprints = (results: AxeResults) =>
  JSON.stringify(
    results.violations.map((v) => ({ rule: v.id, targets: v.nodes.map((n) => n.target) })),
    null,
    2,
  );

test('home: no new violations', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByRole('main')).toBeVisible();
  const results = await scan(page).analyze();
  expect(fingerprints(results)).toMatchSnapshot('home-a11y.txt');
});

The first run fails and writes the snapshot. Commit it, and re-record with --update-snapshots after each fix. Snapshots are named per project and OS (home-a11y-desktop-linux.txt), so record them on the OS your CI runs.

Once the snapshot is down to minor and moderate issues, add a hard gate: filter results.violations to impact critical and serious and expect an empty list. If one rule floods the report, disableRules(['rule-id']) turns it off, with a ticket number in a comment next to it.

2. Triage the JSON with a model

One bug in a shared <Button> can show up as dozens of violations. The test writes its JSON to test-results/<test>-<project>/axe-results.json, and Playwright clears that folder on every run, so copy the file out. Most of it is passing checks, so trim it:

jq '{violations: [.violations[] | {id, impact, help,
      nodes: [.nodes[] | {target, html: .html[0:200]}]}],
    incomplete: [.incomplete[] | {id, help, nodes: [.nodes[] | {target}]}]}' \
  axe-results.json > axe-slim.json

Give the model the trimmed JSON and the source of the affected components, and constrain it hard. Check first that you're allowed to send that code to the model.

Input: axe-slim.json below holds the `violations` and `incomplete` output of
axe-core (tags wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa) for <URL>,
plus the source of the affected components.

Rules:
- Use only the axe output and the code I gave you. Do not add issues.
- Quote the exact `target` selectors from the input for every group.
- Mark anything you infer (a root cause, which component renders a node) GUESS.
- Do not say whether the page is accessible or compliant, and do not write fixes yet.

Tasks:
1. Group violations by likely root cause and component.
2. Order the groups by axe impact, then by node count. Put anything in
   checkout, sign-in or contact forms first.
3. For each group, explain the WCAG success criterion in two sentences.
4. Turn the `incomplete` items into a manual checklist for this page.
5. From the element types in this code (forms, dialogs, carousels, media),
   list what I need to test by keyboard and screen reader.

Output: a markdown table with columns
group | rule ids | target selectors | node count | impact | component | GUESS?
then the lists from tasks 4 and 5.

The quoted selectors let you confirm in seconds that a group is real.

3. Keyboard pass

Unplug the mouse, or at least stop touching it. Safari on a Mac needs Safari > Settings > Advanced > "Press Tab to highlight each item on a webpage" turned on first (Apple). From WebAIM's keyboard guide:

Focus is visible on every interactive element. outline: none with no replacement fails.
Tab and Shift+Tab follow the visual layout, with no traps.
Modals keep focus inside, close on Esc and return focus to the button that opened them.
Enter works on links, Enter and Space on buttons (including anything with role="button"), Space on checkboxes, arrow keys inside radio groups and tabs.

Add these:

The first Tab stop skips to the main content.
No sticky header, cookie banner or chat bubble covers the focused element completely (2.4.11, new at AA in WCAG 2.2).
After a client-side route change, focus lands somewhere sensible.
Tooltips and mega menus can be dismissed without moving focus and stay put while the pointer moves onto them (1.4.13).
Text over photos and gradients passes contrast. axe can't measure that, so use a colour picker.

4. Screen reader pass

NVDA is free and runs on Windows 10 and later. From WebAIM's NVDA shortcuts: H, D and F jump between headings, landmarks and form fields, NVDA + F7 opens the Elements List and NVDA + Space switches between browse and focus mode. If pressing H types an "h" into a field, you're in focus mode.

On a Mac, VoiceOver toggles with Command-F5 (Apple's guide), VO + U opens the Rotor, and per WebAIM it works best in Safari.

Listen for:

Headings and landmarks that form a sensible outline
Link text that makes sense out of context
Each field's label, required state and error, plus focus on the first error or an error summary after a failed submit
States: expanded or collapsed on disclosure buttons, selected on the active tab
A name on every icon-only button (cart, close, search)
Dynamic messages like "added to cart" announced at all

5. Fixes drafted by a model, reviewed by you

Give the model one group from step 2 with its component code, and ask for a fix plus a Playwright test that fails if the bug comes back. In Microsoft's A11y LLM Eval, models writing UI code passed its automated checks 12% of the time with no accessibility instructions and 86% with a skill that makes the model review its own output. Those are automated checks, so read the diff yourself, the way you'd read a junior's pull request, ARIA first. The ARIA Authoring Practices have a section titled "No ARIA is better than Bad ARIA". Check:

Would a native <button>, <a href>, <label> or <dialog> do the job?
Does every aria-label contain the visible text? 2.5.3 Label in Name exists because "people who operate with voice interaction use the visible labels in their commands". A button that shows "Buy" with aria-label="Add product to cart" fails it.
Is aria-hidden="true" on something focusable? Then it's skipped by screen readers but still in the focus order.

After the fix, rerun axe and repeat the keyboard and screen reader checks for that component.

6. Regression test back in CI

Every bug you found by hand gets its own test, because axe won't notice it coming back. For the menu, in tests/menu.spec.ts:

import { test, expect } from '@playwright/test';

test('menu closes on Escape and returns focus', async ({ page }) => {
  await page.goto('/');
  // If the label changes to "Close menu" when open, locate it by test id instead
  const trigger = page.getByRole('button', { name: 'Open menu' });
  const menu = page.locator('#menu');

  await trigger.press('Enter'); // open it the way a keyboard user would
  await expect(menu).toBeVisible();

  // move focus off the trigger first
  await page.getByRole('link', { name: 'Item A' }).focus();
  await page.keyboard.press('Escape');

  await expect(menu).toBeHidden();
  await expect(trigger).toBeFocused();
});

Run every model-drafted test against the broken version and watch it fail first.

Gaps in this flow

It doesn't test zoom and reflow, motion or cognitive load. Ten minutes with NVDA also won't tell you how someone who uses a screen reader every day experiences the site. Before a launch, pay disabled people to test it.

The EAA question from your PM

This isn't legal advice. Each point below links to its source.

The European Accessibility Act applies from 28 June 2025. E-commerce services are in scope, defined as services provided "at the individual request of a consumer with a view to concluding a consumer contract" (Article 3(30)).
Microenterprises providing services are exempt (Article 4(5)).
Products and services that meet harmonised standards cited in the Official Journal are presumed to conform (Article 15). EN 301 549 V4.1.1, published by ETSI on 2 September 2026, is based on WCAG 2.2 A and AA, and as of mid-September 2026 it had not been cited there. If you're building or rebuilding now, aim for WCAG 2.2 AA.
For evidence, keep scan results, manual test notes and known issues with a fix plan.
On effort: steps 1 and 2 scale with a script. Steps 3 and 4 are manual work per template and per state, so list both (home, product, cart, checkout; menu open, modal, form with errors) before anyone estimates.

Where I'd stop

A verdict on whether a site is accessible, WCAG conformant or EAA compliant stays with a person. So does the call on focus order and on what a screen reader announces. Two smaller things are easy to let slide: closing a violation as a false positive before I've looked at the element, and alt text for an image the model hasn't seen on the page.

If you've got a triage prompt that holds up better than this one, post it in the comments.

AI-assisted. Reviewed and edited by me.