“Data warehouses will still exist. Humans just won’t build them anymore.”

​That was the claim. Slightly provoca tive, but grounded in a real question: how far can AI actually go today in building a data foundation from scratch?

This newsletter is about putting that claim to the test. I set myself a clear constraint: build a complete data warehouse for a real client without writing a single line of code. No shortcuts. No manual fixes.

Why does this matter? Because if this works, it changes how we build data foundations. It finally shifts effort away from implementation and toward thinking, structuring, and defining the right problems. This could compress months of work into days.

So let’s walk through what happened.

The setup: a familiar problem

The project was for a German SME going through digital transformation. A classic situation:

• Long company history
• New digital-native leadership
• Fragmented data landscape
• Heavy reliance on Excel and basic dashboards

They had some reporting in Google Analytics and Looker Studio, but no real data foundation.

Their goals were:

→ Improve customer lifetime value
→ Reduce customer acquisition cost
→ Make better marketing budget decisions

To do that, they needed something they didn’t have: a reliable, structured, and scalable data warehouse.

My role in these situations is usually hands-on. Over the past 10 years, I’ve built a productized approach for exactly this type of company. Typically, I do about 80% of the implementation myself.

This time around, one key constraint changed everything: no coding allowed!

The process: same framework, different execution

Even though the tooling changed, the core process stayed exactly the same compared to dozens of previous projects. That’s important.

Every project follows four stages:

1. Define the MVP (minimum viable product) data strategy
2. Build the foundation
3. Drive adoption and usage
4. Hire a successor for continuity

This experiment focused on stages one and two.

Step 1: Understanding the business deeply

I started where I always start: conversations.

I spoke with:

• CEO
• Heads of departments
• Head of IT

The goal wasn’t just to understand metrics. It was to understand business goals and initiatives to achieve those goals. Because initiatives define data needs.

In this case, everything pointed back to marketing performance.

From these discussions, I built a KPI dimension map. If you’re not f amiliar with it, think of it as a structured, one-page logical model that shows:

• Which KPIs matter
• Which dimensions they depend on
• Which combinations are required for the MVP
• What’s currently feasible

It’s inspired by the Kimball bus matrix, but adapted for my use case.

This step surfaced critical gaps. For example:

→ They wanted to link customer lifetime value to acquisition channels
→ But they weren’t tracking transaction IDs in web analytics

So before building anything, we defined what data needed to be captured going forward.

This step is non-negotiable. AI can build fast, but only if the inputs are precise.

The key shift: from coding to context engineering

Once the strategy and logic were clear, the real experiment began.

Instead of writing code, I focused on feeding the right context into Claude Code.

Here’s what I provided:

• A detailed layer logic document ( how each layer of the warehouse behaves)
• A full source catalog (all systems and their structure)
• KPI definitions derived from the KPI dimension map
• Naming conventions
• Testing and assertion standards (test-driven approach)
• CDC and preprocessing rules (e.g. time zones, currencies)
• Known issues and limitations
• Data mart designs (user-facing models)
• Object layer designs

None of this was new. These were all artifacts I’ve developed over years, combined with transcripts from stakeholder conversations.

The difference: instead of guiding humans, these documents guided an AI system.

Did it work?

Short answer: yes.

Long answer: yes, but not in the way you might expect.

It took about 55 hours in total. Roughly seven days.

But that number is misleading.

A large portion of that time went into:

• Learning how to structure Claude Code
• Learning how to use Dataform (I'm more used to dbt)
• Setting up the environment
• Solving integration issues
• Designing the right system of inputs

The actual build time? Around four days.

Let’s break that down.

The build phase: where things got interesting

At the start, I intentionally slowed things down.

For the first 2.5 days:

→ Claude generated Dataform models
→ I manually ran them
→ I fed results back into the system manually

This helped me understand exactly what was happening.

There were also technical hurdles. For example, connecting Claude Code properly to BigQuery and Dataform took some time.

But once that was solved, things accelerated quickly.

In the final 1.5 days, the system ran almost fully autonomously:

• It created tests first
• Then built models
• Then ran a logic-check sub-agent
• Then compiled, executed, and deployed

One particularly useful component was a dedicated “logic check agent” that iteratively reviewed every model for inconsistencies and communicated with the parent agent to resolve them.

That layer of validation made a big difference.

The result: faster than expected

By the end:

• 213 DataForm models were created
• All included tests and assertions
• 7 data sources were integrated:
• 4 Internal MySQL databases
• Google Ads
• Microsoft Ads
• Google Analytics

And again, no code was written manually.

Not even any text, really. Most of the input was dictated using voice while having conversations with stakeholders and walking on an under-desk treadmill.

What actually matters (the real learnings)

The headline is not “AI builds data warehouses.”

The real takeaway is more nuanced.

1. The bottleneck is no longer coding

The hardest part was not building models.

It was:

• Structuring the problem
• Defining clear logic
• Creating high-quality input documents

If those are weak, the system fails.

2. Your frameworks become your leverage

Everything I used already existed:

• KPI dimension maps
• Naming conventions
• Testing standards
• Layer definitions

AI didn’t replace these. It amplified them.

If you don’t have these assets, you won’t get the same results.

3. Test-driven development is essential

One of the most powerful patterns was:

→ Define tests first
→ Generate models second
→ Validate automatically

This reduced errors significantly and made autonomous execution viable.

4. Iteration beats perfection

The manual phase at the beginning was not wasted time.

It helped:

• Debug the system
• Build trust in the outputs
• Refine instructions

Skipping that step would likely have caused bigger issues later.

5. Speed will increase dramatically

This first run took four days of build time.

I’m confident this can be reduced to one day.

Not by working faster, but by:

• Reusing the setup
• Improving inputs
• Removing initial friction

What this means for data teams

This doesn’t eliminate the need for data professionals.

But it changes their role.

Less time spent on:

• Writing transformations
• Debugging pipelines
• Connecting tools

More time spent on:

• Understanding the business
• Defining metrics
• Designing systems
• Ensuring adoption

In short: from builders to architects.

Bottom line

Building a data warehouse without writing code is no longer a thought experiment. It works.

But the value doesn’t come from the automation itself. It comes from how well you define the problem.

If you want to apply this:

→ Invest in clear data models before touching tools
→ Document your logic rigorously
→ Standardize naming, testing, and structure
→ Start small and iterate

The companies that win won’t be the ones with the best tools or the best code.

They’ll be the ones with the clearest thinking.

Cheers,

Sebastian