AI-coderingstools en workflow-integratie

Winst:

• Mogelijkheid om de voltooiing van de editor, chatassistent, CLI-agent en CI-automatiseringscategorieën aan taken toe te wijzen
• Mogelijkheid om het autonomieniveau aan te passen aan het risico en de 'plan eerst'-discipline toe te passen op CLI-agenten
• Mogelijkheid om het gebruik van AI om te zetten in een teamsysteem op basis van een gevalideerde tool, verificatiepoort, transparantie en verantwoording

Tot nu toe hebben we geleerd AI te gebruiken bij individuele taken (coderen, beoordelen, testen, debuggen). In dit laatste onderdeel hebben we de stukjes samengevoegd: verschillende AI-coderingstools leren kennen, de juiste tool aan de juiste taak koppelen en ze veilig inbedden in uw dagelijkse ontwikkelingsstroom – van editor tot versiebeheer, van CI/CD-pijplijn tot teambeheer. Het doel is om de rommelige ‘vraag het zo nu en dan aan de AI’-gewoonte om te zetten in een consistent en controleerbaar werksysteem.

We behandelen voertuigtypen met neutrale categorieën (specifieke productnamen veranderen snel; het gaat erom wat de categorie doet). Elke categorie heeft een ‘sweet spot’ en een risicoprofiel; Meesterschap is weten hoeveel autonomie je aan welke taak moet geven.

Categorieën AI-coderingstools

1. Voltooiing in de editor. Plug-ins die regels/blokken voorstellen terwijl u typt in uw IDE (de ontwikkelomgeving waarin u code schrijft). Sweet spot: in-stream snelheid, boilerplate-code. Risico: beperkte context, de suggestie accepteren zonder na te denken.

2. Chat/zijpaneelassistent. Chatinterface ingebed in de IDE met zichtbaarheid in een deel van uw codebase. Sweet spot: beschrijving, refactor, testen, buganalyse. Risico: beperkt tot de context die u geeft, vereist verificatie.

3. CLI-agents (agenttools). Tools die vanaf de opdrachtregel worden uitgevoerd, kunnen zelfstandig meerdere bestanden lezen en wijzigen, opdrachten uitvoeren en taken met meerdere stappen uitvoeren. Sweet spot: wijzigingen in meerdere bestanden, repetitieve taken, taken van het type "voeg deze eigenschap toe". Risico: hoge autonomie = hoge impact; Als dit niet wordt aangevinkt, leidt dit tot brede en moeilijk te verifiëren veranderingen.

4. Lijn-/automatiseringsintegratie. CI-bots (Continuous Integration) die automatisch beoordelingscommentaar achterlaten op PR's, tests voorstellen of changelogs produceren. Sweet spot: eerste zeef zonder vermoeidheid, consistentie. Risico: lawaai, vals vertrouwen.

Tip: Naarmate de autonomie toeneemt, moet ook de controle toenemen. Omdat de voltooiing van de editor klein en onmiddellijk is, wordt er licht toezicht op gehouden; De wijziging van meerdere bestanden van een CLI-agent moet net zo, zo niet zorgvuldiger, worden onderzocht dan een menselijke PR.

Stap voor stap: AI in de workflow integreren

1. Wijs de taak toe aan de tool. Kleine in-stream toevoeging → voltooiing; begrijpen/refactor/test → chatten; repetitief werk met meerdere bestanden → CLI-agent; continu eerste filter → CI-integratie.
2. Kies het niveau van autonomie. Hoeveel vrijheid heeft de agent? Alleen-lezen suggestie of bestandswijziging + opdrachtuitvoering? Pas aan voor risico.
3. Koester de context. Introduceer permanent projectregels (stijl, architectuur, "don'ts") in de tool; Gebruik een projectinstructiebestand in plaats van het steeds opnieuw uit te leggen.
4. Verificatiepoorten onderhouden. AI-verandering is net als menselijke verandering: het gaat via compilatie, testen, beoordelen en (indien van cruciaal belang) goedkeuring door deskundigen. AI-openings-PR omzeilt de goedkeuring niet.
5. Meten en aanpassen. Kijk wat er echt versnelt, waar de correctielast toeneemt; Snoei toepassingen die niet werken weg.

Drie mini-hoesjes

