The Workbench — Human Judgment Meets Useful Machines

Sheet 01 · The argument

Generation got cheap. Judgment didn't.

Interpretation

Ask a capable model for a landing page and you will get one: a headline, three feature cards, a cheerful call to action, often in less time than it takes to describe the business. The page will usually look finished. That is the problem. Looking finished and being finished have drifted apart, and most of the real work now lives in the space between them.

The work in that space is not typing. It is choosing which problem the page solves and for whom; noticing that the headline promises something the business doesn't offer; checking that the form works without a mouse; refusing the statistic nobody can source; and answering for it when something slips through anyway. A model can help with nearly every one of those steps. It cannot be the one who answers for them.

So this workbench treats AI assistance the way a good studio treats any powerful tool — a laser cutter, a router, a very fast junior draughtsperson who never gets tired and is sometimes confidently wrong. Use it freely where mistakes are cheap and visible. Build jigs, gauges and checklists where mistakes are expensive or silent. Keep a record of who decided what.

The useful measure is not how much was generated or how long it took. It is whether a visitor gets something true and usable, and whether the page behaves when they try.

Three working claims run through the sheets that follow. They are interpretations, not findings:

Drafting is rarely the bottleneck any more; verification and taste are. When output is abundant, the scarce act is deciding what must not ship.
The riskiest errors are the plausible ones. An obviously broken draft gets fixed. A fluent paragraph with one invented figure survives a quick read.
Honest attribution is information, not confession. Telling readers how something was made helps them decide how much to trust it.

↑ Contents

Sheet 02 · Interactive

The critique bench: four broken pages. Fix them yourself.

Fiction Fabricated teaching examples — not client work, not audited cases

Each case is an invented component built to fail in one common way. They are live components, not screenshots: press a fix and the component's actual markup and behaviour change, while the notes say what the fix costs. Use ← → on the case tabs to move between cases.

The interactive bench needs JavaScript. Here are the four cases as written notes.

Case A — The confusing landing page

Failure: a fictional pottery studio greets visitors with “Synergising tomorrow's tactile experiences” and three equal buttons: Learn more, Discover, Explore. Fixes: say what it is (beginner wheel-throwing classes); offer one primary action; answer the deciding questions (session length, what's included, class size); remove decoration that competes with the message. Tradeoffs: specificity turns some visitors away (usually the right ones); a single primary action hides other paths, so navigation must carry them; removing all flourish can erase personality, so keep one distinctive element.

Case B — The unsafe DOM update

Failure: a guestbook preview inserts a visitor's name with innerHTML and their website straight into a link. A “name” containing an image tag with an onerror attribute would run script; a javascript: address would too. Fixes: insert text with textContent; create links only for http: or https: addresses; validate length with a clear error; add a Content-Security-Policy header as a second line of defence. Tradeoffs: validation is not sanitisation and over-strict rules reject real names; CSP can break legitimate inline code and must be tested on a preview deployment.

Case C — The accessibility failure

Failure: a newsletter form with a placeholder instead of a label, a div pretending to be a button (unreachable by keyboard), errors shown only as a red border, and pale, tiny text. Fixes: a visible label; a real button; an error in words tied to the field; contrast of at least 4.5:1 and comfortable target sizes. Tradeoffs: visible labels take space; real buttons bring default styles to override; more text in errors means more to translate and maintain.

Case D — The generic hollow essay

Failure: “In today's fast-paced digital landscape…” followed by “revolutionizing”, “unprecedented” and “unlock your potential”. Fixes: open with a specific situation; make a claim that could be wrong; label its status and say what would change your mind; cut the inflation. Tradeoffs: specific claims can be refuted (that is the point); a concrete scene may not generalise; plainer prose can read as less “exciting” to some readers.

↑ Contents

Sheet 03 · Interactive

When does AI help, and when must a human verify?

Interpretation Evidence on automation bias

“Did AI touch this?” is the wrong question. The better ones are: what happens if this is wrong, who would notice, and how fast could it be undone? Walk the tree with something you are making right now.

Read the whole tree as text

Will anyone act on it, rely on it, or be affected if it is wrong?
- No → Are you generating options to choose from, rather than a finished answer?
  - Yes → A. Let the machine widen the field. Your job is selection and taste.
  - No → B. Draft, then edit for voice and truth. Cut filler; verify any fact that crept in.
