The 10x Data Team = The Markdown Team

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.

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?

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

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.

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

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.

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.

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

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.

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