Wanneer AI nuttig is — en wanneer je de uitkomst moet wantrouwen

We kunnen tegenwoordig in enkele seconden code laten schrijven, een foutmelding laten uitleggen of vragen hoe een sensor moet worden aangesloten.

Dat is een indrukwekkend hulpmiddel.

AI kan een moeilijke uitleg toegankelijk maken, voorbeeldcode opstellen en mogelijke oorzaken aandragen waaraan je zelf nog niet had gedacht. Vooral wanneer je net begint, kan dat veel zoekwerk besparen.

Maar AI staat niet naast je aan de werkbank.

AI ziet niet automatisch:

welk ESP32-ontwikkelbord je werkelijk hebt;
hoe jouw draden zijn aangesloten;
welke sensorchip er op de geleverde module zit;
welke voedingsspanning je multimeter aangeeft;
welke bibliotheekversie is geïnstalleerd;
wat er precies in de seriële monitor verschijnt;
of een onderdeel ongewoon warm wordt;
of het voorgestelde antwoord in jouw situatie veilig is.

Daarom gebruiken we AI in deze gids als gereedschap en niet als autoriteit.

AI kan een route voorstellen. De werkelijkheid bepaalt of die route klopt.

Wat AI eigenlijk doet

Een AI-taalmodel verwerkt de informatie die je aanlevert en maakt op basis daarvan een waarschijnlijk passend antwoord.

Dat antwoord kan bijzonder overtuigend zijn. Het kan duidelijke uitleg, correct uitziende code en technische termen bevatten.

Toch betekent een zelfverzekerde formulering niet dat de inhoud juist is.

AI kan:

correcte informatie combineren;
ontbrekende context proberen in te vullen;
aannemen dat je een gangbaar bord gebruikt;
functies uit verschillende bibliotheekversies verwarren;
een plausibele maar niet-bestaande functie noemen;
een pinout van een ander ESP32-model gebruiken;
een onveilige elektrische aanname maken;
een foutieve oplossing helder uitleggen.

Dat laatste is belangrijk.

Een mens klinkt soms onzeker wanneer hij twijfelt. AI hoeft die onzekerheid niet op dezelfde manier te tonen. Een verkeerd antwoord kan daardoor net zo verzorgd klinken als een juist antwoord.

Waarom AI toch bijzonder nuttig is

Dat AI fouten kan maken, betekent niet dat we het moeten vermijden.

Een multimeter kan ook verkeerd worden ingesteld. Een zoekmachine kan een verouderde pagina tonen. Een forumreactie kan bedoeld zijn voor een ander bord. Een datasheet kan verkeerd worden geïnterpreteerd.

Ieder gereedschap vraagt om een passende manier van gebruiken.

AI is vooral sterk wanneer we het inzetten om:

iets op een andere manier uit te leggen;
een probleem op te delen;
mogelijke hypotheses te verzamelen;
code regel voor regel te bespreken;
een minimale test te maken;
foutmeldingen begrijpelijker te maken;
verschillen tussen twee codeversies te zoeken;
een controlelijst op te stellen;
documentatie samen te vatten;
onze eigen redenering kritisch te toetsen.

De meerwaarde zit niet alleen in het ontvangen van een antwoord. AI kan ons ook helpen betere vragen te stellen.

AI gebruiken om uitleg te krijgen

Technische documentatie is niet altijd voor beginners geschreven. Een datasheet kan nauwkeurig zijn en toch moeilijk leesbaar.

AI kan helpen om een ingewikkeld begrip te vertalen naar het niveau waarop jij het op dat moment nodig hebt.

Je kunt bijvoorbeeld vragen:

Leg het verschil tussen spanning en stroom uit aan iemand die voor het eerst een led op een ESP32 aansluit. Gebruik geen formules en geef daarna één praktisch voorbeeld.

Of:

Leg deze functie regel voor regel uit. Benoem bij iedere regel welk zichtbaar gedrag ik op de ESP32 kan verwachten.

Dat is vaak nuttiger dan:

Leg deze code uit.

Door het gewenste niveau en doel te noemen, krijgt AI meer houvast.

Vraag om meerdere uitlegvormen

Als een uitleg niet duidelijk is, hoef je niet meteen aan te nemen dat het onderwerp te moeilijk voor je is.

Vraag bijvoorbeeld:

leg het uit met een vergelijking;
leg het uit zonder jargon;
geef eerst de korte versie;
gebruik daarna een technischere uitleg;
maak er een stappenplan van;
geef een voorbeeld met onze BME280;
stel na de uitleg drie controlevragen.

