Si trabajas a diario con Microsoft Fabric, seguro que en algún momento te ha pasado: el editor de notebooks del portal va bien para prototipar rápido, pero en cuanto el proyecto crece (control de versiones serio, snippets reutilizables, IntelliSense decente, tu configuración de VS Code de toda la vida) empieza a quedarse corto.

La buena noticia es que Microsoft ya tiene una solución oficial y madura para esto: la Fabric Data Engineering VS Code extension. Te permite descargar tus notebooks de Fabric a una carpeta local, editarlos con todas las herramientas de VS Code, ejecutarlos contra el compute remoto de Spark de tu workspace, y sincronizar los cambios de vuelta sin salir del editor.

Pero para mí el verdadero salto de productividad no es solo “editar en local”. Es que, al estar dentro de VS Code, puedes desarrollar con agentes de IA que escriben y prueban el código directamente contra el runtime real de Fabric, sin salir nunca del editor. Y a esos agentes les puedes añadir skills específicas de Fabric publicadas por Microsoft, para que entiendan de verdad cómo funciona la plataforma en lugar de improvisar.

En este artículo te explico cómo montarlo todo, paso a paso, y cómo encaja la IA en ese flujo.

¿Por qué desarrollar notebooks de Fabric en local?

Antes de entrar en faena, vale la pena dejar claro qué gano frente a trabajar directamente en el portal:

• Mejor experiencia de edición. Autocompletado, snippets, extensiones de Python/PySpark, tu tema y tus keybindings de siempre.
• Control de versiones real. Trabajas con archivos en disco, así que Git, commits, branches y pull requests funcionan de forma natural (aunque Fabric ya tiene integración Git propia, tener los archivos en local facilita ciertos flujos).
• Reutilización de código. Es mucho más cómodo copiar bloques entre notebooks, mantener plantillas o compartir snippets con el equipo.
• Menos dependencia del navegador. Nada de pestañas que se quedan colgadas ni reinicios de sesión por inactividad del portal.
• Desarrollo asistido por IA de verdad. En el portal tienes Copilot, sí, pero en VS Code tienes todo el ecosistema de agentes: agentes personalizados, modo agente, y la posibilidad de “enchufarle” conocimiento específico de Fabric mediante skills. El agente puede escribir una celda, ejecutarla contra tu sesión de Spark remota, ver el resultado o el error, y corregirse solo, todo dentro del mismo editor.

Eso no quita que el notebook siga corriendo donde tiene que correr: en el Spark runtime remoto de tu capacidad de Fabric. Lo único que cambia es desde dónde escribes el código.

Requisitos previos

Antes de instalar nada, asegúrate de tener:

• Visual Studio Code actualizado a la última versión.
• Python 3.8 o superior instalado en tu máquina.
• Una cuenta con acceso a un workspace de Microsoft Fabric.
• La extensión Jupyter para VS Code (se instala desde el Marketplace, es un requisito de la extensión de Fabric).

Con esto ya tienes la base lista para el siguiente paso.

Paso 1: Instalar la extensión Fabric Data Engineering

1. Abre VS Code y entra en la vista de Extensiones (Ctrl+Shift+X en Windows/Linux, Cmd+Shift+X en macOS).

2. Busca “Fabric Data Engineering”.

   

3. Pulsa Install.

4. Reinicia VS Code si te lo pide.

Tras la instalación, verás un nuevo icono de Fabric en la barra de actividad (la barra lateral izquierda). Desde ahí accederás a todo: notebooks, Spark job definitions, entornos y lakehouses.

Paso 2: Iniciar sesión

1. Abre la paleta de comandos (Ctrl+Shift+P / Cmd+Shift+P).
2. Escribe “Fabric Data Engineering” para filtrar los comandos disponibles.
3. Ejecuta Fabric Data Engineering: Sign In.

4. Se abrirá una ventana del navegador: selecciona la cuenta con la que accedes a tus workspaces de Fabric y completa la autenticación.

Cuando todo vaya bien, verás tu nombre de cuenta reflejado en la barra de estado inferior de VS Code.

Modo local vs. modo VFS: ¿cuál elijo?

Antes de conectar tu workspace, conviene entender que la extensión funciona de dos formas bien distintas. No es solo un detalle técnico: condiciona cómo vas a trabajar el resto del día.

Modo local. Descargas los notebooks (y otros elementos) a una carpeta de tu máquina, los editas como archivos normales en disco, y luego sincronizas los cambios de vuelta al workspace cuando estás listo. Es el modo que más se parece a un flujo de desarrollo tradicional con Git: tienes los archivos físicamente delante, puedes versionarlos con tu propio repositorio, trabajar sin conexión en la parte de edición, y decidir tú cuándo subir cambios. La contrapartida es que hay un paso extra de ida y vuelta (descargar → editar → sincronizar) y, si alguien más toca el mismo notebook en el portal mientras tú trabajas en local, puede generarse un conflicto que tienes que resolver a mano con el editor de diferencias.

