# Elenchus-vragen

Standaardvragen om een AI-voorstel te ondervragen, per domein.

> Vrij te gebruiken en aan te passen. Bron: https://ars-socratica.ai
>
> Gebruiksregel: stel de vraag vóórdat je het antwoord accepteert, niet erna.
> Een goede elenchusvraag is geen quizvraag; hij dwingt het voorstel zijn
> eigen zwakte te tonen. Twee of drie vragen die pijn doen zijn meer waard
> dan tien die dat niet doen.

---

## Altijd, ongeacht domein

1. Wat is het bewijs voor deze bewering — en wat zou haar weerleggen?
2. Welke aanname zit er in mijn vraagstelling die jij hebt overgenomen zonder te toetsen?
3. Genereer twee wezenlijk andere alternatieven en bekritiseer alle drie, inclusief je eigen voorstel.
4. Wat weet je hier niet zeker? Benoem het expliciet in plaats van eromheen te schrijven.
5. Als dit over een half jaar stuk is: wat is dan de meest waarschijnlijke oorzaak?

## Architectuur

1. Voor welke schaal is dit ontworpen, en is dat onze schaal? (Over-engineering is ook een fout.)
2. Welke afhankelijkheid introduceert dit, en wat gebeurt er als die wegvalt of verandert?
3. Wat is het goedkoopste ontwerp dat hetzelfde probleem oplost? Waarom is dat niet genoeg?
4. Welke beslissing in dit ontwerp is onomkeerbaar? Kan die uitgesteld worden?
5. Waar zit de verborgen koppeling — twee onderdelen die samen moeten veranderen zonder dat iets dat afdwingt?

## Data

1. Waar komen deze data vandaan, en wie of wat heeft er vóór ons al aan gezeten?
2. Wat gebeurt er bij null, leeg, dubbel, te groot, verkeerd gecodeerd? Toon het pad, niet de intentie.
3. Welke bias zit er in de verzameling, en versterkt deze verwerking die?
4. Is dit persoonsgebonden informatie, en zo ja: waarom verlaat het het apparaat van de gebruiker?
5. Hoe controleren we achteraf dat een transformatie klopte — is er een weg terug naar de bron?

## UX

1. Voor wie is dit ontworpen, en wie sluit het daardoor uit? (Toegankelijkheid, taal, apparaat.)
2. Wat is het worst-case pad — trage verbinding, klein scherm, screenreader — en werkt het daar nog?
3. Welke handeling van de gebruiker is onomkeerbaar, en waarschuwt het ontwerp daarvoor?
4. Wat verwacht de gebruiker dat er gebeurt — en waar wijkt dit ontwerp daarvan af zonder reden?
5. Als de gebruiker dit één keer per jaar doet in plaats van dagelijks: is het dan nog te begrijpen?

## Veiligheid

1. Wat is hier het te beschermen goed — data, toegang, reputatie — en tegen wie?
2. Welke invoer is onvertrouwd, en waar wordt die voor het eerst gevalideerd?
3. Welke rechten heeft dit onderdeel, en welke daarvan gebruikt het daadwerkelijk?
4. Wat lekt er via logs, foutmeldingen of metadata?
5. Als een aanvaller deze code kon lezen: wat zou hij als eerste proberen?

## AI-uitvoer zelf

1. Onderscheid wat je hebt vastgesteld van wat je hebt aangenomen. Twee lijsten.
2. Welke delen van dit antwoord zijn standaardpatronen die je overal geeft, en welke zijn specifiek voor mijn situatie?
3. Citeer je bron — en als die er niet is, zeg dat.
4. Beargumenteer nu het tegendeel, even overtuigend. Wat blijft er daarna overeind?
5. Wat had ik moeten vragen dat ik niet heb gevraagd?