AI kan hetzelfde onderwerp op verschillende manieren presenteren. Dat is een van zijn sterkste toepassingen.

AI gebruiken om code te begrijpen

Het is verleidelijk om code te laten genereren en direct te uploaden.

Een betere eerste toepassing is:

Laat AI bestaande code uitleggen voordat je haar verandert.

Geef bijvoorbeeld een korte functie en vraag:

Leg uit wat deze functie doet. Beschrijf de toestand van WiFi bij iedere mogelijke route door de functie. Benoem ook waar de code kan blokkeren.

Of:

Welke variabelen veranderen in deze functie, wanneer veranderen ze en welk effect heeft dat bij de volgende uitvoering van loop()?

Daarmee gebruik je AI niet alleen als codeschrijver, maar als gesprekspartner bij het lezen van code.

Vraag naar aannames

Een bijzonder nuttige vervolgvraag is:

Welke aannames maakt deze code over het bord, de bedrading, bibliotheken en aangesloten diensten?

Bij onze BME280-code kunnen zulke aannames zijn:

SDA is verbonden met GPIO 21;
SCL is verbonden met GPIO 22;
de sensor gebruikt adres 0x76;
de module kan veilig met 3,3 volt worden gevoed;
de Adafruit BME280-bibliotheek is geïnstalleerd;
de module bevat werkelijk een BME280.

Zodra de aannames zichtbaar zijn, kunnen we ze controleren.

AI gebruiken om hypotheses te verzamelen

Wanneer een project niet werkt, kan AI snel mogelijke oorzaken noemen.

Bijvoorbeeld:

Mijn ESP32 leest de BME280 lokaal correct uit en WiFi is verbonden. MQTT geeft foutcode 4. Geef maximaal vijf waarschijnlijke oorzaken, gerangschikt op waarschijnlijkheid. Stel bij iedere oorzaak één test voor die haar kan bevestigen of uitsluiten.

Dit is veel bruikbaarder dan:

Mijn MQTT werkt niet. Wat moet ik doen?

De eerste vraag bevat:

wat wel werkt;
waar de keten stopt;
een concrete foutcode;
een beperking van het aantal suggesties;
de wens om iedere suggestie te testen.

AI kan dan helpen bij het opstellen van hypotheses. Wij voeren de tests uit en beoordelen de resultaten.

Gebruik AI om mogelijke oorzaken te bedenken, niet om zonder meting een oorzaak aan te wijzen.

Laat AI hypotheses rangschikken

Een lange lijst van twintig mogelijke oorzaken is zelden behulpzaam.

Vraag daarom:

Rangschik de mogelijke oorzaken op basis van mijn waarnemingen. Leg kort uit welke waarneming iedere oorzaak ondersteunt of tegenspreekt.

Daarmee dwing je het antwoord om rekening te houden met het bewijs dat al beschikbaar is.

Een losse verbinding kan bijvoorbeeld veelvoorkomend zijn, maar minder waarschijnlijk wanneer een I²C-scanner de sensor urenlang zonder onderbreking ziet.

AI gebruiken om een test te ontwerpen

AI is vaak nuttiger bij het ontwerpen van een test dan bij het geven van een directe oplossing.

Vraag bijvoorbeeld:

Ik wil onderscheid maken tussen een verkeerd I²C-adres en verkeerde bedrading. Welke twee tests kan ik uitvoeren zonder meerdere dingen tegelijk te veranderen? Geef bij iedere mogelijke uitkomst aan wat ik daaruit mag concluderen.

Een goed antwoord zou dan kunnen verwijzen naar:

spanning meten op de module;
de I²C-scanner uitvoeren;
het gevonden adres vergelijken met de code.

Daarmee blijft onze systematische methode leidend:

Hypothese → voorspelling → test → waarneming → conclusie

Vraag wat een test niet bewijst

Deze vervolgvraag is minstens zo belangrijk:

Wat bewijst deze test niet?

Als de I²C-scanner adres 0x76 vindt, weten we dat een apparaat op dat adres reageert.

We weten nog niet automatisch:

dat het werkelijk een BME280 is;
dat alle drie de meetfuncties goed werken;
dat de sensor nauwkeurig meet;
dat de verbinding langdurig stabiel blijft.

Door ook naar de beperkingen van een test te vragen, voorkomen we te brede conclusies.

AI gebruiken voor minimale testcode

Een groot programma met sensor, WiFi, MQTT en Home Assistant bevat veel mogelijke foutbronnen.

AI kan helpen om één onderdeel los te testen.

Een goede vraag is:

