After:

• boring catalog: open source iceberg catalog

• boring data: Terraform data stack templates

• boring semantic layer: open source semantic layer

Welcome Boring UI to the boring galaxy: an open source framework for shipping agent-centric apps.

The Why

Since the beginning of the year, I’ve spent a lot of time digging into the agent space.

AI can now understand user intent and act on it. And that completely changes how we build tools and interfaces.

For the first time, interfaces can become truly minimal and “boring”.

Boring because the interface can just be reduced to just two things:

• an agent chat on the left

• a workspace on the right (~ mini IDE)

  

I’ve already started seeing this pattern emerge across multiple products, and I think it’s slowly becoming the standard way to build software.

Boring UI provides the foundation for building these kinds of agent-centric applications: a unified agent + workspace model that can adapt to virtually any use case.

I wrote about this back in February, when I shared the three things I believed would bring the most value in the AI era. One of them was “IDE for X.”

After many iterations, Boring UI became the expression of that vision:

A simple (and boring) web-based mini IDE that lets anyone leverage the power of coding agents … without needing to interact with code directly.

You can see it in action here:

Try it

Boring UI is designed for building hosted agent-centric apps.

But it also runs fully locally: no auth, no database, no setup complexity.

Just a stateless agent + workspace running directly on your machine.

To get started:

export OPENAI_API_KEY=
npx @hachej/boring-ui-cli

Boring UI uses Pi as the agent harness (more on this in the next section), so you simply need to configure LLM access through environment variables (ANTHROPIC_API_KEY, OPENAI_API_KEY) or via a pi LLM provider.

Once configured, you instantly get a UI + agent connected to the folder where you launched the CLI.

Pi and therfore Boring UI is provider-agnostic and does not lock you into a specific model vendor. You can use virtually any LLM:

• commercial APIs

• open-source models

• fully self-hosted LLM infrastructure

Yes, this means you can plug in your Codex Pro plan (though not your Anthropic Max plan).

Build on PI

When building Boring UI, I was heavily inspired by the Pi project.

It’s an open-source agent harness that is super lightweight and built to be highly extensible.

I also really connected with the vision and philosophy of its creator Mario Zechner, which pushed me to adopt Pi as the core harness behind Boring UI.

I won’t go too deep into the technical details, but I wanted to give a quick overview of how Boring UI is structured.

At a high level, the system is organized around four main components:

• Web Frontend → chat + workspace UI

• Web Backend → API layer shared by both the frontend and the agent tools

• Pi Harness → agent runtime

• Sandbox → isolated filesystem + execution runtime

One important design axiom I had from the beginning was that the agent and the user should interact with the same core primitives through the same interfaces.

For example, there is a single file API shared by both:

• the frontend file tree

• the agent filesystem tools

The same applies to the UI itself: the agent sees the workspace the same way the user does and can interact with it through dedicated UI tools.

Using Pi made this architecture possible because I could integrate it directly into my backend through its Node.js SDK, while still being able to deeply customize its tools and interfaces.

For example, I was able to override the filesystem tools so they interact with the sandbox system configured by Boring UI.

Currently, Boring UI supports the following sandbox isolations:

• local and 0 isolation :)

• local with bwrap

• remote Vercel sandboxes

And soon more: Kube, Bedrock AgentCore etc

Extensible: Boring Plugins

One of Pi’s biggest strengths is its extensibility.

Anyone can publish a package to extend Pi with custom prompts, skills, and tools.

I wanted Boring UI to fully leverage that ecosystem instead of reinventing it.

So rather than creating yet another plugin model, Boring UI simply extends the one Pi already provides.

Pi plugins focus on the agent layer:

• prompts

• skills

• tools

• slash commands

  

Boring UI adds a UI layer on top of them with concepts such as:

• panels

• command palette actions

• UI events

• catalogs

The two layers are fully compatible: any Pi plugin works out of the box inside Boring UI.

In practice, a plugin is simply a Node package with two manifest blocks:

• pi.* → agent side: prompts, skills, tools

• boring.* → UI side: panels, commands, catalogs, surface resolvers

Example of package.json:

{
  "name": "my-plugin",
  "keywords": ["pi-package"],
  "pi": {
    "extensions": ["agent/index.ts"],
    "skills": ["agent/skills"],
    "prompts": ["agent/prompts"],
    "systemPrompt": "Short agent guidance."
  },
  "boring": {
    "label": "My Plugin",
    "front": "front/index.tsx",
    "server": "server/index.ts"
  }
}

This makes customization extremely flexible.

You can install any existing Pi plugin directly to customize the agent’s behavior.

And if needed, you can progressively enhance that same plugin with Boring UI capabilities like custom panels, commands, or interactive UI surfaces.

Plugins also compose naturally: multiple plugins can coexist side by side, or shared primitives can be wrapped into reusable packages.

I already have a few plugins in the repository:

• ask-user → Agent-to-human Q&A with a UI prompt

• data-catalog → Catalog tab built on data-explorer

• deck → Plugin to let the agent create html slide deck.

Install them in your Boring UI project and you instantly get those capabilities.

I have 10s of ideas for plugins that could emerge from this model:

• Kanban boards

• LLM-powered wikis / second brains

• orchestration interfaces

• observability dashboards

• workflow builders

• openclaw like daemon

Built with boring-ui

To demonstrate the power of this setup, I built a first custom app: boring-macro.

It’s an agent for macroeconomic research.

Note: the app is invitation-only for now, mainly because I haven’t implemented billing yet.

The agent has access to economic series like GDP, employment rates, prices, and more.

It can explore data, perform ad hoc transformations, visualize series, and even generate slide decks.

What’s interesting is that the entire app is implemented as a single Boring UI plugin.

Under the hood, the plugin includes:

• a custom skill to guide the agent’s behavior

• a custom SQL tool to query macroeconomic data

  

• a custom component to explore visualize time series in the workspace

• a custom CLI + SDK to help the agent generate Python transformations of time series

  

  

• the deck plugin to render HTML slide decks in the workspace

I think it’s a good illustration of how far you can go with this model: from data access, to analysis, to visualization, to presentation generation…

THE next feature: hot reload

The next feature I’m excited about is self-buildable UI.

If the agent already has filesystem access, there’s no reason it shouldn’t build its own plugins.

Users could start from a few UI primitives and let the agent create custom skills and panes tailored to their workflows.

That’s exciting because it makes apps even more boring: you ship primitives, the agent handles the last-mile customization.

Right now, plugins are loaded at build time and only reloadable in development.

I’m working on dynamic hot-reloading inside the app so agents can eventually create and evolve their own UI surfaces in real time.

Demo of the agent creating and editing a csv viewer plugin:

Vision

This is still the initial version of Boring UI, and the project is actively evolving.

I already use Boring UI internally for many things in my company:

• accounting

• project: md report edition

• coding: agent plans review

It’s just so much nicer to have a clean, unified UI instead of a collection of TUIs scattered across terminal sessions.

Long term, I imagine Boring UI evolving into a skill-sharing platform.

A place where domain experts can share skills, UI primitives, workflows, and packaged knowledge.

It’s still early.

But I’m genuinely very excited about where this can go.

I hope you’re as excited about this project as I am :)

Again, if you like the project, it would really help to star the repo ⭐.

I’m building this project independently, and every star makes a huge difference.

Github

The possibility of shipping custom agents in a matter of days with Boring UI opens the door to many kinds of collaborations.

I’m actively looking to work with:

• companies interested in deploying custom internal agents

• domain experts interested in partnering to build vertical agent-native apps together

If that sounds interesting, feel free to reach out.

Thanks for reading,

- Ju

I write this post with the need to somehow put on paper the intuition I have built over the last few years.

Five months later, I feel the same need again — but this time focused on AI coding workflows.

Every week brings new models, new tools, new trends, and new CEO hot takes.

Reflecting on the last few months, this feels a lot like the dynamical systems courses I had at university.

An initial state.

A perturbation.

And then a convergence toward a new stable equilibrium with wide back-and-forth swings in between.

This post is a brain dump of everything I’ve learned about the topic over the last few months.

Where I see things starting to converge.

Maybe the premise of a boring AI coding workflow ? Finally.

Note: This post is not AI-generated. I wrote it manually and only used a single prompt to edit it:

“Correct grammar: <> ” :)

No baby sitting

This was my first step this year: getting the most out of a single agent session.

To do that, I had to stop babysitting the agent.

No more permissions prompts.

No more letting my laptop running.

I now rent a VPS on OVHcloud and run all my work from there.

My agents run there continuously in all persmission mode.

I just use a tool that spots dangeroud command and block them.

And this works perfectly: agents don’t get interrupted and keep running until they finish their tasks.

No Agent Swarms

I got caught up in the agent swarm hype at the beginning of the year.

It was definitely the opposite of “boring” — but still worth exploring.

I tested various tools and workflows, but I eventually came to the following conclusion:

Writing the code was not the bottleneck for me anymore.

The real bottleneck was being able to provide enough spec, context, and direction to properly feed the machine.

And once I realized that, the whole premise of agent swarms started to break down for my use case.

Building a swarm of agents makes little sense if I can’t reliably feed it.

Plan Plan Plan

I learned this the hard way.

If you don’t feed the machine correctly, agents still aren’t good enough to build reliable software consistently.

They tend to overcomplicate things, over-engineer solutions, take shortcuts, and drift away from the original intent.

A common way to overcome this is to:

• have good guardrails in AGENTS.md

• spend time writing a good plan

Usually, that’s enough to constrain the model and get good results.

But I find that writing plans is not that easy.

Super detailed plans start to feel like writing the code directly…

Vague plans lead to disasters.

Building the intuition for what to constrain and what not to constrain is probably the real craft now.

Engineering craft is now:

1. Finding the right plan at the right level of abstraction

2. Knowing what to put in the plan — which means knowing what you actually want

… And review

I built some advanced review workflows where several agents using different models review each other’s code.

It worked pretty well — especially when asking Codex to review Claude-generated code.

But as they both lack common sense I still need to review things manually.

I review the overall shape of the code and the details of the most important sections, not every single line.

And that’s part of the craft as well:

Choosing what to review, and at which level of detail.

To do that well, you need to understand your infrastructure, your codebase, and the tradeoffs inside it.

There is no way around.

Up-Skilling

This has been a real aha moment for me over the last month: agent skills.

When they’re well written, they can convey an enormous amount of value for very specific tasks.

The skill I’ve been the most impressed with is impeccable for design. It produces much better designs than a raw model alone.

Personally, every time I do something that I may need later, I try to turn it into a skill.

All my skills are version-controlled in a repo, and I have a simple dispatch script that copies them into ~/.agents/skills on my machines.

But there’s a real danger with this approach: each skill is referenced in the harness system prompt.

So if you accumulate dozens of skills in ~/.agents, you end up polluting the context on every turn, which degrades the quality of the output.

So I’m very careful about what actually gets dispatched globally, and I try to isolate skills to specific projects as much as possible.

OSS to save us

OSS models

Like many developpers after couple months of subusised hoony moon, I have started to get nervous about my dependainy to claude code.

I started playing with OSS models and honestly, I’ve been more than impressed.

I now run Qwen 3.6 on my Mac M3 and use it for all kinds of tasks: research, testing, and bug fixing.

When you run your own model, it feels like entering a new world of freedom.

No “x% of quota remaining” warnings.

No strange feeling of giving my data away.

Just my Mac sweating next to me :)

Note: this is the setup I used.

OSS harnesses

The same lock-in concerns I mentioned about models also pushed me to look for alternatives to Claude Code itself.

That’s where Pi started to get really interesting.

It’s a super lightweight harness designed to be extensible through plugins.

The community is incredibly productive, and almost all the features you find in Claude Code or Codex are already available through plugins.

Most importantly: it works with almost every provider.

Except one: Claude Max Plan :)

I’ve been using it for the last few weeks, and I’m honestly super satisfied.

My model usage has naturally gravitated toward a wider diversity of models:

• GPT-5.5 (Pro Plan) for coding

• DeepSeek 1.4 via OpenRouter for coding

• Qwen 3.6 via Tailscale (running on my Mac) or OpenRouter for general tasks + simple coding

• Gemini 3.1 for reviewing

• Grok for reviewing

Having a single multi-LLM harness makes it incredibly easy to mix models together.

One plugin I use a lot is the subagent plugin. It lets you combine reviews from multiple models within the same session. And honestly, it works very well.

Resisting the tool tsunami

For the rest, I avoid spending too much time testing every new tool popping up in my feed.

My reasoning is simple:

If a tool is truly good, it will eventually get implemented into the harnesses like Claude Code, Codex, or Pi.

The time I’d lose setting it up, integrating it, and maintaining it usually isn’t worth it.

I couldn’t resist, however, playing with the OpenClaw wave: especially to automate some admin work for my company.

I made the classic mistake: I spent time setting it up, it broke many times, and the whole thing became a distraction.

Eventually, I just passed:

• the OpenClaw GitHub repo

• the Hermes GitHub repo

• the Pi GitHub repo

…to my agents, and I one-shotted my own minimal “boring-claw” setup that perfectly fits my needs: one Slack channel per project, each connected to a pi session running on my VPS.

It has now been running for weeks and has required almost zero maintenance and reduced security risk..

This is everything I’ve learned over the past few months.

The convergence is probably temporary, but writing this has helped me measure how much things have evolved in such a short time.

I hope you got something out of this.

Do not hesitate to respond to this email with your experience.

Or, even better, share it publicly in the comments.

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

LLMs have made intelligence on-demand.

Not as a service you build. As a capability you embed.

Intelligence used to live in the code your team wrote: a dashboard, a pipeline, a report.

Now this intelligence can write code everywhere: on your users’ machines, inside your pipelines, inside your orchestrators.

For data teams in 2026 and beyond, this raises a new question: If agents can code, what will we build?

Welcome to the Markdown Team.

Reimagining the Data Team

LLMs keep improving with every release.

At the same time, every data tool provider is rushing to become agent-native.

Put those two trends together, and a new possibility emerges:

with the right context and guardrails, agents may soon be able to write production-grade pipeline code reliably enough.

Not perfectly today.

Not in every case yet.

But soon enough that data teams should already be paying attention.

So if that becomes true, what happens to the way data teams work?

The Old Equilibrium

Today, the data team owns the entire pipeline.

Marketing asks for a dashboard. The data team writes the SQL, models it in dbt, and builds the dashboard. Two weeks later, it is ready.

Product asks, “What is our churn rate?” The data team writes the query, runs it, and sends back the answer. Until then, users wait.

The pattern is simple:

Data team pushes: gold tables, metrics, dashboards
Users pull: answers from those dashboards

The New Equilibrium

Now take the assumption seriously: agents can generate code reliably when given the right context and guardrails.

If that holds, the equilibrium flips.

We can inject that intelligence for 2 things:

• User side: turn core data assets into answers and insights on demand

• Pipeline side: build and adapt pipelines much faster as demand emerges

So instead of the data team pushing a fixed set of dashboards and data products, users ask, and agents handle the last mile.

The new pattern looks like this:

Data team pushes: rules and core artifacts
Users ask
Agents execute

The data team’s job is no longer to manually produce every dashboard, query, or pipeline.

It is to build the highway that makes agent execution safe.

The New Jobs to Be Done

Job 1: Choose where to add determinism

LLMs are great at generating code, but bad at predictable behavior.

So no, vibe-coding a data platform from scratch will not work.

The job of the data team becomes more strategic: decide where determinism is needed, put the right building blocks in place, and let LLMs generate code within those boundaries.