Geval 1: CLI-agent verwerkte het hernoemen van meerdere bestanden. Eén team hernoemde een concept verspreid over 60 bestanden. Ze gaven de taak aan een CLI-agent, vroegen eerst om een ​​plan, keurden het plan goed, voerden vervolgens de wijziging door en voerden de hele testsuite uit. Agent 3 heeft een randgeval in het dossier gemist; Tests hebben het ontdekt en gerepareerd. De klus, die handmatig ongeveer 3 uur in beslag nam, werd onder begeleiding in 50 minuten geklaard.

Geval 2: Ongecontroleerde autonomie had een averechts effect. Een andere ontwikkelaar zei tegen een agent dat hij "deze module moest verbeteren" en bracht deze uit; De agent heeft 18 bestanden gewijzigd en twee afhankelijkheden toegevoegd. De wijziging was zo breed dat deze niet kon worden herzien en moest worden ingetrokken. Les: geef agenten een beperkte reikwijdte, duidelijke acceptatiecriteria en discipline om eerst te plannen, later te doen.

Geval 3: CI-reviewbot werd het eerste filter. Eén team heeft een bot gebouwd die geautomatiseerde AI-beoordelingsopmerkingen achterlaat op PR's. Zodra de bot nulcontrolefouten en stijlproblemen opmerkte, konden menselijke recensenten hun tijd besteden aan bedrijfslogica. Het team maakte echter duidelijk dat de bot geen ‘goedkeuring’ gaf: er was nog minstens één menselijke goedkeuring vereist. Om het geluid te verminderen, hebben ze de boot zo afgesteld dat er alleen geluid met een hoge/gemiddelde intensiteit achterblijft.

Vier kopieerbare sjablonen

Discipline 'Eerst plannen' voor CLI-agent:

Taak: {{duidelijke, beperkte taak}} Acceptatiecriteria: {{meetbaar resultaat}} Beperking: werk alleen op {{de volgende directory/bestanden}}; nieuwe afhankelijkheid toevoegen. Presenteer eerst een plan ZONDER VERANDERING: welke bestanden, wat zal er veranderen, welke tests moeten worden uitgevoerd. Wacht tot ik het plan GOEDKEUR. Pas het vervolgens stap voor stap toe en voer bij elke stap tests uit.

Projectinstructiebestand (persistente context voor tools):

Vaste regels voor AI-tools in dit project: - Taal/versie: {{...}}. Stijl: {{...}}.- Architecturale beperking: {{e.g. richting tussen lagen}}.- NOOIT: geheimen inbedden, productiegegevens gebruiken, {{verboden bibliotheken}}.- Elke wijziging moet testbaar zijn; De openbare API-handtekening wijzigen ZONDER te vragen. - Bij twijfel, stop en vraag.

Taak-tool mapping beslissing:

Ik definieer de volgende taak: {{task}}. Met welke klasse tools moet ik dit doen: (a) voltooiing van de editor, (b) chatassistent, (c) CLI-agent, (d) CI-automatisering? Schrijf uw beweegredenen, risico's en aanbevolen autonomieniveau op (slechts een suggestie / bestand wijzigen / opdracht uitvoeren).

CI review bot-gedragscode:

Laat alleen bevindingen met een HOGE en GEMIDDELDE ernst achter als commentaar in de PR-beoordeling. Elke bevinding: categorie, ernst, voorgestelde correctie. Verzamel notities op het niveau van stijlvoorkeur in een afzonderlijk samenvattend commentaar. U STEMT NIET IN; menselijke goedkeuring vereist.

Zwakke prompt/sterke prompt

Zwak: (tegen CLI-agent) "Maak de betalingsmodule beter."

Sterk: (naar CLI-agent) "Alleen uitgevoerd onder src/betalingen/. Taak: Extraheer de recursieve validatielogica uit de functie restitutie() in een enkele helper; gedrag en handtekeningen veranderen niet. Presenteer eerst het plan en wacht op mijn goedkeuring; voer vervolgens de tests/betalingen/pakket uit en voer deze uit. Voeg nieuwe afhankelijkheid toe."

De sterke versie verkleint de reikwijdte, stelt acceptatiecriteria en beperkingen, en legt de discipline 'plan eerst' op. Vage ‘doe het beter’-eisen zijn de hoofdoorzaak van enorme en oncontroleerbare veranderingen.

voertuigklasse

Waar hij het beste in is

autonomie

inspectie gewicht

Voltooiing van de editor

Kleine toevoeging in de stroom

laag

Licht (direct lezen)

chat assistent

Begrijpen, testen, refactoreren

middelmatig

Medium (uitvoerverificatie)

CLI-agent

Meerdere bestanden, recursief

hoog

Zwaar (plan + volledige review)

CI-automatisering

