Onderhoudbaar
Componenten hebben duidelijk gedefinieerde en gedocumenteerde verantwoordelijkheden en interfaces. De code is zo gestructureerd dat anderen deze kunnen begrijpen, onderhouden en aanpassen.
Een praktische gids voor engineering teams
AI-ontwikkeling
Teamafspraken
Verken de afwegingen. Bepaal je grenzen. Maak afspraken waar je team echt mee kan werken.
Definieer codekwaliteit
Wat is
kwalitatief goede code?
Bepaal eerst samen wat kwalitatief goede code voor jullie team betekent. Twee belangrijke ingrediënten zijn onderhoudbaarheid en code die duidelijk laat zien wat de bedoeling is.
Laat de bedoeling zien
De code maakt het bedoelde gedrag duidelijk en voldoet aan de afgesproken principes. Het doel moet begrijpelijk zijn en het gedrag moet aansluiten bij de eisen.
TEAMOEFENING 5 minuten
Wat betekent kwalitatief goede code voor jullie team?
Geef aan hoe belangrijk elk aspect is in jullie definitie. Bespreek verschillende inzichten en kies samen één score.
Scoor wat belangrijk is
Deze scores beschrijven jullie prioriteiten, niet hoe goed jullie huidige code is. Laat een aspect open als jullie het nog moeten bespreken.
1 Afhankelijk van de context2 Nuttig3 Belangrijk4 Zeer belangrijk5 Essentieel
Onderhoudbaarheid
Duidelijke intentie
Lees de voorgestelde definitie
0 van 6 aspecten beoordeeld
Scoor de aspecten die voor jullie team belangrijk zijn om een voorstel voor jullie definitie van kwalitatief goede code te zien.
Maak de definitie van jullie
Schrijf jullie eigen definitie, of gebruik het voorstel en verfijn het samen. Voeg voorbeelden toe en alles wat in de scores ontbreekt. Jullie tekst blijft ongewijzigd wanneer je de scores aanpast.
Kies de juiste rol voor AI
Eerst duidelijkheid,
dan delegeren.
Weten wat je moet bouwen en weten hoe je het moet bouwen zijn twee verschillende dingen. Verken wat er verandert als een van beide onduidelijk is.
TECHNISCHE DUIDELIJKHEID →
De productduidelijkheid neemt toe van onder naar boven
Kies een kwadrant om de AI-rol, menselijke verantwoordelijkheid en het bewijs voor die situatie te bepalen. Elk kwadrant bewaart zijn eigen antwoorden.
DEFINIEER DEZE SITUATIE
Vergelijken en prototypen
Begin met het ingevulde voorbeeld. Pas de drie velden aan om vast te leggen wat jullie team afspreekt.
Ingevuld voorbeeld
Gebaseerd op de workshopDe regels voor het campagnebudget zijn duidelijk. Een backendontwikkelaar vraagt AI om een interface te prototypen in een onbekende frontendstack. Een frontendspecialist beoordeelt toegankelijkheid, statusbeheer en implementatiekeuzes.
Een overtuigend prototype bewijst niet dat de implementatie klaar is voor oplevering. Los de technische onzekerheid op met deskundige ondersteuning.
Dit is een gesprekskader uit de workshop, geen systeem dat toestemming verleent. Vertrouwen alleen is geen duidelijkheid. Als niemand een wijziging kan verifiëren, regel dan ondersteuning, beperk de scope of pauzeer.
Beheer de context
Behandel je AI-context
als je code.
Hoe werkt jullie team nu met AI? Begin bij de werkwijzen die jullie gebruiken en bepaal daarna hoe jullie die samen beheren.
BEGIN BIJ JULLIE TEAM 3 vragen
Welke werkwijzen horen bij jullie werk?
Jullie antwoorden bepalen de richtlijnen hieronder. Kies wat jullie team op dit moment beschrijft.
Skill-bestanden zijn herbruikbare instructies en voorbeelden die AI helpen bij een bepaald soort taak.
Agents gebruiken AI om taken uit te voeren met tools, instructies en een afgesproken mate van zelfstandigheid.
Specificatiegedreven ontwikkeling begint met een beschrijving van het bedoelde gedrag en de acceptatiecriteria, als leidraad voor de implementatie en controles.
Beantwoord een vraag om richtlijnen voor jullie team te zien.
De volgende stappen voor jullie team
Beheer het werk achter het werk.
Maak dit jullie gezamenlijke routine voor de werkwijzen die jullie invoeren.
- Geef het een vaste plek en een eigenaar
Bewaar servicecontext bij de code; geef herbruikbare teamrichtlijnen en gedeelde richtlijnen een vaste plek en een beheerder.
- Beheer versies in Git
Leg instructies, specificaties en voorbeelden vast, samen met hun wijzigingsgeschiedenis.
- Beoordeel en controleer wijzigingen
Gebruik een pull request, een aangewezen reviewer en representatieve controles voordat je een wijziging accepteert.
- Leg de goedgekeurde versie vast
Zet geteste gedeelde versies vast en leg vast welke context bij een taak is gebruikt, zodat het team de resultaten kan herleiden.
- Onderhoud en test opnieuw
Spreek een evaluatiedatum af; werk bij en test opnieuw wanneer gedrag, architectuur, tools of teambehoeften veranderen.
Bekijk een voorbeeld van een repositorystructuur
Geef elk werkbestand een duidelijke plek. Deze namen zijn voorbeelden; pas de structuur aan jullie organisatie aan.
Servicerepositoryservice-repo/specs/
Bewaar specs, acceptatiecriteria, plannen en servicespecifieke prompts dicht bij de implementatie.
Keur de spec goed voordat je gaat programmeren. Werk hem bij met de wijziging.AI-repository van het teamteam-ai/
Deel herbruikbare skills, prompts, voorbeelden en evaluatiecases. Leg gebruiksnotities en wijzigingen vast.
Wijs een beheerder aan. Publiceer geteste releases met versienummers.Gedeelde engineeringrepositoryengineering-ai/
Beheer gemeenschappelijke regels, sjablonen en skills die meerdere teams gebruiken. Maak eigenaren en goedgekeurde versies zichtbaar.
Zet een geteste gedeelde versie vast. Link vanuit je documentatie naar de bronnen.MAAK HET JULLIE WERKWIJZE
Spreek jullie richtlijnen af
Maak een eerste concept op basis van jullie antwoorden, of schrijf er zelf een. Voeg concrete locaties, eigenaren en reviewmomenten toe. Je tekst blijft behouden als je de antwoorden aanpast.
Maak ruimte voor elkaar.
Meer gegenereerde code is niet hetzelfde als een beter teamresultaat.
Leer als team
Praat over het werk.
Toets daarna de belofte.
Geef auteurs en reviewers ruimte om ervaringen te vergelijken. Leg vast wat jullie hebben geleerd en wat jullie samen willen opvolgen.
Deze signalen komen uit de ervaring van één collega in de oorspronkelijke workshop. Het zijn gespreksstarters, geen gemeten resultaten. Laat een keuze open als jullie die nog moeten bespreken.
Bespreek per gebied een concrete toepassing. Of iets klaar is voor gebruik, hangt af van de toepassing, niet van een heel vakgebied.
Verkennen er zijn nog hiaten / Pilot afgebakende proef / Bewezen aangetoond / Opschalen klaar voor teamgebruik
TEAMREFLECTIE 10 minuten
Leg jullie gesprek vast
Vat de gedeelde inzichten, verschillende ervaringen en open vragen samen. Voeg vervolgacties toe, wie ze oppakt en wanneer jullie erop terugkomen.
Bepaal de scope
Dezelfde tool.
Andere grenzen.
Toestemming hangt af van de service, taak, gegevens en omgeving. Maak elke grens expliciet.
OOntwikkeling
TTest
AAcceptatie
PProductie
Toestemming in de ontwikkelomgeving geldt niet automatisch voor test, acceptatie of productie. Een maximale rol geeft op zichzelf nooit toestemming voor mergen, deployen of toegang tot gegevens.
L / BeperktBeperkte impact.
Eenvoudig herstel.
M / AanzienlijkVerstoring voor klanten of bedrijf.
Gecoördineerd herstel.
H / KritiekErnstige impact op platform,
financiën of gevoelige gegevens.
BRENG JULLIE GRENZEN IN KAART
Eén service. Eén taak. Eén omgeving.
Voeg een aparte regel toe zodra de toestemmingen veranderen. Laat onbesliste velden open.
Maak de afspraken
Jullie team.
Jullie werkafspraken.
Maak van het gesprek een concept dat jullie samen kunnen beoordelen, versioneren en herzien.
Spreek een maximale AI-rol af
Kies voor elke situatie binnen jullie afgesproken scope. Een hogere maximale rol is geen doel op zich. Open betekent nog niet besloten; dat is iets anders dan geen AI.
Wat betekenen de vier rollen?
- Geen AI
- Geen AI-gebruik binnen de afgesproken taak, gegevens en omgeving.
- Verkenning
- Onderzoek, leer en vergelijk opties binnen de goedgekeurde toegang. Implementatie voor oplevering valt buiten deze rol.
- Ondersteuning
- Een mens stuurt het werk stap voor stap aan. AI mag binnen die aansturing wijzigingen of tests voorstellen; de mens kiest de aanpak en controleert elke stap.
- Afgebakende delegatie
- Een agent voert een omschreven taak uit met afgesproken tools, acceptatiecriteria en stopvoorwaarden. Een mens beoordeelt het resultaat en accepteert of verwerpt het.
Los technische bezwaren op; neem niet het gemiddelde van de keuzes. Servicegrenzen en bestaand beleid kunnen elke rol verder beperken.
Wat we elkaar verschuldigd zijn
De pauzeregel
Als niemand met de juiste kennis een wijziging kan verifiëren, regel dan ondersteuning, beperk de scope of pauzeer de implementatie.
Neem het gesprek mee.
Jullie conceptafspraken
Concept voor teamoverleg. Onbesliste keuzes blijven open.
Lees jullie gegenereerde concept
Download als Markdown voor jullie repository of documentatie. Alle hoofdstukken verkennen betekent niet dat de afspraken zijn goedgekeurd. Beoordeel ze met het team voordat jullie ze invoeren.