Vibe Coding Forem: Niclas Olofsson

TDD for dbt: unit testing the way it should be

Niclas Olofsson — Wed, 07 Jan 2026 00:00:53 +0000

Unit testing arrived in dbt 1.8. Finally, right? Except nobody does it.

About this article
I wrote this. The ideas are mine; the execution is collaborative.

Write tests with mock data, verify your business logic, practice TDD like any proper software engineer. That's what dbt 1.8 promised. Except nobody does it.

And I get it. I tried. You sit down with good intentions, open a new YAML file, and then reality hits. You need to figure out which models your test depends on. Query the warehouse to get realistic sample data. Format everything as YAML dictionaries with the right structure. Then do it again for every edge case you want to cover. Then maintain all of it as your models evolve.

That's not TDD. That's YAML accounting.

So the feature sits there, unused. Which creates two problems that feed into each other.

First, TDD stays theoretical. The boilerplate overhead kills any chance of test-first development. You write the model, then maybe add tests later if you have time. You don't.

Second, and this is the one that hit me harder, your AI collaboration suffers. Without tests, there's no verification mechanism. You ask Copilot to implement something, it generates code, and now you're stuck manually checking if the logic is right. Query the warehouse, eyeball the results, spot the bug, explain it, wait for the fix, check again. Your flow state is gone. You're babysitting syntax instead of thinking about the problem.

But here's what I discovered building dbt-core-mcp: when AI can handle the tedious parts, unit tests stop being a burden and start being a dialogue. The same tooling that lets AI scaffold YAML fixtures also lets AI iterate with test guardrails. Write test, run test, fix code, run test. That loop can happen without you leaving navigation mode.

The refactoring problem

Software developers figured this out decades ago. Martin Fowler documented it extensively: you can't maintain quality code without refactoring. And you can't refactor with confidence unless you have tests.

You write code. It works. Six months later, requirements change or you understand the domain better or the model becomes too complex. You need to restructure it. Simplify the logic. Optimize the queries. Make it maintainable again.

Without tests, refactoring is terrifying. Change the SQL, run the full pipeline, manually verify the output matches what it used to produce. Hope you didn't break something subtle. That fear keeps you from refactoring, so the code rots. Technical debt compounds.

With tests, refactoring is mechanical. Change the implementation, run the tests, they pass, you're done. The tests document what the model should do. As long as the behavior stays consistent, the implementation can evolve.

And here's what happens once you get used to it: you start finding the rhythm. Maybe you write tests after the fact at first, adding coverage to legacy models as you touch them. But eventually, you notice it's easier to write the test first. Define the edge case, write the test, then implement the logic that makes it pass. That's TDD. Test-driven development.

Analytics engineering could have had this all along. The capability was there in dbt 1.8. But the YAML accounting killed adoption before it started. Writing fixtures by hand, sampling data, formatting dictionaries, it was too much friction.

AI removes that barrier. The tedious parts get automated. Suddenly TDD isn't theoretical anymore. It's practical. And that changes everything.

When bugs happen

Software developers learned another pattern: when something breaks, you don't just fix it. You write a failing test first.

The workflow: a bug gets reported. Customers with exactly one order are showing null for first_order_date. Before touching the code, you write a test that reproduces the problem. One customer, one order, assert the date should match. Run it. It fails. Good - now you've proven you understand the bug.

Then you fix the code. Maybe you forgot to handle the single-record case in your aggregation. Add the logic, run the test, it passes, ship it.

But here's the real value: that test stays. Forever. It's not just a bug fix anymore, it's documentation. Six months from now when someone refactors that model, the test will catch it if they reintroduce the same bug. The test is evidence that this edge case matters, that it broke before, and here's exactly what the correct behavior should be.

Without tests, bug fixes are "I think I fixed it, seems to work now, hope it doesn't come back." With tests, bug fixes are "Here's the test that proves it was broken, here's the test passing that proves it's fixed, and here's the permanent guard against regression."

And yes, AI can help here too. "Write a test that reproduces the bug where customers with one order get null dates." Copilot scaffolds the failing test, you verify it actually fails for the right reason, then ask AI to fix it. Or fix it yourself. Either way, the test documents the fix.

What this actually looks like

Without tests: I ask Copilot to add customer order counts. It generates code. Now what? I need to verify it works. Maybe I run the model and query the output in Databricks. Maybe I just spot-check a few rows. Maybe I trust it and ship it. Whatever I do, it's manual and ad-hoc. No systematic verification. And when I notice it returns null for customers with no orders, we're back to the same cycle: point it out, wait for fix, check again. Context switching. Flow broken. Hope it's right this time.

And let's be honest: "without tests" is today's default.