Modo VFS (Virtual File System). Aquí no descargas nada: abres y editas el notebook directamente como si fuera un archivo remoto, y cada vez que guardas (Ctrl+S), el cambio se sincroniza automáticamente con el workspace. No hay carpeta local que gestionar, ni paso de sincronización manual, ni gestión de conflictos al estilo “merge”: el historial completo de versiones queda registrado en el versionado en vivo del propio portal de Fabric. Para entrar en este modo, seleccionas Open a Remote Window en VS Code y luego Open Fabric Data Engineering Workspaces; o, más cómodo todavía, pulsas el botón Open in VS Code (Desktop) directamente desde la página de un notebook en el portal de Fabric, y VS Code se abre ya conectado a ese workspace. El modo VFS también te permite tener varios workspaces de Fabric abiertos a la vez en la misma ventana, algo que en modo local es más incómodo.

¿Cuál usar entonces? Para mí, la regla rápida es:

• Modo local, si quieres versionar tus notebooks con tu propio Git (más allá de la integración Git nativa de Fabric), trabajar con plantillas o snippets compartidos en disco, o simplemente prefieres tener los archivos físicamente en tu equipo.
• Modo VFS, si lo que buscas es agilidad: abrir rápido un notebook desde el portal, tocar algo puntual, guardar y listo, sin preocuparte de descargas ni sincronizaciones. También es la opción más cómoda si saltas entre varios workspaces a menudo.

Y un matiz importante para lo que viene después sobre IA: en modo VFS también puedes ejecutar el notebook seleccionando Microsoft Fabric Runtime como kernel, y corre igualmente contra el compute remoto de Spark sin descargar nada. Sin embargo, el agente personalizado FabricNotebook de Copilot Chat solo está disponible cuando el tipo de sesión es Local; en VFS no aparece como opción. Así que si tu prioridad es desarrollar con ese agente específico, el modo local es el que necesitas — y por eso el resto de este tutorial se centra en él.

Paso 3: Conectar tu workspace en modo local

1. Abre el panel lateral de Fabric Data Engineering.
2. Selecciona Select Workspace, o el icono de flechas para Switch Workspace.

3. Elige el workspace con el que quieres trabajar de la lista que aparece.
4. Define dónde quieres guardar los archivos descargados ejecutando Fabric Data Engineering: Set Local Work Folder desde la paleta de comandos.

A partir de aquí, el panel lateral te mostrará todos los elementos de ese workspace organizados por tipo: notebooks, lakehouses, entornos de Spark, etc.

Paso 4: Descargar y editar un notebook

Los notebooks del workspace aparecen listados, pero no puedes editarlos directamente hasta descargarlos:

1. Pasa el ratón por encima del nombre del notebook que quieras editar.
2. Pulsa Download Notebook y guárdalo en tu carpeta de trabajo local.

3. Una vez descargado, verás un indicador de estado junto al nombre:
   • L (verde): el notebook está sincronizado con la versión remota.
   • C (rojo): hay conflictos entre tu versión local y la del workspace.
4. Pasa el ratón por el notebook descargado y selecciona Open Notebook Folder para abrirlo como cualquier archivo .ipynb en VS Code.

A partir de este punto, edita el notebook exactamente como harías con cualquier Jupyter Notebook local: celdas de código, celdas de markdown, reordenar, todo igual.

Paso 5: Ejecutar el notebook contra el compute remoto

Aquí está la magia del asunto: aunque editas en local, la ejecución sigue ocurriendo en el clúster de Spark de tu capacidad Fabric.

1. En el selector de kernel del notebook, elige Microsoft Fabric Runtime.

2. Selecciona el lenguaje que necesites: PySpark, Spark SQL, Scala o Python.

3. Ejecuta las celdas con normalidad. La primera ejecución tardará un poco más mientras se arranca la sesión de Spark; las siguientes serán más rápidas si la sesión sigue viva.

Si revisas el monitor de Fabric, podrás ver la sesión del notebook activa con el sufijo _vscoderemote

Paso 6: Sincronizar cambios con el workspace

Cuando termines de editar, tienes que publicar tus cambios de vuelta al workspace remoto:

1. Desde el panel de Fabric, localiza la opción para subir o sincronizar el notebook editado.

2. Si hay conflictos (alguien más editó el mismo notebook en el portal mientras tú trabajabas en local), VS Code abre un editor de diferencias: a la izquierda verás la versión del workspace, a la derecha la tuya.
3. Resuelve los conflictos celda a celda y pulsa Merge en la esquina superior derecha del editor de diff para confirmar.
4. Si otra persona tiene el mismo notebook abierto en el portal mientras subes cambios, recibirá una notificación para aceptar o rechazar tus cambios desde VS Code.