Maak minimale Arduino-code voor een ESP32-WROOM-32 die alleen een I²C-scanner uitvoert. Gebruik SDA op GPIO 21, SCL op GPIO 22 en de seriële monitor op 115200 baud. Voeg geen WiFi, MQTT of andere bibliotheken toe.

Hiermee geef je duidelijke grenzen aan.

Controleer de code vervolgens vóór het uploaden:

wordt het juiste bord bedoeld;
kloppen de GPIO’s;
zijn de gebruikte functies beschikbaar;
zijn er geen onnodige onderdelen toegevoegd;
doet de code werkelijk maar één test?

Minimale testcode is een diagnosemiddel. Bewaar de werkende hoofdcode apart.

AI gebruiken om foutmeldingen te begrijpen

Compiler- en netwerkfouten bevatten vaak technische termen.

Geef de exacte foutmelding aan AI en voeg relevante context toe.

Bijvoorbeeld:

Ik gebruik Arduino IDE met ESP32 Dev Module. Bij het compileren krijg ik onderstaande fout. Leg eerst letterlijk uit wat de compiler niet kan vinden. Noem daarna maximaal drie mogelijke oorzaken. Verander nog geen code.

Plak vervolgens de volledige relevante melding.

Dat laatste is belangrijk. Een samenvatting zoals:

Er stond iets met BME280.

neemt juist de informatie weg die voor de diagnose nodig is.

Begin met de eerste fout

Een compiler kan na één typefout tientallen vervolgmeldingen tonen.

Vraag AI daarom:

Welke melding is waarschijnlijk de eerste werkelijke fout en welke meldingen zijn mogelijk alleen gevolgen daarvan?

Corrigeer daarna één fout en compileer opnieuw.

Laat niet meteen het volledige programma herschrijven. Een ontbrekende puntkomma vraagt geen nieuw ontwerp.

AI gebruiken om twee versies te vergelijken

Wanneer code eerst werkte en na een aanpassing niet meer, kan AI verschillen helpen onderzoeken.

Geef:

de laatste werkende versie;
de huidige versie;
het gedrag van beide versies;
de foutmelding of afwijking.

Vraag bijvoorbeeld:

Vergelijk alleen de wijzigingen die invloed kunnen hebben op MQTT-herverbinding. Negeer wijzigingen in commentaar en opmaak. Noem per relevante wijziging welk gedrag daardoor kan veranderen.

Dit kan helpen om een grote hoeveelheid code terug te brengen tot enkele verdachte veranderingen.

Blijf wel controleren of beide versies volledig en correct zijn aangeleverd. AI kan geen ontbrekend deel vergelijken.

Wanneer je AI extra moet wantrouwen

Niet ieder AI-antwoord vraagt dezelfde mate van voorzichtigheid.

Wees extra kritisch wanneer het antwoord gaat over:

voedingsspanningen;
maximale stromen;
netspanning;
accu’s en laadschakelingen;
warmte en brandveiligheid;
pinnen met een opstartfunctie;
level shifting tussen 5 en 3,3 volt;
beveiliging en wachtwoorden;
het openen van netwerkpoorten;
certificaten en versleuteling;
het wissen van geheugen;
code die fysieke machines of krachtige belastingen aanstuurt;
handelingen die apparatuur kunnen beschadigen.

Bij zulke onderwerpen is “probeer het eens” geen geschikte strategie.

Controleer de informatie aan de hand van officiële documentatie en voer eerst een veilige meting of beperkte test uit.

Een overtuigend schema kan onveilig zijn

AI kan een aansluitschema beschrijven dat logisch oogt, maar bijvoorbeeld:

een 5-voltsuitgang rechtstreeks met de ESP32 verbindt;
een motor direct via een GPIO laat lopen;
een relais zonder transistor of vrijloopdiode aanstuurt;
een verkeerde voedingspin gebruikt;
twee voedingen onveilig met elkaar verbindt.

Controleer vóór het aansluiten:

de voedingsspanning van ieder onderdeel;
de signaalspanning;
het stroomverbruik;
de toegestane waarden van de GPIO;
de noodzaak van een gemeenschappelijke GND;
de documentatie van het specifieke ontwikkelbord en de module.

Upload nooit code naar een aangesloten krachtige belasting voordat je hebt vastgesteld welke uitgangstoestand tijdens opstarten en reset ontstaat.

AI kent jouw exacte hardware niet vanzelf

“ESP32” is geen volledig hardwaremodel.

Er bestaan onder andere:

verschillende ESP32-families;
verschillende WROOM-modules;
verschillende ontwikkelborden;
afwijkende pinindelingen;
verschillende USB-chips;
borden met extra hardware;
modules met verschillende spanningsregelaars.

Als je alleen schrijft:

Maak code voor mijn ESP32.

kan AI aannemen dat je een gangbaar bord gebruikt.

Geef daarom specifieker aan:

Ik gebruik een ESP32-ontwikkelbord met ESP32-WROOM-32-module. De BME280 is via I²C aangesloten met SDA op GPIO 21 en SCL op GPIO 22. De module wordt gevoed met 3,3 volt.

Voeg waar nodig toe:

de exacte tekst op het bord;
een link naar de productpagina;
de pinout van dat model;
een duidelijke foto;
de gebruikte modulevariant.

Zelfs dan blijft controle nodig. Productpagina’s kunnen onduidelijk of onjuist zijn.

AI kan vergelijkbare onderdelen verwarren

Een BME280 lijkt sterk op een BMP280.

Een antwoord kan code voorstellen die luchtvochtigheid uitleest, terwijl jouw fysieke module alleen temperatuur en luchtdruk ondersteunt.

Ook namen zoals:

VIN;
VCC;
3V3;
SCK;
SCL;
SDI;
SDA;

kunnen per module en communicatiemethode anders worden gebruikt.

Vraag daarom niet alleen:

Waar moet deze draad?

Vraag:

Welke functie heeft deze pin op exact deze module, bij gebruik van I²C en voeding met 3,3 volt? Welke documentatie ondersteunt dat?

Controleer vervolgens de documentatie zelf.

AI kan bibliotheken en versies verwarren

Arduino-bibliotheken veranderen.

Een functie kan:

in een nieuwe versie anders heten;
alleen op een ander bord bestaan;
onderdeel zijn van een andere bibliotheek;
verouderd zijn;
andere argumenten verwachten;
in een online voorbeeld verkeerd zijn overgenomen.

AI kan bovendien geldige functies uit twee verschillende bibliotheken combineren tot code die overtuigend oogt maar niet compileert.

Let op signalen zoals:

was not declared in this scope

of:

no matching function for call

Controleer dan:

welke bibliotheek werkelijk is geïnstalleerd;
wie de auteur is;
welke versie wordt gebruikt;
welke voorbeeldcode bij die versie hoort;
of de functie in de officiële API voorkomt.

Vraag AI eventueel:

Geef voor iedere niet-standaardfunctie aan uit welke bibliotheek en klasse deze afkomstig is. Als je dat niet zeker weet, zeg dat expliciet.

AI kan niet zien wat jij niet vertelt

Stel dat je vraagt:

Waarom wordt mijn BME280 niet gevonden?

Zonder verdere informatie weet AI niet:

of de sensor voeding ontvangt;
welke spanning je gebruikt;
wat de pinvolgorde is;
welke GPIO’s zijn aangesloten;
welk adres de scanner vindt;
welke bibliotheek is geïnstalleerd;
of het misschien een BMP280 is;
wat bme.begin() teruggeeft.

AI vult ontbrekende informatie mogelijk in met gebruikelijke aannames.

Die aannames kunnen toevallig kloppen, maar ze zijn niet gemeten.

Geef relevante context

Een betere vraag is:

Ik gebruik een ESP32-WROOM-32. De BME280-module wordt met 3,3 volt gevoed. SDA zit op GPIO 21 en SCL op GPIO 22. Op de module meet ik 3,28 volt. De I²C-scanner vindt adres 0x77. Mijn code gebruikt bme.begin(0x76) en meldt dat de sensor niet wordt gevonden. Wat is de waarschijnlijkste oorzaak en welke ene wijziging test dat?

Nu is het antwoord bijna af te leiden uit de waarnemingen.

Hoe beter je meet en beschrijft, hoe minder AI hoeft te gokken.

AI kan iets verzinnen

Een AI-antwoord kan informatie bevatten die niet uit een betrouwbare bron afkomstig is.

Dat kan bijvoorbeeld zijn:

een niet-bestaande functie;
een verkeerde foutcode;
een verzonnen bibliotheekoptie;
een niet-bestaand pinnummer;
een onjuiste maximale spanning;
een link of documenttitel die overtuigend klinkt maar niet bestaat.

Dit wordt soms een hallucinatie genoemd.

Het antwoord probeert dan een passend patroon te vormen zonder dat de onderliggende informatie klopt.

Herken signalen

Wees extra alert wanneer AI:

geen concrete bron kan noemen voor een precieze technische grens;
verschillende termen door elkaar gebruikt;
bij doorvragen van uitleg verandert zonder de fout te erkennen;
een functie noemt die niet in de voorbeelden of API staat;
absolute zekerheid uitspreekt bij weinig context;
een ongebruikelijke oplossing voorstelt zonder eerst eenvoudige oorzaken te testen;
beweert jouw fysieke schakeling te hebben gecontroleerd terwijl alleen tekst is aangeleverd.