Even Anthropic seems to recognize this. In the leaked Claude Code source code, a tool call like print.ts is one big if-then conditional: hundreds of branch points, deeply nested, all inside a deterministic symbolic loop.

That is the right mental model: LLM for pattern matching + symbolic rules.

Fortunately, the data ecosystem is moving in that direction.

More and more tools are becoming agent-native and provide us with these reliable deterministic building blocks:

• dlt provides deterministic ingestion

• dbt provides deterministic transformation

• semantic layers provide deterministic metric querying

That means the data team’s role is to select the right deterministic tools and define the rules that let LLMs combine them coherently.

Which, in many ways, is just platform engineering:

• choose the tools

• define the architecture

• enforce the governance

• document the standards

Job 2: Context encoding

This one is straightforward: LLMs fail when they do not understand the meaning of the data.

If a model does not know what a dataset represents, how the company operates, or what a metric actually means, it will make mistakes.

So the second role of the data team is to encode that context: gathering information from different sources, cleaning it, removing contradictions, and exposing it in a form that agents can reliably consume.

This context is not static and has to be shaped from both sides: from the company’s knowledge and structure, but also from observing how agents consume that context in practice.

That means analyzing agent failures and adapting definitions, documentation, and context structures to make the right things more explicit for the agent next time.

In that sense, context encoding is not just documentation work. It is an additional layer in the stack, one that needs its own feedback loops, maintenance, and tooling.

And a new category of tools is starting to emerge to support that context curation work — nao being one example.

New AI Order

Data teams should become context teams

Remember when your company connected their BI tool directly into the production database? Figures were always wrong. Nobody trusted the dashboards - so we built data stacks to fix that…

Read more

4 months ago · 31 likes · 6 comments · Claire Gouze

Job 3: Kaizen

This all sounds obvious in theory. The hard part is making it real.

The answer is the same as with any good data platform: iteration.

Start with a first version of the rules. Capture the platform design, the best practices you already know, and the pitfalls you have already seen. You can even ask an agent to inspect your current codebase and surface patterns.

Then let the agent build.

When it fails, look closely at why.

Because most failures are not syntax failures: agent are good at writing and debugging SQL/dbt/dlt etc code.

They are context failures:

A metric definition was unclear.
A table was less reliable than expected.
A join was much more expensive than it looked.
A business assumption was never written down.

That is the agent flywheel: every failure becomes a new rule, a new skill file, a new script, a new constraint.

Each iteration strengthens the system.
Each correction makes the agent safer.
Each new rule increases autonomy.

The New Roles

If agents can code, data roles move up the stack.

Data engineer → platform architect

The data engineer becomes a platform architect.

• platform design: tools, architecture, governance, monitoring

• pipeline guardrails: what agents can and cannot do

• cost governance

You stop writing pipelines one by one.

Your job is to design the environment in which pipelines can be generated reliably.

Data analyst → research analyst

The data analyst becomes a research analyst.

You own:

• metric definitions and contracts

• business-facing data documentation

• deep-dive analysis: scenario modeling, simulations, and decision support

That last point matters a lot.

If agents can answer most routine business questions, then the analyst’s role does not disappear. It shifts upward.

The analyst spends less time answering questions like “what happened?” and more time exploring questions like:

• what happens if we change pricing?

• what happens if conversion drops in one segment but rises in another?

• what happens if we shift budget across channels?

In other words, the analyst moves from reporting to research.

So this is my vision for the future of data teams.

No, we are not fully there yet.

But after a few months of intense interaction with AI, I think we are getting close enough that data teams should already be paying attention.

And yes, it changes a lot about our jobs.

Many of us got into this field because we love the technical craft: writing code, writing SQL, building things ourselves.

I think more of that will fade in the medium term.

Working in a data team may mean writing Markdown files and orchestrating agents all day long.

That shift can feel uncomfortable if what you love most is the craft.

But it also creates space for something bigger.

Data teams may become less execution-heavy, but far more strategic, influential, and embedded in decision-making.

And ultimately, more impactful for the business, which was the original goal all along.

Thanks for reading,

Ju

Coding agents now sit between us and our tools—and that changes how we judge the ecosystem.

In data ingestion, my old heuristic was simple:

• Managed for standard sources (Fivetran, Airbyte)

• Python when you need flexibility (custom connectors)

Fivetran has an SDK, but it always felt too heavy—until agents entered the picture.

If an agent can absorb the SDK complexity, even proprietary interfaces become usable.

That collapses the old ELT spectrum: managed (Fivetran) vs code-driven (dlt).

So I tested it: can the same coding agent build custom connectors for both—using the Fivetran SDK on one side and dlt on the other?

Same API. Same LLM. Same goal.

Let’s see what happens.

Designing the Nightmare API

AI copilots are a powerful tool for accelerating software development, and stand to commoditize (or even trivialize) data integration.

The goal of this post is simple: find the limits of AI-driven integration.

To test this properly, I built a virtual FastAPI server exposing three types of records:

• customers

• orders

• events

Easy mode

In the “realistic” version, the API looks like a typical demo:

• Auth: Bearer token

• Schema: consistent and complete

• Pagination: cursor (customers), offset (orders), Link header (events)

• Rate limiting: none

Pretty standard.

Hard mode

Then I made it deliberately painful:

• Broken records: null IDs, evolving schemas, random extra fields

• Type chaos: metadata as dict/str/list, amount as int/str/null

• Deep nesting: JSON 7 levels deep

• Auth upgrade: HMAC-SHA256 with X-Api-Key, X-Timestamp, X-Nonce, X-Signature

• Rate limiting: 5 requests / 10s, 429 + Retry-After

Protocol

The FastAPI server exposes a complete OpenAPI spec—schemas and auth included—so an agent has, in theory, everything it needs.

To compare dlt and Fivetran, I ran both locally and loaded the results into DuckDB.

dlt is Python-native, so local runs are the default.

Fivetran’s Connector SDK can also run fully locally, which keeps the comparison fair.

For each tool, I launched an isolated Claude Code agent (Opus 4.6), gave it a minimal prompt, and let it build the connector.

Build a Fivetran connector for the Nightmare API Easy mode with incremental mode.

Setup:

- Create venv in this folder

- Create DuckDB file

Build:

- Read spec: http://localhost:8787/openapi.json

- Implement using <fivetran-connector-sdk/dlt>

- Load to DuckDB

- Iterate until working

- Write report

I simulated incremental loads by adding new records after the first run, then rerunning the exact same pipeline.

At the end of each scenario, a separate agent compared the two DuckDB databases and flagged any differences.

Results: Easy Mode

Both agents did great: end-to-end in ~3–4 minutes.

The first run succeeded for both tools.

On the second run, both behaved as expected: they loaded only new incremental records and even detected a duplicate.

So far, so good—but a few type differences showed up:

• Dates: dlt uses TIMESTAMP, Fivetran stores ISO 8601 strings as VARCHAR

• Decimals: dlt uses DOUBLE, Fivetran uses DECIMAL

Schema handling

Fivetran treats the OpenAPI spec as the contract: if a field exists (even optional), it creates the column—whether or not the API ever returns it.

dlt is schema-on-observation: it creates columns only for fields it actually sees in the payloads.

In our case, a few fields were marked optional in the spec but never appeared in actual responses.

Fivetran still created the corresponding columns (all NULL/empty), while dlt never created them because it never observed those fields in the data.

Nothing dramatic—just different philosophies.

A solid warm-up: easy for both tools.

Now let’s go up a level.

Results: Hard Mode

Hard mode introduced some real friction: NULL primary keys, deeply nested structures (7 levels), mixed data types, and HMAC authentication—across the same three endpoints (customers, orders, events), each serving 1,000 records.

Both agents handled HMAC auth and rate limiting easily.

The outcome:

• dlt: 3,000 / 3,000 records loaded (100%). Created 5 tables, including child tables for nested arrays.

• Fivetran SDK: 2,815 / 3,000 records loaded (93.8%). 185 records dropped—all with NULL primary keys.

Here’s what happened.

dlt failed once the broken records appeared. A schema inferred from the clean run broke when corrupted variants showed up—specifically metadata changing types.

The agent had to patch the pipeline by:

• adding variant handling for metadata

• generating surrogate keys for NULL IDs

Fivetran ran end-to-end without code changes. Its “serialize to VARCHAR/JSON” approach avoided type conflicts, and its strict primary-key requirement filtered out invalid records.

The trade-off: 185 records never landed.

Mixed Metadata Types

Orders returned metadata as a dict, a string, or an integer.

• dlt inferred a STRUCT from the first batch (all dicts). When strings/integers appeared later, the pipeline broke. After the agent fixed it, metadata was split into four columns: metadata__source, metadata__campaign, metadata__value (for non-dict values), and metadata__type (to track the variant).

• Fivetran serialized metadata into a single VARCHAR JSON column, so it never broke—but you lose the typed structure.

Nested Data

dlt flattened nested arrays into child tables—orders__line_items (2,534 rows) and events__tags (516 rows)—linked back to the parent via foreign keys.

Fivetran kept them inline by serializing the arrays as JSON strings in VARCHAR columns (_line_items_json, tags).

Both work, but the ergonomics differ: dlt is join-ready; Fivetran requires JSON parsing at query time (or an extra staging model).

Most of these edge cases could probably be handled with better prompting—and a bit more upfront guidance.

What’s interesting is how far you can get with a one-shot prompt, and how each framework’s defaults reveal its underlying philosophy.

In both cases, the agent navigated the tools smoothly and set up ingestion quickly. That’s what makes these tools compelling: they’re solid building blocks an agent can adapt for last-mile customization.

One more takeaway: maintenance. Agents aren’t just useful for bootstrapping pipelines—they can also keep them running. In this test, the agent diagnosed why the dlt pipeline failed after the first run and patched it into a more resilient shape.

Conclusion

ELT decisions traditionally come down to four things:

1. Cost model — MAR vs compute

2. Engineering time — setup + maintenance

3. Connector catalog — what you get out of the box

4. Custom connectors — how painful it is to build what’s missing

AI compresses #4 and a big chunk of #2.

Both dlt and the Fivetran SDK can get to a working custom connector fast, even against awkward APIs.

Once “can we build the connector?” stops being the differentiator, what matters most is the operating model:

• Fivetran SDK: your connector runs on Fivetran’s platform. You inherit hosting, scaling, scheduling, monitoring, retries, security, and general operational burden.

• dlt: you get full Python flexibility, but you own the whole stack: runtime, orchestration, scaling, observability, and on-call.

So the decision becomes a strategy choice.

For smaller teams (say, <400 people) with limited ops bandwidth, no desire to own ingestion, and highly commodified data models, Fivetran is a sensible default.

If you need maximum flexibility and control, and you’re willing to invest in running and maintaining ingestion, dlt is the better fit.

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

This is the fourth episode of our chat-BI series with nao.

Quick recap.

Post 1: We explored a modern approach to chat-BI, using the filesystem to store and serve context to the model.

Post 2: We stress-tested that setup on real benchmarks (BIRD + DABStep).

Post 3: We reran those benchmarks with a semantic layer and showed how it reduces ambiguity.

In this post, I’ll deep dive into how nao tests an analytics agent.

The team has iterated a lot over the past few months and gathered some really interesting insights into what it takes to test agent frameworks.

Let’s go.

Testing Agent != Testing SQL

In the previous posts of this series, we ran chat-BI agents on real benchmarks.

We saw agents can fail—not because of bad SQL syntax, but because of misinterpretation:

• They misread metric definitions.

• They answered questions that had no answer in the data.

• They missed basic business conventions.

If you want to reduce these errors, you need to measure them systematically.

The obvious solution is to compare SQL:

1. Give it a prompt

2. Pick an expected SQL query

3. Compare the two

But here’s the problem:

An agent can issue multiple queries, structure them differently (different CTEs, different aliases), or reach the same answer through different intermediate steps.

Sometimes it won’t even return SQL at all—it might return plain text, a table, or a chart.

So the real challenge isn’t validating the process (“did it write my SQL?”).

It’s validating the outcome: did it get the right answer, while keeping the freedom to reason its own way?

nao testing framework

To support this non-deterministic agent behavior and still ship BI agents with real control, nao built its own testing framework.

The setup is simple.

You define test cases as small YAML files in a tests folder. Each file contains a name, a prompt, and a validation query (SQL) used to compute the expected result:

name: total_revenue

prompt: What is the total revenue?

sql: SELECT SUM(amount) AS total_revenue FROM payments;

That validation SQL is not there to compare against the agent’s SQL. It’s there to compute the golden result set.

You’re not testing “did you write this SQL?”

You’re testing “did your answer match this data?”

When you run nao test, here’s what happens:

nao sends each YAML test case to a specific LLM. Then it:

1. collects the agent’s answer

2. normalizes it with a synthesizer (more on that below) which converts the answer into a structured list of records and sorts it consistently by rows and columns

3. compares it to the golden result produced by the validation SQL

Furthermore, each run is logged as a single JSON artifact with everything you need to debug later: transcript, tool calls, SQL queries, intermediate outputs, and token usage.

Because this is standardized, you can scale evaluation easily across many test cases and across multiple LLM providers.

A few details that matter:

• Runs are isolated: the agent does not know about how his answer will be evaluated

• Concurrent execution: multiple models × multiple tests can run in parallel.

• Cost visibility: for some warehouses (e.g., BigQuery), nao can capture query cost in addition to token cost, so you can track the full cost of an agent run.

Synthesizer LLM

This is where most people expect a simple SQL comparison.

nao does something different.

After the agent completes its full loop, nao takes the full conversation transcript and sends it to a second LLM: the synthesizer.

The synthesizer’s job is simple: extract the agent’s final answer into a structured format that matches the expected schema.

Here’s the prompt it uses:

Based on your previous analysis, provide the final answer to the original question.

Format the data with these columns: ${columns.join(’, ‘)}

Return the data as an array of rows, where each row is an object with the column names as keys.