Continu eerste filter

middelmatig

Medium (regel + menselijke goedkeuring)

Teambeheer: van individuele vaardigheden tot gedeeld systeem

Het goed inzetten van AI op individuele basis is een begin; echte volwassenheid is een consistent systeem op teamniveau. Dit systeem is gebaseerd op verschillende pijlers: een lijst met goedgekeurde tools (welke tools kunnen worden gebruikt met welke gegevens – vanaf unit 10), verificatiepoorten (AI-verandering gaat via dezelfde build/test/review-poorten – vanaf unit 11), transparantie (beweren dat een verandering AI-aangedreven is, zorgt voor traceerbaarheid waar nodig) en duidelijkheid over de verantwoordelijkheid (de persoon die tekent en verantwoordelijk is, is duidelijk). Dit raamwerk beperkt risico’s met behoud van snelheid en zorgt ervoor dat nieuwe teamleden met dezelfde discipline werken.

Let op: Hoe groter de autonomie van een tool (vooral CLI-agents die bestanden kunnen wijzigen en opdrachten kunnen uitvoeren), hoe strenger de toegang tot de productieomgeving, vertrouwelijke gegevens en moeilijk ongedaan te maken bewerkingen wordt beperkt. Koppel destructieve commando's (permanente verwijdering, inzet) aan menselijke goedkeuring.

Veel voorkomende fouten

• Taak betekent incompatibiliteit. Ik probeer een taak uit meerdere bestanden uit te voeren met voltooiing van de editor of een kleine bijlage met een zware agent.
• Het vrijgeven van de agent. Agenttaken die met een beperkte reikwijdte en zonder ‘eerst een plan’ worden gegeven, veroorzaken niet-onderzochte veranderingen.
• Het versoepelen van de verificatiepoorten voor AI. “AI heeft het gedaan, laten we snel verder gaan” is de gevaarlijkste uitzondering; De deuren zijn voor iedereen hetzelfde.
• Elke keer handmatig de context doorgeven. Het niet schrijven van projectregels in een permanent instructiebestand leidt tot inconsistentie en duplicatie.
• De goedkeuring van de CI-bot verwarren met menselijke goedkeuring. Een bot is een filter; Verantwoordelijke menselijke goedkeuring is verplicht.

Samengevat

AI-coderingstools vallen in vier hoofdcategorieën: voltooiing van de editor, chatassistent, CLI-agenten en CI-automatisering. Meesterschap is het matchen van de taak met het juiste hulpmiddel en het juiste niveau van autonomie; Naarmate de autonomie toeneemt, neemt ook de controle toe. Geef tools een persistente projectcontext, leg een ‘plan eerst’-discipline op aan agenten met meerdere bestanden en laat AI-verandering door dezelfde verificatiepoorten gaan als menselijke verandering. Individuele vaardigheid; Transformeer het in een teamsysteem dat is gebouwd op een goedgekeurde toollijst, verificatiepoorten, transparantie en duidelijkheid over de verantwoordelijkheid. AI is een end-to-end snelheidsvermenigvuldiger; De persoon die de rekening tekent en afgeeft, is altijd een bekwaam persoon.

Applicatie taak

Noem drie echte taken die je volgende week gaat doen. Gebruik voor elke taak het sjabloon 'Taak-aan-voertuig-matchingbeslissing' om te rechtvaardigen welke voertuigklasse en welk niveau van autonomie u kiest. Voer vervolgens een beperkte taak uit voor een CLI-agent (of chatassistent) met een ‘plan eerst’-discipline: keur het plan goed, voer het af, voer de tests uit en bekijk de verandering als een menselijke PR. Stel ten slotte een 5-punts “AI-gebruiksregel” op voor uw team (goedgekeurde tools, dataregel, verificatiepoort, autonomielimiet, aansprakelijkheid).

controlelijst

• [ ] Ik kan onderscheid maken tussen categorieën van AI-coderingstools en de ‘sweet spot’ van elke categorie.
• [ ] Ik koppel de taak aan de juiste voertuigklasse en het juiste autonomieniveau.
• [ ] Ik geef permanente projectcontext (instructiebestand) aan de tools.
• [ ] Ik pas een beperkte reikwijdte en 'plan eerst'-discipline toe op CLI-agenten.
• [ ] Ik laat AI-wijzigingen door dezelfde verificatiepoorten gaan als menselijke wijzigingen.
• [ ] Ik pleit voor een gevalideerd instrument, dataregel, transparantie en verantwoordingskader op teamniveau.

Module-examen