Vraag bij twijfel:

Op welke officiële documentatie baseer je deze pinbeperking? Noem het document en de relevante sectie.

Open daarna zelf de bron en controleer of die werkelijk jouw hardware behandelt.

Goede bronnen en hun rol

Voor technische controle gebruik je bij voorkeur bronnen dicht bij de maker van het product of de software.

Denk aan:

datasheets van Espressif of Bosch;
officiële API-documentatie;
voorbeeldcode van de bibliotheekauteur;
schema’s van het exacte ontwikkelbord;
release notes;
broncode van de gebruikte bibliotheek;
documentatie van Home Assistant en de MQTT-broker.

Een forum, video of AI-antwoord kan helpen om iets begrijpelijk te maken. Voor veilige grenzen en exacte functies is officiële documentatie meestal de betere controlebron.

Ook officiële documentatie moet bij de juiste variant en versie horen.

Een datasheet van de ESP32-S3 is niet automatisch geldig voor onze klassieke ESP32-WROOM-32.

Vraag AI om onzekerheid zichtbaar te maken

Je kunt AI expliciet vragen onderscheid te maken tussen:

wat zeker uit jouw informatie volgt;
wat waarschijnlijk is;
wat nog onbekend is;
wat gemeten of opgezocht moet worden.

Bijvoorbeeld:

Verdeel je antwoord in vier delen: bevestigde feiten, aannames, waarschijnlijke oorzaken en tests. Behandel niets als bevestigd als ik er geen meting of foutmelding voor heb gegeven.

Dat maakt het antwoord beter controleerbaar.

Vraag ook:

Welke informatie ontbreekt om deze conclusie betrouwbaar te maken?

Een goed antwoord wijst dan bijvoorbeeld op:

het exacte bord;
de voedingsspanning;
de volledige foutmelding;
de bibliotheekversie;
het gemeten I²C-adres;
de MQTT-foutcode.

Vraag om tegenargumenten

Als AI één oorzaak zeer waarschijnlijk noemt, vraag dan:

Welke waarneming zou aantonen dat deze verklaring niet klopt?

Of:

Geef een alternatieve oorzaak die hetzelfde symptoom veroorzaakt en een test waarmee ik beide kan onderscheiden.

Zo gebruik je AI om je eigen tunnelvisie tegen te gaan.

Laat AI niet onbeperkt code herschrijven

Wanneer een programma bijna werkt, is een volledige herschrijving vaak onnodig en riskant.

Een nieuwe versie kan onbedoeld:

topicnamen veranderen;
herstelgedrag verwijderen;
andere pinnen gebruiken;
timing aanpassen;
geheime gegevens in het hoofdprogramma plaatsen;
blokkerende lussen introduceren;
werkende foutcontroles weghalen.

Vraag liever:

Pas alleen de MQTT-herverbinding aan. Laat alle pinnen, topics, sensorfuncties en WiFi-logica ongewijzigd. Toon eerst welke regels je wilt veranderen en waarom.

Vergelijk daarna de wijzigingen met je je werkende versie.

Kleine wijzigingen zijn beter testbaar

Een kleine aanpassing levert een duidelijke test op.

Bijvoorbeeld:

Voeg alleen een seriële melding toe die toont wanneer mqttClient.publish() false teruggeeft.

Dat is gemakkelijker te beoordelen dan een volledig nieuw programma van honderden regels.

Dezelfde regel geldt voor AI als voor handmatig foutzoeken:

Verander één betekenisvol onderdeel tegelijk.

Plak niet zomaar geheime gegevens

Wanneer je code met AI bespreekt, controleer dan of deze gegevens bevat zoals:

WiFi-wachtwoorden;
MQTT-wachtwoorden;
API-sleutels;
tokens;
certificaatsleutels;
persoonlijke netwerkgegevens;
interne adressen die je niet wilt delen.

Vervang ze vooraf door herkenbare placeholders:

#define SECRET_SSID "[WIFI_NAAM]"
#define SECRET_PASS "[WIFI_WACHTWOORD]"
#define SECRET_MQTT_PASS "[MQTT_WACHTWOORD]"

Laat de structuur staan, maar verwijder de echte waarde.

Als een geheim toch openbaar of met een onverwachte partij is gedeeld, behandel het dan als mogelijk bekend en vervang het.

Een wachtwoord uit een bericht verwijderen verandert niet wat al eerder is verzonden.

Publiceer niet blindelings door AI gemaakte code