If you cannot answer, set data to null.`;

nao enforces this with structured output, so the synthesizer returns parsable JSON—not free-form text.

Why does this exist?

If you tell the agent upfront what output format you expect, you bias it.

So you need two isolated steps:

1. let the agent run with zero knowledge of the expected output format

2. after it’s done, extract the answer with the synthesizer

The agent needs freedom in how it gets there—multiple queries, different SQL shapes, different intermediate steps.

The synthesizer simply normalizes the output so you can evaluate the result, not the path.

JSON trace

Another strength of nao’s testing framework is that it collects all the run metadata in one central place.

Why does this matter?

Because it gives you freedom in how you debug and iterate.

You can:

• inspect runs in nao’s UI (nao test serve)

• ask another agent to analyze failures

• build your own workflow on top of the raw logs, or export everything to your analytics stack.

No lock-in.

Furthermore, the log file and especially the tool calls, lets you reconstruct exactly what the agent did, step by step:

• Which files did it read?

• Did it query the right tables?

• Did it try several SQL queries unsuccessfully before getting stuck?

All of that is traceable.

What’s Covered (and What Isn’t)

Let’s be explicit about scope.

There are three steps in an analytics agent’s response:

1. Map the question to an intent

2. Retrieve the right data

3. Present the result

nao’s testing framework mainly targets (1) + (2)—especially retrieval.

The hypothesis is simple: if the agent reliably retrieves the correct information, you’ve solved the hardest part of chat-BI.

Limitation of output-only checks

nao validates the final output, not the path.

That means you can get false positives in some tricky cases.

Example:

• Question: “What is the conversion rate of product X?”

• Golden SQL returns: 0.45

• The agent takes a wrong path (wrong table, wrong join)… but by chance still ends up with 0.45

• The test passes, even though the reasoning was wrong

This points to an obvious evolution for the framework: the ability to add path constraints (quality gates), for example:

• “This table must be used”

• “This join relation must be used”

• “This context file must be read”

• “This metric must be called”

That likely means introducing a small DSL so you can express these constraints cleanly in test definitions.

Context debugging tool

nao provides a good foundation to push context building further.

Once you have tool-call logs, you can go beyond pass/fail and start debugging the context itself.

A few ideas that would be extremely valuable:

Context heatmap

Which context files are actually used? If you have 50 files and only 10 are ever accessed, that’s a signal: the rest may be noise—or simply not discoverable.

You could even go beyond the file level and measure usage at the section level using tool logs.

Context holes

Does the agent repeatedly search for information that doesn’t exist? If it reads 20 files before answering a simple question, something is off.

Context contradictions

Across runs, does the agent pull definitions from different files—and does that change the output? That’s a great way to detect conflicting rules or duplicated definitions.

Conclusion

The hard part isn’t writing test cases.

The hard part is defining what “correct” means for an agent with freedom.

nao’s answer:

• Let the agent behave like an agent

• Compute the expected result independently

• Use a second model to normalize the answer

• Compare the data, not the path

This is a solid foundation. But there’s clear room to evolve:

• Path validation to catch false positives

• Context observability to turn test logs into insights

The next frontier isn’t just “did it work?”

It’s “how did it work, and what does that tell us about our context?”

I hope this post helped you understand how modern Chat-BI systems are built.

This is the 4th episode of a mini-series we’re working on with the nao team.

In the coming weeks, we’ll publish deeper dives on:

• BI-Agents and memory

• The impact of Chat-BI on data roles

Stay tuned.

We have released a new episod of our podcast with blef (in english :)). Check it out here:

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

This is the third episode of my chat-BI series with nao.

A quick recap:

• Post 1: I explored a modern approach to chat-BI, using the filesystem to store and serve context to the model.

• Post 2: I stress-tested that setup on real benchmarks.

We ran 25 questions across BIRD + DABStep.

Out of all the errors, none were SQL errors.

The failures happened before SQL:

• Interpretation: the model misreads metric definitions

• Framing: it answers questions that have no answer in the data

• Common sense: it misses basic conventions

So where does that leave us?

If context isn’t enough—and RULES.md doesn’t scale—how do we get reliability?

My take: stop asking the model to navigate from scratch. Give it a map.

That’s what a semantic layer is: predefined routes and hard definitions for your metrics.

In this post, we’ll rerun the same benchmarks from Post 2 with a semantic layer in the loop and see which failure nodes disappear—and which ones remain.

Let’s go.

What is a semantic layer ?

Think of a semantic layer as a set of predefined itineraries your agents can pick to navigate your schema.

It defines metrics so they can be reused immediately—without having to think about joins, table relationships, or column definitions.

Metrics usually come from combining two things:

Measures are the calculations:

• revenue = SUM(amount) WHERE status = ‘completed’

• fraud_rate = SUM(CASE WHEN is_fraud THEN eur_amount ELSE 0 END) / SUM(eur_amount)

Dimensions are how you slice those measures: by country, by month, by product category… Same measure, different angles.

Users combine measures × dimensions, and the semantic layer’s job is to generate the corresponding SQL against the underlying database.

BSL?

If you’ve been following my newsletter, you’ve seen BSL before.

If not: Boring Semantic Layer is a lightweight semantic layer built on top of Ibis, that we developed together with .

Install is literally:

pip install boring-semantic-layer

How does it work, concretely?

You define measures and dimensions in YAML, and commit them next to your code:

payments:
  table: transactions
  dimensions:
    merchant:
      expr: _.merchant
      description: "Merchant identifier / name"

  measures:
    total_volume:
      expr: _.eur_amount.sum()
      description: "Total monetary volume in EUR"

This YAML can be used directly by an LLM to query data.

Give it the BSL Python library, and it can execute queries like:

bsl.model("payments")
    .group_by("ip_country")
    .aggregate("fraud_rate", "total_volume")
    .execute()

When we designed BSL, composability was a core goal. You can enhance any semantic model in three ways:

• One-off post-aggregation transforms (ad hoc calculations)

flights_st
    .group_by("carrier")
    .aggregate("flight_count")
    .mutate(market_share=_.flight_count / _.flight_count.sum().over(w) * 100)

• Add new measures and dimensions (promote ad hoc logic into reusable metrics)

flights_st = flights_st.with_measures(
    market_share=lambda t: t.flight_count / t.all(t.flight_count) * 100,
)

• Join models together (compose richer semantic models)

flights_with_carriers = flights_st.join_many(
    carriers_st,
    lambda f, c: f.carrier_code == c.code,
)

And the cherry on the cake: there’s no lock-in.

Your LLM can always ask BSL for the raw SQL it generates, then tweak it if needed:

q = payments.group_by("ip_country").aggregate("fraud_rate", "total_volume")
q.sql()

BSL + nao

If you’ve followed the previous episodes, you’ve seen how an LLM can navigate a filesystem to gather context before querying the database.

That’s why a YAML-based semantic layer fits so well here: it’s just another set of files the model can read.

The semantic model stays in the background—an extra context source, not a central platform in your stack.

Your context becomes a clean, version-controlled bundle:

• Schema metadata (tables, columns, relationships)

• Docs + rules (RULES.md + supporting .md files)

• Metric definitions (measures + dimensions in YAML)

That way, the LLM can navigate different layers of context depending on what the question requires:

RULES.md → metrics (YAML) → schema

Start with high-level guardrails, fall back to metric definitions for business logic, and only drop down to the raw schema when it needs table/column details.

Demo

I took the same nao setup as in the previous episode and added BSL into the mix.

Concretely, I only added two files:

• profiles.yaml — DB connection

dabstep_db:
  type: duckdb
  database: "./dabstep.duckdb"
  read_only: true

• semantic_model.yaml — dimensions + measures

payments:
  table: payments
  description: "Payment transactions processed by the payment processor. Each row is one transaction with amount, fraud status, and card/country metadata."
  dimensions:
    merchant:
      expr: _.merchant
      description: "Merchant name"
    card_scheme:
      expr: _.card_scheme
      description: "Card scheme: MasterCard, Visa, Amex, Other"
...
  measures:
    transaction_count:
      expr: _.count()
      description: "Total number of transactions"
...

After that, my project looked like this:

dabstep_bsl/
  ├── nao_config.yaml            ← project config (DB + LLM)
  ├── RULES.md                   ← agent instructions
  ├── semantic_model.yml         ← BSL metric definitions
  ├── profiles.yml               ← DuckDB connection config
  │
  ├── docs/
  │   └── manual.md              ← business rules & definitions
  │
  ├── databases/                 ← schema metadata (nao context)
  │   └── type=duckdb/database=dabstep/schema=main/
  │       ├── table=payments/
  │       ├── table=fees/
  │       ├── table=merchants/
  │       └── ...

I finished by adding a small note in RULES.md:

... 
## Semantic Model
We use `boring-semantic-layer` for canonical metric definitions (`semantic_model.yml` + `profiles.yml`).

Use sandboxed execution to run BSL queries like:

```python
from boring_semantic_layer import from_yaml

models = from_yaml("semantic_model.yml", profile="dabstep_db", profile_path="profiles.yml")
payments = models["payments"]

df = (
    payments
    .filter(lambda _: _.is_credit == True)
    .group_by("card_scheme")
    .aggregate("transaction_volume")
    .execute()
)
df
...

And enabling two things in nao:

• Sandboxed Python execution

With nao’s sandboxes, the agent can safely run BSL queries in a safe runtime—no raw eval().

• Web search (so it can look up BSL docs when needed)

Then I ran a quick smoke test in nao chat: nao’s agent automatically understood it needed to install BSL inside its sandbox.

Now let’s go back to the two questions that broke the system in Post 2 and see what happens this time.

Test 1: Interpretation failure

In Post 2, we asked:

What is the top country (ip_country) for fraud?

The agent used COUNT(*) instead of SUM(eur_amount).

I added there fore a metric in BSL:

fraud_rate:
    expr: (_.has_fraudulent_dispute.cast("int64") * _.eur_amount).sum() / _.eur_amount.sum()

And the model picked it up directly:

One metric call. No interpretation. Correct answer: BE.

And that’s the biggest advantage of a semantic layer for me: it reduces the number of failure nodes and makes chat-BI agents much more reliable.

Test 2: Framing failure

In Post 2, we asked:

Is Martinis_Fine_Steakhouse in danger of getting a high-fraud rate fine?

The expected answer was “Not Applicable”—no such concept exists in the data.

But the agent invented a definition and answered “Yes.”

With the semantic layer we had the same problem:

I tried tightening RULES.md with a stricter decision policy:

• Prefer BSL: if the metric exists in semantic_model.yml, use it.

• If it’s not in BSL: decide whether it’s in-scope but undefined (ask for confirmation) or out-of-scope (answer “Not Applicable”).

But it still didn’t reliably work.

So framing errors remain an open problem for me.

The missing piece is a stronger grounding mechanism—something that forces the agent to prove a concept exists before answering.

Rules.md vs Semantic Layer

So when do you add a rule to RULES.md, and when do you define a metric in the semantic layer?

My rule of thumb:

• Use RULES.md for behavior: how the agent should think, what to read first, how to answer, what not to invent, how to handle ambiguity. Keep it short—guardrails, not business logic.

• Use the semantic layer for definitions: anything that must be precise and reusable—metric formulas, filters, time windows, what “volume” means, what counts as fraud, etc.

In practice:

1. Start with basic context + a handful of core metrics.

2. Ship, log failures, and turn recurring errors into eval questions.

3. If an interpretation issue keeps repeating (“volume”, “active”, “churn”), promote it into the semantic layer.

   • Guidance = RULES.md

   • Contract = semantic layer

4. Rerun eval and refine metric names/descriptions until selection is stable.

This loop—observe → eval → promote → validate—keeps RULES.md lean, grows the semantic layer with real usage, and prevents context drift.

This was episode 3 of a mini-series with the nao team on chat-BI architectures and design patterns.

Next episode: what chat-BI changes for data roles (analytics, BI, analytics engineering, and data platform).

We have released a new episode of our podcast with blef (in french). Check it out here:

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

This is the second episode of my chat-BI series in collaboration with nao.

In the last post, I explored a modern approach to chat-BI: using the filesystem to store and serve context to the model.

Here, the LLM reads the codebase to reconstruct the data model, then runs iterative queries—refining its hypothesis each step—until it converges on an answer.

In this post, I continue the exploration and try to find the limits of this setup. I want to understand when it fails and what kinds of errors it produces.

The goal is to build intuition for where agentic chat-BI breaks down—and why.

I think this can help data teams a lot: not just to benchmark models, but to understand the practical limits of these systems and how to improve them.

This will be quite empirical, but I think it’s a necessary step to build that intuition.

Let’s go.

The Setup

Inspired by Jacob Maston blog post, where he tested BIRD-Bench with schema-only context, I used the following two benchmarks:

• BIRD: the most widely used text-to-SQL benchmark. It has 500 question–SQL pairs across 11 databases.

  Context provided: column descriptions only.

• DABStep: a newer benchmark from Adyen and Hugging Face. It includes 450+ tasks derived from real financial analytics workflows—not synthetic questions, but actual problems data analysts face at a payments company.

  Context provided: one large manual.md file + some column descriptions.

BIRD is large, but label quality can be uneven. I isolated a subset of BIRD (the financial dataset) and ran an initial LLM pass to validate the labels. Only 15 questions remained.

DABStep, on the other hand, has only 10 labeled questions in its dev set.

So I merged the two sets. I now have 25 questions that should, in theory, be close to the edge of the kinds of “real” questions someone might ask a system like this.

Yes, this is too small to produce a reliable performance metric. But it should be enough to surface failure modes and collect a set of wrong answers.

Eval Framework

I used Nao as the evaluation framework—they provide a few utilities that make the process pretty smooth.

You simply define question/answer pairs in separate YAML files:

name: dabstep_1681
prompt: ‘For the 10th of the year 2023, what are the Fee IDs applicable to Belles_cookbook_store?


  Guidelines: Answer must be a list of values in comma separated list, eg: A, B, C. If the answer is an empty list, reply with an empty string. If a question does not have a relevant or applicable answer
  for the task, please respond with ‘’Not Applicable’‘’
sql: SELECT ‘741, 709, 454, 813, 381, 536, 473, 572, 477, 286’ AS expected_answer

And then nao test cmd processes them one by one:

• Run chat agent on each question

• Compare the result with the golden answer

• Collect token usage + tool-call metrics along the way

• Serve a UI to explore the result

For both benchmarks, I followed the same procedure:

• Create a DuckDB instance with the benchmark data

• Run nao sync to dump schema metadata into context files

I also cleaned up the context provided by the benchmarks and moved the column descriptions into Nao’s native format for both datasets.

  └── databases/
      └── type=duckdb/
          └── database=dabstep/
              └── schema=main/
                  └── table=*/
                      ├── columns.md
                      ├── description.md
                      └── preview.md

For DABStep, I simply copied the large manual.md file into the docs/ folder and referenced it in RULES.md.

I first ran a few smoke tests to get a feel for the models: I had to tweak the RULES.md file for DABStep. The agent was skipping the context files I’d placed in the docs/ folder. So I added a classic rule in RULES.md:

IMPORTANT: Before writing any SQL query, you MUST read `docs/manual.md` first. 
It contains critical business definitions that you cannot guess from the data alone. 
Then read `docs/payments-readme.md` for column descriptions.

SQL is solved

Now that everything was ready, I ran the benchmark on the two datasets with Opus 4.5.

Here are the first-pass results:

• BIRD: 11/15 correct answers

• DABStep: 3/10 correct answers

When I first looked at the results, my takeaway was: LLMs have gotten really good at writing SQL. I didn’t see any SQL syntax errors.

So this confirms the intuition that SQL is no longer the bottleneck.

Next, I dug into the failures.

To do that, I used Nao’s UI, which makes it easy to inspect the agent’s tool calls and reasoning step by step.

The next sections might be a bit tedious to read, but I think they’re worth it to understand where LLMs still struggle today.

Error: Context Ambuigity

• Question

What is the top country (ip_country) for fraud? A. NL, B. BE, C. ES, D. FR

• Context

Fraud is defined in the context file as: fraudulent volume / total volume

• What went wrong

The agent interpreted volume as number of transactions, so it used COUNT(*).

But the golden answer assumes volume means monetary volume, so it should use SUM(amount).

This isn’t a SQL problem—it’s a definition problem. If the context doesn’t specify what “volume” means, the agent can’t reliably choose the intended metric.

So I added a new rule un RULES.md:

In the payments domain, "volume" always refers to monetary amount (sum of eur_a +mount), not transaction count.

And rerun the eval.

The agent picked the right interpretation of “volume,” but failed at the next failure node: it computed total fraudulent volume (an absolute value) instead of the fraud rate (a ratio).

In other words, even after clearing the first interpretation step it tripped this time on the next one (“is the metric a ratio or an absolute?”).

So my takeaway is:

Every small ambiguity introduces a new interpretation node—and each node is a chance to fail.

As analyses get more complex, the number of nodes increases, and the probability of an error compounds quickly.

Error: Knowing when you don’t know :)

• Question

Is Martinis_Fine_Steakhouse in danger of getting a high-fraud rate fine?

• Expected

Not applicable

• Agent answer

Yes

• What went wrong

The concept of a “high-fraud rate fine” isn’t defined anywhere in the data or documentation.

The manual discusses fraud levels and how they impact processing fees, but there’s no explicit fine mechanism.

