Programming with AI
ENRU
8.5

AI mistakes in the frontend, and a checklist

checking with your eyes is checking too

What it is

The chapter's closer. The frontend differs from everything earlier in the book in one way: here the result is checked with your eyes. The code ran, there are no errors, and the button doesn't press or the text overlaps the image — and the only way to learn that is by looking.

AI mistakes in the frontend

1. div instead of semantics

<div class="btn"> with a click handler. Doesn't work from the keyboard, invisible to screen readers (article 8.2).

2. Outdated layout

float, position: absolute and tables for placing boxes. Code from the era there is more of in the training data (article 3.1, reason 3). Today that is flex and grid.

3. !important instead of understanding

It overrides a conflict by force without resolving it (article 8.3).

4. Magic numbers

margin-top: 37px, width: 433px — eyeballed for one screen.

5. No responsiveness

The page looks good at exactly the width it was composed at. On a phone, horizontal scrolling.

6. Styles inline in the markup

style="..." on every element: it overrides external rules and cannot be reused.

7. Accessibility forgotten

No alt, no label, text contrast below the standard, focus invisible. An AI adds these only if asked outright.

8. The script runs before the markup

<script> in the <head> with no defer — querySelector returns null, because the element doesn't exist yet (article 8.4).

A frontend checklist

Six steps on top of the general acceptance checklist (article 4.7). The first three with your eyes, the second three in the developer tools.

1. Look at it

Open it and look. Obvious, and it is the chapter's main check: neither tests nor types will tell you the text has landed on top of the button.

2. A narrow screen

Shrink the window to phone width. Horizontal scrolling appeared — there is no responsiveness.

3. Long text

Type a string three times longer than expected into a field or a heading. A layout built around short labels falls apart exactly here.

4. The console

F12, Console tab. There should be no red.

5. The network

Did every file load? A 404 on a stylesheet or a script explains most of the strangeness.

6. The keyboard

Walk the page with Tab. Every button and link must receive focus, and the focus must be visible. That is thirty seconds and the most common finding in generated markup.

What to tell the AI

Prompt
Check this markup against the list:
- are there divs with handlers instead of button and a
- is float or position: absolute used for layout
- are there !important and magic pixel numbers
- what happens on a 360-pixel-wide screen
- do images have alt and fields have label

Which of these are problems? If none, say so.
Prompt
Make this block responsive: three columns on a wide screen,
one on a narrow one. With grid, without a media query per
width — use auto-fit and minmax.
Prompt
Check accessibility: heading order, alt, label, contrast,
focus visibility. A list of problems with line numbers.

Cheat sheet

  • The frontend is checked by eye: neither types nor tests show a broken layout.

  • Eight common mistakes: div instead of a button, float, !important, magic numbers, no responsiveness, inline styles, no accessibility, script before markup.

  • Checklist: look · narrow screen · long text · console · network · Tab.

  • Narrow screen, long text and the keyboard catch almost everything and cost a minute.

  • There should be no red in the console.

  • An AI adds accessibility only when asked directly.