- Yes → Can you check it with a method independent of the model?
  - No → C. Stop. Don't ship what you can't check. Find a primary source or an expert, or shrink the claim.
  - Yes → If it's wrong, will the mistake be visible quickly and cheap to undo?
    - Yes → D. Use AI, verify independently, stage, keep a rollback.
    - No → E. Human verification is the job. AI may assist the reviewer; a qualified person reviews every line, ideally a second person too.

Evidence Why the tree distrusts quick approval

Raja Parasuraman and Dietrich Manzey's 2010 review in Human Factors pulls together studies of automation complacency and automation bias. It reports that complacency appears in both naïve and expert participants and is not overcome by simple practice, and that imperfect decision aids lead people into errors of omission (missing what the aid missed) and commission (following its wrong advice).

What this does not establish: those studies concern decision aids in settings such as aviation and process monitoring, not language models or web work. Applying them here is my interpretation — a reasonable one, I think, but untested in this exact setting.

For organisations, NIST's AI Risk Management Framework 1.0 (2023) offers a voluntary vocabulary organised around four functions: Govern, Map, Measure and Manage. This tree is a pocket heuristic for one maker, not an implementation of that framework.

↑ Contents

Sheet 04 · Workflow

Build, review, stage, release — and keep the way back.

Established practice Evidence from Cloudflare's documentation

This is the workflow behind a small static site: plain HTML, CSS and a little JavaScript, uploaded to a host such as Cloudflare Pages. It is boring on purpose. Its job is to make every change reviewable before visitors see it, and reversible after.

Drawing 04 — the release pipeline. Stages marked in yellow need a person's sign-off.

Brief
Write one sentence for the page's job, one for its reader, and one list of things it must not claim. The third list is the one models never write for you.
Build locally
Generate and edit in plain files you can read and compare. Keep secrets out of a static site entirely: anything in the folder will be public.
Review
Read every claim against its source. Complete every task with a keyboard. Narrow the window to 320 pixels. Open the browser console and treat any error as a bug. Use the release gate.
Package
Zip the contents of the folder so index.html sits at the archive's root. If everything sits inside a nested folder, the site's root URL has no index page to serve. Practical note
Stage on a preview
Deploy to a temporary preview address first, not straight over the live site. Cloudflare's documentation shows a _headers rule that adds X-Robots-Tag: noindex on pages.dev addresses so previews stay out of search results. Evidence
Verify on the preview
Check what a local file cannot show: HTTPS, the response headers that were actually served, the 404 page, and whether a strict Content-Security-Policy broke anything. Per Cloudflare, _headers rules apply to static assets but not to responses generated by Pages Functions, and a file may hold up to 100 rules. Evidence
Release
Promote only what passed on the preview, and write down what changed. A dated line in a changelog is cheap; reconstructing what happened from memory is not.
Keep the way back
Cloudflare documents that any successfully built production deployment is a valid rollback target, but preview deployments are not. Evidence So the safety net only exists once a known-good production release exists. Keep the previous ZIP as well, and remember that a rollback restores files, not trust: anyone who screenshotted the mistake still has it.

↑ Contents

Sheet 05 · Specimens

Specimens you can lift

Established framework: WCAG 2.2, OWASP Illustration

Small, working patterns used on this very page. Each comes with the reason it exists, because copying code without its reason is how the next mistake gets made.

S1 A skip link and real landmarks

Keyboard users should not tab through the whole header on every page. A skip link plus header, nav, main and footer gives assistive technology a map. WCAG 2.2 calls this “Bypass Blocks” (2.4.1). Press Tab once at the top of this page to see it.

<a class="skip-link" href="#main">Skip to content</a>
<header>…<nav aria-label="Page">…</nav></header>
<main id="main" tabindex="-1">…</main>
<footer>…</footer>

/* Visible when focused, never display:none */
.skip-link { position:absolute; left:1rem; top:-4rem; }
.skip-link:focus { top:1rem; }

S2 A toggle that says what state it is in

Every fix button on the bench is a native button with aria-pressed. The state is announced to screen readers and shown visually with a text change, not colour alone (WCAG 1.4.1, Use of Color).

<button type="button" aria-pressed="false" class="fix">
  <span class="fix__state">Off</span> Use a real label
</button>

btn.addEventListener('click', () => {
  const on = btn.getAttribute('aria-pressed') !== 'true';
  btn.setAttribute('aria-pressed', String(on));
  btn.querySelector('.fix__state').textContent = on ? 'On' : 'Off';
});

S3 An error in words, tied to its field