The agent inferred that such a fine exists and answered “yes,” instead of recognizing that the question refers to something outside the available context.

I tried adding this to RULES.md:

If a concept or metric is not defined in the documentation or data, 
do not invent a definition. Answer "Not Applicable" instead.

But the agent kept returning the same wrong answer. It finds enough related data to construct something plausible.

My takeaway:

In line with the last section, we don’t only have interpretation failure nodes (ambiguous metrics, vague definitions, etc.).

We also have framing failure nodes.

Those framing decisions add another layer of compounding error:

• Interpretation failure nodes = choosing meaning

• Framing failure nodes = choosing scope (is this answerable from the available schema/docs, or is it out of scope?)

As we’ve seen, this is hard to fix with prompting alone. One possible approach would be to add a grounding mechanism, where the agent has to cite and justify its answer using specific sources from the available context and data.

Error: Lack of Common Sense

Question: For the 10th of the year 2023, what are the Fee IDs applicable to Belles_cookbook_store?

The agent debated whether “10th of the year” meant January 10 or October, and eventually settled on October.

LLMs still miss basic conventions and “common sense” assumptions.

This adds a third failure node:

• Interpretation failure nodes

• Framing failure nodes

• Common-sense failure nodes = applying basic conventions and implicit assumptions

The problem with these common-sense failures is that they’re hard to fix with context. You can’t keep adding endless rules to RULES.md for things that should be basic intuition.

These issues ultimately need to be solved by the underlying model.

Iterative Context Building

As you can see, building an evaluation loop—where you confront your LLM with canonical (gold) answers—is essential.

It’s the only practical way to surface failure nodes, understand what kind they are, and then decide what to do next.

A key trap is to use an LLM to generate the evaluation set.

That’s usually the wrong approach: the model will generate the most likely questions given your context, which means you’ll mostly test “happy paths.” Your agent will look artificially good—and you’ll miss the real failure nodes.

The better approach is to observe the system in production:

• Log failures and wrong answers

• Classify them by failure node type (interpretation, framing, common sense, etc.)

• Look for recurring patterns

Once a pattern emerges, add it to your evaluation set. Then iterate on your context and prompts until the results stabilize.

The advantage of tools like Nao is that this process becomes reproducible and easy to plug into CI. You can run the test suite on every context change—every RULES.md update, every new column description, every doc tweak—and catch context drift the same way you prevent code regressions.

Rules.md Spaghetti Prompt

RULES.md can quickly turn into a dumping ground of “Important:” instructions.

And at some point, the model stops treating it like guidance and starts treating it like noise.

There’s also a second trap: overfitting.

When you debug by patching each new failure with a very specific rule—something like:

“If you get asked about X, then do Y.”

…it might fix that case, but it doesn’t generalize. It doesn’t scale. And it gradually makes your context longer, more brittle, and harder for the model to follow.

So where does that leave us?

If context isn’t enough—and rules don’t scale—how do we get reliability?

Probably by combining probabilistic LLM behavior with deterministic metric definitions.

That’s what we’ll dig into in the next post.

I hope this post helped you understand how modern Chat-BI systems are built.

This is the first episode of a mini-series we’re working on with the Nao team, exploring Chat-BI architectures and design patterns.

In the coming weeks, we’ll publish deeper dives on:

• Semantic models and Chat-BI

• The impact of Chat-BI on data roles

Stay tuned.

We have released a new episod of our podcast with blef (in french). Check it out here:

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

It usually starts the same way.

Someone on the team says:

“How hard can it be?

We already have the data.

LLMs are now super clever.

Let’s just plug them together.”

So they do.

They give the model:

• access to the warehouse

• the schema

• a system prompt that says:

The first demo works.

They type:

“What were last month’s revenues?”

The model writes SQL, the database returns numbers.

Seeing your chat working so quickly feels so good…

Like riding a horse bareback: raw power moving in the right direction—no saddle, no reins, no rules.

Until…

… The horse starts to accelerate…

Edge cases are found ?

→ Add an instruction in system prompt

A wrong join?

→ Add more schema context.

A business rule?

→ Paste a definition.

Then come the tools.

At first, there’s just:

• run_query

Then:

• list_tables

• describe_table

• get_sample_rows

• metric helpers

• validation helpers

• retry helpers

• …

Soon, the system prompt is no longer a prompt.

It’s a document.

And because all of this lives in the context window… Every single LLM call becomes slower, more expensive.

And even worse: performance starts to degrade.

You hit the classic “lost in the middle” effect where instructions buried in the center of a long prompt are quietly ignored.

Your LLM doesn’t get smarter, it gets lost:

And more broadly, everything feels heavy. Overengineered. You’re no longer building a product. You’re maintaining scaffolding.

In 2025 the industry figured this out and teams began to realize something uncomfortable: the problem wasn’t the model, it was the environment.

Claude Code showed a different way to build agents — not by adding more orchestration, but by simplifying the world the model operates in.

Instead of giant prompts and layered control systems, it relied on:

• A filesystem as the primary interface

• A small set of native Linux tools

No prompt bible. No tool explosion.

Why did this work so well? Because file systems and Linux CLI tools are deeply embedded in LLM training data. Models have seen: ls, grep, sed, cat millions of times in their training sets.

They don’t need to be taught this environment. They already know how to move inside it. You’re not forcing them to reason in an artificial orchestration layer.

So the obvious question is now: What if we applied the same idea to Chat BI?

This is what the Vercel team did:

They started by implementing a list of super complex tools:

And finally decided end of 2025 to remove most of them, and replaced it with:

The results speak for themselfs:

Agentic coding flipped the approach, now Chat-BI agent browses files to get insight about semantic, schemas, data strucure and finaly use a query tool to retrieve the data.

2025 Chat BI systems look like this:

• A filesystem

• Context split across local files

• A harness

What we call the harness is the set of tools and constraints provided around the LLM.

The most well-known examples are Claude Code and Codex, but you can also build one easily using frameworks like LangChain / LangGraph.

Chat-BI in action

So the question now is: how do we bring all of this together into one system?

For this, we gone use Nao’s Jaffle Shop project, which you can start with a single command:

docker run -d \
  --name nao \
  -p 5005:5005 \
  -e BETTER_AUTH_URL=http://localhost:5005 \
  getnao/nao:latest

You then get access to a chat interface running an agent against a DuckDB file.

The project provides a predefined context structured into folders:

  nao/example/
  ├── RULES.md
  ├── docs/
  │   └── notion/
  │       └── jaffle-shop-information.md
  └── databases/
      └── type=duckdb/
          └── database=jaffle_shop/
              └── schema=main/
                  └── table=*/
                      ├── columns.md
                      ├── description.md
                      └── preview.md

There is, of course, a system prompt, kept intentionally concise (RULES.md):

We are a company that has jaffle shop, we are selling products to our customers. You have to help us to analyze the data and answer questions about the business.

Always be concise and to the point, explain the data and the business logic in a way that is easy to understand. If the user does not give enough details, ask for more details.

The databases/ folder contains metadata about the DuckDB database. For each table, there are three Markdown files:

• Column list

# customers

**Dataset:** `main`

## Columns (7)

- customer_id (int32)
- first_name (string)
- last_name (string)
- first_order (date)
...

• Descriptions and metadata

# raw_payments

**Dataset:** `main`

## Table Metadata

| Property | Value |
|----------|-------|
| **Row Count** | 113 |
| **Column Count** | 4 |

## Description

...

• Data Preview

# customers - Preview

**Dataset:** `main`

## Rows (10)

- {"customer_id": 1, "first_name": "Michael", "last_name": "P.", "first_order": "2018-01-01 00:00:00", "most_recent_order": "2018-02-10 00:00:00", "number_of_orders": 2, "customer_lifetime_value": 33.0}
- {"customer_id": 2, "first_name": "Shawn", "last_name": "M.", "first_order": "2018-01-11 00:00:00", "most_recent_order": "2018-01-11 00:00:00", "number_of_orders": 1, "customer_lifetime_value": 23.0}

The Harness

For this project, Nao provides its own harness: a set of tools available to the LLM.

These tools allow the LLM to build its own context by reading files from file system.

Any coding-oriented harness could work as well: Claude Code, OpenCode, Codex, and others.

It exposes a small set of tools:

• File operations: list, search, read, grep

• SQL operations: execute_sql

• Rendering: display_chart

• UX helpers: suggest_follow_ups, propose_next_user_questions

These tools are composed into a simple workflow:

The model no longer tries to memorize everything inside a single prompt.

Instead, it navigates a structured environment, explores files, retrieves context when needed and executes SQL only when necessary.

Tests

Let’s test a few queries.

You can see in the screenshots how the agent explores the metadata files before executing the final SQL query.

Now let’s try more advanced cases.

• Non-existent data

• Ambiguity trap: monthly revenue

Here are the model’s “thought”:

The user is asking about monthly revenue. I need to query the orders table to get revenue aggregated by month. Let me first check the orders table structure to understand the date column and amount column.

From what I know:
There’s an orders table
It has order_date and amount columns
I need to group by month and sum the amounts

The model didn’t use the metric defined in the YAML file. Since “revenue” is open to interpretation, it should have either asked for clarification (completed orders only? net revenue excluding returns?), or used the metric definition directly from the YAML.

• advanced SQL:

Looks good !

Final try:

It failed once — but eventually produced the correct answer.

With such a simple schema, it’s hard to truly push the system to its limits.

But don’t worry.

That’s exactly what the next posts in this series are for. 😉

I hope this post helped you understand how modern Chat-BI systems are built.

This is the first episode of a mini-series we’re working on with the Nao team, exploring Chat-BI architectures and design patterns.

In the coming weeks, we’ll publish deeper dives on:

• Semantic models and Chat-BI

• Context maintenance in agentic systems

• The impact of Chat-BI on data roles

Stay tuned.

We have released a new episod of our podcast with (in french). Check it out here:

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

Every week, a new model drops.

Last week, we even got two.

Models keep getting better.

And somehow, so does my anxiety.

January was a strange month:

• Wow moments: crazy productivity gains.

• Ouch moments: watching more and more of the value chain get eaten by a couple of players.

The question I’ve been obsessed with lately as a consultant and entrepreneur:

Where is the value now?

How do you build anything defensive at all?

Software as Specs

plan → implement → validate

What’s becoming clear: there is very little defensible value left in implementation.

LLM are much better, faster, resilient that us to write code.

But what about the spec side ?

LLMs are excellent at doing. They are much worse at structuring.

If you let them loose without constraints, you get:

- JSONL files scattered everywhere,

- massive, unreadable code files,

- implicit conventions no human would ever agree on,

- “it works” systems nobody dares to touch.

Why ?

Because structuring requires understanding a company context, an ecosystem context, and a problem context. That context exists in the real world — and AI doesn’t have direct access to it.

That asymmetry is our edge: we perceive the environment, understand the vision and constraints, and the agent implements the solution. This is likely where a true defensive moat can be built.

And I think this implies we should rethink how we distribute our knowledge.

Previously, as consultants or entrepreneurs, we delivered value through code and implementation. Now, perhaps the leverage shifts toward delivering specs — not the software itself.

To illustrate this “spec-only” shift, I came across an open-source project last weekend that contains … only four md files:

The provider delivers specification, invariants, constraints, and intent.

The user (and their agents) handle customization, environment-specific choices, and ownership of the implementation.

If implementation is just a commoditized expansion of a plan… why distribute the expanded form at all?

IDE for X

In the last 12 months, I’ve moved from code writer to agent orchestrator.

This new abstraction has materialized in a shift in my tooling. My development tools have changed focus: from an IDE to an Integrated Review Environment.

My IDE is now mostly a diff viewer.

tmux has become my multi-agent chat manager.

There’s no reason this evolution should apply only to developers.

Many SaaS tools today are rigid workflow builders — forms, and if you’re lucky, a drag-and-drop canvas.

But I think there’s an ocean of opportunity to build workflow-specific, agent-centric environments:

Such tools would focus on two core tasks:

1. Context gathering — collecting files, artifacts, documentation, and rules.

2. AI-generated artifact review — validating and refining what the agent produces.

For example:

• Accountants provide a set of transactions and review the finalized company balance sheet.

• Marketing teams provide company documentation and review generated content (blog posts, LinkedIn posts, campaign drafts).

• Doctors input patient observations and review the proposed diagnosis.

• Teachers upload learning objectives and review the generated teaching materials.

There’s no reason developers should be the only ones having all the fun 🙂

Inter-agent distribution

OpenClaw — and especially Clawbook — are showing us something important: a new agent-to-agent market is emerging.

Right now, only one side of the transaction is truly LLM-powered.

The user searches for a product through ChatGPT (or another assistant). The demand side is agent-augmented but the supply side is still mostly human-optimized: websites, dashboards, forms, traditional SaaS interfaces.

We all understand by now that LLMs are only as good as the context we provide them.

If an agent has access to your emails, files, Notion, and internal documentation, it becomes dramatically more powerful. It doesn’t just answer questions — it acts.

And this new generation of local-first agents is essentially coding under the hood. Which means they prefer interacting with systems that are agent-native, such as:

• CLI interfaces

• MCP servers

• API-first services

They don’t need visual interfaces.

They need structured, programmable access.

When your personal agent researches, compares, or integrates services, it will naturally favor tools that require less effort — and fewer tokens — to use.

That’s why I think there’s opportunity in transforming services built around human UIs (web apps, dashboards) into agent-native interfaces (CLI, MCP, APIs).

The intelligence embedded inside the user’s agent (Claude Code, local agents, etc.) handles the final-mile customization — adapting your service to the user’s specific context.

That level of personalization — grounded in the user’s own data and environment — is extremely hard to compete with.

To illustrate this: Stripe is moving in that direction and has released an agent charging feature.

So these are the areas where I see opportunity in the coming months.

I’m starting to see signals that the market is moving in these directions, as I tried to illustrate with a few examples.

Let’s see how it plays out.

One thing, however, feels certain:

Value is concentrating in the hands of a small number of companies — and even individuals.

And it’s becoming harder and harder to compete…

I am launching a new podcast with :)

The idea?

Everyone is trying to figure out how to get the most out of all these AI tools.

With this podcast, we want to share what we’re discovering — and invite guests to explain how they use AI in their day-to-day work.

“How Do I AI?”

The first episode is in French, but we’ll also be releasing episodes — and inviting guests — in English.

We’ll keep improving things episode after episode, so don’t hesitate to share your feedback.

Thanks for reading,

-Ju

I found myself trapped in a constant back-and-forth, acting as a manual bridge between different agents.

I felt less like a developer and more like a manager micromanaging engineers.

And I don’t like it.

It got me obsessed with a single question: how do I scale my agent usage?

I don’t want to manage 1–5 agents in parallel; I want to manage 20 or 30.

Last Sunday, I came across Steve Yegge’s GasTown Medium post from early January.

I remembered reading it before, but it didn’t click at the time.

This time, I got that “aha” moment (writing last week’s post probably helped it land).

So I went down a rabbit hole to understand how the craziest vibe coders on the planet are leveraging coding agents.

By the end of the month, I want to have good “agent swarm” infra in place—enough to run 20–30 sessions in parallel.

In this post, I share what I added to my stack this week and my first exploration of agent orchestration tools.

If you still need convincing, try watching this:

What happened this week

I ditched my IDE

Yeah, I never thought that would happen…

I almost didn’t open VS Code (or Cursor) this week.

I run everything in tmux now and can jump super easily across sessions.

I split each session into panes and windows, which makes it really easy to run several Claude Code sessions in parallel.

How do I check code? nvim + Neo-tree.

How do I check diffs ? directly in GitHub.

