GitHub Copilot voor Umbraco-developers: wat werkt en wat niet
Twee jaar Copilot in onze Umbraco-praktijk: het versnelt views, queries en mappers, maar struikelt op composition-keuzes en obsolete API's. Een eerlijke balans voor teams die de winst willen pakken zonder hun ambacht te verliezen.
Het korte antwoord
GitHub Copilot is voor Umbraco-development een nuttige collega — eentje die snel meekijkt, slimme voorzetten doet en je urenlange tikwerk uit handen neemt. Maar het is ook een collega die af en toe een verzonnen API uit z'n mouw schudt en met droge ogen claimt dat het werkt. Niet boos worden, gewoon controleren.
Na bijna twee jaar Copilot in onze dagelijkse Umbraco-praktijk is de balans simpel: voor herhalend werk (view models, Razor-partials, LINQ-queries, dictionary-lookups) verdienen we de licentie ruim terug. Voor framework-specifieke patronen (composition-keuzes, BlockGrid-modellering, uSync-XML) moet je vooral blijven nadenken, want Copilot heeft daar de feeling van een nieuwkomer die net het werkbankboek heeft doorgebladerd.
Dit artikel laat zien waar de winst zit, waar je tegen muren loopt en hoe je je Umbraco-developmentpraktijk zo inricht dat AI-assistentie het ambacht versterkt in plaats van vervangt.
Waar Copilot wel schittert
Begin met de winst, want die is reeel. In onze stelling: voor 60 tot 70 procent van de code die in een Umbraco-project wordt geschreven, levert Copilot duidelijke tijdwinst op.
Razor-partials en repeterende views. Heb je net een Document Type met vijftien properties opgezet en moet je daar een renderview voor maken? Copilot snapt na twee, drie property-uitlezingen het patroon en laat de rest van het bestand voor je vallen. Inclusief proper escaping en nullable handling. Spaart letterlijk een halfuur tikwerk per partial.
LINQ-queries op IPublishedContent-trees. Vraag het iets als "geef alle pages onder deze section met TagPicker die 'X' bevat, gesorteerd op publish-date". Copilot weet hoe extension methods als Children(), DescendantsOrSelf() en Where() in elkaar haken. Wel even kijken of het geen obsolete .Children-property gebruikt — daar hapt het soms nog op terug.
View models en mapping-code. Veel Umbraco-projecten leunen op view models tussen content en presentation. Het schrijven van die mappers is meestal mechanisch werk en precies daar excelleert Copilot. Geef het je IPublishedContent-source en je viewmodel-doel, en het levert in een keer een werkbare mapper.
Dictionary- en localization-lookups. Vooral op meertalige sites is dit dankbare materie. Copilot pakt patronen rond dictionary-keys snel op en biedt netjes fallbacks aan voor lege waardes.
Migratie-scripts en uSync-XML lezen. Voor het schrijven van content-import-scripts of het pluizen van bestaande uSync-mappen is Copilot een uitstekende speurhond. Het herkent de structuur van datatypes.config en helpt bij batch-aanpassingen.
Bash en PowerShell rond .NET CLI. Niet direct Umbraco-specifiek, maar wel je dagelijkse werk: dotnet add package, EF-migraties, deploy-scripts. Copilot kent dat dialect uit z'n hoofd.
Die cijfers zijn niet uit een marketingbrochure geplukt — ze komen uit onze eigen logs. We meten al een jaar lang hoeveel Copilot-suggesties we accepteren, hoeveel we afkeuren en hoe vaak we ze achteraf moeten herschrijven. Het patroon is stabiel sinds halverwege 2025: stille tijdwinst op het herhalende werk, scherpe waakzaamheid op alles dat raakt aan Umbraco-specifieke architectuur.
Copilot is een leerling-brouwer, geen meesterbrouwer. Hij kent de bewegingen, maar mist soms de feeling voor welke gist dit jaar werkt. Behandel elke suggestie als een eerste schets — niet als gepubliceerde code. Voor de meeste Umbraco-projecten is dat exact de juiste mentaliteit.
Waar het tegen Umbraco-grenzen loopt
Dan de andere kant. Op deze plekken gaat Copilot vaker mis dan goed:
Composition-keuzes voor Document Types. Of je iets als Composition of als nested Document Type modelleert is een ontwerpbeslissing met directe impact op de redacteurs-UX. Copilot kiest meestal het meest voor de hand liggende — en dat is in Umbraco regelmatig niet de beste optie.
BlockGrid versus BlockList. Een terugkerend foutje: Copilot stelt een BlockList voor waar BlockGrid-functionaliteit (areas, kolomspans, drag-and-drop layout) thuishoort. Of andersom. Het ziet beide als "lijst met blokken", maar mist dat de redacteur ze totaal anders ervaart.
Obsolete APIs. Dit is het meest verraderlijke. Copilot is getraind op tonnen Umbraco-code, waarvan een aanzienlijk deel uit het 8/9/10-tijdperk komt. Het stelt zonder blikken of blozen IPublishedContentQuery-aanroepen voor waar inmiddels IDocumentNavigationQueryService de juiste keuze is. Of .Children als property in plaats van als extension method. Wij hebben eerder over deze tendens geschreven in een bredere context.
uSync-bestanden van nul opzetten. Lezen en aanpassen: prima. Het volledig opzetten van een nieuw doctype-config-bestand inclusief alle juiste tabs, groups en property-volgordes: gaat consistent fout. De kans dat je iets per ongeluk overschrijft is hoog. Doe dit met de hand of vanuit de backoffice plus uSync-export.
Custom property editors voor de Umbraco 14+ backoffice. De nieuwe backoffice met Vite, Lit-elements en de moderne extension manifests is jong vergeleken met de AngularJS-jaren. Copilot leunt nog flink terug op de oude AngularJS-patronen die we juist willen vermijden. Voor backoffice-werk hebben we het AI-aandeel bewust kleiner gemaakt.
UFM (Umbraco Flavored Markdown). De single-curly-brace syntax van UFM — {umbValue: alias}, {umbContentName: pickerAlias} — is specifiek en sinds Umbraco 14. Copilot levert hier in negen van de tien gevallen de oude AngularJS-versie met double curly braces aan, die in v14+ simpelweg niet meer werkt.
Een werkbare Copilot-workflow
Hoe maak je hier in de praktijk werk van? Niet door Copilot uit te zetten — dan laat je echte productiviteitswinst liggen. Wel door bewust te zijn van waar het waarschijnlijk goud is en waar je wantrouwen je vriend is.
Voor onze teams zijn drie principes leidend:
-
Een goede .github/copilot-instructions.md aanmaken die je project-specifieke conventies vastlegt: Umbraco-versie, BEM-naamgeving, BlockGrid- versus BlockList-richtlijnen, uSync-workflow. Daarnaast prompt-files voor terugkerende taken als blok-creatie of viewmodel-mapping. Eenmalig werk dat elke dag rendement geeft.
-
Gebruik Copilot voor de gouden categorie: views, mappers, queries, scripts. Schakel het bewust uit (of negeer suggesties) tijdens model-design, BlockGrid-architectuur en uSync-werk. Pas op met code voor backoffice-extensions — vraag daar bewust om Umbraco 14+ patronen.
-
Pull-request-reviews behandelen Copilot-code identiek aan menselijk geschreven code. Geen ruimte voor 'het was AI, dus het zal wel kloppen'. Specifiek opletten op obsolete API's, ongeteste edge cases en magic strings die ergens uit de trainingsdata zijn komen aanwaaien.
De winst die we hieruit halen is geen dramatisch sprongetje. Het is een stille verschuiving van anderhalf tot twee uur per developer per week, gemeten over een sprint. Op een team van vier developers is dat een dag aan calm-coding-tijd die je in iets anders kunt stoppen — code reviews, refactoring, of een halve middag echt nadenken over modellering.
Zo introduceer je het in je team
Als jullie het nu nog niet gebruiken, is dit het patroon dat bij ons werkt:
Een persoon eerst. Iemand die graag experimenteert. Laat die over een sprint of twee meten waar het wel en niet werkt op jullie codebase. Dat geeft een veel beter beeld dan een algemene "wij gebruiken nu AI"-presentatie.
Conventies eerst, gebruik daarna. Schrijf je .github/copilot-instructions.md voordat het hele team het gaat gebruiken. Zonder die context produceert Copilot generieke code in plaats van code die bij jullie past.
Review-cultuur eerst. Zorg dat code reviews voor AI-bijdragen niet afgezwakt worden. Het tegendeel: een reviewer mag rustig vragen "is deze suggestie geverifieerd tegen Umbraco 17?" en daarop een wijziging eisen.
Valkuilen die we in de praktijk zien
Verzonnen package-namen. Copilot stelt soms NuGet-packages voor die niet bestaan of die wel bestaan maar al jaren niet meer onderhouden worden. Altijd controleren op nuget.org voordat je iets installeert.
Magic strings uit de trainingsdata. Connectionstrings, API-keys, dummy GUIDs. Dat hoort niet in jullie code. Een veiligheidsbewust developer haalt zo'n suggestie eruit, een gehaaste developer commit het mee.
"Even snel" SQL vanuit een controller. Voor directe database-aanroepen vanuit Umbraco-controllers stelt Copilot meestal een patroon voor dat werkt — maar SQL-injection-risico's introduceert. Hier moeten reviewers waakzaam blijven.
Overcomplicated abstractions. Soms tovert Copilot vijf interfaces tevoorschijn waar een simpele class voldoet. Geen Umbraco-specifiek probleem, maar wel een die we vaak zien terugkomen — vooral als je veel design-pattern-blogs in je trainingsdata hebt zitten.
Wanneer wel, wanneer niet
Gebruik Copilot in je Umbraco-werk als je een team van twee of meer developers hebt, een redelijk goed onderhouden codebase, en als jullie review-discipline al stevig staat. Dan haalt het mensen voorbij hun tikwerkmodus en houdt het ze in nadenkmodus — precies wat je wilt.
Wees voorzichtiger als je net begint met Umbraco, of als de codebase die je beheert door de jaren heen rommelig is geworden. In beide situaties versterkt Copilot bestaande problemen: het pikt slechte patronen op en serveert ze opnieuw. Eerst opruimen, dan AI.
Voor de meeste Umbraco-bureaus en in-house teams die we kennen is de balans inmiddels gekanteld. Niet gebruiken voelt langzaamaan als zonder elektrische schroevendraaier werken in een hedendaagse meubelmakerij — het kan, maar je verliest tijd zonder dat het ambacht er wat aan heeft.
Wil je sparren over hoe je AI-assistentie in jullie Umbraco-team praktisch inricht? Lees hoe wij Umbraco-development aanvliegen of neem direct contact op. We delen de instructions-files die wij intern gebruiken graag en kijken samen waar in jullie codebase de grootste winst te halen is.