With tests: I say "Add customer order count, zero for customers with no orders, not null." Copilot inspects the model dependencies through dbt-core-mcp, samples some data, writes a unit test for the edge case, implements the model, runs the test, fails, fixes the coalesce, runs again, passes, and tells me "Test passing, ready for review."

I review the test assertion and the implementation together. One cycle. I never left the conversation.

The trick isn't that AI writes better code. It's that AI can now verify its own work systematically before reporting back. Tests become the feedback mechanism that keeps the loop tight.

The anatomy of a dbt unit test

A dbt unit test looks like this:

unit_tests:
  - name: test_customer_with_no_orders
    description: "Verify customer with no orders gets 0 count, not null"
    model: customers
    given:
      - input: ref('stg_customers')
        rows:
          - {customer_id: 99, first_name: 'New', last_name: 'Customer'}

      - input: ref('stg_orders')
        rows: []

    expect:
      rows:
        - {customer_id: 99, number_of_orders: 0}

You tell it what model you're testing, what input data to use (the given section), and what output to expect. The test runs against mock data, not your warehouse. Fast. Isolated. Repeatable.

The pain is in given. Every input needs realistic fixtures. Every column that matters needs a value. Every edge case needs its own setup. That's where the YAML accounting happens, and that's exactly what AI is good at generating.

How dbt-core-mcp makes this work

The MCP server gives AI the tools it needs to scaffold tests intelligently. You don't see these tool calls in the chat - this is what happens under the surface while Copilot is working. When I ask Copilot to write a test, it can:

Choose to inspect the model to understand dependencies:

get_resource_info('customers')
→ Shows: depends on ref('stg_customers'), ref('stg_orders')

Choose to query sample data to get realistic fixtures:

query_database("SELECT * FROM stg_customers LIMIT 3")
→ Returns actual column structure and example values

Choose to run specific tests for fast iteration:

run_tests(select="test_name:test_customer_with_no_orders")
→ Immediate feedback on just that test

It chooses which tools to use based on what it needs. Building a test from scratch? Inspect the model and query sample data. Adding a test to an existing file? It'll likely read your existing tests first and follow the same style and patterns your team already uses. The fixture format you prefer, the naming conventions, the level of detail - AI adapts.

AI uses these to build tests that actually make sense for your data. Not generic placeholder values, but fixtures that reflect your schema. And it can iterate on them without waiting for full pipeline runs.

Where to put the tests

dbt's official recommendation is to keep unit tests alongside your models. Same directory, same context. It's a reasonable approach - everything related to a model lives together.

I prefer something different:

dbt_project/
├── models/
│   └── marts/
│       └── customers.sql
│
└── unit_tests/
    └── marts/
        └── customers_unit_tests.yml

Separate directory that mirrors the model structure. Clean separation between code and tests. Easy to find. Easy to exclude from production builds if needed. Easy to navigate.

This is how the rest of the software development world does it. Python projects have src/ and tests/. Java has src/main and src/test. C# has separate test projects. Separating tests from implementation code is established practice everywhere outside data engineering.

If you go this route, you'll need to tell dbt where to find your tests. Add this to your dbt_project.yml:

model-paths: ["models", "unit_tests"]

Is this controversial in the dbt community? Maybe. But let's be honest - how controversial can it be when nobody's writing unit tests anyway?

Choose what works for your team. The structure matters less than actually having the tests.

The patterns that matter

Once you start writing tests (or having AI write them), some patterns emerge that make the difference between maintainable tests and a YAML nightmare.

Keep fixtures minimal

It's tempting to dump all the columns into your test fixtures. Don't. Only include what the test actually needs.

# This is noise
- {customer_id: 1, first_name: 'Alice', last_name: 'Smith', 
   email: 'alice@example.com', phone: '555-1234', 
   address: '123 Main St', city: 'Portland', ...}

# This is a test
- {customer_id: 1, first_name: 'Alice', last_name: 'Smith'}

Minimal fixtures are faster to read, make it obvious what's being tested, and don't break when you add columns to your staging models. AI tends to over-include columns when it first scaffolds, so this is worth reviewing.

One behavior per test

Each test should prove one thing. If your test name needs "and" in it, split it.

unit_tests:
  - name: test_customer_with_no_orders
    # Proves: null handling works

  - name: test_customer_with_single_order
    # Proves: min = max when one record

  - name: test_customer_order_aggregation
    # Proves: count, min, max all work together

Three small tests beat one comprehensive test. They run faster, fail clearer, and document behavior better.

If multiple tests need the same base data, use YAML anchors to share fixtures (covered in the YAML anchors section below).

Happy path, then edge cases

When writing tests, start with the normal case. How should the model work when everything is straightforward? Customer has orders, all fields present, typical data.

