Run a small AI coding pilot with a reviewable result

A useful AI coding pilot answers a narrow question: can the assistant help produce one understandable change that meets an acceptance check? It does not need a new application. Use a small feature with explicit failure states, review the diff and record the checks you actually run.

The task and inputs

Our teaching feature is a compare button beside two tool selectors. The available catalogue IDs are alpha, beta and gamma. The button should be enabled only when the user selects two different, available IDs. Reversing the pair is valid. Missing, duplicate or unavailable selections must leave the button disabled and explain the problem.

In an existing project, give the assistant the relevant UI files, the catalogue interface, the test command and project conventions. Use a separate branch or another reversible checkpoint. Keep credentials and private production data out of the exercise. Decide what is out of scope: in this example, pricing, network analysis, account creation and new dependencies.

Write acceptance criteria before asking for code

• Empty selection: disabled; message asks for two tools.
• alpha + alpha: disabled; message asks for different tools.
• alpha + retired: disabled; message explains unavailability.
• alpha + beta and beta + alpha: enabled.
• Changing a valid selection to an invalid one immediately disables the action.
• Each selector has a visible label; the status is announced without moving focus.

These are expected outcomes, not claims that a particular assistant or product passed a test. The measurable deliverable is a focused diff plus your own verification record.

A prompt with a boundary

Implement only the two-selection compare state described below.
First explain the files you need to change and any assumptions.
Use existing project conventions; add no dependencies.
Keep decision logic separate from DOM updates. Treat catalogue IDs
as exact strings. Disable the action for missing, identical or
unavailable IDs. Revalidate before starting the comparison.
Use textContent for status text and visible labels for both selectors.
Add tests for empty, duplicate, unknown, valid and reversed inputs.
Return a short diff summary and the commands I should run.
Do not claim tests passed unless you actually ran them.

A small reference implementation

Save the following as compare-state.mjs. This example makes validation order visible: an incomplete selection is handled first, a duplicate second and a stale catalogue entry third. Adjust the messages to your product, while keeping the conditions explicit.

export function comparisonState(selected, availableIds) {
  if (!Array.isArray(selected) || selected.length !== 2 ||
      selected.some(id => typeof id !== 'string' || !id)) {
    return { enabled: false, message: 'Choose two tools.' };
  }
  const [a, b] = selected;
  if (a === b) {
    return { enabled: false, message: 'Choose two different tools.' };
  }
  if (!Array.isArray(availableIds) ||
      !availableIds.includes(a) || !availableIds.includes(b)) {
    return { enabled: false, message: 'A selected tool is unavailable.' };
  }
  return { enabled: true, message: 'Ready to compare.' };
}

In the UI, pass the two current selector values to this function on every change. Set button.disabled = !state.enabled and status.textContent = state.message. A status element such as <p role="status"></p> lets assistive technology announce the updated message. Re-read the selection and revalidate inside the action handler; the catalogue may have changed since the button was enabled.

Run the focused checks

Save this file as compare-state.test.mjs beside the function. It uses Node’s built-in test runner and assertion library. Use Node.js 22 or newer and run node --test compare-state.test.mjs. Treat the output from your own run as the verification record.

import test from 'node:test';
import assert from 'node:assert/strict';
import { comparisonState } from './compare-state.mjs';
const ids = ['alpha', 'beta', 'gamma'];

test('rejects incomplete, duplicate and unavailable selections', () => {
  for (const selected of [[], ['alpha'], ['', 'beta'], [null, 'beta']]) {
    assert.equal(comparisonState(selected, ids).enabled, false);
  }
  assert.deepEqual(comparisonState(['alpha', 'alpha'], ids), {
    enabled: false, message: 'Choose two different tools.'
  });
  assert.deepEqual(comparisonState(['alpha', 'retired'], ids), {
    enabled: false, message: 'A selected tool is unavailable.'
  });
});

test('accepts a valid pair in either order', () => {
  for (const selected of [['alpha', 'beta'], ['beta', 'alpha']]) {
    assert.deepEqual(comparisonState(selected, ids), {
      enabled: true, message: 'Ready to compare.'
    });
  }
});

The pure-function checks cannot establish that labels, focus, status announcements or click handling work. Open the interface, use the keyboard to change both selections and exercise every acceptance criterion. Also simulate a catalogue entry disappearing. A button that looks disabled but still starts the action fails the check.

Review the diff, not just the demonstration

Ask the assistant to point out each changed file and why it is needed. Read the diff yourself. Look for unrelated refactors, added packages, hidden network calls, removed validation and HTML insertion of untrusted text. MDN distinguishes plain text assignment from parsing HTML; a status message needs text, so textContent is the appropriate operation here.

Check the interface between the helper and its caller. The helper expects exact catalogue strings; silently trimming or lowercasing IDs elsewhere can change identity. Avoid making tests merely assert whatever the implementation happens to return. Keep the acceptance cases independent and add a new case only when a real requirement or failure calls for it.

Record a useful pilot result

Feature:
Assistant contribution:
Files changed:
Automated checks run and actual output:
Manual acceptance cases checked:
Corrections I made:
Unresolved limitations:
Decision: keep / revise / revert

Count your review and correction time as part of the pilot. A passing helper test does not demonstrate production security, application-wide compatibility or an assistant’s general quality. Keep the change only when you understand it and can reproduce the result. Node, MDN and W3C references below explain the specific APIs and accessibility practice used in this exercise.