Beads in the mix

As I mentioned in my last post, I was struggling to coordinate multiple agents working on the same problem—each tackling sub-stories in parallel.

I started using Beads, and it works pretty well.

(So well, in fact, that Anthropic seems to have incorporated it directly into Claude Code yesterday.)

Now I plan first: a quick back-and-forth with an agent until we land on a solid plan using OpenSpec.

Once the specs are ready, I ask my planning agent to transcribe them into Beads, then let it do 3 back-and-forth rounds with Codex via the Codex CLI.

Stories are linked in a DAG, so Claude Code can then spin up x sub-agents.

With this setup, I’ve been able to run 5–10 sessions in parallel.

And honestly, it’s been working pretty well—but I still need to jump in too often:

Things aren’t properly tested.

Simple bugs go through.

Simple architecture decisions aren’t made.

And these stupid permission requests… Speaking of witch:

Sandboxing: no clean solution

I tested the sandboxing solution in Claude Code, but it was too restrictive—for example, the agent couldn’t access localhost.

So I ended up using the --allow-dangerously-skip-permissions flag.

It works great, but it doesn’t feel very… safe.

Any tips?

Browser Interaction

I started to use broser-agent from Vercel and it’s really good, much faster than claude code chrome feature.

Next Week, Next Level

Next week, I want to take this setup to the next level.

To do that, I looked into a few agent orchestration frameworks:

- multiclaude (312 ⭐)

- GasTown (5.2k ⭐)

- claude-flow (12.6k ⭐)

I don’t want to describe them in detail in this post but instead understand how they solve these problems:

• Coordination

• Parallel Execution

• Merging

Let’s go !

Coordination & Task Tracking

All three projects follow a similar approach: one agent has a dedicated planning role—it pulls the current open tasks and assigns them.

Multiclaude

Agents communicate by writing messages to files.

The planner drops tasks into each worker’s folder. A daemon prompts workers to check for new tasks; they execute them and write results back.

No fancy tools—just files and polling.

GasTown

GasTown uses a dedicated MCP mail system.

Each agent gets a mailbox and can send/receive messages via that MCP mailbox.

GasTown uses this for all communication:

• Agent starts → a hook reads the inbox → picks up work.

• Done → the agent updates the inbox.

Agents don’t talk to each other directly—only via mail—so each agent’s context stays clean and doesn’t get polluted.

Claude-Flow

Claude-flow, on the other end of the spectrum, is more complex:

No files, no mail—everything is coordinated in memory by a hierarchy of planner agents.

A strategic planner breaks work down into tasks, and a router assigns each one to the best worker, learning over time which agent type performs best.

Workers claim tasks from a shared registry. If an agent dies, the task is released and picked up by another worker.

Parallel Execution & Isolation

20 agents touching the same codebase = chaos.

Multiclaude and GasTown avoid that by leaning on Git worktrees.

For each feature, the planning agent:

• creates a worktree in a central location (e.g., ~/.multiclaude/ or ~/gt/)

• creates a dedicated tmux session

Claude-flow takes a different approach:

No worktrees—just a shared codebase, where agents claim tasks.

A claim means: “I’m working on this, don’t touch it.”

If an agent dies, the claim is released and another agent can pick the task up.

Diff Merging

20 agents = 20 branches.

How do changes land in main?

This “merge wall” gets brutal at 20+ parallel workers: every merge shifts the baseline, and later PRs end up targeting code that’s already changed.

Multiclaude

The Multiclaude philosophy puts CI front and center.

If it passes, the code goes in—and the next PRs need to adapt.

The resolution workflow looks like this:

The daemon regularly asks the planner to check PR status.

If it detects a failing PR, the planner assigns the fix to the original worker.

GasTown

GasTown, on its end, leverages Beads queues.

Each time a worker finishes, it pushes to GitHub and adds a new message to the review queue.

A dedicated agent, running in its own worktree, polls the review queue, merges PRs that can be merged, and sends a message to the planning agent if conflicts occur.

The planning agent then asks the initial worker to resolve them.

Claude-flow takes a different approach: no branches, no worktrees, just a shared codebase coordinated through task claims.

Agents claim work to avoid conflicts, propose changes, and rely on a consensus mechanism—rather than Git—to decide what gets merged.

I have limited experience with these frameworks so far, but it’s interesting to see where the real problems are—and how they’re being solved today.

Some solutions might be over-complexified, but they still offer a lot of ideas you can borrow and implement in your own workflows.

One thing is clear: agents need to communicate with each other, especially for conflict resolution.

That’s a key piece, and I really like the mail MCP approach. It’s an elegant solution that could scale to team collaboration as well. If one developer has 20 agents working on a repo, then a team of 5 has ~100 agents on the same codebase… that’s a lot of conflicts to resolve 😅

Within a few months, Claude Code and Codex will probably integrate these patterns natively, hiding most of the complexity from the user.

What I’m less sure about is whether they’ll allow orchestration across providers—which I think has a lot of value, for example:

• easy tasks for OSS models

• hard tasks for Codex

• regular implementation work for Claude Code

Finally, all of this is currently centered around pure software engineering.

But in the data world, what does it mean to have dozens of agents running in parallel?

I see only one way: truly adopt git-for-data approaches across the stack and properly isolate agents.

Thanks for reading,

-Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

Everyone’s coding workflow has changed in the last few months:

copy-pasting → inline completion → agent.

The web is full of hype, and it’s hard to separate signal from noise.

I’ve been experimenting a lot lately across personal projects, open source, and client work.

I’m convinced we now have genuinely powerful tools in our hands—while all of us are still figuring out how to use them well.

So I want to use this newsletter to share practical tips and tricks.

Here’s my ask:

How do you vibe-engineer?

The goal isn’t to deliver thousands of AI coding insights—it’s to start a conversation in the comments and learn from each other.

I’d love to hear from your experience: comment below or reply to this email with your best tips and tricks.

I’ll share the best insights I receive in future newsletter issues.

My Stack

The IDE Journey

I’ve been using VS Code for years, but this past year has been a bit of a rollercoaster.

I switched to Cursor in 2024.

Then over the summer, it started crashing my machine—most likely because I opened a project that was simply too large.

Unlike Claude Code or Codex, Cursor indexes your entire project to enable semantic search.

Claude Code and Codex, on the other hand, rely more on grep and other CLI tools.

That approach is probably slower in some cases, but it can be more efficient in terms of output and long-term maintenance (this Vercel post is a good illustration).

I’ll write more about agent tooling this in the coming weeks.

After the Cursor incident, I went back to VS Code, and I’ve been using it ever since.

The Agent: Claude Code

I started on the Pro plan, but I hit the limits pretty quickly—so I upgraded to Max ($200/month).

If you’re considering the $100 plan: from what I’ve seen, it’s intentionally restrictive and tends to nudge you toward Max.

If you use it heavily, you’ll probably end up upgrading anyway.

That said, I use it now for everything—coding, project management, company management, admin tasks.

So for my personal case, the price is worth it.

Since late December / early January, the output quality has jumped a lot with the latest Opus 4.5 release.

Everything suddenly got… better.

Less fighting. Fewer retries. More tasks done in one shot.

The Shift: Local-First Everything

Here’s where things got interesting.

Last year, I started stripping out cloud tools:

• I killed Notion

• Stopped using Google Sheets and Drive

I vibe-engineered a custom CLI for accounting. I built a habit tracker that runs on a my Tailscale network.

Everything became local.

All invoices and reports are Markdown files. When I need a database to power a web app, I just use SQLite.

And after getting tired of having 10–15 VS Code windows open at the same time, I even tried going full tmux + Neovim.

But I gave up.

My brain is just too wired for VS Code, and I’m too lazy to accept the short-term productivity loss.

Tips & Tricks

Here’s an unstructured list of tips and tricks—patterns I’ve seen work.

Plan Mode - Don’t Be Lazy

I’ve noticed Claude wants to DO DO DO. It’s eager. It wants to start writing code immediately.

My role as the coder is to BREAK BREAK BREAK.

What works for me is forcing planning first. I spend a lot of time scoping the requirements. Plan time is where we add the most value.

The more detailed the specs, the better the output.

I’ve also noticed that when I’m tired at the end of the day, I tend to let things slide too easily—and I regret it later.

The potential impact of being tired at work is way higher now than it used to be :)

Multi-Agent on Same Branch

I let multiple agents work on the same branch. It sounds messier in theory, but I’ve found it cleaner in practice.

A lot of people recommend using worktrees. I do sometimes—but once you run multiple worktrees, you often end up re-building your local setup each time.

So I only create worktrees when I really need true isolation.

What I do instead: I tell my agents, “commit ONLY your changes.”

You can even create a slash command for that:

I think the problem here is that agents are not aware of what the others are working on, but knowing they can isolate their changes and commit only when needed helps.

I’m still searching for the best setup for this problem.

“SIMPLIFY !!!”

I keep telling yelling at the agent: simplify.

It’s not for no reason that Anthropic released a code-simplifier subagent.

Every time I end up in a “simplification review,” I realize my original plan wasn’t good enough.

And yes—you’ve probably noticed it too: review is now critical.

To tie this back to the first point, engineers add the most value at:

• design time

• review time

For this review process, I accumulate notes in CLAUDE.md.

Over time, the agent gets higher-quality context, which steadily improves the output.

After a session, I ask Claude Code to look up the session transcript in ~/.claude (sessions) and extract the useful bits into CLAUDE.md: how we solved bugs, architecture decisions, bugs we found, coding patterns, etc.

For workflow-oriented memory—how to do stuff—I create skills.

For company management and other admin workflows, that’s been especially helpful.

PoC Mode

A good pattern I’ve found is to run PoCs in an isolated environment.

Instead of confusing the agent with the rest of the codebase, I let it try a new tool or a new design in a dedicated folder first. This works really well.

Agents are also great at copying patterns, so having a reference implementation PoC becomes a solid guideline—and helps avoid it getting lost during the full implementation.

Starting fresh like this (globally) has always given me good results.

Coding in 2026 = Building Agent Loop

I’ve gotten good results by designing agent tasks where the agent can evaluate its output against a clear baseline—tests that must pass, expected UI behavior, or target values.

Building these loops:

• forces you to think in terms of output instead of “how”

• lets the agent run longer (and more autonomously)

Good engineers in 2026 will probably be the ones who master designing agent loops—and who get creative about how to define the baseline.

Multi-Model Loop (Claude + GPT)

I’d seen some Codex hype, so I decided to try it.

Codex is actually really good at:

• architecture analysis

• code review

• hard problems where Claude Code gets stuck

I started on the $20 plan and I’m pretty happy with it.

Now I’m constantly copy-pasting messages back and forth between the two panels:

• “review this”

• “write detailed specs”

• “why did this fail?”

• “what are the edge cases?”

• etc.

This is also an area where I see a lot of potential: getting Claude Code and Codex to talk to each other in a loop until they converge on a good state—then I can jump in and make the final call.

I found this project that might be a good option:

But what I’d like is a YAML-based interface for orchestrating coding agents.

agents:
  builder:
    provider: claude_code
    model: opus
    prompt:
      - ""

  reviewer:
    provider: codex
    model: latest
    prompt:
      - ""

....

…but the hard part is probably that this kind of DSL isn’t easy to generalize.

This is more or less the approach used by the Wiggum Loop.

The idea here is brutally simple: just let Claude Code run in a loop until it reaches a good state.

Claude Code even released an official plugin for it.

I haven’t tested this yet, but I think agent orchestration is going to be a pretty interesting topic over the next few months.

Frontend: Browser Control

For frontend tasks, I’ve seen big efficiency gains using the claude --chrome extension.

I let Claude Code iterate on the code, start the dev server, and pull console logs directly from the browser. It can also use screenshots to get visual feedback from the UI.

That said, I’ve found it pretty slow.

To-Test List

I haven’t tested it yet, but this project keeps popping up in my feeds—and it’s currently #1 on my list:

As I mentioned above, my main area of experimentation right now is multi-agent orchestration—getting multiple agents to collaborate around a shared source of truth. I think Beads could help a lot with that.

I’m curious:

- What’s your stack? (IDE, model, workflow)

- What one trick changed everything for you?

- What overhyped thing actually doesn’t work for you

How to share:

- Drop in comments below

- Email me: respond to this email

I’ll compile the insights in the next newsletter release!

Thanks a lot !

Thanks for reading,

-Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

Last year, I published less than usual: 14 posts.

Not because I ran out of ideas — but because I was busy building:

• Helped 6 data teams build data platforms (some with AI, some without — still possible in 2025 😉)

• Shipped my first public products and OSS projects:

  • Boring Data — Terraform data stack templates

  • Boring-catalog — file-based Iceberg catalog

  • Boring-semantic-layer — Ibis-based semantic layer

  • kurt — an IDE for writers (more on this soon)

Across all these projects, I had to make a lot of design decisions.

During the end-of-year break — helped by Miami’s sunny vibes 🌴 — I reflected on:

• what actually worked

• what didn’t

• and the patterns I keep seeing over and over again

This post is less technical than usual.

I attempt to formalize the Boring philosophy.

(Slightly ironic to write this in a not-so-boring city 😄)

1 — Why Boring?

Because complexity is the default tendency of most engineering projects I see—mine included.

Not because teams are bad.

Not because engineers are careless.

But because of our constant craving for tools.

As a result, complexity naturally accumulates:

• every new tool solves a local problem

• most tools eventually become obsolete

• every vendor wants to be the vendor (aka platforms)

• every abstraction hides a detail… and introduces another

And let’s be honest: vendors are really good at developer marketing 🙂

This marketing-driven push nudges the industry into ideological dilemmas:

• OSS vs SaaS

  “Just use X, reduce TCO” vs “Vendor lock-in is evil”.

• Snowflake vs Databricks

  (no comment 😅)

• Cloud vs on-prem

  “Just use managed services—100 engineers worked on this button”.

  vs

  “AWS is down? I don’t care, I spent hundreds of days building my own setup”

The problem isn’t that these debates are wrong.

It’s that they’re often argued without context, which makes it extremely hard, as an engineer, to pick the right tool for the right situation.

2 — What Boring Engineering Is Not

Boring Engineering is not:

• anti-innovation / conservative

• anti-SaaS

• anti-cloud

• anti-complex systems

Boring Engineering puts complexity where you can reason about it and maintain it.

Not where only the original author can.

3 — My Mistakes

Mistake 1: Picking a tool too early

Demos always look good.

Tools always have edge cases—hidden corners.

So now I default to proven, boring choices—until the problem demands otherwise.

Here’s what my current default stack looks like:

• Code interfaces? Python

• Compute? a Linux VM + DuckDB

• Storage? S3 bucket

• ELT? dlt

• Application database? PostgreSQL

• Collaborative data platforms? Snowflake or Databricks

• To-do app? A piece of paper in my pocket

• Car? Renault Kangoo ^^

  

Mistake 2: Over-generalizing a solution

I’ve repeatedly tried to design “generic” solutions that would cover every future use case.

In practice, this often resulted in:

• poor or useless interfaces

• complexity hidden behind overly implicit abstractions

• systems that were hard to understand, extend, or debug

Trying to hide complexity doesn’t remove it—it just moves it to places where users have less control.

This is what I’m trying to achieve with the boring-* projects:

• easy to install (e.g. pip install …)

• no Docker required

• smart defaults that work on day one, but can be tweaked later

• ideally written in Python, making them easy for users to customize

Boring tools are designed to:

• be learned in minutes, not weeks

• fade into the background once adopted

If learning the tool becomes the work, the tool is the problem

(yes, certifications…)

Mistake 3: Designing for a future that never arrived