- name: test_customer_order_aggregation
  # The normal case: customer with multiple orders

That establishes the baseline. Then add the edge cases - the scenarios where things can break:

- name: test_customer_with_no_orders
  # Edge case: empty join result

- name: test_customer_with_single_order
  # Edge case: min = max

This is the natural TDD rhythm. Happy path first proves the core logic works. Edge cases prove it handles the boundaries correctly. Both matter, but the happy path gives you the foundation.

The essential edge cases for most models:

Empty inputs (what if there are no orders?)
Single item (what if exactly one record?)
Null handling (what if optional fields are missing?)
Boundary conditions (first order = last order?)

Use dict format, not CSV

dbt supports CSV format for fixtures. Ignore it.

# This will hurt you later
format: csv
rows: |
  customer_id,first_name,last_name
  1,Alice,Smith
  2,Bob,Jones

# This is what you want
rows:
  - {customer_id: 1, first_name: 'Alice', last_name: 'Smith'}
  - {customer_id: 2, first_name: 'Bob', last_name: 'Jones'}

Dict format doesn't care about column order. It survives adding columns. It produces readable git diffs. It's the default for a reason.

YAML anchors for shared fixtures

Once you have several tests for a model, you'll notice duplicate fixtures. Three tests that all need the same base customer data. YAML anchors can help, but use them sparingly.

# Define once at the top
_base_customers: &customer_input
  input: ref('stg_customers')
  rows:
    - {customer_id: 1, first_name: 'Alice', last_name: 'Smith'}
    - {customer_id: 2, first_name: 'Bob', last_name: 'Jones'}

unit_tests:
  - name: test_basic_aggregation
    model: customers
    given:
      - *customer_input      # Reuse the whole thing
      - input: ref('stg_orders')
        rows: [...]

Rule of thumb: only use anchors when three or more tests share identical fixtures. Before that, the duplication is clearer than the abstraction.

Here's the thing about DRY (Don't Repeat Yourself) in tests: it's not always best practice. Shared fixtures can create coupling in your test code. Change one fixture to handle a new test case, suddenly three other tests break. You're refactoring tests to fix tests, not production code.

Sometimes duplication in tests is better. Each test is self-contained. You can read it without jumping between anchor definitions. You can change it without worrying about breaking other tests. More code can mean less coupling. Use anchors when the duplication is truly painful, not just because DRY says so.

A complete cycle

I'm building a customers model that aggregates order data. I want order counts, first order date, most recent order date. And I want customers with no orders to show zero, not null.

I tell Copilot: "Create a customers model that counts orders per customer. Zero for customers with no orders, not null."

Copilot gets to work. It inspects the likely dependencies (stg_customers, stg_orders), queries sample data to understand the schema, and scaffolds the first test:

unit_tests:
  - name: test_customer_with_no_orders
    description: "Verify customer with no orders gets 0 count, not null"
    model: customers
    given:
      - input: ref('stg_customers')
        rows:
          - {customer_id: 99, first_name: 'New', last_name: 'Customer'}

      - input: ref('stg_orders')
        rows: []

    expect:
      rows:
        - {customer_id: 99, first_name: 'New', last_name: 'Customer', 
           number_of_orders: 0}

Then implements the model:

with customers as (
    select * from {{ ref('stg_customers') }}
),

orders as (
    select * from {{ ref('stg_orders') }}
),

customer_orders as (
    select
        customer_id,
        count(order_id) as number_of_orders
    from orders
    group by customer_id
),

final as (
    select
        customers.customer_id,
        customers.first_name,
        customers.last_name,
        coalesce(customer_orders.number_of_orders, 0) as number_of_orders
    from customers
    left join customer_orders 
        on customers.customer_id = customer_orders.customer_id
)

select * from final

Runs the test. Passes. Reports back.

I look at the test assertion. Does it match what I asked for? Zero instead of null? Yes. I look at the implementation. Left join, coalesce, makes sense. I approve.

Now I can say "Add first and most recent order dates" and Copilot will add another test, extend the model, verify it passes, and report back. Same cycle, building on verified work.

I never had to open the warehouse. Never had to manually check output. Never had to write YAML fixture syntax. I stayed in the conversation, thinking about what the model should do, not how to verify it.

Test what needs to be tested

Software developers learned this decades ago: you don't unit test getters and setters. You test the logic that can break. The transformations. The edge cases. The parts where bugs hide.

The same applies to dbt models.

Test the happy path first - the normal case where everything works as expected. Customer has orders, all fields present, typical data. This is your baseline. It proves the core logic works. Always test this. And here's the kicker: when things break during refactoring or changes, it's usually the happy path test that catches it first, not the edge cases.