Voordat je code uploadt, doorloop je minimaal deze controle:

Hardware

Klopt het exacte ESP32-model?
Komen de gebruikte GPIO’s overeen met de bedrading?
Zijn de pinnen geschikt voor hun functie?
Zijn alle signaalspanningen veilig?
Vraagt een belasting niet te veel stroom?
Wat gebeurt er tijdens opstarten en reset?

Software

Zijn alle bibliotheken echt en correct geïnstalleerd?
Bestaan de gebruikte functies in de geïnstalleerde versie?
Compileert de code zonder waarschuwingen die we moeten begrijpen?
Zijn setup() en loop() logisch opgebouwd?
Bevat de code blokkerende lussen?
Worden fouttoestanden afgehandeld?
Blijven lokale functies werken zonder netwerk?

Netwerk

Staan er geen echte wachtwoorden in gedeelde code?
Kloppen brokeradres en poort?
Is de verbinding versleuteld wanneer dat nodig is?
Wordt geen interne dienst onnodig op internet geopend?
Zijn client-ID’s uniek?
Kloppen topics en toegangsrechten?

Test

Kan het programma eerst met een led of ongevaarlijke belasting worden getest?
Kan één functie in een minimale opstelling worden getest?
Welke uitvoer verwacht je in de seriële monitor?
Wat doe je als de code zich anders gedraagt?

Een goede vraag aan AI opbouwen

Een sterke technische vraag bevat meestal zes onderdelen.

1. Doel

Wat wil je bereiken?

Ik wil temperatuur van een BME280 via MQTT publiceren.

2. Hardware

Wat gebruik je precies?

ESP32-ontwikkelbord met ESP32-WROOM-32.
BME280 op 3,3 volt, SDA 21 en SCL 22.

3. Software

Welke omgeving en bibliotheken gebruik je?

Arduino IDE, Adafruit BME280 en PubSubClient.

4. Verwachting

Wat had er moeten gebeuren?

Iedere tien seconden moet een temperatuurwaarde
op werkplaats/sensor/temperatuur verschijnen.

5. Waarneming

Wat gebeurt er werkelijk?

De seriële monitor toont een geldige temperatuur.
WiFi is verbonden. MQTT geeft foutcode 4.

6. Gewenste hulp

Wat moet AI met deze informatie doen?

Geef maximaal drie hypotheses en bij iedere hypothese
één test. Herschrijf de code nog niet.

De volledige vraag wordt dan:

Ik gebruik een ESP32-ontwikkelbord met ESP32-WROOM-32 en een BME280 op 3,3 volt. SDA zit op GPIO 21 en SCL op GPIO 22. Ik programmeer met Arduino IDE, Adafruit BME280 en PubSubClient. Ik wil iedere tien seconden de temperatuur publiceren op werkplaats/sensor/temperatuur. De lokale temperatuurmeting is geldig en WiFi krijgt een IP-adres, maar MQTT geeft foutcode 4. Geef maximaal drie hypotheses, gerangschikt op waarschijnlijkheid, en bij iedere hypothese één onderscheidende test. Herschrijf de code nog niet.

Deze vraag maakt duidelijk waar de keten al werkt en welk soort antwoord we nodig hebben.

Minder bruikbare en betere vragen

Te weinig context

Mijn ESP32 werkt niet. Geef code.

Beter:

Mijn ESP32-WROOM-32 start en toont seriële uitvoer, maar de BME280 wordt niet gevonden. De module ontvangt 3,3 volt, SDA zit op GPIO 21 en SCL op GPIO 22. De I²C-scanner vindt niets. Welke drie hardwarecontroles onderscheiden een bedradingsfout van een defecte module?

Direct om een oplossing vragen

Los mijn MQTT op.

Beter:

WiFi is verbonden en MQTT Explorer kan met dezelfde broker verbinden. Mijn ESP32 krijgt bij mqttClient.connect() foutcode 5. Welke informatie wijst op een rechtenprobleem en hoe kan ik dit testen zonder de volledige code te wijzigen?

Een volledig project laten herschrijven

Schrijf alles opnieuw zodat het stabiel werkt.

Beter:

Zoek in deze functie naar code die de sensorlus kan blokkeren wanneer WiFi ontbreekt. Stel de kleinste wijziging voor en leg uit hoe ik het verschil kan testen.

Alleen om zekerheid vragen

Weet je zeker dat GPIO 34 een uitgang kan zijn?

Beter:

Controleer in de documentatie van de klassieke ESP32-WROOM-32 of GPIO 34 als uitgang kan worden gebruikt. Maak expliciet onderscheid met andere ESP32-families.

