AI voor developers
Van kleine wijziging naar gecontroleerde oplevering.
Voor developers · Editie september 2026

Van lezen naar zelf proberen.
Gebruik AI om code te begrijpen, bugs te onderzoeken en wijzigingen te testen. Met een exportcasus, reviewvragen en duidelijke grenzen voor agents.
Je werkt eerst uit wat je wilt doen, welke informatie nodig is en wat je zelf moet controleren. Bij ieder voorbeeld lees je wat AI kan voorbereiden en waar de grens ligt.
Dit komt aan bod.
21 hoofdstukken en 5 werkbladen om zelf in te vullen.
- De wijziging telt, niet de hoeveelheid code
- Code begrijpen met controleerbare verwijzingen
- Een bug reproduceren vóór je hem repareert
- Een kleine patch met duidelijke stopgrenzen
- Tests ontwerpen die de implementatie kunnen tegenspreken
- Een overdracht die precies zegt wat af is
- Van chat naar agent: rechten zijn de echte uitbreiding
- Meet tijd tot een geaccepteerde wijziging
- Een volledige bugfix als oefenproject
- De selectiefunctie lezen en beproeven
- Tests die het contract zichtbaar maken
- Een bug onderzoeken met hypotheses
- Context geven zonder de hele repository te dumpen
- Reviewen en releasen met een vaste grens
- Vijf lastige agenttaken oefenen
- Productiviteit meten op afgerond werk
- Begrijpen wat de assistent doet
- Je eerste werksessie in zes stappen
- Een bronpakket dat je kunt onderhouden
- Een resultaat toetsen dat je niet blind vertrouwt
- Je beslissing na de proef
Uit het boek · illustratief voorbeeld
Code begrijpen met controleerbare verwijzingen
Je onderzoekt een exportfunctie. Er is een API-handler, een filterfunctie en een formatter. De ticketbeschrijving beweert dat alle gebruikers alleen eigen records kunnen exporteren. Dat is nog geen bewijs dat de code die grens handhaaft.
Leg de route van request naar export uit op basis van deze bestanden. Geef per stap bestand en functie. Scheid wat zichtbaar in de code staat van wat je aanneemt over middleware of configuratie. Markeer ontbrekende context. Stel nog geen wijziging voor.
Een bruikbaar antwoord noemt waar identiteit wordt vastgesteld, waar records worden geselecteerd en waar de uitvoer wordt gemaakt. Als de authenticatiemiddleware niet is aangeleverd, blijft dat een onbekend punt. “Dit is veilig omdat het een interne route is” is geen onderbouwing.
Wat je zelf blijft controleren.
Gegenereerde code vraagt review en passende tests. Een groen buildresultaat bewijst geen veilige implementatie of geslaagde productie-uitrol.
Je houdt er iets aan over.
Een doorlopende praktijkcase, vijf toepassingen, een startplan, controlevragen en vijf invulbladen. Je oefent met complete voorbeelden en beoordeelt de waarde inclusief controle en herstel.
De voorbeelden zijn illustratief. Ze laten zien hoe je een proef opzet; ze beloven geen specifieke besparing of omzet.
Lees het gratis inkijkexemplaarVerder lezen.
Wil je de werkwijze eerst interactief bekijken? Verken de BRAIGHT Blueprint.