1. Wat doet het onderliggende grote taalmodel van een codeerassistent eigenlijk als het code produceert?

• A) Voorspelt patroonmatig de meest waarschijnlijke voortzetting op basis van de gegeven context ✔
• B) Garandeert het juiste resultaat door de code daadwerkelijk te compileren en uit te voeren
• C) Het scant de code live over het hele internet en kopieert de meest nauwkeurige code.
• D) Begrijpt de logica van de code als een menselijke ingenieur en begrijpt de bedoeling

Verduidelijking: LLM 'begrijpt' code niet als een mens; Het genereert de meest waarschijnlijke voortzetting van de gegeven context, op basis van patronen die het leert uit een zeer grote hoeveelheid tekst en code. Daarom hangt de kwaliteit van de output rechtstreeks af van de kwaliteit van de context en instructie die u geeft, en elke output moet gevalideerd worden.

2. Hoe noem je het als AI op overtuigende wijze een niet-bestaande functie of bibliotheek verzint, en wat is het enige echte tegengif?

• A) Dit wordt een compilatiefout genoemd; Het tegengif is sterkere uitrusting
• B) Dit wordt hallucinatie genoemd; Het tegengif is het verifiëren van de code en elke gebruikte API ✔
• C) Dit wordt regressie genoemd; Het tegengif is om het model opnieuw op te starten
• D) Dit wordt contextoverflow genoemd; Het tegengif is om de prompt in te korten

Beschrijving: Dit wordt hallucinatie genoemd en veroorzaakt een van de duurste bugs in software. Het enige echte tegengif is verificatie: bevestigen dat elke gebruikte functie, API en pakket daadwerkelijk bestaat en dat de code werkt. De zelfverzekerde toon van het model is geen bewijs van nauwkeurigheid.

3. Welke aanpak verbetert de kwaliteit en consistentie van de output het meest bij het genereren van code met AI?

• A) Het model vrijgeven door te zeggen 'schrijf dit aan mij' zonder enige context te geven
• B) Een zo lang en mooi mogelijke prompt schrijven
• C) Specificeer en geef voorbeelden van input/output-contract, randgevallen, versie en stijl ✔
• D) Het direct combineren van de gegenereerde code zonder deze te lezen

Uitleg: Het bepalen van de invoer/uitvoertypen (contract), randgevallen, taal/versie en stijlbeperking van de functie en het geven van een voorbeeld aan het model maakt de overgang van voorspelling naar precisie mogelijk. Contextloze 'schrijf mij dit'-verzoeken produceren code die elke keer anders is en vaak randgevallen omzeilt.

4. Bij het verkennen van een buitenlandse codebase met AI kan de naam van een functie 'validateAndSave' zijn, maar is de AI-samenvatting mogelijk onjuist. Wat is de juiste aanpak?

• A) Volledig vertrouwen in de AI-samenvatting, aangezien de naam voor zich spreekt
• B) De functie direct wijzigen zonder deze te lezen
• C) Beslissen door alleen naar de functienaam te kijken
• D) Behandel de AI-beschrijving als een hypothese en verifieer kritische beweringen regel voor regel in de code ✔

Uitleg: AI kijkt misschien naar de naam in de code en vertelt je ‘hoe het eruit ziet alsof het doet’, maar in werkelijkheid kan de logica anders zijn (of zelfs omgekeerd). De AI-verklaring is dus een hypothese; Kritieke claims, vooral die met betrekking tot veiligheid, autoriteit of geldstromen, moeten visueel worden geverifieerd op de relevante regels.

5. Wat is het grootste gevaar als je zegt: 'AI zag het, het is duidelijk' in AI-ondersteunde codebeoordeling?

• A) AI kan vals-negatieven produceren; Echte gemiste fouten creëren vals vertrouwen ✔
• B) AI-beoordeling is te traag, waardoor er tijd wordt verspild
• C) Het team begrijpt het niet omdat de AI alleen commentaar geeft in het Engels
• D) PR convergeert niet omdat AI altijd overinterpreteert

Uitleg: AI produceert zowel valse positieven (waarbij een probleem wordt gemarkeerd terwijl het niet bestaat) als valse negatieven (waarbij de echte bug wordt gemist). Valse negatieven zwijgen; De gevaarlijkste fouten zijn fouten die helemaal niet in de recensie worden vermeld. AI is dus een eerste filter, geen goedkeuring; Het besluit tot fusie ligt bij een verantwoordelijke persoon.