AI als foutzoekpartner

AI wordt het nuttigst wanneer we een gesprek voeren waarin iedere ronde nieuwe gemeten informatie bevat.

Bijvoorbeeld:

Eerste vraag

De BME280 wordt niet gevonden. Voeding is 3,29 volt. Welke test volgt?

Antwoord

Voer een I²C-scan uit.

Nieuwe waarneming

De scanner vindt apparaat 0x77.

Vervolgvraag

Mijn code gebruikt bme.begin(0x76). Welke ene wijziging test of het adres de oorzaak is?

Test

We veranderen alleen het adres.

Resultaat

De BME280 wordt nu gevonden en geeft geldige waarden.

AI hielp hier bij het kiezen van de volgende stap. De conclusie werd echter bevestigd door de werkelijke test.

Dat is een goede samenwerking:

AI helpt redeneren. Jij meet. De hardware beslist.

Wanneer je een antwoord moet stoppen en opnieuw moet beginnen

Gebruik een AI-antwoord niet verder wanneer het:

uitgaat van een ander bord dan je hebt;
jouw gemeten resultaten negeert;
meerdere grote veranderingen tegelijk voorstelt;
onveilige spanningen gebruikt;
niet-bestaande functies blijft noemen;
wachtwoorden of beveiliging onnodig openbaar maakt;
een netwerkdienst rechtstreeks op internet wil openen zonder beveiligingsplan;
stelt dat meten niet nodig is;
zekerheid claimt zonder voldoende context;
niet kan uitleggen waarom de voorgestelde test onderscheidend is.

Ga dan terug naar de feiten en formuleer een kleinere vraag.

Bijvoorbeeld:

Negeer alle eerdere oplossingen. Gebruik alleen deze waarnemingen: de sensor ontvangt 3,3 volt, de I²C-scanner vindt 0x76 en bme.begin(0x76) geeft false. Noem alleen welke ontbrekende informatie nodig is voor de volgende diagnose.

Een praktisch beoordelingsmodel

Voordat je een AI-antwoord gebruikt, stel je vijf vragen.

1. Past het bij mijn exacte situatie?

juiste ESP32;
juiste sensor;
juiste bibliotheek;
juiste pinnen;
juiste spanningen;
juiste netwerkopbouw.

2. Kan ik de redenering volgen?

Kun je uitleggen waarom de voorgestelde wijziging invloed zou hebben?

Als je de redenering niet begrijpt, vraag dan eerst om uitleg.

3. Is de suggestie veilig?

Kan de wijziging:

de ESP32 beschadigen;
een GPIO overbelasten;
kortsluiting veroorzaken;
gegevens wissen;
een dienst onveilig bereikbaar maken;
een fysieke belasting onverwacht inschakelen?

Controleer veilige grenzen in officiële documentatie.

4. Is de suggestie testbaar?

Weet je vooraf:

wat je gaat veranderen;
wat je verwacht;
wat de mogelijke uitkomsten betekenen?

5. Kan ik de wijziging terugdraaien?

Bewaar de werkende code en maak foto’s van de bedrading.

Voer geen grote onomkeerbare wijziging uit zonder betrouwbare controle.

Een oefening: beoordeel een AI-antwoord

Stel dat je aan AI vraagt:

Mijn BME280 wordt niet gevonden. Wat moet ik doen?

Je ontvangt dit antwoord:

Sluit de sensor op 5 volt aan, gebruik GPIO 34 voor SDA en GPIO 35 voor SCL, verander het adres naar 0x77 en installeer een andere bibliotheek.

Deze reactie stelt vier wijzigingen tegelijk voor.

Voordat we iets uitvoeren, controleren we:

Voedingsspanning

Is onze specifieke module veilig voor 5 volt en blijven de I²C-signalen veilig voor de ESP32?

Dat is nog niet aangetoond. We gebruiken daarom niet blindelings 5 volt.

Pinnen

GPIO 34 en 35 zijn alleen ingangen. I²C gebruikt lijnen die niet zomaar als uitsluitend passieve ingangen kunnen worden behandeld. Deze keuze vraagt dus om controle en is voor onze opstelling niet logisch.

Adres

We weten nog niet of de sensor 0x76 of 0x77 gebruikt. Dat kunnen we meten met een I²C-scanner.

Bibliotheek

Er is nog geen bewijs dat de bibliotheek het probleem vormt.

Aantal wijzigingen

Zelfs als het daarna werkt, weten we niet welke verandering verschil maakte.

Een beter vervolg is:

Houd de veilige 3,3-voltvoeding aan.
Houd SDA op GPIO 21 en SCL op GPIO 22.
Meet de voeding op de module.
Voer de I²C-scanner uit.
Pas alleen het adres aan als de scanner daar aanleiding toe geeft.

We verwerpen het AI-antwoord dus niet omdat het van AI komt. We verwerpen de aanpak omdat de voorgestelde wijzigingen onvoldoende onderbouwd, slecht testbaar en mogelijk onveilig zijn.

Een oefening: AI goed inzetten

Stel dat MQTT niet verbindt.

Verzamel eerst:

BME280: werkt
WiFi-status: verbonden
IP-adres: 192.168.1.74
Brokeradres: 192.168.1.50
Brokerpoort: 1883
MQTT-foutcode: 4
Andere MQTT-client: verbindt met een ander account

Vraag daarna:

Gebruik alleen bovenstaande waarnemingen. Geef twee waarschijnlijke verklaringen voor MQTT-foutcode 4. Geef per verklaring één test die geen wijziging aan de sensor- of WiFi-code vraagt. Noem ook wat de test niet bewijst.

AI kan nu helpen om gericht te kijken naar:

gebruikersnaam;
wachtwoord;
accountconfiguratie;
mogelijk onderscheid tussen authenticatie en autorisatie.

We hebben de vraag zo opgesteld dat het antwoord binnen het juiste deel van de keten blijft.

Wat AI niet van je kan overnemen

AI kan uitleggen hoe je een multimeter instelt, maar kan niet voelen waar jij de meetpen werkelijk plaatst.

AI kan een bedradingsschema beschrijven, maar kan niet automatisch vaststellen dat een jumperdraad intern gebroken is.

AI kan zeggen dat de temperatuur waarschijnlijk wordt beïnvloed door de ESP32, maar kan de sensor niet fysiek verder van de spanningsregelaar plaatsen.

AI kan een MQTT-topic vergelijken wanneer je beide teksten aanlevert, maar weet niet welk topic werkelijk op jouw broker verschijnt tenzij je dat controleert.

AI kan hypothesen voorstellen, maar jij blijft verantwoordelijk voor:

veilig aansluiten;
waarnemen;
meten;
vergelijken;
testen;
beoordelen;
beslissen.

Precies daar ontstaat technische zelfstandigheid.

Wat je uit dit hoofdstuk kunt meenemen

AI kan een waardevolle gids naast de gids zijn.

Het kan helpen om:

ingewikkelde uitleg toegankelijk te maken;
code regel voor regel te begrijpen;
aannames zichtbaar te maken;
mogelijke oorzaken te verzamelen;
hypotheses te rangschikken;
onderscheidende tests te ontwerpen;
minimale testcode te schrijven;
foutmeldingen uit te leggen;
codeversies te vergelijken;
ontbrekende informatie te herkennen;
je eigen redenering kritisch te bekijken.

Maar AI kan ook:

ontbrekende context invullen met een verkeerde aanname;
verschillende hardwaremodellen verwarren;
ongeschikte pinnen voorstellen;
bibliotheekfuncties verzinnen of vermengen;
verouderde informatie gebruiken;
overtuigend klinken terwijl het antwoord onjuist is;
een elektrisch onveilige oplossing voorstellen;
te veel tegelijk veranderen;
jouw fysieke waarneming niet vervangen.

Daarom houden we een aantal vaste regels aan:

Geef zoveel mogelijk concrete context.
Deel waarnemingen en foutmeldingen, geen vage samenvatting.
Vraag om hypotheses en tests, niet alleen om oplossingen.
Vraag welke aannames het antwoord maakt.
Controleer precieze technische grenzen in officiële documentatie.
Begrijp code voordat je haar uploadt.
Verander één betekenisvol onderdeel tegelijk.
Test eerst met een veilige, minimale opstelling.
Deel geen wachtwoorden, sleutels of tokens.
Laat de werkelijke meting altijd zwaarder wegen dan een overtuigend antwoord.

De belangrijkste houding is:

Vertrouw AI niet blindelings, maar wantrouw het ook niet automatisch. Controleer het.

Dat is dezelfde houding die we tegenover ieder technisch hulpmiddel mogen hebben.

AI kan je sneller bij een goede vraag brengen. Het kan uitleg geven wanneer documentatie moeilijk leesbaar is. Het kan een onverwachte hypothese aandragen en helpen een test te ontwerpen.

Maar het moment waarop jij meet, vergelijkt en begrijpt waarom iets werkt, kan AI niet voor je overslaan.

En juist dat is het doel van deze gids:

Niet alleen een project bouwen dat vandaag werkt, maar leren hoe je morgen zelfstandig verder kunt.