A red border tells some people something is wrong and tells others nothing. WCAG 3.3.1 asks that detected errors be identified and described in text. aria-describedby makes the message part of the field's description.

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email"
       aria-invalid="true" aria-describedby="email-err">
<p id="email-err" class="error">
  ⚠ Enter an address like [email protected]
</p>

S4 Putting untrusted text on the page safely

OWASP's DOM-based XSS cheat sheet recommends textContent as the fundamental safe way to place untrusted data in the page, and warns against passing it to innerHTML, outerHTML or document.write. Links need their own check: a javascript: address is still code.

// Text: never parsed as HTML
nameEl.textContent = untrustedName;

// Links: allow only web addresses
function safeLink(raw, label) {
  let url;
  try { url = new URL(raw); } catch { return null; }
  if (url.protocol !== 'https:' && url.protocol !== 'http:') return null;
  const a = document.createElement('a');
  a.href = url.href;
  a.rel = 'nofollow noopener';
  a.textContent = label;
  return a;
}

S5 Metadata that tells the truth

Titles, descriptions and social previews are often the first thing a stranger reads, and often the last thing anyone checks. Google's guidance on generative AI content explicitly extends its call for fact-checking to titles, meta descriptions, structured data and image alt text.

<title>The Workbench — Human Judgment Meets Useful Machines</title>
<meta name="description" content="What the page actually offers, in one sentence.">
<link rel="canonical" href="https://workbench.sahiltayal.com/">
<meta property="og:title" content="…">
<meta property="og:image:alt" content="Describe the image, not the brand.">

S6 Headers as a second line of defence

The _headers file shipped with this site. The Content-Security-Policy only works because the page has no inline scripts, inline event handlers or style attributes; a stricter-sounding policy that breaks the page is worse than none. Verify on a preview before trusting it.

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  X-Frame-Options: DENY
  Content-Security-Policy: default-src 'self'; script-src 'self';
    style-src 'self'; img-src 'self' data:; object-src 'none';
    base-uri 'self'; form-action 'none'; frame-ancestors 'none'

https://:project.pages.dev/*
  X-Robots-Tag: noindex

(The real file keeps the policy on a single line; it is wrapped here for reading.)

↑ Contents

Sheet 06 · Limits

What QA can certify — and what it can't

Interpretation Established framework: WCAG 2.2

Every check answers a narrower question than its name suggests. A QA report becomes trustworthy when it says exactly which questions it asked.

Common checks, what they can tell you, and what they cannot
Check	Can tell you	Cannot tell you
HTML validator	The markup parses as intended; IDs are unique; elements are allowed where they sit.	Whether headings describe their sections, or whether the page makes sense.
Automated accessibility scan	A subset of machine-detectable issues: missing alt attributes, missing labels, some contrast failures.	Whether alt text is accurate, whether focus order is logical, whether the experience works for a person.
Contrast checker	The ratio between two specified colours.	States you forgot to test: hover, focus, error, text over images or gradients.
Keyboard pass by hand	Whether you could complete each task, in the browser you used.	How it behaves in browsers and devices you didn't try.
Screen-reader spot check	How one reader and browser pairing announces what you tested.	Every other pairing, or tasks you didn't attempt.
Link checker	Each link resolved when checked.	That the page still says what you cited it for, or that it will resolve next month.
Security-header scan	Which headers the server sent.	Whether the page's own logic is safe; headers are a seatbelt, not brakes.
Reading every claim against its source	Whether each claim is supported by what you read.	Whether the source itself is right.

WCAG 2.2 The standard itself is candid about limits. It notes that its success criteria are designed to be tested through a combination of automated testing and human evaluation, and that even content conforming at the highest level (AAA) will not be accessible to every person with every type, degree or combination of disability. WCAG also treats conformance claims as optional; this site makes none.

A useful QA report therefore has four columns: what was tested, how, on what, and what was not tested. The phrase “fully tested” deserves suspicion — including when this site's own README is tempted to use it.

↑ Contents

Sheet 07 · Essay

Who made this? Attribution, creativity, error and value

Interpretation

Attribution is a label, not a confession

The debate about AI and authorship often shrinks to a yes-or-no question: did a machine write this? Readers usually need something more specific. They need to know which parts to trust and on what grounds. Google's search guidance on generative AI content points in the same direction: it suggests giving readers context about how content was created, and asks that AI-assisted material be checked for accuracy before publishing. Evidence

A credit line that helps a reader answers three questions: what did the tool do, what did a person decide, and what was checked? Here is the honest version for this page:

This page was produced with substantial AI assistance (Anthropic's Claude) from a detailed written brief by Sahil Tayal. The brief set the subject, boundaries and editorial standards. The AI drafted the copy and code and selected the sources, which were checked against the original pages or their publishers' citation records; the interactions were tested in a headless browser, with the results and gaps listed in the project's README. Treat it as a reviewed draft, not an audited publication.

That is less flattering than “crafted by hand” and more useful. It tells you where to push.

Where creativity sits

A model will offer a hundred headlines in a minute. The creative act may be recognising the one that is true for this café, and deleting the other ninety-nine. Choosing the problem, setting the constraint, making the cut: these are real creative decisions, and studios have always valued them.

But it would be too convenient to stop there. Selection is not the same as origination, and some of what we call taste is a learned preference for whatever we saw most often. If every maker selects from similar machine-generated options, the web may drift towards a pleasant sameness. Hypothesis One small defence is to begin with your own constraint — a sketch, a sentence, a refusal — before asking for options.

Errors have owners

“The model said so” is not an explanation a reader can accept, any more than “the spellchecker let it through.” Whoever publishes owns the error. In practice ownership looks like dull machinery: a visible way to report mistakes, a date on the page, a changelog, and the habit of correcting in public rather than quietly editing. If you find an error here, email Sahil; corrections are part of the work, not an interruption to it.

Value delivered, not effort displayed

Lines of code and hours spent are tempting proxies because they are easy to count. They measure input. A forty-line page that answers a visitor's question beats a four-thousand-line page that performs effort. Yet small is not automatically virtuous either: keyboard handling, error states, fallbacks for when scripts fail and print styles all add code that most visitors never notice and some visitors depend on. The questions that matter are plainer. Can a visitor do what they came to do? Does the page behave? Are its claims supported? Is the next person able to maintain it?

Sahil writes longer essays on adjacent questions — about thinking, work and modern tools — in his writing archive on Medium.

↑ Contents

Sheet 08 · The case against

Objections, counterexamples and misconceptions

Interpretation

Strongest objection: “This is laziness rebranded as curation.”

If a machine produced most of the material, calling the human part “craft” can be self-flattery. Clicking accept on a plausible draft is not judgment.

Reply: the objection is right about a real failure mode, so it deserves a test rather than a defence. Human involvement counts as craft only when it changes outcomes you can point to: a false claim removed, a keyboard trap fixed, a section cut because it served the author rather than the reader. If the human contribution is indistinguishable from approval, the objection wins.

“Human verification is theatre.”

The automation-bias research cited on sheet 03 cuts both ways: reviewers who expect a tool to be right tend to look less carefully. A human signature on an unread draft is worse than no signature, because it borrows trust it didn't earn.

Reply: make verification independent and recorded. Check against something other than the model — a validator, a test, a primary source, another person — and write down what you checked, so the claim of checking can itself be checked.

“Checklists kill taste.”

Reply: partly fair. A checklist catches omissions; it does not create quality. Keep it short, treat it as a floor rather than a ceiling, and retire items that never catch anything.

Counterexamples to this page's own tree

Misjudged stakes. A “low-stakes” joke on a personal site can wound a group the author never pictured. The tree's first question is only as good as the imagination answering it.
Reversible for you, not for them. A staged page can be rolled back in seconds, but a visitor who acted on a wrong price already acted.
Independent checks that share a blind spot. Two sources that copy each other are one source. Two reviewers trained to look for the same things will miss the same things.

Misconceptions worth retiring

“AI output is either trustworthy or it isn't.”: Reliability varies by task inside a single answer: the layout may be fine and the one statistic invented.
“A high automated accessibility score means the page is accessible.”: Automated tools catch a subset of issues. A page can score well and still trap keyboard users or mislabel controls.
“More code means more work, which means more value.”: Value is what the visitor receives. Code size measures neither effort nor benefit reliably.
“Disclosing AI use destroys credibility.”: Vague disclosure can. Specific disclosure — what the tool did, what was checked — gives readers a way to calibrate.
“Human-written means verified.”: People invent figures and misremember sources too. Verification is an act, not a property of the author.

↑ Contents

Sheet 09 · Interactive

The release gate

A working tool · a record, not a certificate

Twelve checks, deliberately short. Tick what you have actually done, not what you intend to do. Nothing is saved or sent: your ticks live only in this browser tab and disappear when you leave or reset.

Content and claims Every factual claim links to a source I opened, is labelled as interpretation, or has been removed. Fictional or illustrative material is labelled where it appears, not only in a footer. A stranger can tell what the page is for from its first screen.

Accessibility I completed every task with a keyboard alone, and focus was always visible. Text meets 4.5:1 contrast and controls 3:1, in every state I could find (hover, focus, error). Images and icons have text alternatives or are marked decorative. The layout works at 320 pixels wide and at 200% zoom without sideways scrolling.

Security and privacy Dynamic text uses textContent or createElement; no untrusted innerHTML, no eval. No secrets or private data are in the files; visitor input is not stored or sent without saying so. Security headers were checked on the preview URL, and the page still works with them.

Release The ZIP has index.html at its root and went to a preview URL first. Links, the 404 page and metadata were checked on the preview, and I know which deployment I would roll back to.

0 of 12

0 of 12 checks ticked.

↑ Contents

Open question

If machines eventually check better than we do, what part of answering for the work should stay human — and why?

Not the typing; that has already moved. Perhaps the choice of what is worth making, and for whom. Perhaps the willingness to be accountable to a particular reader. Perhaps something else. I don't think this page settles it, and I would rather hear a good disagreement than pretend it does.

Email Sahil your answer

Sources

Sources, and what each one does not prove

Sources 1, 2 and 5–7 were opened and read on 24 October 2026. For sources 3 and 4, the bibliographic details and DOIs were confirmed through the publishers' and repositories' citation records (NIST's publication page; Technische Universität Berlin's repository and OpenAlex), and the summaries rely on the published abstracts. Paraphrases are mine; any misreading is mine to correct.

W3C (2024). Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 12 December 2024. w3.org/TR/WCAG22

Establishes: testable success criteria, including Bypass Blocks, Use of Color, Error Identification, Focus Not Obscured and Target Size (Minimum, 24 by 24 CSS pixels). Does not: certify this site; no conformance claim is made here.
OWASP Cheat Sheet Series. DOM based XSS Prevention Cheat Sheet. cheatsheetseries.owasp.org

Establishes: widely used guidance to place untrusted data with textContent and avoid HTML-rendering sinks such as innerHTML. Does not: guarantee that following it makes an application secure.
Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 52(3), 381–410. doi:10.1177/0018720810376055

Establishes: a review of studies on automation complacency and bias, reported in novices and experts. Does not: study language models or web development; its use here is an extrapolation.
NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. doi:10.6028/NIST.AI.100-1

Establishes: a voluntary, organisation-level framework built on Govern, Map, Measure and Manage. Does not: endorse or describe this page's decision tree.
Google Search Central. Google Search's guidance on using generative AI content on your website (page last updated 1 October 2026). developers.google.com

Establishes: Google's stated expectations: focus on accuracy and quality, fact-check AI-assisted content including metadata, and consider giving readers context on how content was made. Does not: say how any page will rank.
Cloudflare Docs. Pages: Headers. developers.cloudflare.com/pages/configuration/headers

Establishes: the _headers syntax, the 100-rule limit, the pages.dev noindex pattern, and that rules don't apply to Pages Functions responses. Does not: tell you which policy suits your page.
Cloudflare Docs. Pages: Rollbacks. developers.cloudflare.com/pages/configuration/rollbacks

Establishes: successfully built production deployments are rollback targets; previews are not. Does not: undo anything that happened while the faulty version was live.

Related worlds

Editorial connections within Sahil's own projects. They are neighbours, not evidence for anything argued here.

Leave the bench tidy.

Close the cases, reset the gate, take whichever specimen you need. The rest of the Sahilverse is a library of questions with experimental doors.

← Back to Sahilverse Email Sahil Read the Medium archive

The machine drafts. Someone still signs the drawing.

Case A — The confusing landing page

Case B — The unsafe DOM update

Case C — The accessibility failure

Case D — The generic hollow essay

Brief

Build locally

Review

Package

Stage on a preview

Verify on the preview

Release

Keep the way back

S1 A skip link and real landmarks

S2 A toggle that says what state it is in

S3 An error in words, tied to its field

S4 Putting untrusted text on the page safely

S5 Metadata that tells the truth

S6 Headers as a second line of defence

Attribution is a label, not a confession

Where creativity sits

Errors have owners

Value delivered, not effort displayed

Strongest objection: “This is laziness rebranded as curation.”

“Human verification is theatre.”

“Checklists kill taste.”

Counterexamples to this page's own tree

Misconceptions worth retiring

If machines eventually check better than we do, what part of answering for the work should stay human — and why?

Leave the bench tidy.