Wat als je Fabric notebooks gewoon in Visual Studio Code kunt ontwikkelen, GitHub Copilot kunt gebruiken tijdens het schrijven van PySpark, én je code nog steeds kunt uitvoeren op een Fabric Spark cluster?
Dat is precies waarom de integratie tussen Microsoft Fabric en VS Code interessant is. Voor veel developers is VS Code namelijk de plek waar het echte ontwikkelwerk gebeurt: code schrijven, snel wisselen tussen bestanden, documentatie bijwerken, Copilot gebruiken en overzicht houden over wat je aan het bouwen bent.
Microsoft heeft in de Fabric April 2026 Feature Summary meerdere verbeteringen rondom VS Code benoemd. Denk aan het beheren van Fabric workspace items vanuit VS Code, het bewerken van notebooks met automatische sync naar de Fabric workspace, het beheren van environments en het instellen van een default Lakehouse voor notebooks.
Omdat deze verbeteringen sinds april 2026 beschikbaar zijn, voelt de integratie veelbelovend maar ook nog in ontwikkeling. Sommige onderdelen werken al erg prettig, terwijl andere onderdelen nog wat volwassener mogen worden. Juist daarom is dit een interessant moment om ermee aan de slag te gaan.
Voor mij is het grootste voordeel simpel: VS Code is een vertrouwde ontwikkelomgeving. Wanneer ik aan Fabric notebooks werk, wil ik snel kunnen ontwikkelen, makkelijk kunnen wisselen tussen notebooks en gebruikmaken van de tooling die ik al dagelijks gebruik. Met de Fabric Data Engineering extensie brengt Microsoft een deel van de Fabric-ervaring naar VS Code.
Daarmee voelt notebook development minder als “werken in een browser” en meer als reguliere softwareontwikkeling. Je werkt met notebooks, Lakehouses, Spark job definitions, environments en workspace items vanuit een omgeving die veel developers al kennen. Dat maakt de drempel lager en het ontwikkelproces vaak sneller.
De eerste sterke use case is natuurlijk notebook development zelf. Je kunt bestaande Fabric notebooks openen, aanpassen in VS Code en je code uitvoeren op remote Spark compute in Microsoft Fabric. Daarmee combineer je de fijne editorervaring van VS Code met de kracht van Fabric Spark.
Een tweede groot voordeel is GitHub Copilot. Zeker bij het schrijven van PySpark-code kan Copilot helpen met boilerplate, transformaties, markdown-documentatie of het sneller opzetten van logica. Het vervangt je eigen denkwerk niet, maar het versnelt wel veel terugkerende taken.
Ook het snel wisselen tussen notebooks is prettig. Zeker wanneer je werkt aan een oplossing met meerdere notebooks, wil je overzicht houden. In VS Code voelt dat vaak natuurlijker dan steeds navigeren door de Fabric UI.
Daarnaast kun je op verschillende manieren werken. In local mode download je items lokaal, pas je ze aan en sync je ze daarna terug naar Fabric. In VFS mode werk je direct met workspace items als remote bestanden. Je hoeft dan minder met lokale kopieën te werken.Voor notebook-heavy development zou ik op dit moment vooral VFS mode aanraden. Dat houdt je workflow dicht bij de Fabric workspace en voorkomt onnodig lokaal bestandsbeheer.
Mijn huidige workflow is vrij eenvoudig. Ik maak de basisstructuur meestal eerst aan in de Fabric UI. Denk aan folders, notebooks en de juiste workspace-inrichting. Voor dat soort structurele taken vind ik de portal op dit moment nog steeds het meest overzichtelijk.
Daarna verplaats ik het inhoudelijke ontwikkelwerk naar VS Code. Daar schrijf en verbeter ik de notebook code, gebruik ik GitHub Copilot, werk ik documentatie bij, beheer ik variabelen en run ik code op remote Spark.
Voor mij werkt die combinatie goed: Fabric UI voor structuur, inrichting en overzicht. VS Code voor development, documentatie en iteratie. Het is dus geen vervanging van de Fabric UI, maar eerder een aanvulling die het dagelijkse ontwikkelwerk prettiger maakt.
Een ander handig onderdeel is het analyseren van notebook runs. Vanuit VS Code kun je recente runs bekijken, details inspecteren, logs downloaden en Spark-informatie openen.
Dat is vooral handig wanneer je wilt begrijpen wat er tijdens een run is gebeurd. Wie heeft de notebook uitgevoerd? Hoe lang duurde de run? Waar ging het mis? Welke Spark logs zijn beschikbaar?
Alle Spark logs zijn direct beschikbaar om verder te inspecteren. Dat maakt troubleshooting toegankelijker, zeker wanneer je veel met notebooks en Spark workloads werkt.
De integratie is nuttig, maar nog niet perfect. In mijn ervaring beheer ik sommige structurele zaken liever nog vanuit de Fabric UI. Denk aan het aanmaken van folders, het opzetten van de initiële notebookstructuur en het netjes organiseren van items in de workspace. Folder management voelt in VS Code nog niet zo soepel als ik zou willen.
Ook zijn er nog praktische beperkingen of randgevallen rondom notebookbeheer. Denk aan lokaal notebooks importeren, notebooks kopiëren of hernoemen, afhankelijk van de manier waarop je werkt.
Daarnaast heb ik af en toe een save-error gezien. Niet constant, maar genoeg om alert te blijven. Mijn advies: let goed op de sync-status en ga er niet blind vanuit dat iedere wijziging direct goed is opgeslagen.
Kortom: de integratie is al erg bruikbaar, maar ik zou de Fabric UI nog niet volledig vervangen door VS Code. De beste ervaring krijg je op dit moment door beide te gebruiken waar ze sterk in zijn.
De Fabric Data Engineering extensie voor Visual Studio Code is een mooie stap richting een meer developer-friendly Microsoft Fabric ervaring.
Voor Fabric Notebooks maakt het ontwikkelen sneller, herkenbaarder en beter gestructureerd. De combinatie van VS Code, GitHub Copilot, remote Spark execution, notebook run monitoring en directe workspace sync kan het dagelijkse ontwikkelwerk echt verbeteren.
Is het al perfect? Nog niet. Is het nu al waardevol? Absoluut.
Omdat de nieuwste verbeteringen pas sinds april beschikbaar zijn, verwacht ik dat deze integratie de komende tijd alleen maar beter wordt. Zeker als Microsoft verder investeert in notebookbeheer, folder management en een nog soepelere sync-ervaring.
Voor de officiële setup en ondersteunde functionaliteit verwijs ik graag naar de documentatie van Microsoft.