Hoe feature slicing en AI agents elkaar versterken

In een vakgebied waar ontwikkelingen elkaar in hoog tempo opvolgen, gebeurt het regelmatig dat twee op zichzelf staande trends elkaar onverwacht versterken. Zo ook bij het concept feature slicing en de opkomst van AI augmented engineering. AI-tools zoals GitHub Copilot profiteren van de voordelen van feature slicing, en kunnen tegelijkertijd enkele nadelen ervan compenseren. Binnen mijn huidige project heb ik hiermee geëxperimenteerd, met verrassend goede resultaten.

Feature slicing

Softwareontwikkeling draait uiteindelijk om de functionele eisen van een applicatie. Waarom zou je de architectuur daar dan niet op afstemmen? In plaats van alle functionaliteit over verschillende applicatielagen te verspreiden, draait het bij feature slicing juist om co-location. Alle code voor een functionele eis hoort bij elkaar te staan. In dezelfde folder, of zelfs in hetzelfde bestand. Zoals elk architectuurconcept brengt dit zowel voor- als nadelen met zich mee.

Code co-location

Een van de grootste voordelen van feature slicing is dat alle code die bij een feature hoort, op één plek te vinden is. Dit maakt het voor ontwikkelaars veel makkelijker om de juiste code te vinden als er een aanpassing gemaakt moet worden. Je hoeft namelijk niet meer in meerdere projecten of mappen te zoeken. De isolatie van features beperkt ook de mogelijke neveneffecten van een aanpassing.

Voor AI tools biedt dit ook nagenoeg dezelfde voordelen. Een AI agent hoeft minder code te doorzoeken om bepaalde aanpassingen te maken. Ook hoeft het bij nieuwe features geen bestaande code op andere plaatsen aan te passen. De kans dat de agent een aanpassing maakt die een andere feature sloopt is zo ook beperkt. Je kan zelfs een heel feature bestand in het chatvenster van een AI agent stoppen.

Helaas brengt deze co-location voor ontwikkelaars ook nadelen met zich mee. Feature slicing gaat soms tegen de DRY (Don’t repeat yourself) principes in. Er kan veel boilerplate-code nodig zijn om een feature onafhankelijk op te zetten. Ook is het niet de bedoeling om functionele logica in features te delen. Daardoor kan het voorkomen dat je code dubbel moet schrijven. Dit kan deels verholpen worden door domeincode buiten de features onder te brengen. AI kan er natuurlijk voor zorgen dat het weinig moeite kost om code te herhalen. Als je zelf de herhaalde code niet hoeft te schrijven, is het dan nog altijd bad practice om je code te herhalen? Uiteindelijk moet je natuurlijk zelf een goede balans hierin zien te vinden.

Feature design documents als prompt

Als je waarde hecht aan documentatie, dan zal je alle features in een feature design document vastleggen. Je kan hier een eigen standaard template voor maken, maar het zal grofweg de volgende aspecten:

• Feature naam en beschrijving
• Context van de feature
• Ontwerp
• Foutafhandeling
• Testplan
• Autorisatie

Een grondige invulling hiervan maakt het makkelijk om een feature te programmeren. Het grootste deel van het denkwerk is hiermee al gedaan. Als dit uitgewerkt is, dan heb je eigenlijk ook meteen een AI prompt. Hoe beter het design document, hoe beter de AI agent het kan uitvoeren. Én je houdt er nog eens goede documentatie aan over.

Promptcontext optimaliseren

In een feature slice-architectuur kun je elke feature volledig inrichten op basis van wat die feature nodig heeft. Toch is het in de praktijk handig om afspraken te maken over hoe verschillende soorten features zijn opgebouwd. Dat zorgt voor meer houvast voor ontwikkelaars én een betere codekwaliteit.

Als je die afspraken vastlegt in een document, heb je meteen een contextbeschrijving die je aan een AI-agent kunt meegeven. AI-tools worden steeds beter in het begrijpen van je werkomgeving, maar het werkt vaak nóg beter als je die context expliciet aanlevert.

In mijn huidige project heb ik daarvoor een prompt context-bestand toegevoegd. Dit bestand beschrijft hoe een standaard API-endpoint feature eruitziet. Dankzij die beschrijving verloopt de samenwerking met AI consistenter en efficiënter.

In deze context heb ik onder andere de volgende zaken opgenomen:

• Projectstructuur met mappen en naamgeving
• Database setup
• Beschrijving van een feature file
• Voorbeeld van een feature implementatie
• Beschrijving van een standaard testklasse
• Voorbeeld van een test

Als je iets tegenkomt wat de AI agent vaak fout heeft, zoals welke package je gebruikt om te mocken, dan kan dit verwerkt worden in de prompt context. Hoe specifiek je moet zijn met deze regels zal heel erg afhangen van welke AI model je gebruikt.

Resultaat

Binnen mijn project heb ik de in dit artikel beschreven methode gebruikt om een aantal simpelere CRUD features te realiseren voor een nieuwe database entiteit. Dit soort lagere complexiteit maken het goede features om door AI te laten implementeren. Het begon met het kopiëren en plakken van de context en het feature ontwerp in het chatvenster van Copilot. Na wat iteratie op de context is het gelukt om deze features volledig door Copilot te laten realiseren met de edit mode van Copilot. Dit was nog voor de preview van de Copilot Agent mode beschikbaar was, wat deze methode nog effectiever maakt.

Na het experimenteren heb ik de code gereviewed en getest. Er waren opvallend weinig aanpassingen nodig. Sterker nog: één van de aanpassingen die ik deed bleek achteraf onterecht — Copilot had het feature design document nauwkeuriger geïnterpreteerd dan ikzelf. Hierdoor heb ik uiteindelijk wel 30-50% minder tijd aan deze features hoeven besteden dan als ik het zelf moet programmeren. Zo kan ik minder tijd besteden aan repetitief en simpel programmeerwerk en meer aan de leuke problemen.