Test aggregations - count, min/max, group by. This is where null handling breaks. Where empty groups return unexpected results. Where your left join suddenly drops customers because you forgot the coalesce. These transformations have logic, and logic needs verification.

Test business logic - calculations, case statements, conditional logic. If you're implementing "customer lifetime value" or "revenue recognition rules" or any domain logic that came from a business requirement, test it. These are the models that change when requirements change. Tests document what the business actually wanted.

Test edge cases - nulls, empty sets, boundary conditions. The customer with no orders. The single transaction that's both first and last. The optional field that's missing. Production data will hit all of these eventually. Better to define the behavior now than debug it later.

Test critical models - finance, customer-facing, regulatory. If it goes in a report that executives read or customers see or auditors review, test it. The cost of being wrong is too high.

Test what you'll refactor - anything you know you'll change later. Tests are your safety net. You can restructure the SQL, optimize the joins, rework the CTEs, and know immediately if you broke the behavior.

Don't test pass-throughs - simple select-star models, basic renaming, casting. These are mechanical transformations with no logic. If they break, the downstream tests will catch it.

My rule: if the model has group by, case when, or coalesce, it probably deserves a test. That's where the logic lives.

The meta shift

Here's what surprised me most: the same patterns that make AI better at writing tests also make me better at reviewing them. When Copilot scaffolds a test, I'm not fighting YAML syntax. I'm not sampling data. I'm looking at the assertion and asking: does this capture what I meant? Is this the edge case that matters? Is the expected output correct?

That's a different kind of work. Navigation and judgment instead of execution. I'm thinking about behavior, not formatting. And because the tests exist, I can refactor safely. Change the implementation, run the tests, know immediately if I broke something. That confidence compounds. You build faster when you're not afraid of breaking things.

Getting started

You need dbt 1.8 or higher for unit testing support. For dbt-core-mcp, you'll need dbt 1.9 or higher. Setup instructions are at github.com/NiclasOlofsson/dbt-core-mcp.

Start small. Pick your most complex model, the one with the group by and the edge cases you're always nervous about. Ask AI to write one unit test for one edge case. Review it. Run it. See how it feels. Then notice how your next conversation changes. You're not debugging syntax anymore. You're having a dialogue about what the model should do. AI verifies its own work. You stay in flow.

That's the shift. Unit testing was always possible in dbt. AI makes it practical. And practical changes everything.

Get dbt-core-mcp: github.com/NiclasOlofsson/dbt-core-mcp

Copy-paste is not a workflow: building dbt-core-mcp

Niclas Olofsson — Mon, 05 Jan 2026 22:51:32 +0000

Three tools. Three windows. Clipboard gymnastics for breakfast, lunch, and dinner. I snapped and built something that actually works.

About this article
I wrote this. The ideas are mine; the execution is collaborative.

I write SQL transformations for a living. Medallion architecture, source to final data product, the whole pipeline. It's what data engineers do. And if you do it professionally, the SQL gets complex fast. CTEs stacked on CTEs, proper structure, because the alternative is unmaintainable spaghetti that no one can debug six months later.

Here's the problem: I can't actually develop those transformations in VS Code.

The tooling is primitive. SQL syntax highlighting barely works. Mix in Jinja (which we have to do for dbt) and it falls apart completely. Command completion? Forget it. Compared to what a C# or Python developer has at their fingertips, SQL in an IDE feels like we're still in 2005. dbt Fusion promises a better future, but we're not there yet.

So I develop transformations in a SQL editor. Databricks in my case. That's where I can actually run queries, test CTEs, see results, iterate. I write the transformation there until it works, then I copy it back to my dbt model file in VS Code and manually re-add all the dbt syntax: the ref() calls, the source() references, the Jinja. Hope I didn't break something in translation. Test it with dbt run. Find out I broke something. Repeat.

I'm developing in two places at once, manually translating between them.

And that's before AI enters the picture. Copilot is actually really good at SQL. It understands dbt syntax, helps review transformations, suggests improvements. So naturally I use it. Which means now I'm shuttling context between three places: VS Code for the model file, my SQL editor for testing, and Copilot for help. Copy this, paste that, translate back, repeat.

It's exhausting. And it's slow.

Why every existing tool is wrong

Let's talk about your options if you want AI help with dbt in VS Code. Spoiler: they all suck in different ways.

Power User for dbt? 388,000 installs, impressive feature list, but the AI parts need an Altimate API key. Which means your schema, your SQL, your metadata—all living on their servers. Datamates says "local-first" in the marketing but funny story: you still need an account at their SaaS platform and they still upload your "metadata" (schema, SQL, task summaries). Turns out "local-first" has a flexible definition.

And Power User itself has its own environmental issues—tries to install its own dbt environment that conflicts with yours, doesn't respect your adapter setup. Not great when you're already juggling version compatibility.