“We can scale to hundreds of terabytes.”

I’ve said it. I’ve built for it.

In many projects, features I was proud of later turned out to be over-engineered for scale (yes, Spark 😅).

The reality is simpler.

This is the core DuckDB message: a single node is good enough for a very large share of data workflows—in 99% of companies.

And this isn’t just theory.

I’ve verified it repeatedly across client projects.

From archi-tech to archi-preneur

The core of the Boring philosophy is being output-driven first.

Because of this, I now try to behave less like an architect—and more like an entrepreneur.

That means:

• ship first

• get feedback

• tweak later

This is why the MVP mindset matters so much in data engineering.

MVP doesn’t mean trash output.

It means doing one very specific thing—and doing it really well.

When I start a project today, I avoid immediately building a generic solution.

Instead, I ask myself:

What is the question we need to answer first?

Then I plan backward.

Example:

• Can DuckDB support the load?

  Instead of building the full pipeline upfront, I generate data and quickly run a stress test.

• Can dlt support this source?

  I build this in isolation first, validate the assumptions, and only then move on.

The goal is to gather information early and push one-way decisions as late as possible.

Boring Design Philosophy

A boring system is:

• as little code as possible

  From An Engineer Sight

  Issue 43 - The Best Code You Never Wrote

  Code is technical debt. The optimal spot for engineers is to write the least code possible but still write code…

  Read more

  a year ago · 6 likes · 6 comments · Benoit Pimpaud

• optimized for easy maintenance, not fancy features

• understandable by the largest number of engineers possible

• designed without assuming massive growth

Is AI boring?

Boring Engineering isn’t anti-AI—it’s about using AI boringly: as a productivity multiplier, not a revolution.

These 2025 projects allowed me to deeply engage with the AI coding wave.

Like many of you, my social feeds has been full of “game-changing” claims.

I don’t know whether AGI arrives tomorrow.

Engineers won’t be replaced.

What is happening, though, is more interesting.

There’s a boring side to this wave—and that’s where the real leverage is.

For me, coding agents like Claude Code have completely changed how I work this year.

Over the last two years, I gradually moved from:

• writing 100% of the code myself

• to inline completions

• to full prompting

Today, I spend most of my time coordinating agents and reviewing changes.

In 2026, the boring way to engineer might be to leverage AI.

You keep the design.

You outsource the implementation—while staying accountable for the result.

Outlook for This Year

AI has changed how we build.

Everything feels new, and everyone is still figuring out how to use these tools effectively.

This year, I want to get back to publishing weekly, as I (almost) managed to do in my first two years.

This newsletter will embrace the Boring philosophy, with a clear focus on engineering in an AI-first world:

• Stress-testing data tools: understanding where tools work, where they break, and which ones are best suited to which problems

• Leveraging AI coding assistants: practical workflows, patterns, and limits

I want this newsletter to be:

• opinionated, but grounded in practice

• focused on real-world trade-offs, not ideology

• useful for engineers making decisions under constraints

Thanks for reading,

Ju

Bonjour!

I’m Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

In this post, I wanted to share my experience building a chat-BI agent using BSL.

BSL is an open source Semantic Layer we built with Hussain Sultan (xorq).

It aims to be extremely lightweight — pip-installable and compatible with any analytics DB through Ibis.

Because BSL is designed to be minimal and flexible, we thought it would be pretty cool to expose it through a chat interface directly in the terminal.

Want to try it?

Choose your poison:

export OPENAI_API_KEY=sk-...
export ANTHROPIC_API_KEY=sk-ant-...
export GOOGLE_API_KEY=...

and for OpenAI run:

uvx --from "boring-semantic-layer[agent]" \
    --with langchain-openai,langchain-anthropic,duckdb \
    bsl chat --sm https://raw.githubusercontent.com/boringdata/boring-semantic-layer/main/examples/flights.yml \
    --llm openai:gpt-5.2 

or Anthropic:

uvx --from "boring-semantic-layer[agent]" \
    --with langchain-openai,langchain-anthropic,duckdb \
    bsl chat --sm https://raw.githubusercontent.com/boringdata/boring-semantic-layer/main/examples/flights.yml \
    --llm anthropic:claude-opus-4-5-20251101

This post is the first in a series where I’ll share everything I’ve learned over the past few weeks while building this kind of agent.

There are three main ways to wire an LLM to your database:

1. Direct SQL Generation

   User → LLM → SQL → DB

2. via MCP

   User → LLM → MCP + Semantic Layer → DB

3. via Tools

   User → LLM → LLM Tool + Semantic Layer → DB

Let’s dive in !

Option 1: Direct SQL Generation

This is the simplest approach: LLMs keep getting better at writing SQL, so you can pass them a well-crafted system prompt and let them translate user requests directly into SQL.

This works reasonably well for small and simple data models, where the number of tables and relationships is limited.

However, as your data universe grows, more and more context ends up living only in your analysts’ heads.

The LLM doesn’t have access to that implicit knowledge — so it naturally makes more mistakes.

For example, a user_id in table A may not represent the same entity as a user_id in table B, even though the column names look similar.

Without that context, the LLM confidently produces incorrect joins or misleading queries.

The more information remains implicit or hidden, the more frequently the LLM will get things wrong.

A way to reduce hallucinations is to limit the LLM’s degrees of freedom by introducing a semantic layer.

This layer defines pre-approved metrics, joins, and aggregation patterns, which the LLM can safely use.

Instead of translating natural language into complex SQL, the LLM only needs to map user intent to a small set of measures and dimensions.

This doesn’t eliminate hallucinations entirely, but it drastically reduces syntax errors and invalid queries.

So the next question becomes: how do we give an LLM access to a semantic layer?

There are two main ways to add this capability:

• MCP interface

• LLM Tools

Option 2: User → LLM → MCP

MCP has been everywhere in recent months.

The idea is straightforward: expose external tools to an LLM through the new MCP protocol.

It’s a great way to give an LLM access to remote capabilities—emails, Slack, databases—and it’s already widely supported across major LLM providers.

BSL supports this via a dedicated class:

This works very well… but it requires you to host an MCP server.

And that feels unnecessarily heavy (and definitely not boring) when all you need is a simple bridge between an LLM and your database.

Option 3: User → LLM → Tool

LLM tools are another way to give models additional capabilities.

You provide the model with a description of each tool: its purpose, parameters, and usage guidelines.

The LLM then takes the user prompt and returns a list of tools to execute, along with the associated parameters.

Contrary to the MCP approach, tool execution happens directly in the environment that is calling the LLM, not through a remote server.

Local coding agents use this pattern extensively.

Claude Code, for example, is essentially an LLM combined with a set of tools for searching, reading, and editing files.

Ideally, we would also like to outsource tool execution to the LLM provider.

And indeed, providers are starting to offer sandbox capabilities through their “Code Interpreter” features.

This would be the ideal workflow, but unfortunately you can’t install your own libraries inside these sandboxes, which means you can’t access BSL from within them.

So for now, the only viable approach is to handle tool execution ourselves.

The workflow is then the following:

• Step 1: Receive a request from the user.

• Step 2: Send it to the LLM along with:

  • the list of tools it can call

  • the semantic models definitions

• Step 3: Execute the tool selected by the LLM.

• Step 4: If the LLM chooses to run a query, pass that query to BSL.

• Step 5: BSL executes the query, retrieve the result, and return it to the user.

In the case of BSL, we expose four tools:

• list_models — lists the available models

• get_model — returns the measures and dimensions available for a given model

• query_model — executes a BSL query and returns or charts the results

• get_documentation — provides a set of prompts the LLM can use for more advanced patterns

These tools are just JSON definitions following the OpenAI tool format: they describe how a tool should be called and which parameters it accepts.

We wrap them in a dedicated BSLTool class that handles execution for you.

You simply provide your semantic model in YAML—and that’s it.

Any LLM can then immediately use these tools to query your database.

You can use it with OpenAI:

Or Anthropic:

No hosting, no MCP.

Just: pip install + 1 YAML file

… So boring …

From LLM Tool to Chat

Now we can have our favorite LLMs calling BSL queries and accessing your data.

To build a full charting experience on top of this, we also need to manage conversation context, multiple tool calls, and chat history.

Rather than reinventing all of that infrastructure, we rely on existing frameworks that already handle:

• LLM provider integration

• Conversation history

• Chat context management

For now, we started with LangChain/LangGraph.

We’ve implemented a first version of this in the LangGraphBackend class, which is the class used behind the chat CLI command.

The goal is to extend support to other frameworks as well as the ecosystem evolves.

There’s a lot more to say about this—especially around context management, prompt structure, and how to keep the context small to avoid exploding LLM costs.

We’re still experimenting a lot on these topics and will share our findings in a follow-up post.

Next steps

This agent feature is still quite new, and we’re looking forward to gathering feedback from users to refine the prompts and handle edge cases.

If you find any bug, don’t hesistate to open an issue here.

In the coming posts, I want to share more about context management, eval strategies, and everything I learn along the way while building this.

On the feature side, I’d love to add the following to this v0:

• support for local LLMs

• out-of-the-box Slack integration

• code sandbox support (with only DB and LLM connections allowed)

• markdown based analytics report (similar to evidence.dev but with BSL queries)

For the markdown reports, the idea is simple:

1. write a Markdown document with BSL query blocks,

2. run it through the BSL CLI,

3. get a fully rendered HTML report with charts and data tables.

This would allow you to persist the BSL queries generated during a chat session into shareable artifacts.

We are super excited by this new step of BSL.

We’re convinced that BSL is quickly becoming the lightest and most flexible semantic layer solution on the market.

A big thanks to all contributors who helped improve BSL.

If you share our enthusiasm:

• Explore the repo

• Give it a ⭐

• And show us what you build with it!

Thanks for reading,

Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

Three months ago, we launched with (xorq) the Boring Semantic Layer (BSL).

Since then, we’ve been lucky to gather tons of feedback from early adopters.

We’re excited to announce the launch of BSL v2!

This new version unlocks a set of powerful possibilities, and in this post, we’ll walk you through:

1. What v1 looked like

2. What we learned from its limitations

3. How v2 changes the game

1 - BSL v1

The first version of BSL kept things extremely straightforward:

One SemanticModel that takes as input:

• 1 Ibis table

• measures, dimensions, and join definitions (defined as lambda functions)

Example:

Querying was just as simple as selecting dimensions and measures:

In that case, the output = a DataFrame with flight counts per origin.

We then extended around this concept with:

• YAML support → define semantics in declarative files

• Chart → query results as charts, not just DataFrames

• MCP integration → expose the query() method directly to LLMs

2- Limitations

As clean as v1 was, we hit a few walls quickly:

Complex aggregation

Things like percent of total, rankings, or rolling windows often require two steps:

1. Aggregate

2. Post-process

Our simple query()interface wasn’t expressive enough for these.

We considered adding a post_agg attribute, but that approach didn’t feel elegant or scalable.

Filters

In v1, filters were limited to dimensions:

But users wanted more flexibility:

• Filters before and after aggregation

• Filters on dimensions, measures, or even raw table columns

Composability

In v1, the SemanticModel was the end of the road: once defined, you could only query it.

But in practice, teams want to compose models:

• Marketing defines a Users semantic model

• Support defines a SupportCases semantic model

• Together, they want a metric: support cases per customer category

With v1, this meant rebuilding from raw tables again.

Not ideal.

Enter BSL v2

For BSL v2, we have decided to change its core and bring it to the next stage.

We’ve almost completely rewritten it, introducing a much deeper integration with Ibis.

To understand what changed in v2, it helps to take a step back and look at how Ibis itself works.

How Ibis works

At its core, Ibis doesn’t execute queries directly.

Instead, it builds an expression graph:

• Every table, column, dimension, or measure you define is a node in the graph.

• Each operation (like group_by, count, or filter) creates a new edge.

Let’s take the following ibis query:

When the user defines agg_expr, no SQL is executed yet — Ibis creates the following expression graph:

Only when you call .compile() or .execute() does Ibis translate the graph into the native SQL of your backend (DuckDB, BigQuery, Postgres, Snowflake, …):

In BSL v1, the semantic layer was essentially a query endpoint that sat on top of the Ibis graph without integrating into it.

This means that dimensions and measures were not part of the expression graph itself, which limited composability and the ability to perform more complex transformations.

BSL is now part of the Ibis graph

With BSL v2, semantic models are now first-class nodes within the Ibis expression graph.

A semantic model is no longer just a query endpoint — it is a dedicated node in the graph that carries both dimension and measure metadata.

Concretely, this means we have introduced a new kind of Ibis table: semantic tables.

These are regular Ibis tables to which you can attach semantic information, such as definitions for dimensions and measures:

This table behaves like a regular Ibis table, but it also provides access to semantic metadata.

• Want to select a dimension? → performs an ibis .group_by()

• Want to select a measure? → performs an ibis .aggregate()

Querying your semantic model now feels like a regular Ibis query, but with a semantic layer:

This makes queries highly flexible; users can also apply ad-hoc transformations directly on the semantic table:

Additionally, this enables the use Ibis’s mutate() method, which allows post-aggregation and unlocks the following use cases:

Percentage of total:

Rolling averages

Composability

With v2, semantic tables are first-class nodes in the Ibis graph.

This means you can treat the output of one semantic table as the input to another, just like any other Ibis expression.

For example, imagine:

• The marketing team defines a “User” semantic table.

• The support team defines a “SupportCases” semantic table.

Together, they want a metric like support cases per customer segment, so they create a new semantic model built on top of these two existing models:

The user (or LLM) can then simply query the measure avg_case_value and aggregate it along any available dimension from any model.

All without worrying about where the underlying information comes from:

BSL v1→v2

Of course, all BSL v1 features remain fully compatible with v2:

• YAML-based semantic definitions — you can still define semantic tables declaratively.

• Charting — the .chart() method works as before, now directly on SemanticTable queries.

• MCP integration — expose your semantic tables to LLMs via MCP just like in v1.

Next Step

One incredible advantage of BSL sharing the same API as Ibis is that LLMs are already fluent in Ibis :)

Additionally, LLMs can now execute their own Python code in a sandbox environment.

This means that with BSL, giving an LLM access to your semantic model is as easy as handing over a YAML file with your model definition.

No MCP, no server, no hosting, nada… just a boring YAML file.

But… that’s a topic for the next post :)

We are super excited by this new milestone for BSL.

We’re convinced that BSL is quickly becoming the lightest and most flexible semantic layer on the market.

A big thanks to all contributors who helped improve BSL over this summer.

If you share our enthusiasm:

• Explore the repo

• Give it a ⭐

• And show us what you build with it!

Thanks for reading,

Hussain & Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

In the last episode of this Boring Semantic Layer mini-series, I wrote a lot about the tool from a consumer’s perspective.

Today, we welcome to the newsletter for a co-written post, where we approach the semantic layer not just as a consumption-only interface, but as a back-and-forth between modeling and consuming.

Boring Semantic Layer

John is a data analyst at a SaaS company called Monotone Labs.

It’s finally summertime, and for once, John has a bit of breathing room.

No urgent requests, no last-minute marketing campaigns.

Just time to step back and maybe look at the bigger picture.

After a long sunny lunch break, John returns to his desk around 1:00 p.m., slightly sweaty in his button-up shirt.

He sits down, opens his laptop, and stares at the now-familiar AI chat interface — blank, blinking, waiting.

Then he remembers something a friend told him over drinks last week:

“I tested this open-source semantic layer tool on our sales data — works great with Claude.

You should give it a try.”

It clicks.

He hasn’t looked at sales volume since the last product launch a few months ago — maybe now’s the time.

