Would You Let a Builder Start Without Plans? Why AI Needs a Spec Too

Picture this. You hire a builder to add a kitchen extension. He is quick, keen and cheerful, and he has never once asked to see the plans. By Friday there is a lovely new wall. By the following Friday there is a conservatory you didn’t ask for, a patio door where you wanted a window and a boiler big enough to heat a small hotel.

None of it is shoddy. Every part does exactly what it was built to do. It just isn’t what you agreed, and nobody can quite explain how it got there.

Now swap the builder for an AI assistant.

AI coding tools have made building data solutions very quick. A notebook, a pipeline or a Power BI semantic model that once took days can often be drafted in minutes, and some tools that plug into Microsoft Fabric will even set up the workspace items for you. That is useful, right up until you remember that, like our builder, the assistant does what it is told one instruction at a time, and then carries on building.

Here are the four things that go wrong on the building site, and the same four turn up in data projects.

The surprise conservatory. Each new instruction nudges the project a little further from the original brief. A table here, an extra calculation there, a dimension nobody asked for. Each addition is reasonable on its own. Together, you have built something other than what you agreed.

Three bricklayers, three methods. With no shared building standards, one session writes in PySpark and the next in pandas, the naming changes halfway up the walls and the same business rule is built twice in slightly different ways. Try handing that to a maintenance team.

“Move that wall back a bit.” When something is wrong, the natural reaction is to say so and ask again. Every round of corrections costs time and AI usage, and because the assistant is reacting to your last comment rather than the whole plan, a fix in one place can quietly undo something somewhere else.

The hotel-sized boiler. Built to work is not the same as built to fit. In Azure and Fabric that can mean more capacity than the job needs, full refreshes where a small top-up would do, or copies of the same data in several workspaces. It shows up on the bill, and in Fabric it draws on the same capacity as everything else your business runs.

Any decent builder works from plans, and the fix for data projects is the same. We call it specification-driven development, which is a grand name for a simple habit: write down what you are building before anyone, or anything, starts building it. The specification says what the solution must do, which data it uses, how each measure is calculated and how everyone will know it is finished.

A few other bits of the building trade turn out to be useful too.

One set of plans. If you have ever had two reports show different revenue for the same month, you know why a single source of truth matters. That is the idea behind OneLake, and the spec gives the build the same thing. No more requirements scattered across chat threads and half-remembered prompts.

A site diary. A decision log records every change to the plan and the reason for it. Six months on, when someone asks why the churn figure leaves out customers on trial plans, the answer is in the diary rather than in someone’s memory.

Drawings signed off before the bricks arrive. The assistant drafts a plan from the spec, and the team and the client review it while changing it costs nothing more than an edit.

A building inspector. Automation can propose changes, but a person checks and approves them before anything goes live.

If you would like the technical detail, including how a spec can sit in Git alongside your Fabric workspaces and trigger a reviewed code change whenever it is updated, we have written it up: Spec-Driven Development for Data & BI on Microsoft Fabric and Azure.

And if you want to talk about bringing AI into your Microsoft Fabric or Azure data work without losing control of scope, quality or cost, drop us a line at our enquiries page or join us on LinkedIn, where there is always up to date and relevant information about data and how we use it in real life. We promise to ask to see the plans first.