6. Wat is de meest verraderlijke valkuil die optreedt als je de AI alleen maar de code geeft en tests afdrukt?

• A) AI schrijft altijd te veel tests en vergroot de codebase
• B) AI test het huidige (misschien verkeerde) gedrag van de code als 'correct' en repareert de bug ✔
• C) AI verwijdert automatisch code bij het schrijven van tests
• D) AI schrijft niet alleen tests voor het gelukkige pad, maar altijd voor het randgeval

Uitleg: AI heeft de neiging om naar code te kijken en beweringen te schrijven die het huidige gedrag testen. Als de code vanaf het begin verkeerd is, repareert AI dit verkeerde gedrag als 'correct'. Daarom moeten de verwachtingen van de test worden geschreven volgens de vereiste regel (specificatie), en niet volgens de huidige uitvoer van de code.

7. Wat bepaalt het meest de nauwkeurigheid van hypothesen bij het debuggen van een bug met AI?

• A) Hoe beleefd de prompt is geschreven.
• B) Hoe vaak is de vraag opnieuw gesteld
• C) Kwaliteit van het bewijs dat aan het model wordt geleverd: volledige foutmelding, stacktracering, invoer en verwacht gedrag ✔
• D) In welk kleurthema is de code geschreven?

Uitleg: AI ziet de fout niet zoals u dat doet; Hij kent alleen het bewijs dat u hem geeft. Gegeven de volledige foutmelding, stacktracering, triggerende invoer en verwacht gedrag somt het model de werkelijke mogelijkheden op; Als er geen bewijs is, wordt er een gok gedaan (hallucinatie) en wordt u op het verkeerde spoor gezet.

8. Wat is de meest kritische stap voordat productielogboeken ter analyse aan AI worden verstrekt?

• A) Het logboek plakken zoals het is, voor de hele dag
• B) Converteer log eerst naar hoofdletters
• C) Logregels in alfabetische volgorde rangschikken
• D) Het maskeren van persoonlijke gegevens en geheimen en het tonen van alleen het relevante venster ✔

Beschrijving: Ruwe productielogboeken bevatten IP, e-mail, sessie-ID, token en soms publiek geheim. Ze in een AI-tool stoppen zonder ze te maskeren is een ernstige schending van de privacy. Bovendien moet het logboek worden gefilterd op een smal tijdvenster; Maar de eerste noodzaak is het opschonen van gevoelige gegevens.

9. Wat moet er gedaan worden als de AI in loganalyse zegt dat twee gebeurtenissen ‘gelijktijdig’ hebben plaatsgevonden en één daarvan als hoofdoorzaak aangeeft?

• A) Het negeren van correlatie als causaliteit en het verifiëren van de claim met statistieken en code ✔
• B) De oorzaak als definitief aanvaarden omdat AI een tijdsrelatie tot stand brengt
• C) Onmiddellijk opnieuw starten van de eerste beschuldigde component
• D) De logs volledig verwijderen en opnieuw verzamelen

Uitleg: De meest voorkomende valkuil bij loganalyse is het verwarren van correlatie met causaliteit. De door de AI vastgestelde tijdsrelatie is een aanwijzing, geen bewijs. Echte causaliteit vereist timing, mechanisme en, indien mogelijk, herhaalbaarheid; De claim moet worden gevalideerd met statistieken en code.

10. Wat is de niet-onderhandelbare gouden regel bij refactoring met AI en wat waarborgt deze?

• A) De code moet korter zijn; Het aantal regels garandeert dit
• B) Geen gedragsverandering; tests die huidig gedrag vastleggen, zorgen hiervoor ✔
• C) De code bevat meer commentaar; AI garandeert dit
• D) Het hele bestand in één keer herschrijven; de makelaar garandeert dit

Uitleg: Refactoring is het verbeteren van de interne structuur van de code zonder het externe gedrag ervan te veranderen; De gouden regel is dat gedrag constant blijft. Wat hiervoor zorgt is testen: een testnet dat het huidige gedrag vastlegt voordat het wordt gewijzigd, wordt na elke stap opgezet en uitgevoerd. Refactoring zonder testnet is een gok.

11. Wat is de laag in de documentatieproductie die AI niet kan kennen en die gevaarlijk is om te verzinnen?

• A) Hoe u de installatiestappen uitvoert
• B) Parameterlijst van een functie
• C) Verantwoording van 'waarom' een ontwerpbeslissing op die manier is genomen ✔
• D) In welke taal is de code geschreven?

