De volgende prompts zijn gereconstrueerde lesvoorbeelden, geen oorspronkelijke ontwikkelgesprekken. Zonder appcode, sleutels, configuraties of implementatiedetails. Gebruik een toegelaten beschikbaar hulpmiddel of papier. Zonder AI teken je het proces en schrijf je criteria; wacht niet op de docent. Verzin ook voorbeelden voor online overleg.
Een herbruikbare ontwikkelroute
Beschrijf persoon en situatie → kies kleinste proces → maak een versie met verzonnen materiaal → doe één taak op het apparaat → noteer obstakels → wijzig één ding en hertest → nodig vrijwilligers uit → beslis op basis van bevindingen.
Je kunt met AI en bestaande mogelijkheden een prototype beginnen voordat je Android/iOS-programmering systematisch beheerst. Leer wel wat de taak vraagt: rechten en toestanden, API en kosten, opslag en herstel, toegang en verificatie. Pakketten maken, ondertekenen, installeren en dienstbeschikbaarheid moet je werkelijk toetsen. Deze casus steunt op eerdere ervaring, niet op ogenblikkelijk maken zonder kennis.
Opdracht 1 | Help iemand beginnen met vertellen
‘Ontwerp een minimaal prototype voor spraaknotities. De gebruiker wil rustig vertellen zonder eerst een artikel te schrijven. Demonstreer met verzonnen dagelijkse vragen en alleen vragen, antwoorden, pauzeren en bewaren. Geef toestanden en controlecriteria vóór een uitvoeringsvoorstel. Geen echte accounts, privéopnamen of automatisch cameragebruik. Markeer te bevestigen rechten, kosten en fouten.’
Controleer: eerst de vraag horen; werkelijk stoppen bij pauze; opgeslagen inhoud terugvinden; fouten uitleggen zonder bevestigde inhoud te wissen.
Opdracht 2 | Nadat AI zegt dat het gerepareerd is
‘Verwacht: opnieuw afspelen leest alleen de huidige vraag. Werkelijk: geen geluid op de telefoon. Scheid bekend, onbekend en drie toetsbare hypothesen. Geef minimale reproductie en één eerste controle. Wacht op uitkomsten vóór wijzigingen en verander niet meerdere modules tegelijk. Leg daarna hertest en resterende risico's uit.’
Kopieer geen echte logboeken; die kunnen identificatoren of toegangssleutels bevatten. Dit oefent reproduceren, hypothesen, één variabele wijzigen en hertesten, niet syntaxis of frameworknamen.
Opdracht 3 | Orden feedback zonder voor mij te besluiten
‘Verzonnen proef: A wil proberen maar installeerde niet; B loopt vast bij installatie; C wil tekst wijzigen maar vindt de plek niet; D wil dagelijkse onderwerpen en vindt later bestaande opties. Scheid houding, gedrag, obstakel en mogelijke behoefte. Markeer ontbrekend bewijs. Geef voor ieder één waarneembare vervolgstap zonder verkoop, behandeling of behoeften van alle gebruikers af te leiden.’
Leerlingen moeten zien dat ‘voeg een functie toe’ soms een onvindbare bestaande functie betekent. Lof is geen transactie en een suggestie bewijst geen behoefte.
Productverantwoordelijkheid voor gegevens en API
| Probleem | Wat de leerling moet kunnen uitleggen | Casus en vervolgstap |
|---|---|---|
| Wat verlaat de telefoon? | Waar gaan opnamen, tekst en instellingen heen? Wie heeft toegang? | Alleen een eenvoudig gegevensdiagram, geen echte dienstconfiguratie |
| Waarom één Key per persoon? | Helpt toegang, quota en kostentoerekening. Aparte facturering hangt af van dienstverlener en accountinstellingen | Scheidt persoonlijke notities niet automatisch. Toewijzing bij registratie moet gelijktijdigheid, lege voorraad en intrekking afhandelen |
| Waarom beheerderssleutels geen gewone instelling zijn | Cliënten kunnen worden geanalyseerd. Codeverhulling is geen geheimhouding | Gemak bij interne proeven heeft restrisico's en is geen volwassen beveiligingsontwerp |
| Kleine proeven minder risicovol maken | Minimale gegevens, beperkte rechten, intrekbare toegang, hersteltests en foutafhandeling | Echte scheiding vraagt beheerde diensten, toegangscontrole, audits en andere technische maatregelen. De les claimt niet dat alles opgelost is |
| Kosten begrenzen | Wie draagt aanroepen, duur, dienstfouten en budget? | Studenten gebruiken een hypothetisch quotum, geen verzonnen leveranciersprijzen. Stel eerst een limiet in en toets daarna |
Alleen verantwoordelijkheid en aanpak worden uitgelegd, zonder echte beheertabellen, instellingen, Bot-sleutels of uitleesmethoden. Gesloten code is een productkeuze; beveiliging mag er niet alleen op rusten.
Omgaan met krachtiger analyse- en nabouwtools
Per 2026-10-23 zijn alleen repositoryuitleg en licentieaanduidingen gelezen. Geen installatie, uitvoering of praktijktest.
Officiële REA-repository ↗: beschrijft hulp bij analyse van appgedrag, binaire bestanden en uitvoering. Die beschrijving garandeert geen geslaagde analyse van ieder doel.
Officiële replica-skill-repository ↗: organiseert kijken, reconstrueren en testen als skill. De README bepleit functies en processen opnieuw opbouwen met eigen materiaal, zonder doelcode, merk, teksten of inhoud te kopiëren.
Beide tonen momenteel MIT. Controleer voor gebruik versie, afhankelijkheden en licentie opnieuw.De toollicentie staat los van rechten op en toegang tot de doelapp. Repositoryslogans zijn geen juridische toestemming of veiligheidsgarantie. Alleen eigen of duidelijk toegestane voorbeelden worden besproken, zonder juridisch oordeel of reverse-engineeringtraining.
Vier vragen vóór de beslissing
Mag ik dit benaderen en analyseren? Gebruik ik een methode, een gelicentieerd component of inhoud die niet van mij is? Hoe vermeld ik de bron en test ik het resultaat? Ook met dezelfde buitenkant: wie zijn mijn gebruikers, welke waarden kies ik en wat is mijn verantwoordelijkheid?
‘Mijn eigen kern’ is geen vrijstelling van verantwoordelijkheid en vereist niet elke coderegel vanaf nul. De maker staat in voor richting, bronnen, controle, weigeringen en eindresultaat.