Here's the thing that drives me insane: they don't actually need your data on their servers. This isn't a technical requirement. It's an architecture decision. They built everything around their SaaS platform because that's their business model. Meanwhile, GitHub Copilot already has my code in the editor. There's zero technical reason another vendor needs my proprietary schemas living on their infrastructure.

The official dbt extension from dbt Labs? Actually looks promising—proper IntelliSense and everything. But it needs Fusion, which is still in beta and not production-ready. So that's future, not now.

And here's the kicker: none of them solve the actual problem. I'm still writing transformations in Databricks, then copy-pasting back to VS Code and manually re-adding all the dbt syntax. The tools just gave me a fourth window to juggle.

What should have been obvious

Here's what I'm not willing to compromise on (and frankly, shouldn't have to):

No copy-paste. That's the core requirement. I shouldn't be developing a transformation in one tool and copying it to another. I shouldn't be copying SQL to test it, or copying results back for analysis. Copy-paste means I'm manually shuttling information between disconnected tools. That's not a workflow—that's duct tape.

Syntax highlighting that actually works. SQL mixed with Jinja shouldn't break the editor. I need to see the structure of my queries—CTEs, joins, subqueries—at a glance. This is baseline functionality that's been standard in IDEs for decades.

IntelliSense for dbt. When I type ref(', I should see a list of available models. When I reference a column, the editor should know if it exists. When I change a model's schema, the editor should tell me what breaks downstream. This is how C# developers have worked since Visual Studio existed. There's no reason dbt can't have the same.

Integrated documentation. When I'm using a dbt function, adapter-specific syntax, or just need to remember how window functions work in SQL—I shouldn't have to context-switch to a browser. Whether it's Databricks SQL functions or standard SQL syntax, the IDE should show me what I need, when I need it.

One place to develop. I should be able to write a transformation and test it in the same environment. Not develop in Databricks, then copy it to VS Code and manually re-add all the dbt syntax. The iteration loop—write, test, refine—should happen in one place.

My data stays mine. I work with proprietary business logic. Schema definitions that represent months of modeling decisions. Transformations that encode competitive advantages. None of that belongs on a third-party vendor's servers just because they built their architecture around cloud uploads. A proper IDE works with my code locally.

Use what I already have. I have dbt installed. I have adapters configured. I have virtual environments. Whatever IDE tooling I use should work with my setup, not force me to maintain a parallel dbt installation with different versions and configurations.

These aren't luxury features. This is the foundation of software development that's existed for 30 years. dbt work deserves the same.

Then help arrived (thank god)

Those fundamentals I just listed? Syntax highlighting, IntelliSense, integrated docs—that's table stakes. The baseline we've had for decades in other languages. dbt is finally getting there with Fusion.

But here's what nobody saw coming:

AI assistance. Not the "autocomplete on steroids" kind. The "I understand what you're trying to do and can actually help you do it" kind. A pair programmer who doesn't get tired, doesn't need coffee breaks, and has instant access to documentation you'd spend 20 minutes searching for.

And here's the thing: it changes what we need from the IDE. I still need syntax highlighting and IntelliSense—I'm responsible for the code, I need to review it, own it, understand it. But the workflow shifts. The conversation becomes the anchor. I work through talking to the AI. The AI works with the IDE.

When it works right, you forget you're even working with AI—it just feels like the IDE finally understands what you're doing.

But there's a problem. My shiny new AI colleague can read my code. Suggest improvements. Write SQL. But when it comes to dbt? It's useless. Can't run anything. Can't query models. Can't check dependencies. It's stuck giving advice and waiting for me to be its hands. "You should run dbt list to see what's affected." Thanks, Copilot. Really helpful. Let me just switch to my terminal again.

So the AI can see everything but do nothing. It's a consultant, not a coworker.

That's the gap. And that's what I fixed.

What it actually looks like when it works

I'm troubleshooting a complex transformation. Medallion architecture, bronze through gold. The final mart model has twelve CTEs stacked on each other, and somewhere in that stack the numbers are wrong. I ask Copilot, "Test the intermediate aggregation CTE, just that fragment." It extracts that CTE and all its dependencies (just what's needed, nothing more) and executes it against the warehouse, shows me the results. The bug is in the join logic. I fix it. "Test it again." It does. Numbers look right now.

The conversation becomes the workflow—query execution, analysis, and iteration all in one place.

I need to add a new field to a mart. That means tracing it back through silver, all the way to bronze, potentially adding a new source table we haven't ingested yet. I tell Copilot what I need. It helps me locate the data—we have hundreds of models, complex ERP structures with thousands of tables. It knows the ERP documentation. It suggests which source table to pull from. It helps me add the field through each layer, following whatever style that layer uses. We have legacy code. Different patterns in different areas. It adapts. The edits are almost flawless.

When I'm working with unfamiliar data (and in an ERP system, most data is unfamiliar), Copilot can query using ref() and source() syntax. It can use our macros. It understands the structure. It helps me discover what's actually in these tables, analyze it, figure out if it's what I need. It's like having a colleague who's already memorized the entire data warehouse.

I'm validating a new transformation. "Analyze the quality of this output." It runs the standard aggregations we always do as data engineers. Checks distributions. Finds nulls where there shouldn't be any. Traces the issue back to the source. Suggests fixes.

The model works, but it's slow. "How can we optimize this?" It reviews the SQL, suggests simplifications. Then it actually tests them. Runs the original. Runs the optimized version. Extracts query plans from both. Compares execution times. Shows me which approach is faster and why. It's not just advice—it's empirical.

All of this happens in the conversation. Copilot executes. I review. I decide. I own the code.

This is what I meant by "no copy-paste." Not just avoiding clipboard gymnastics, but eliminating the entire pattern of manually shuttling context between disconnected tools. The AI has the powers it needs to actually help me work. Run models. Query results. Check dependencies. Understand impact. Analyze data. Trace issues.

And here's the part that should go without saying but apparently doesn't: all of this happens locally. dbt-core-mcp calls my dbt CLI. Uses my warehouse connection. Reads my manifest. Copilot sees the results, but my schema and data never leave my environment. No API keys to third-party vendors. No accounts. No uploads. No "metadata" living on someone else's servers.

Just my tools. Doing the work they're supposed to do.

This is flow development. The IDE understands dbt. The AI can execute, not just advise. I state intent, it handles mechanics. The conversation is the workflow.

It is my code. I supervise. I decide. I own it. But I'm not doing the AI's legs anymore. And the AI isn't stuck waiting for me to be its hands.

Get started

NiclasOlofsson / dbt-core-mcp

dbt Core MCP Server: Interact with dbt projects via Model Context Protocol

dbt Core MCP Server

Meet your new dbt pair programmer - the one who actually understands your environment, respects your workflow, and does the heavy lifting.

Why This Changes Everything

If you've tried other dbt tools with Copilot (dbt power user, datamate, etc.), you know the pain:

They don't respect your Python environment
They can't see your actual project structure
They fail when adapters are missing from THEIR environment
You end up doing the work yourself anyway

dbt-core-mcp is different. It's not just another plugin - it's a true pair programming partner that:

Zero dbt Dependencies: Our server needs NO dbt-core, NO adapters - works with YOUR environment
Stays in Flow: Keep the conversation going with Copilot while it handles dbt commands, runs tests, and analyzes impact
Respects Your Environment: Detects and uses YOUR exact dbt version, YOUR adapter, YOUR Python setup (uv, poetry, venv, conda)
Actually…

View on GitHub

MIT licensed. Works with your existing dbt installation. Click the install buttons in the repo, point it at your dbt project, and you're running. No accounts. No uploads. Just dbt, but now your AI can actually help you use it.

🚀 I shipped 47 features in ONE WEEK with Claude and it was INSANE 🔥

Niclas Olofsson — Mon, 05 Jan 2026 13:50:53 +0000

(Spoiler: Not the kind of insane you're thinking.)

About this article
I wrote this. Claude DoubleDash 4.5 added the em dashes—apparently that's how it marks its territory. The ideas are mine; the punctuation is suspiciously well-placed.

I did it. I went FULL VIBE MODE for a week. 🚀🚀🚀 Let Claude COOK. Shipped EVERYTHING. Didn't read most of it. Just vibes, baby. ✨ 47 features. Seven days. UNSTOPPABLE. 🔥💯

I was literally mass-producing features while SLEEPING. The AI was doing all the work. I just kept hitting "Accept All Changes" like a BOSS. 😤

Then came day 8.

Something broke. I don't know what. I don't know why. I definitely don't know how to fix it. Because I didn't write it. I didn't review it. I didn't understand it. I just shipped it. And now I'm staring at 4,000 lines of code that might as well be ancient Sanskrit, trying to figure out which of my 47 glorious features killed production.

This got me thinking about something nobody in this community seems to want to talk about.

Who maintains this?

Not the demo. Not the tweet. Not the "SHIPPED 🚀" post. I mean the actual code. The living, breathing, eventually-breaking code. Six months from now, when you've forgotten what half of it does. When Claude's context window doesn't include the decisions you never made because you weren't really there when they happened.

Who fixes it at 3 AM when it breaks? Who explains it to the new hire? Who owns it?

"But I shipped 47 features!" Did you though? Or did Claude ship 47 things while you watched? Because if you can't explain it, you didn't ship it. You just received it. Like a package from a contractor who doesn't work here anymore and left no documentation.

I scroll through this community and I see the success posts. The rocket emojis. The celebration threads. What I never see is the follow-up.

"My Claude app is in production, 6 months later"—where are these posts? "How I debug code I didn't write"—where's this guide? "The feature I shipped last month just caused an incident"—why isn't anyone talking about this?

I'll tell you why. Those posts don't get engagement. They don't get sponsorships. They don't fit the narrative we've all agreed to perform.

The vibe coding pitch is seductive: Ship faster. Think less. Let the AI handle it.

The unspoken second half is: ...and someone else will deal with the consequences.

But who's "someone else"? If you're a solo founder, it's future you—good luck with that. If you're on a team, it's your colleagues, the ones who have to maintain your vibes long after the dopamine of shipping has faded. If you're a junior hoping this approach will make you competitive, it's the senior who eventually has to explain why your "shipped" feature doesn't actually work.

The bill always comes due. We're just not talking about who pays it.

Look, I'm not saying AI is bad. I use it every day. Genuinely. It's transformed how I work.

But I read what it produces. I understand before I commit. I make sure I can explain every decision—because the moment I merge that code, those decisions are mine. I'm accountable for them. Not Claude. Not the vibes. Me.

That's the difference between using AI and being used by it.

So here's my question for this community—a real question, not a rhetorical one:

What happens when the vibes stop working?

Not if. When. Because they will.

Who's accountable then?

I shipped 47 features last week. I own exactly zero of them.

That's not insane. That's just sad.

Vibe factory: insanity, scaled

Niclas Olofsson — Mon, 05 Jan 2026 10:57:23 +0000

"Insanity is doing the same thing over and over expecting different results."

Someone put that in a for-loop and is selling it to you on YouTube right now.

About this article
I wrote this. The ideas are mine; the execution is collaborative.

I'm tired. And I'm pissed off.

(Fair warning: this is my first article and it doesn't come with nice sections and headers. Apologies. A rant doesn't come with a table of contents.)

I'm tired of watching influencers (people who've never shipped anything that mattered) torch this industry for clicks. I'm tired of the rocket emojis and the "🔥 SHIPPED IN 2 HOURS 🔥" threads that conveniently skip the part where the code is unmaintainable garbage. I'm tired of sponsored content dressed up as revelation.

And I'm especially tired of watching developers (good developers, junior developers, developers who deserve better) drink this poison because some YouTuber with a shocked face thumbnail told them this is how real engineers work now.

It's not. It's a grift. And it's happening so fast we might not have an industry left by the time people figure it out.

If you've been watching this unfold and feeling like you're taking crazy pills—you're not crazy. You're just paying attention.

Here's how it works. Pay attention, there might be a quiz later. (Just kidding. There are no quizzes in vibe coding. There's no accountability at all. That's the whole point.)

Someone builds a wrapper around Claude that keeps generating code until... actually, until what? Until it compiles? Until it looks right? Until the demo video has enough green text scrolling by to seem impressive?

Nobody knows. Nobody cares. That's not the point.

The point is the content. The thread. The video. The "Claude built me a full ERP system while I slept and it's INCREDIBLE 🚀" flex. They don't show you the code—obviously. They don't show you it working a week later—because it isn't. They definitely don't show you tests—because lol, tests. There's just vibes. Ship it, record it, post it, collect the check, move on.

The sponsors line up. The algorithm rewards engagement. More developers watch. More developers try it. More developers produce code that might do something (they're not entirely sure what, but it's deployed, baby!)

And the influencer? Already onto the next grift. They don't maintain what they shipped. They don't deal with the consequences. They never intended to.

You're left holding the bag. But hey, at least you got a like.

Let's be really clear about what a "vibe factory" actually is.

It's automated insanity.

The famous definition: doing the same thing over and over expecting different results. That's literally the algorithm. Generate code. Doesn't look right. Generate again. Still wrong. Generate again. Keep going until... something happens. Something that looks good enough for a screenshot.

They put the insanity in a bash script and called it innovation. Genius, really. Why experience personal growth when you can just while true your way to success?

"But it works!"

Does it? How would you know? Did you test it? Did you read it? Or did you just see it run once without an error message and decide that was good enough?

You're not engineering. You're not even debugging. You're pulling a slot machine lever and calling whatever comes out "shipped."

Vegas thanks you for your service.

Here's what keeps me up at night. Besides the coffee. And the existential dread. But mostly this:

There's a generation of developers coming up right now who think this is normal. Who think software engineering means writing prompts and waiting. Who've never debugged something they didn't understand—because they've never understood anything they've shipped.

But that's not even the worst part.

The worst part is the experienced developers. The ones with fifteen years of hard-won intuition. The ones who actually know how to architect systems, debug production issues, make real technical decisions. The ones who could benefit massively from AI assistance—because when you multiply experience by AI capability, you get something genuinely powerful.

They're watching these vibe factory demos and thinking: "So this is what AI coding is? This reckless, unthinking, ship-and-pray nonsense? Fuck that."

And they walk away.

Can you blame them? I can't. If this circus was my first introduction to AI-assisted development, I'd run too.

The influencers aren't just misleading juniors. They're poisoning the well for everyone. They're making "AI-assisted development" synonymous with "irresponsible hacking" in the minds of exactly the people who would use it best.

We're not just creating a generation of developers who can't develop. We're alienating a generation of developers who can, turning them away from tools that would make them even better, because the loudest voices have convinced them those tools are for fools.

That's the real destruction. The juniors will eventually learn (the hard way, probably at 3 AM, definitely in production). But the seniors who never engage? That expertise, multiplied by AI, creating genuinely excellent software? We lose that forever.

The influencers get paid either way. Funny how that works.

Follow the money. Always follow the money. (My therapist says I have trust issues. I call it pattern recognition.)

Who benefits from convincing you that thinking is optional? That understanding is a bottleneck? That the fastest path is to let the machine handle it while you move on to the next prompt?

Tool vendors benefit. More API calls. More subscription revenue. More "enterprise" deals with companies who've decided that AI means they can hire fewer seniors and more juniors who'll push the "accept all" button. What could go wrong? (Everything. Everything could go wrong.)

Influencers benefit. Sensational content performs. "I think carefully about code" doesn't get clicks. "I SHIPPED 47 APPS THIS WEEK WITH THIS ONE WEIRD TRICK" does. The trick is not caring about quality. Saves tons of time.

The actual craft of software engineering? That's the cost center. That's what's getting optimized away. Not because it's inefficient—because it's inconvenient for the business model.

If you've ever wondered why the loudest voices are saying the dumbest things, there's your answer. The dumb things pay better.

The biggest lie is that this is inevitable. That this is what AI-assisted development is. That your only choices are "vibe code" or "get left behind."

Bullshit.

I work with AI every single day. I code through conversation. I stay in flow for hours, building things, shipping things, understanding things. The AI handles execution while I handle judgment. It's faster than the old way. It's better than the old way.

And it looks nothing like what these influencers are selling.

The difference? I never stop thinking. I review what the AI produces. I push back when it's wrong (often). I make sure I can explain every line before it goes in. I own the code—not because I typed it, but because I understand it and can defend it.

That's not slower. That's not "fighting the future." That's just being a professional. Remember professionals? We used to have those.

Here's the thing that nobody wants to say out loud:

If you weren't there (if you didn't engage, didn't think, didn't make decisions), then the session didn't happen. Not for you. The AI had a session. You just watched. Or worse, you didn't even watch. You set it running and checked Twitter. Planning your next thread. Drafting the clickbait title. Feeding the impression machine while the code writes itself.