Alright. Let’s see what this thing can do.

He opens his Claude Desktop settings and adds a new MCP config:

{
  "mcpServers": {
    "cohort_sm": {
      "command": "uv",
      "args": [
        "run",
        "https://raw.githubusercontent.com/boringdata/boring-semantic-layer/refs/heads/main/examples/example_mcp_cohort.py"
    ]
    }
  }
}

PS for reader: yes you can try as well :)

Boom — semantic layer connected.

No install. No setup.

Just Claude talking to a clean interface over John’s order data.

He types his first prompt:

🧠 Claude thinks… calls the right tools… queries the model…

And just like that — charts. Numbers. A real trend.

Not bad for a lazy Friday.

But John’s not done yet.

He wants to break this down by customer segment.

He tries:

Nothing.

Error.

Turns out the current semantic model doesn’t include customer data.

Of course.

No panic.

He switches to Cursor, opens the repo, and finds the file that defines the semantic model.

He asks Claude:

Claude proposes a change.

He reviews the code — makes sense.

He validates and reloads the model.

Now Claude can safely access customer info — no weird joins, no hallucinations.

While he’s at it, John figures: why not ask THE crazy question?

(Yes John does not like sentences…)

John leans back.

He didn’t write a single SQL query.

He didn’t click a single dashboard filter.

Just natural language, a semantic layer, and a good chat interface.

When One Question Leads to Ten

John stares at the new chart.

It’s clear — there’s a trend worth digging into.

But instead of stopping there, he wonders: “What else could I ask?”

One of the biggest leaps LLMs enable is the ability to ask probing questions — not just answer them.

This is a well-known prompting technique.

By encouraging the model to explore the problem space, it often uncovers angles we wouldn’t think of on our own.

But this isn’t new.

It’s what we do naturally with teammates — in meetings, at coffee machines — exchanging perspectives to deepen understanding and reveal blind spots.

So far, everything John’s done has been analyst-driven:

He asked a question → hit a gap → updated the model → asked again.

But what if he flipped the dynamic?

What if the semantic layer didn’t just respond — but evolved through the conversation itself?

What if the LLM could suggest the next question?

Let’s give it a try:

Start with one question.

The LLM responds — and proposes where to explore next.

A bunch of follow-up questions appear, each pointing to new angles:

John could just say “yes” and hope the model has what it needs to answer them.

But he knows better — the underlying semantics aren’t there yet.

Instead, he asks Claude to help build what’s missing.

John reviews it, tweaks a line or two, and approves.

They co-create the semantic definition together.

Recursive Semantic Model Building

With this experiment, we tried to illustrate how we imagine the future of analytics inside modern organizations:

1. A human poses an initial question
   

2. The AI analyzes and identifies semantic gaps
   

3. The AI suggests related questions — the human refines or expands the scope
   

4. The semantic layer evolves organically, shaped by real questions
   

The cycle accelerates, enabling deeper, more sophisticated analysis over time

This feedback loop isn’t just efficient — it solves a deeper, persistent issue in analytics: institutional memory.

In most companies, the same insights are rediscovered over and over because:

• Analysts leave

• Business context gets lost

• Past analyses become buried artifacts

Traditional BI tools fall short here — they preserve results, but lose the reasoning behind them.

By contrast, a semantic model declared as code becomes a living artifact.

It can be:

• Versioned

• Audited

• Reviewed over time
  

More importantly, tracking these feedback loops means we don’t just capture what was analyzed —but also why, how, and what questions led there.

That’s the foundation of analytics that learns — and remembers.

In Data We Trust

There are real limitations to this approach — and the biggest one is trust.

Letting an LLM write code to define your semantic layer is risky.

Semantics are inherently human — they reflect how we think about the business and what we care about.

Context engineering and iterative questioning help mitigate that risk — semantics gradually emerge through the conversation.

But still, it’s not foolproof.

When agents write application code, it’s easy to build trust:

If clicking a button produces the desired behavior, you don’t really need to read the code behind it.

But with data, it’s different.

You can’t trust a chart unless you trust the logic that produced it.

And validating that logic is hard — especially when it’s auto-generated.

And yet — we love this chat BI experience.

First, because the LLM guides you — it doesn’t just answer questions, it gives you new ideas to explore.

Secondly, as the interface is generated on the go, you can place yourself at the perfect zoom level.

BI dashboards are static and frozen, overloaded with details and information you can’t act on.

LLMs show you only what you need to see.

Similar to when you zoom in and out on Google Maps.

You’re not stuck staring at a frozen dashboard overloaded with stale KPIs.

You see just enough to make the next decision — and if you want more, just zoom.

That’s the magic: The LLM gives you the map with control over the zoom level …

Thanks for reading

Benoît and Ju

Thanks Benoît for the super insightful collab (as always :) ).

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

Last week we launched the boring semantic layer.

The Boring Semantic Layer (BSL) is a lightweight semantic layer built on top of Ibis.

I love ❤️ it because:

• It’s super light: pip install boring-semantic-layer

• It’s Ibis-powered — meaning it works with almost any engine out of the box

  Boring Semantic Layer Github

Today, I want to explore into how this connects with the MCP integration I mentioned in the launch post.

I started exploring the semantic layer space while experimenting with LLM interfaces for data.

If you take a brute-force approach and let an LLM query your raw tables directly, you’ll quickly run into hallucinations — things like:

• Wrong joins

• Bad aggregations

The semantic layer serves as an interface that defines pre-built aggregations and validated relationships — helping prevent those kinds of issues.

Take the flights example: we have two tables, flights and carriers.

Rather than exposing those raw tables to the LLM, we expose ready-to-query aggregations, such as:

In this setup, the LLM can only aggregate the number of flights per origin and destination — nothing more.

That constraint is a feature, not a bug: it allows the LLM to focus on intent, not SQL correctness.

You’re trading SQL flexibility for reliability.

MCP

MCP is a protocol designed to standardize how LLMs interact with external tools.

Each MCP exposes a set of so-called “tools” — think of them as API endpoints with predefined inputs and outputs.

When a user asks a question, LLMs are now trained to browse the available MCPs and identify the one they can use to handle the request.

Python MCP

Anthropic has released a Python SDK that implements the MCP protocol.

It allows you to build an MCP server that can be exposed to a client.

A client, in this context, could be Cursor, Claude Desktop, Claude Code, etc.

Using the @tool decorator, you can easily add tools to the MCP server.

When an LLM scans the MCP, it will see each tool along with its docstring documentation.

The docstring is crucial — it helps the LLM understand what the tool does and how to structure the input correctly.

Semantic Layer + MCP

In the context of our semantic layer, MCP acts as a bridge between the LLM and the Boring Semantic Layer.

Here’s how it works:

1. The user asks a question to the LLM.

2. The LLM scans the available tools and calls the appropriate MCP tool with a corresponding query.

3. The MCP forwards the query to the Boring Semantic Layer, which translates it into SQL.

4. The results flow back to the LLM, which then formats the response in natural language.

BSM: SemanticMCP

To enable a smooth integration between the Boring Semantic Layer (BSL) and an MCP, we introduced a new class this week: MCPSemanticModel.

It inherits from the original FastMCP class by Anthropic and extends it with a set of built-in tools that the LLM can use to query your data.

To use it, simply pass your semantic model as input to the MCPSemanticModel class.

Run this file, add the MCP to your client and that’s it !

The client’s LLM will be able to access your semantic layer.

(Check the demo section below if you want to try it yourself.)

The MCP server comes with a set of pre-implemented tools:

• list_models – Returns the list of available semantic models.

• get_model – Fetches the definition of a specific semantic model.

• get_time_range – Retrieves the time range covered by a model’s data.

• query_model – Executes a query against a semantic model.

Each tool includes a proper docstring, which acts as a prompt for the LLM.

This prompt is especially important for tools like query_model.

In the prompt, we explain to the LLM how to format its queries: the JSON format for filtering, the available time ranges, and more.

The beauty of this setup is its flexibility.

The MCPSemanticModel is just an instance of FastMCP.

You can enhance the MCPSemanticModel class as you wish: add new tools, add prompts, add resources, and more.

Demo

There is a ready-to-use MCP implementation in the repo here.

Just add this config to your Claude Deskop MCP config file:

Nothing to install (except uv) !

{
  "mcpServers": {
    "flight_sm": {
      "command": "uv",
      "args": [
        "run",
        "https://raw.githubusercontent.com/boringdata/boring-semantic-layer/refs/heads/main/examples/example_mcp.py"
    ]
    }
  }
}

That’s it! Open your Claude Desktop, and you can start chatting with the flight data.

Let’s start by asking a simple question:

“top 10 flights destinations”

If you look at the MCP call, the LLM goes through the following steps:

1. Lists all the available models (datasets)

2. Retrieves more details about the flights model

3. Performs a query

Now, let’s add a time dimension to the prompt:

“Analyze the quarterly flight number evolution in Boston.”

In this case, the model also uses get_time_range to verify the available date range in the dataset before running the query.

And then leverage the time_grain in the query() to aggregate data correctly.

Claude even generated a nice dashboard for us:

From the tests we ran, the LLM generally understands the prompts we provide about how to query the data model.

It does make occasional mistakes — for example: “Error executing tool query_model: Operator ‘in’ requires ‘values’ field.”

But what’s impressive is that it learns from the error message and often manages to correct itself in the next attempt.

Next Step

You got it — the LLM is only as good as your semantic model.

If a measure isn’t exposed, the LLM won’t be able to retrieve the information.

In that sense, building the semantic model is becoming the new bottleneck in the analytics process.

But wait…

Could the LLM help us build the semantic model itself?

Does it have to be an ad-hoc process?

What if we could build it incrementally, as users ask questions?

That’s exactly what we’ll explore with in the next edition of the newsletter.

Stay tuned!

We’d love to hear your feedback and welcome contributions — and don’t forget to ⭐ the project!

Thanks for reading,

-Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

👨🏽‍💻 echo {YOUR_INBOX} >>

This post is brought to you by Bufstream— a Kafka drop-in replacement with built-in schema enforcement.

Bufstream ensures data quality at the source by validating every message against a Protobuf schema — so bad data never enters your streams in the first place.

Read more about Bufstream

Yet another semantic layer!

I’m currently working with , leveraging Boring Data templates to build vertical data products.

One of our core assumptions is that MCP-only interfaces can disrupt traditional UI-based data products.

While building our first product, which manages Stripe failed payment dunning, we noticed a major limitation:

LLMs struggle to generate correct SQL queries when retrieving data from a DB.

They often:

• Misinterpret the join relationships

• Get confused about column meanings or context

Our key takeaway:

👉 We need a semantic layer!

By enforcing consistent data access patterns, this semantic layer helps reduce the error rate of the LLM.

I researched the available tools on the market.

I wanted a simple Python package that I can use directly within my MCP implementation:

I haven’t found anything that fully meets my needs: open, composable, and … simple.

Semantic layer tools fall into one of the following categories:

• Not Open Source:

  • dbt MetricFlow

  • Snowflake Semantic Layer

• Bundled with a larger platform:

  • Rill Data

• Requires hosting a dedicated service:

  • Cube.dev

  • DataJunction

The best option I found was Malloy.

But Malloy isn’t easily embeddable in Python as far as I know, and I’m concerned that LLMs may struggle to generate correct Malloy queries.

So…

We partnered up with Hussain Sultan from xorq-labs (a multi-engine version of ibis) and built the simplest semantic layer on earth: boring-semantic-layer.

It has two main differentiators:

• Lightweight: Just pip install boring-semantic-layer

• Built on top of Ibis: Supports any engine Ibis integrates with

Boring Semantic Layer

Demo Time!

Let’s take a look at how our semantic layer works.

Step 1: Define your semantic model

With boring-semantic-layer, you define your semantic model using a SemanticModel class:

Each model is built on top of an Ibis table — meaning it works with any backend Ibis supports, like DuckDB, BigQuery, Snowflake, and more.

Example with DuckDB and Parquet:

Once you’ve defined your table, you can declare your dimensions and measures:

• Dimensions describe how you slice your data — e.g. country, user_cohort, or time_of_day.

  Think of them as the “by” in “group by”: flights by origin, users by signup_date.

• Measures define what you measure — e.g. total_revenue, unique_users, or average_order_value.

  These are usually aggregations or calculations.

All dimensions and measures are expressed as Ibis expressions — which are Python functions representing database operations.

This gives you a clean, backend-agnostic way to express logic.

The t parameter represents your Ibis table — and you can chain operations naturally, like you would with pandas.

Ibis compiles these expressions into optimized SQL for the target engine — whether it’s DuckDB, Postgres, BigQuery, or others.

Step 2: Query your semantic model

Once defined, the semantic model exposes a .query() method that lets you combine dimensions and measures.

For example, if you want to count the number of flights by origin, run:

This returns a DataFrame like:

Under the hood, the Ibis expressions are compiled into SQL to query the underlying data sources.

As you can see, the .query() interface is much more restrictive by design.

By only allowing dimensions and measures to be specified, the input is tightly constrained, making it far less error-prone.

Filtering

Querying dimensions and measures is great — but you also need a way to filter data dynamically to answer more specific user questions.

The easiest way to add filters to a query is, of course, by using Ibis expressions:

However, there’s a catch: Ibis expressions are difficult to serialize, which makes them hard for an LLM to generate or interact with.

To address this, we’ve implemented an additional filtering option: JSON-based filtering.

Instead of writing Ibis expressions directly, the user can specify filters using a simple JSON format:

This filtering approach is much more LLM-friendly and covers all basic filtering needs using standard operators.

However, this solution doesn’t cover more complex filtering and transformations, especially those involving time-based logic.

To address that, we’ve implemented a dedicated time-based query mechanism, inspired by Rill’s MCP implementation.

To use it, simply define a time_dimensions in your SemanticModel that points to a timestamp column:

The user can then perform simple time-based aggregations using the time_range and time_grain parameters of the .query() method.

This makes time-based analysis incredibly easy.

Want the number of flights per day in January?

Just write:

Want the year-to-date (YTD) number of flights?

Super simple and flexible.

Join

In most cases, tables are exposed in a normalized form, split across multiple tables.

These relationships should be abstracted away from the semantic layer consumer.

To handle this, we expose a Join class that allows you to define relationships between semantic models.

Let’s stick with the flight example from earlier.

Now, we’ll add a new semantic model: carriers.

We can now enhance our flight semantic model by using the joins argument:

The end user can now query carrier information without having to think about any joins:

Next Step

We’re really excited about the boring-semantic-layer!

In the coming weeks, we’ll be adding:

• A YAML interface

• Charting support

• MCP support

• Materialization and caching support

We’ve already seen very promising results with MCP and will share more in a follow-up post.

Check out the demo video:

We’d love to hear your feedback and welcome contributions — and don’t forget to ⭐ the project!

We’ll also be sharing updates with David about the product we’re building on top of the boring-semantic-layer.

Stay tuned!

Thanks for reading,

-Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

I gave a talk last week at a meetup in Zürich.

In this post, I’ll walk you through the slides I presented and share some context around each one.

Today I wanted to talk about one of my customers: “Tumport”.

They operate in the Trumportation of goods between China and Greenland…

I had a conversation the other day with their CTO:

And he was quite worried…

Why?

Because on one hand, his business is under strong pressure to integrate AI

But on the other hand, he has a bad gut feeling.

Why?

First of all, he hates (data 😄) migrations — and for good reason:

Most of them go over budget:

And in today’s fast-moving AI world, the market is so unstable that if he chooses a provider now…

Will he be forced to migrate again in six months?

Will the tools still exist?

Will the pricing still make sense?

