Naar de inhoud springen
kenjtecJournal
Het Journal doorzoeken

Laat de fout zien: duidelijkere overdrachten aan ChatGPT met screenshots

Een screenshot laat de toestand zien, maar niet automatisch de oorzaak ervan. Een volledig visueel bugrapport verbindt de weergave, de handeling en een controleerbare volgende stap.

Ana houdt twee identieke foto’s naast elkaar en heeft op één ervan een plek omcirkeld. AI-illustratie.

‘De knop klopt niet’ is lastig om mee aan de slag te gaan. ‘Na het verzenden verschijnt de melding op een smal scherm rechts, buiten het formulier’ geeft al een handeling, een toestand en een zichtbare afwijking. Een screenshot wordt waardevol als het zo’n beschrijving aanvult.

ChatGPT ondersteunt afbeeldingen als context, waaronder screenshots en diagrammen. De documentatie raadt aan om het relevante gebied, het gewenste resultaat en de grenzen van de vraag te benoemen. Ons eigen voorbeeld bestaat uit twee kunstmatige weergaven van een formulier. Er is daarvoor geen echte beeldanalyse of oplossing uitgevoerd.

De afbeeldingen moeten vergelijkbare toestanden laten zien

Afbeelding A toont een leeg registratieformulier, afbeelding B de toestand na het invoeren van gegevens en het verzenden. De vensterbreedte blijft gelijk. Een bewust ingebouwd probleem betreft de melding onder de knop. Zo wordt duidelijk welke verandering tussen de twee afbeeldingen ligt.

Beschrijf de volgorde expliciet. Twee op elkaar lijkende bijlagen zonder uitleg maken het verleidelijk om verschillen als willekeurige ontwerpvoorkeuren te behandelen. Verwijder persoonsgegevens als ze niet nodig zijn voor de technische vraag. Verzonnen veldinhoud is voldoende om mee te beginnen.

Scheid de zichtbare waarneming van de technische hypothese

De afbeelding kan laten zien dat een regel wordt afgekapt. Of een vaste breedte, een regelafbreking, een ander lettertype of een bovenliggend element daarvoor verantwoordelijk is, volgt daar nog niet uit. Een bruikbaar antwoord moet deze niveaus uit elkaar houden.

Compare the two form views I created myself.
A: before input. B: after submitting, same window width.
Look at the notice below the button.
1. Describe only visible differences.
2. State the expected behaviour from my description.
3. Mark technical causes explicitly as guesses.
4. Suggest a small next checking step.

Deze eigen opdracht vraagt nog niet om een volledige codeoplossing. Een gerichte vervolgvraag over de bijbehorende HTML of de relevante CSS-regel kan nuttiger zijn dan een zelfverzekerde wijziging aan een vermoedelijke oorzaak.

Een bugrapport is een klein contract over een toestand

Houd de begintoestand, de handeling, de verwachting en de daadwerkelijke waarneming bij elkaar. Voeg de vensterbreedte toe en, waar relevant, de ingevoerde inhoud. Zo kan een tweede persoon proberen precies dezelfde toestand na te bootsen. Dat is een sterkere basis dan één zin over een ‘kapot’ scherm.

Starting point: empty sample form at a fixed narrow width.
Action: enter example data, then submit.
Expected: notice remains fully readable below the button.
Observed: notice extends sideways beyond the form area.
Open: which specific rule causes the overflow?

Dit is een illustratieve bevinding voor het geplande patroon, geen verslag van een applicatie die is waargenomen. Juist deze aanduiding voorkomt dat een plausibele bugbeschrijving later wordt doorgegeven als een productbug die daadwerkelijk is gereproduceerd.

Verander telkens maar één voorwaarde

Een volgende stap kan de identieke toestand met het toetsenbord nabootsen of naar de bijbehorende regel kijken. Als je browser, breedte, gegevens en inhoud tegelijk verandert, blijft onduidelijk welk verschil effect had. Houd bij het vergelijken de voorwaarden dus zo veel mogelijk herkenbaar gelijk.

Geef de nieuwe waarneming daarna terug als aanvullend bewijs. ‘Bij dezelfde breedte is de regel na deze wijziging volledig zichtbaar’ is concreter dan ‘werkt nu’. Bij een echte oplossing hoort ook het controleren van andere zinvolle toestanden, zoals een langere meldingstekst.

Een deelweergave blijft een deelweergave

Een screenshot laat niet automatisch de documentstructuur, een serverrespons of het volledige toetsenbordpad zien. Het bewijst ook niet de toegankelijkheid als geheel. Voor die vragen heb je geschikte aanvullende waarnemingen van het echte werk nodig.

De kracht van een visuele overdracht zit in de precisie: mensen en AI praten over dezelfde plek, dezelfde toestand en dezelfde verwachting. Een nuttige volgende stap volgt uit de vraag die nog openstaat. Een productwissel of een algemene herstelknop is daarvoor geen voorwaarde.

Bronnen en documentatiestatus: 25 oktober 2026.

Hamburg is ons vertrekpunt.

Het nuttige reist met je mee.

Praktische AI uit Hamburg, internationaal uitgelegd.

Bewaarde artikelen