AI-assisted development: Why a green build is not enough

Each check answers a particular question

A successful build shows that the application can be built. A type check catches certain inconsistencies in the code. An automated test checks the behaviour we described to it. These are valuable forms of evidence, each with a limited scope. Whether someone can use every part of a contact form on a small screen needs to be checked as a separate question.

Working with AI allows me to develop features and make changes quickly. That also increases the number of states that need to work together. Part of development is therefore defining concrete acceptance criteria for important workflows: what should the user achieve, and how will we know it works?

494 pixels of content in a 390-pixel viewport

An initial check of my portfolio's mobile GitHub calendar found no horizontal overflow of the overall document. Yet part of the calendar was missing on the right. Measuring individual elements explained why: the calendar was 494 pixels wide in a 390-pixel test viewport. A surrounding container clipped the excess content, hiding the problem from the existing check.

The correction had to address the layout. The grid must be able to shrink to the available width, and calendar cells need to follow the space they actually have. I then checked the bounds of the calendar card and search suggestions as well. The useful question was whether the content people needed remained fully visible and reachable.

An update does not replace an already open browser tab

The second problem appeared in a browser that had been in use for some time. An older portfolio tab and the new version accessed the same stored cookie-choice record. The older code did not recognise its new format and removed it. The new tab immediately showed the dialog again, even though a choice had just been confirmed.

The underlying browser behaviour is documented: localStorage changes are reported to other tabs on the same origin through the storage event. The MDN documentation linked below explains this connection. A clean test browser had not contained the problematic combination of older and newer application versions.

The new choice is now stored separately from the old format. Equivalent decisions can be carried over; an older permission does not authorise new purposes. A later refusal in an older tab is still respected. The additional test keeps both versions open together and checks reloads and withdrawal as well.

What happens after the click is part of the feature

Filling in a contact form is only one step in the task. Do required fields and limits in the browser match the backend? Does the confirmation arrive? Does the enquiry appear in the intended dashboard? For a booking, the available time, confirmation and possible cancellation belong to the same workflow.

This perspective matters for internal applications too. My sales CRM connects boards, inboxes and appointments. The content platform connects topic evaluation, an agent and editorial planning. Much of their value comes from these handoffs: information needs to arrive where someone can act on it. Separately tested components do not automatically prove those connections work.

Combine repeatable tests with an existing browser session

Playwright is one of the tools I use for repeatable browser checks. Its documentation describes how to emulate properties such as viewport size, touch input and language. This makes it possible to check the same workflow under different conditions. Emulation represents selected properties; it does not reproduce every aspect of every physical device.

It is also useful to inspect a browser that has already been in use, with saved preferences, open tabs and state from before the latest update. In this case, that exposed a missing test scenario. The observed failure then becomes a repeatable check, helping catch its return during later changes.

What to clarify before handover

A small prototype and a business system used every day need different levels of verification. The important part is to account for key workflows and the consequences of failure within the agreed scope. Concrete answers to these questions make a project conversation more useful:

• Which task must a user be able to complete from start to result?
• Which devices, languages and existing browser states matter?
• What happens with invalid input, repeated actions or missing data?
• How do we verify that an enquiry, booking or change actually arrived?
• How will we detect a problem after an update, and how can we roll the change back?

Turn a concrete problem into work that can be verified

If you want a website, internal tool or AI-assisted application built, describe a typical working day with it. Who will use it, which steps need to connect and where does the current process take time? That gives us a basis for planning implementation and verification together. For existing software, a specific workflow that fails in everyday use is also a useful place to start.