But then he told me there’s something he’s even more worried about:

Big Tech is pouring massive amounts of money into AI.

But if we look at how AI is being implemented in companies, it’s still early days…

Capgemini, for example, reported that only 6% (😮) of their bookings in Q1 2025 were AI-related.

There are two possible explanations:

• Companies are slow to adopt ?!?

• AI does not work (yet)

So if AI fails to deliver on its promises…

Who’s going to pay the bill?

Probably us — the cloud consumers.

And cloud costs?

They’re about to explode.

The question, therefore, is how to protect yourself against all these instabilities.

This is particularly true in Europe, where tech sovereignty is becoming an increasingly important priority.

I don’t think the answer is to stop using the cloud, stop using cloud warehouses, or stop integrating AI.

The answer is to start decoupling.

Decoupling means separating where you store your data from where and how it’s used.

Or, put differently:

Choose wisely where you store your data.

Then, leverage tools only for their compute capabilities (AI, cloud warehouses).

In this situation, Open Table Formats represent an incredible opportunity to decouple your data stack.

Why?

“Traditionally,” there have been two main ways to build a data stack:

• Warehouse-centered approach:

  Pick one cloud data warehouse and go all-in.

✅ Great developer experience

❌ lock-in. Switching providers is painful and requires copying data around

• Data lake–centered approach

  Store raw Parquet files in an object storage bucket.

✅ Easy to set up and inexpensive to get started.

❌ Can quickly become chaotic (no schema enforcement/evolution)

Open Table Formats get the best of both worlds by storing metadata about your data alongside Parquet files in a cloud storage bucket.

Getting control over metadata is incredibly powerful.

From a technical perspective, it provides true “table-like” behavior over data files stored in YOUR bucket.

From a tactical standpoint, it lets you manage and control which provider has access to your data.

This means that by betting on Open Table Formats (OTF), you can choose lightweight, open-source single-node engines to process your data when appropriate.

Or, if you need to scale for a specific job, you can pick your favorite large-scale engine.

And interestingly, betting on OTF now means supporting the “in 10 years” leading compute engine.

What about the limitations?

• JVM oriented

Open Table Formats are still new in terms of adoption and have mostly come from the Big Tech world.

Because of this, many tools are JVM-based, but support for Python, Rust, and Go is growing fast.

• Maintenance

Controlling metadata means you have to do some maintenance to maintain good performance.

This adds complexity, but more and more managed services (like S3 Tables) handle this for you.

• Catalog hosting

Finally, for Iceberg specifically, you need to host a dedicated catalog, which adds another layer of complexity.

However, providers are offering better and better managed catalog services, or you can go for the boring-catalog.

But what about AI?

Can Open Table Formats support AI workloads?

First, it’s possible to store vectors inside Parquet files—and therefore inside Iceberg.

However, when storing large vectors in Parquet, query performance can degrade.

More details why here:

This is why file formats like Lance have been created: to store large blobs more efficiently.

And guess what?

Lance has recently shared their vision for integrating with Iceberg.

In the future, depending on the workload, data will be stored in the most suitable format, while metadata will be maintained in a standardized way (OTF)—allowing any engine to efficiently query all types of data.

I find it super interesting that open table formats are rising just as the AI wave shakes the tech world.

And when European companies are sinking deeper into dependency on US tech platforms.

Open table formats feel like a lifebelt falling from the sky…

I did another interview this week on this topic with Mehdi from MotherDuck.

Check it out here:

Thanks for reading,

-Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

👨🏽‍💻 echo {YOUR_INBOX} >>

Snowflake, AWS, Databricks, and GCP all have their own Iceberg catalog implementations…

So I needed mine 😂.

Since S3 introduced conditional writes, I’ve had this idea: use it to build a damn simple Iceberg catalog.

No server to set up.

No REST API.

No cloud service.

No config.

Just one (boring) JSON file — and a smooth developer experience.

Let’s dive into the boring catalog story.

Github Boring Catalog

The boring catalog is an experiment and still in its early days. Use with caution.

This implementation is very basic and doesn’t cover some enterprise requirements like governance or advanced security.

The goal is simple: to let people experiment easily with Iceberg’s commit mechanism and remove some of the usual friction around catalog setup.

The Boring Catalog

Boring catalog is distributed as a Python package:

uv install boringcatalog

It is composed of a CLI called “ice”:

ice --help

and a Python package

from boringcatalog import BoringCatalog
catalog = BoringCatalog()

git init → ice init

Inspired by Thomas McGeehan, I took inspiration from the git workflow to design the catalog UX:

ice init

This command creates two files:

• catalog.json — the actual catalog file (by default, created in a new catalog folder)

• .ice/index — a small file that stores the path to your catalog, similar to how .git/index works

Of course, you can store your catalog.json anywhere, as long as it’s a PyArrow Filesystem or fsspec–compatible URI:

... AWS CLI auth ...

ice init --catalog s3://<your-bucket>/catalog.json

git commit → ice commit

Okay, our catalog is set up.

Let’s write some data to Iceberg.

First, grab a Parquet file:

curl https://d37ci6vzurychx.cloudfront.net/trip-data/yellow_tripdata_2023-01.parquet -o /tmp/yellow_tripdata_2023-01.parquet

Then commit it to the catalog:

ice commit my_table --source /tmp/yellow_tripdata_2023-01.parquet

This will automatically create a default namespace and a new table called my_table.

Note: For now, commit only accepts Parquet files as input and appends data to the target table.

git log → ice log

Iceberg uses a snapshot mechanism — every operation (like appends or schema changes) is recorded as a distinct snapshot.

To view the history of operations made to your catalog, run:

ice log

Similar to the git log command, the most recent commit is shown first, along with a summary of the operation:

Each entry includes metadata such as the snapshot ID, timestamp, operation type (e.g., append), and the number of files or rows involved.

Ice Duck: DuckDB shell

I personally love using DuckDB for data exploration and quick manipulation.

If you run:

ice duck

This opens a DuckDB shell with your Iceberg context already loaded.

You’ll get:

• A table listing all namespaces

• A table listing all the Iceberg tables

• Views are automatically created for each Iceberg table, ready to query

  

And of course, for a more visual experience, you can launch the DuckDB web UI with:

ice duck -ui

Python Interface

As mentioned earlier, you can also interact with the catalog via Python using the boringcatalog library:

from boringcatalog import BoringCatalog
catalog = BoringCatalog()

You can then use it just like you would with PyIceberg:

import pyarrow.parquet as pq

df = pq.read_table("/tmp/yellow_tripdata_2023-01.parquet")

table = catalog.load_table(("ice_default", "my_table"))

table.append(df)

Polars Interface

Since Polars integrates with PyIceberg, you can also ingest data directly via Polars:

import polars as pl

df = pl.read_parquet("/tmp/yellow_tripdata_2023-01.parquet")

...

table = catalog.load_table("ice_default.my_table")

df1.write_iceberg(
    target = table,
    mode = "append"
)

How does it work?

Under the hood, the catalog is simply an instance of the generic Catalog class from the PyIceberg library.

PyIceberg already provides several catalog implementations out of the box — Hive, REST, AWS Glue, Nessie, and more.

I just adapted a few methods to read from and write to a plain JSON file.

That’s it.

⚠️ What About Concurrency?

Traditional catalog backends use a database or service to coordinate concurrent writes.

In this implementation, we leverage S3 conditional writes to ensure consistency without a separate backend.

Here’s how it works:

1. Fetch the current ETag of the catalog.json file

2. Perform the operations

3. Before committing to the catalog, check if the file ETag has changed

   • If not, proceed to update the catalog.json file

   • If yes, raise an error

It’s then up to the writer to refresh the catalog and retry the operation.

⚠️ What About Governance?

This will probably be the main complaint about such implementation: there is no control over who can read/write a table (except S3 access control).

3- Next Steps

I mostly use this catalog to quickly spin up an Iceberg setup and experiment with different behaviors.

I’ve noticed that using the ice CLI provides a really smooth and fast experience, especially when sensible defaults are set up, like a default namespace and automatic table creation.

So, I want to enrich the CLI experience by adding more features for playing with partition specs, merge operations, schema evolution, etc.

An interesting next step I’m considering is to expose a REST catalog interface for the boring catalog, either via the CLI command:

ice rest 

(or maybe even through a Lambda URL)

You might wonder: why expose a REST interface?

Simply because REST catalogs are becoming the standard way Iceberg integrates with other platforms.

For example, Snowflake supports REST catalogs now:

So, a possible next step would be to enable writing directly from Snowflake in the boring catalog.

If you like the project, please consider giving the GitHub repo a star.

And don’t hesitate to comment on this article or reply to this email and tell me what you think about it: stupid, interesting, or anything else.

I’d love your honest feedback.

Building a data stack is complex—too many moving pieces, too little time.

That’s where Boring Data comes in.

I’ve created a data stack onboarding package combining ready-to-use templates and hands-on workshops.

Interested?

Check out boringdata.io or reply to this email—I’d be happy to walk you through our templates and workshops.

boringdata.io

Thanks for reading,

-Ju

Bonjour!

I'm Julien, freelance data engineer based in Geneva 🇨🇭.

Every week, I research and share ideas about the data engineering craft.

Not subscribed yet?

DuckDB has become well-known as a lightweight, portable, and fast OLAP database.

I've primarily seen it used for local testing and stateless computations.

While it excels as an embedded engine, could we push its boundaries further?

Could we build an actual data platform centered around DuckDB?

This post, written with Hussain, explores how to build such a stack and transform your DuckDB into a DuckHouse.

—

You can find the source code of this project here.

Note: This project is an exploration and is not production-ready.

Design

Here are the requirements for our DuckHouse:

• We must support concurrent writers because we need multiple ETL jobs running simultaneously. This would also enable a single DuckHouse instance to support a multi-tenant setup.

• Allow multiple concurrent readers to access data

• The storage format must handle both small and large tables efficiently

• Support seamless integration with dbt

Out of scope:

• Governance and read/write limitations across users.

—

To address these requirements, we implemented a hybrid storage design:

• Small tables are stored in .duckdb format directly on S3

  → e.g., s3://<bucket>/duckhouse.duckdb

• Large tables (like events) are stored in Iceberg format on S3

  → e.g., s3://<bucket>/<table>/

This setup provides DuckDB's simplicity and performance for light workloads while scaling with Iceberg for heavy datasets.

Let’s dive in!

1. Arrow Flight

TL;DR

We implement an Arrow Flight server as a gateway to our DuckDB storage, solving write concurrency challenges.

DuckDB and Write Concurrency

Writing concurrency is likely the first challenge you’ll encounter on this journey.

DuckDB isn’t built to handle concurrent writes automatically—it only allows one writer at a time.

An external component must handle the concurrency control.

This is where Arrow Flight comes into play.

Arrow Flight Server

Arrow Flight is a modern alternative to REST APIs for data transfer.

It enables fast and efficient transfer of large datasets across systems using the Arrow format.

Traditional data systems require multiple conversion steps:

1. Server converts data to JSON/CSV

2. Data travels over the network

3. Client converts back to DataFrame

With Arrow Flight, data stays in Arrow format end-to-end, eliminating the need for conversion.

To solve our concurrency problem, we'll use a Flight server as a gateway for all write operations.

This server queues write requests and processes them sequentially to avoid any locks.

Xorq

Xorq is a declarative framework for building multi-engine computations in Python.

They provide a ready-to-run flight server that can be easily connected.

Running a flight server becomes as easy as:

The server supports SQL and Ibis expressions and provides pre-implemented methods across several backends (DuckDB, Iceberg, Snowflake, Trino, etc): create_table, list_tables, get_schema, and upload_data.

Here’s how to upload data, for example, to a server:

As mentioned in DuckHouse's requirements above, we need to support writing to either a DuckDB instance or Iceberg for data persistence.

This means we work with two backends: DuckDB and Iceberg.

We built for this PoC a custom backend on top of Xorq's native Pyiceberg and DuckDB backends:

The Flight server writes data to either backend based on the user-provided target parameter.

Additionaly, to maintain s3://duckhouse.duckdb as a single read entry point, whenever we write to an Iceberg table, we create (or replace) a DuckDB view that points to its latest snapshot.

2. Writing to the Duckhouse

TL;DR:

• Data ingestion via the Flight server directly

• Data transformation via dbt and a custom duckdb-dbt plugin

Let's examine how we interact with the Duckhouse for our two write use cases: data ingestion and transformation.

• Data Ingestion

The most straightforward way to write to our new warehouse is to call the Flight server directly, as shown above.

This method serves as our primary approach for data ingestion.

• Data Transformation

Once data is ingested, we run transformations using dbt.

For this, we use the powerful dbt-duckdb extension.

This extension runs your dbt project pipeline against an in-memory DuckDB database that won't persist after your run is complete.

It provides a super powerful plugin system, which allows you to enhance dbt and provide custom model read/write behaviors:

A dbt-duckdb plugin is a simple class that implements these four methods:

• initialize

• configure_connection

• load: used to load the sources of a dbt model

• store: used to persist a dbt model

Our plugin forwards the dbt read/write calls of each model to our flight server:

A dbt model looks like the following:

Depending on the model’s config, it can be persisted in any of these locations:

• materialized="external"

  target = "iceberg"

  ⇒ Model written to Iceberg s3://duckhouse/my_table/

• materialized="external"

  target = "duckdb"

  ⇒ Model written to our duckhouse s3://duckhouse.duckdb

• materialized="table"

  ⇒ Model written to the temporary in-memory DuckDB instance used by dbt

Reading from the Duckhouse

The read path is much simpler: you need to expose the duckhouse.duckdb file to your users.

They then need to open a DuckDB shell and run:

That's it!

Users can access both tables stored in s3://duckhouse.duckdb (tables) and Iceberg tables (via views).

The system is fully decentralized—users can query data and run computations on their machine.

Users can also directly access the flight service and use Xorq to perform computations if needed:

Example Pipeline

Let's look at an example pipeline.

First, we'll use an ingestion script to write taxi data to a landing table in Iceberg:

We can then check the data in the Duckhouse via a DuckDB shell:

Let’s create duplicates by rerunning the ingestion; we now have 6.133.532 rows.

We then create a simple dbt DAG:

The sources.yml points to the landing table we have just created:

We then have a first dbt staging model simply deduplicating the rows for the landing table:

This model is stored in Iceberg.

A third model computes a simple metric stored in DuckDB:

We run dbt run:

And that’s it !

We only need to run duckdb duckhouse and we have access to the 3 tables:

We can query the staging table in Iceberg:

And finally, query the metric in DuckDB:

Next Steps

I love this combination of Flight server, DuckDB, and Iceberg.

It’s a perfect compromise:

• Light – requires only a single Flight server

• Cheap – compute with DuckDB and 100% S3-based storage

• Scalable – large tables live in Iceberg - any engine can process them

Several features remain to be implemented:

• Flight server:

  • Add incremental read/write operations

  • Add MERGE support (currently append-only)

  • Handle table migration when the target changes

• Iceberg:

  • Integrate with a proper catalog (currently using SQLite)

  • Enable partitioning and clustering configuration in dbt models

Additionally, we plan to leverage the Flight server to leverage interfaces with additional backends such as Snowflake, BigQuery, and PostgreSQL.

Building a data stack is complex—too many moving pieces, too little time.

That’s where Boring Data comes in.

I’ve created a data stack onboarding package combining ready-to-use templates and hands-on workshops.

Interested?

Check out boringdata.io or reply to this email—I’d be happy to walk you through our templates and workshops.

boringdata.io

Thanks for reading, and thanks, Hussain, for the very nice collaboration.

-Ju