That's not development. That's not even learning. It's like getting a diploma without attending class. The certificate is worthless because you are unchanged. You didn't gain anything. You can't do anything you couldn't do before. You just have some code now that you don't understand.

Congratulations. You own nothing. But your GitHub has lots of green squares, so that's nice.

Here's the ownership test. It's simple.

Look at the code you just "shipped." Ask yourself:

Can I explain what it does?
Can I defend why it's built this way?
Can I fix it when it breaks?

If yes, it's yours. You built it. Welcome to the club. We have mass anxiety about production and strong opinions about tabs vs. spaces.

If no, you own nothing. You're holding someone else's work and pretending it's yours. The AI's work, technically. But you can't even ask the AI to explain it, because you weren't paying attention when it made the decisions.

That's the test. That's the line.

I'm not asking you to reject AI. I use it constantly. It's genuinely transformative when used well.

I'm asking you to reject the grift.

Reject the influencers who've never maintained production code telling you how to write it. Reject the sponsored content pretending to be engineering advice. Reject the idea that understanding is optional, that thinking is a bottleneck, that the goal is to produce code as fast as possible regardless of whether anyone can maintain it.

The vibe factory isn't the future of development. It's the absence of development. It's what happens when we let the incentive structure of social media dictate how we practice our craft.

Insanity doesn't scale. It just fails faster.

And if you're one of the good ones—if you're reading this and nodding along, relieved that someone finally said it—know that you're not alone. There are more of us than the algorithm would have you believe.

We're just quieter. Because we're busy actually building things.

But I'm done being quiet.

I'll be writing more. About the principles that actually matter. The ones that let you use AI without losing your mind or your craft. Someone has to.

If this hit a nerve, good. That was the point.