Beschrijving: AI kan de 'wat/hoe'-laag (wat doet de functie, hoe is deze ingesteld) uit de code halen; maar het kan de 'waarom'-laag (de ontwerpreden voor een beslissing, de reden voor een grenswaarde) niet kennen. Een verzonnen ‘reden’ is gevaarlijker dan geen rechtvaardiging; De code-eigenaar moet deze laag toevoegen.

12. Wat moet een ontwikkelaar doen als hij een configuratiebestand met een live API-sleutel in een niet-goedgekeurde AI-tool wil plakken terwijl hij een urgente bug oplost?

• A) Voor de snelheid plakt u het bestand zoals het is en verwijdert u vervolgens de chat
• B) Voeg een 'vertrouwelijke' notitie toe aan het einde van het bestand en verzend het
• C) Laat de sleutel staan en verander alleen de bestandsnaam
• D) Verwijder/maskeer geheimen en geef alleen noodzakelijke, niet-gevoelige context ✔

Openbaarmaking: Geheimen, persoonlijke gegevens en vertrouwelijke bezittingen mogen nooit op niet-goedgekeurde wijze worden ingevoerd; Urgentie schort deze rode lijn niet op. De juiste aanpak is om eerst de geheimen te extraheren/maskeren en alleen de noodzakelijke, niet-gevoelige context te geven. Als er toch een geheim lekt, is het eerste wat je moet doen de sleutel onmiddellijk omdraaien.

13. Een door AI gegenereerde code doorstaat de tests en wordt in productie genomen. Bewijst dit dat de code veilig is?

• A) Nee; 'werken' betekent niet veilig, beveiliging vereist een aparte authenticatielaag ✔
• B) Ja; Code die de test doorstaat, is per definitie veilig
• C) Ja; Als u het in productie uitvoert, worden alle kwetsbaarheden geëlimineerd
• D) Nee; maar veiligheid is alleen van belang als de code traag is

Toelichting: 'Werken' is niet hetzelfde als 'veilig'. Zelfs als de code een kwetsbaarheid bevat, zoals SQL-injectie, kan deze de tests doorstaan ​​en soepel werken; De kwetsbaarheid wordt pas onthuld als een aanvaller deze vindt. Daarom moeten, naast de nauwkeurigheid, beveiligingsgerichte beoordelingen en scans zoals SAST als een aparte laag worden uitgevoerd.

14. Wat is de veiligste discipline bij het geven van een taak met meerdere bestanden aan een CLI-agent (autonoom hulpmiddel dat bestanden kan wijzigen en opdrachten kan uitvoeren)?

• A) De agent vertellen 'verbeter deze module' en volledige vrijheid geven
• B) Het geven van beperkte reikwijdte en acceptatiecriteria, eerst om een plan vragen, het goedkeuren, het stap voor stap implementeren en de tests uitvoeren ✔
• C) Voeg alle wijzigingen van de agent direct samen zonder ze te bekijken
• D) Het geven van onbeperkte toegang aan de agent tot de productieomgeving en vertrouwelijke gegevens

Uitleg: Naarmate de autonomie toeneemt, moet ook de controle toenemen. De agent een beperkte reikwijdte en duidelijke acceptatiecriteria geven, eerst om een ​​plan zonder wijzigingen vragen, het plan goedkeuren, het vervolgens stap voor stap laten implementeren en bij elke stap tests uitvoeren; Het voorkomt wijzigingen die breed zijn, niet kunnen worden beoordeeld en moeten worden teruggedraaid.

15. Wie is aansprakelijk als gevolg van door AI gegenereerde code in beveiligingskritische software (bijvoorbeeld betaling of authenticatie)?

• A) Omdat de code afkomstig is van AI, bevindt deze zich in de voertuigaanbieder
• B) Als AI voldoende ontwikkeld is, heeft niemand dat gedaan; verifiëren is niet nodig
• C) Het team/de ingenieur die de code onderzoekt, assembleert en distribueert; AI vervangt toestemming niet ✔
• D) Alleen de persoon die de prompt schrijft, niet degenen die deze beoordelen

Beschrijving: AI is een snelheidsvermenigvuldiger en blauwdrukgenerator; kan geen verantwoordelijkheid aanvaarden. De verantwoordelijkheid voor eventuele fouten, kwetsbaarheden of schendingen die voortkomen uit de code in productie ligt bij het team dat de code beoordeelt, samenstelt en distribueert. Op veiligheidskritische gebieden is AI-output onder geen enkele omstandigheid een vervanging voor beoordeling en goedkeuring door een gekwalificeerde ingenieur.