Vibe Coding Fabric Notebooks in VS Code: A Production Checklist
1. Key Insights Level: 300 - practical implementation. You need to know Spark and Fabric notebooks. You do not need to know how the extension works internally. The situation. Fabric notebooks are an excellent environment for developing and operating Spark workloads. But once a notebook passes a few hundred lines, the engineering activities - refactoring, documentation, architecture review, large-scale changes - become hard to do in a browser. The alternative. The Fabric Data Engineering extension for VS Code opens a different workflow: Download the notebook from Fabric Work on it locally with a modern coding agent - Claude Code, the Claude extension, GitHub Copilot agent mode, OpenAI Codex, or a local agent Publish it back You keep Fabric's managed Spark platform, and you add what VS Code already has: advanced refactoring, Source Control, review workflows, and project-wide AI context. What surprised me. The value was not where I expected it, and the line is not where most people draw it. Generating a notebook from scratch was the weakest use. Ask for the whole thing at once and you get something plausible that you then have to verify end to end - which costs more than writing it yourself. Generating code block by block worked well. "Add one more cell that does X" is bounded. I can read it, run it, and reject it in seconds. Improving notebooks that already exist was the strongest of all. The existing code is the specification, so the agent has something to be correct against. So the useful rule is not generation bad, refactoring good. It is about scope: the agent is reliable when the change is bounded and verifiable in one reading, and unreliable when it is unbounded. What it costs. Every capability here has its limitation, and they belong in the same paragraph: Notebook synchronization is not a real-time collaborative experience. Treat it as checkout, not as co-editing. AI-generated changes require human review - and the notebook diff you review is not a code diff. That is Section 3, and it is the part I did not expect. Production workloads still need governance, validation and security controls. The agent does not provide them. So, the conclusion up front. Successful Spark vibe coding is less about replacing engineering discipline and more about augmenting it. If you skip the review step, you have not saved time - you have only moved the risk later. What is in this article. A practical workflow: prerequisites, the development patterns that worked, three review strategies with their trade-offs, production safeguards, the prompt set I reuse, and the lessons from real experimentation. The prompts are at the end. 2. When Spark Notebooks Vibe Coding is Helpful Experimenting, I found a few cases where having Spark in VSCode is more beneficial than having to solve its complexity and logistic: Converting messy 30-cells notebook into a well-structured sanctuary Solving complex technical problems (API ingestion, complex transformation, complex dependencies), to save time for copy-paste, and doing that coding step-by-step, with powerful AI assistance in place Refactoring becomes just easier using VSCode. It may be done using AI, by prompting. Or, if we want to do it manually, F2 (Windows) or Fn-F2 when the desired variable is selected will help. It is a very clean way to refactor code at scale, with minimal risk. 3. When is Vibe Coding not worth the cost? Simple, straightforward notebooks - easier to modify using the web or copy-paste AI-generated code. Highly critical pipelines, where the mistake costs a lot or the privacy model is incompatible with AI provider terms - these are subject to reconsider using AI in autonomous or partly autonomous mode. Now, let's observe some workflows and prerequisites to be able to vibe-code in Spark notebooks. 4. Prerequisites What is needed to start vibe-coding in Fabric/Spark? VSCode - indeed; Fabric Data Engineering VS Code - to connect to Fabric; Coding agent (I use the Claude extension, installed in VSCode) Turned on AutoSave in VSCode will help avoiding overwriting and keep the changes actual. 5. Workflow Extension -> Workspace -> Notebook -> Download -> Open Then - modifying the code, using vibe-coding. Then - publishing back. If the notebook was updated on the web, it is possible but harder to merge all the changes. I would omit that scenario entirely to avoid any issues. Full journey may look like that: During testing, I found that notebook synchronization between Fabric and VS Code should not be treated as real-time collaboration. If substantial changes were made through the Fabric web interface, re-downloading the notebook may be safer than attempting to merge changes manually. Disclaimer: If somebody changed the code in the web interface, getting these changes may be a challenge. Simple Update icon doesn't help, even though it says the update was successful. So, additional awareness is required for that matter. It will be an alert during publishing the code with the option to accept local or remote change: 6. Production-ready best practices 6.1. Security & Privacy If we work in production, it is important to follow the organization's rules, and use only appropriate AI tools. 6.2. Responsibility AI may change code very unpredictably. It may break production silently. Two options for handling that. First is asking AI to show all the changes. The second one is to manually check points at the beginning of vibe-coding and at the end. 6.2.1. Strategy one - risky: Asking AI to show differences Before vibe-coding, give an instruction similar to this: Before making any file modifications, show me the proposed diff and wait for my approval. As a result, the agent may showcase the changes it made. The key thing here is it may miss something or hallucinate. So, for highly critical pipelines, it may not work. This strategy is good for prototype, PoC, and MVP development. But, actually, I would say, it is overall the best time to use vibe-coding. Fully productionized critical system - it is debatable whether the outcome outweighs risks using AI assistants to write code in agentic mode. It is much safer to use manual coding, by copy-paste-debug without writing to the final tables. 6.2.2. Strategy two - conservative: Backup notebook and related data Backing up related data and code - it is a highly conservative strategy. It make sence doint this only if vibe-coding will bring much more benefits than the other ways of changing the logic 6.2.3. Strategy three: Checking the changes before and after Open notebook in VS Code. Initialize Source Control (Git). Let Claude modify the notebook. Open Source Control (Cmd+Shift+G). Click the modified notebook, to see the differences, before publication. 7. Additional block - Prompts for success 7.1. Prompt 1 - Notebook Structure Overview the notebook, and add its title, description, and after that - all the Headlines and sub-headlines, with prefixes like 1., 2., 3., 1.1., 2.2., etc 7.2. Prompt 2 - Find weak points Check code and find what may be improved. Don't do any changes. Only give the comments. 7.3. Prompt 3 - Refactor Notebook Refactor this notebook without changing functionality. Extract duplicated logic into reusable functions, improve variable naming, add comments where necessary, and reorganize code into logical sections. 7.4. Prompt 4 - Documentation This is probably the highest ROI prompt. Generate markdown documentation for this notebook. Explain business purpose, inputs, outputs, dependencies, assumptions, and execution flow. Many Fabric notebooks have zero documentation. 7.5. Prompt 5 - Performance Review This is very Spark-specific. Review this PySpark code for performance issues. Identify unnecessary shuffles, collect operations, driver-side processing, inefficient joins, and repeated scans. 7.6. Prompt Set for Feature Building 7.6.1. API Ingestion Prompt: Review this notebook and create a reusable API ingestion framework with retry logic, pagination support, logging, and configuration-driven endpoints. 7.6.2. Data Quality Framework Prompt: Convert all validation checks into reusable functions and generate a summary report at the end of execution. 7.6.3. Monitoring Notebook Prompt: Extract all monitoring logic into reusable functions and create a centralized alerting section. 7.6.4. Legacy Notebook Cleanup Prompt: Refactor this notebook into logical sections and eliminate duplicated code. 8. Before & After examples Before: After: 9. What agents may we use here? The agents selection is not limited. When we work with the notebooks that way, they are stored locally. It means, Claude Code, OpenAI Code, Loca agent from VSCode, Github Copilot Agend mode and others are fully available for us. 10. Lessons Learned Documentation generation produced the highest ROI. Structural refactoring was more reliable than business logic generation. Source Control review was essential. Small notebooks rarely justified the overhead. Large notebooks benefited the most. This makes the article feel based on real experimentation rather than theory. 11. Conclusion Spark notebooks are a surprisingly good candidate for vibe coding. The extension also supports Python notebooks and Spark SQL, from what I tested. Large notebooks often contain repetitive patterns, technical debt, and insufficient documentation-areas where modern coding agents can provide significant value. However, AI-generated changes should always be reviewed before publication, especially for production workloads. Combined with VS Code Source Control and the Fabric Data Engineering extension, vibe coding can become a practical addition to a data engineer's toolkit rather than a replacement for engineering judgment.An introduction to Fabric Apps
One of the shiny new items in Microsoft Fabric is Fabric Apps, and these open up a bunch of possibilities for what is possible in Fabric. Fabric Apps enabled functionality that previously would have needed to be custom workloads, which are a lot more complex to get up and running than Fabric Apps. What is a Fabric App? A Fabric app (built on the Rayfin SDK) is a Fabric item with two components, a backend service for data access and authentication, and a front end web app. When a Fabric App is created, Fabric automatically creates a SQL Database, an authentication server, and static content hosting for the front end web app. You provide data models for your application in TypeScript and Fabric Apps automatically creates a database schema and type-safe GraphQL API. Before you can create one, a tenant admin has to enable it. It's still in preview, so it needs to be explicitly enabled, and Fabric Apps are not available in all regions. Fabric Apps are currently available in the following regions (As of August 18th, 2026): US - Central US US - North Central US US - West US US - West US 2 Europe - West Europe France Central Italy North Norway East Switzerland North UAE North South Africa North Asia - East Asia Asia - Southeast Asia Australia East India - Central India Japan East Korea Central To enable the preview in your tenant: 1. Sign in to the Fabric admin portal (https://app.fabric.microsoft.com/admin-portal). 2. Go to Tenant settings. 3. Under Enable Fabric App Items (preview), toggle it to Enabled, scoped to your whole org or specific security groups. 4. Select Apply. Give it a few minutes to propagate. If you don't see App (preview) in your New item list, either this is why or your capacity is in an unsupported region. Part 1: Create and Deploy the Sample App Create the item in Fabric Creating the item itself is the same as any other Fabric item: 1. Open a workspace where you have contributor or higher access. 2. Select New item. 3. Search for App (preview), select it, give it a name, and select Create. This creates the item, and all the backend services I mentioned before. From here, you can select a blank app, or start with a sample To-Do App, or a sample Data App. For the sake of this post, I am going to select the To-Do App. Once selected, Fabric will start to deploy your app and present you with some instructions for getting the Rayfin CLI up and running. Create the project with npm From a terminal, run the command shown in the Fabric App: npm create Microsoft/rayfin@latest -- "<appitemname>" --template todoapp --workspace <workspacename> That one command creates a full project from the `todoapp` template and wires it to the workspace and item you just created, using the Rayfin CLI. Then change your working directory to the project directory that was just created cd <your project directory> Run it locally npm run dev This spins up the frontend and backend together against your Fabric backend, so you can test changes before anything goes live. By default it runs at `http://localhost:5173`. Deploy with npx npx rayfin up Under the hood, `rayfin up` does six things in order: 1. It creates (or reuses) the Fabric App item 2. It retrieves the publishable key 3. It syncs your `rayfin.yml` settings 4. It applies the database schema from your TypeScript models 5. It builds and deploys static content, 6. Finally, it writes the deployment details back to `rayfin.yml` and a `.env.fabric-<workspacename>` file. When it finishes, you get a live hosting URL, a Fabric portal link, and a deployment ID. Tip: Want to check what a deploy will do without actually running it? Use `npx rayfin up --dry-run`. To check current deployment state at any time, use `npx rayfin up status`. Part 2: The Database Objects Here's the part that surprised me the most coming from a data background: there's no SQL to write, and no separate database designer to open. Your data models are TypeScript classes, and Fabric Apps turns them directly into database tables. Defining an entity Entities or tables live in `rayfin/data/` and use the `@entity()` decorator from `@microsoft/rayfin-core`, as well as field decorators for each column: Each table needs to be defined in it's own typescript file. import { entity, uuid, text, boolean, date } from '@microsoft/rayfin-core'; @entity() export class Todo { @uuid() id!: string; text() title!: string; text({ optional: true }) description?: string; @boolean({ default: false }) isComplete!: boolean; date() createdAt!: Date; date() updatedAt!: Date; } Every entity gets a UUID `id` primary key. If you don't include it in your entity definition, Fabric will automatically add it. When records are inserted into your table, Fabric will generated a UUID server-side unless you supply your own. Composite keys and custom key names aren't supported. The full set of field decorators: `@uuid()`, `@text()`, `@int()`, `@decimal()`, `@boolean()`, `@date()`, `@email()`, and `@set()` for enumerated strings. Modifiers like `{ optional: true }`, `{ unique: true }`, `{ default: value }`, and `{ min, max }` add constraints to the columns. Note: The TypeScript `?` optional marker only affects the compile-time type. To actually make a database column nullable, you need `{ optional: true }` in the decorator itself. Relationships If your app has more than one table, use `@one()` and `@many()` to define relationships, and Fabric auto-generates the foreign key column for you following a `{property}_id` convention. One-to-many and many-to-one are supported; many-to-many is not, so model it with an explicit join table instead. Registering the schema Once every entity has been created, they then need to be added to `rayfin/data/schema.ts`: import { Todo } from './Todo.js'; export type TodoAppSchema = { Todo: Todo; }; export const schema = [Todo]; Applying schema changes Whenever you add or edit an entity: npx rayfin up db apply If a change would drop a column or rename a table, the CLI blocks it and warns you first. You can override with `--force`, but know that as soon as you add --force, you will be making a destructive change that cannot be undone. Warning: Using `--force` on a schema apply can cause data loss and cannot be undone. After being deployed, you are able to see the database in your workspace under the Fabric App. The SQL Database child item will allow you to access the Fabric SQL query editor where you can run SQL queries to read data. Don't change things in SQL here, as anything you change will be overwritten the next time you deploy the schema. Wrapping Up This post covers creating the sample app, deploying it, and how the database objects work. The full version, including how authentication (local email/password vs. Fabric SSO) and the front end (the RayfinClient data calls) work, is on the blog, linked below. Microsoft Learn references: Create your first Fabric app (https://learn.microsoft.com/en-us/fabric/apps/create-app) | Fabric Apps project structure (https://learn.microsoft.com/en-us/fabric/apps/project-structure) | Define data models for Fabric Apps (https://learn.microsoft.com/en-us/fabric/apps/data-models) | Deploy a Fabric app to Fabric (https://learn.microsoft.com/en-us/fabric/apps/deploy-app) Read more: Read the full post, including the Authentication and Front End sections, on the Fabric Field Notes blog: https://www.fabricfieldnotes.ca/blog/2026/08/18/an-introduction-to-fabric-appsThe Fabric Blueprint: Architecting Workspaces for Enterprise Success
This quick guide establishes the organizational standard for managing Microsoft Fabric within our enterprise environment. By adopting these patterns, we ensure security, maintainability and streamlined CI/CD deployments across all data projects.
Microsoft Fabric Apps: The Next Step in Data Application Development
At Microsoft Build 2026, Microsoft introduced Fabric Apps, a new way to build, deploy, and share data-driven web applications directly inside Microsoft Fabric. As someone who has been working with Fabric since its early days, I wanted to move beyond the announcement and build something real. Here is what I found.Why Microsoft Fabric Is Changing Modern Data Analytics
At first, I thought Microsoft Fabric was just another Microsoft product. But after learning more, I realized the real idea behind Fabric is much bigger: bringing Data Engineering, Analytics, Data Science, and Power BI together in one unified platform. That’s exactly what made me start creating Arabic content to simplify the learning journey for others.Moved Your Power BI Model to a New Fabric Workspace and It Broke? Here's Why, and the New Fix
If you've ever moved a Direct Lake semantic model to a new Fabric workspace and watched your report break with a confusing partition error, you're not alone it's one of the most common questions in the Fabric Community. Here's why it happens in plain terms, and the official fix Microsoft just shipped.Fabric SDD+AI Series (1/3) | Plan Better, Deliver More [PT/EN/ES]
🇧🇷PT: Começar no Microsoft Fabric pode ser intimidador, mas o segredo do sucesso não está apenas na ferramenta, e sim no planejamento. Descubra como o Spec Driven Development (SDD) transforma o GitHub Copilot em seu assistente mais preciso para projetos de BI. Esta é a Parte 1 de uma trilogia dedicada a tirar você do zero com segurança e IA. 🇺🇸EN: Starting with Microsoft Fabric can be daunting, but the secret to success isn't just the tool—it's the planning. Discover how Spec Driven Development (SDD) turns GitHub Copilot into your most precise assistant for BI projects. This is Part 1 of a trilogy dedicated to getting you from zero to hero safely with AI. 🇪🇸ES: Comenzar en Microsoft Fabric puede ser intimidante, pero el secreto del éxito no está solo en la herramienta, sino en la planificación. Descubra cómo el Spec Driven Development (SDD) transforma a GitHub Copilot en su asistente más preciso para proyectos de BI. Esta es la Parte 1 de una trilogía dedicada a llevarlo de cero a la meta con seguridad e IA.Overcoming Common Challenges in Microsoft Fabric: A Practical Guide
Facing issues with data integration, performance, or governance in Microsoft Fabric? This guide breaks down the most common challenges and offers practical, real-world solutions to help you get the most out of your Fabric environment.
From 48-Hour Delays to 3-Hour Refresh Cycles: Modernizing Asset Intelligence with Microsoft Fabric
In large restaurant chains, keeping tabs on thousands of assets equipment, inventory, purchase orders, and transfers across hundreds of locations is a significant operational challenge. When that data lives in disconnected systems, gets reported manually, and arrives 24–48 hours late, the business is always flying behind the windshield. This post walks through how we helped Restaurant Industry Company replace a fragile, manual reporting pipeline with a fully automated Microsoft Fabric Medallion Lakehouse architecture , reducing data latency from 48 hours to under 3, eliminating manual reporting effort, and laying the foundation for AI driven forecasting.