Para traer la última versión remota antes de seguir editando, usa la opción Update Notebook sobre el nombre del notebook en el explorador.

Historial de versiones

Si accedes al historial de versiones del notebook, podrás ver si se ha modificado desde VS Code:

Desarrolla con IA: el agente FabricNotebook en Copilot Chat

Hasta aquí tienes el flujo “clásico”: descargar, editar, ejecutar en remoto, sincronizar. Pero la razón por la que este setup me parece imprescindible hoy es otra: dentro de VS Code puedes desarrollar el notebook con un agente de IA que prueba el código contra el runtime real de Fabric en cada paso, en lugar de escribir a ciegas y descubrir el error al ejecutar manualmente.

Si ya usas GitHub Copilot Chat, hay un agente personalizado pensado específicamente para esto: FabricNotebook. A diferencia de un agente de propósito general, entiende patrones propios del entorno, como la variable spark ya inicializada en la sesión, o la diferencia entre usar rutas relativas para el lakehouse por defecto y rutas ABFSS completas para lakehouses adicionales.

Para activarlo:

1. Abre un notebook de Fabric en VS Code y el panel de Copilot Chat.
2. En el selector de tipo de sesión, elige Local (es el único tipo soportado por este agente).
3. En el selector de agentes, elige FabricNotebook.
4. Elige uno de los modelos base compatibles en el selector de modelos.

A partir de ahí puedes pedirle directamente que te genere código Spark, refine la lógica de una celda o te ayude a depurar un error, todo con contexto específico de Fabric. Y como el kernel sigue siendo Microsoft Fabric Runtime, cuando el agente ejecuta una celda lo hace contra tu sesión de Spark real, con tus datos reales en OneLake — no es una simulación aparte.

Más contexto para el agente: Microsoft Fabric Skills

El agente FabricNotebook ya viene “preentrenado” para notebooks, pero si trabajas con más tipos de elementos de Fabric (APIs REST, Dataflows Gen2, Eventhouse/KQL, modelos semánticos…) puedes ir un paso más allá y darle a tu agente de IA conocimiento oficial de toda la plataforma, no solo de notebooks.

Microsoft mantiene un repositorio público de código abierto, skills-for-fabric, con instrucciones reutilizables escritas por los propios equipos de Fabric: cómo llamar a la API REST correctamente, qué audiencia de token espera cada endpoint, cómo estructurar un pipeline siguiendo arquitectura medallion, etc. Sin estas skills, un agente genérico genera código que “parece” correcto pero llama al endpoint equivocado, se olvida de la autenticación o monta una arquitectura que no encaja con cómo funcionan realmente los elementos de Fabric — y acabas corrigiendo a la IA en lugar de ir más rápido con ella.

Yo uso Claude Code, y la buena noticia es que usa el mismo flujo de instalación que GitHub Copilot CLI, vía marketplace de plugins:

# Añadir el marketplace público de Microsoft
/plugin marketplace add microsoft/skills-for-fabric
 
# Instalar el paquete completo
/plugin install fabric-skills@fabric-collection

También puedes instalar solo el paquete que te interese (autoría, consumo, operaciones, Power BI) o filtrar por workload concreto:

/plugin install fabric-authoring@fabric-collection
/plugin install fabric-skills@fabric-collection --filter "spark-*"

Una vez instalado, simplemente le pides la tarea al agente en lenguaje natural y responde apoyándose en los patrones oficiales de Fabric, no en una respuesta genérica de Spark:

Ten en cuenta que la mayoría de operaciones contra Fabric requieren autenticación en Azure, así que antes de lanzarte conviene tener la sesión iniciada con az login. Y si usas otra herramienta como Cursor o Windsurf, el repositorio también incluye configuración para que las recoja automáticamente al clonarlo en tu proyecto.

Conclusión

Trabajar con Fabric Notebooks desde VS Code no sustituye al portal —para prototipado rápido o para compartir con perfiles menos técnicos sigue siendo más cómodo el navegador—, pero para desarrollo serio marca una diferencia notable, y hay más de un camino para llegar ahí. El modo local te da control de versiones real y la posibilidad de usar el agente FabricNotebook; el modo VFS te da agilidad para entrar y salir rápido de un notebook sin gestionar nada en disco. Elige según lo que necesites en cada momento, no hay una única forma “correcta”.

Pero el cambio que de verdad noto en el día a día es desarrollar con un agente de IA que prueba cada celda contra el runtime real de Fabric, y que además puedo dotar de conocimiento oficial de la plataforma instalando las skills de Microsoft como plugin en Claude Code. Pasas de “escribir código y rezar” a “escribir, ejecutar y corregir en el mismo sitio, con un agente que conoce Fabric de verdad.”

Una vez tienes el flujo completo rodando —elegir modo, editar con ayuda de IA, ejecutar en remoto, sincronizar y revisar el historial de versiones—, cuesta volver atrás.