Skip to main content

2 posts tagged with "technical"

Technical discussions

View All Tags

The Bugs That Aren't in the Text: What Deep Relational Introspection Catches

· 7 min read
Matthias Broecheler
CEO of DataSQRL

Part 2 of 4: How a data engineering harness eliminates the AI coding agent errors that survive review.

Introduction

"Why do I need that? Isn't Claude Code good enough?"

Deep introspection of the logic behind a data pipeline can reveal logical flaws

We get that question a lot. We are building an open-source data engineering harness, the tooling and guardrails that a coding agent uses to build data pipelines. Claude Code, Codex, and OpenCode already write plausible data pipeline code. So what is the harness for?

Part 1 was about the seams between systems, and how a transpiler generates them deterministically. Part 2 is about a harder problem.

Some bugs have no correctness condition in the query text at all. The condition lives in the relationship between a query, the data it reads, and how that data changes over time. An agent reads SQL/code as text, and at the text level these bugs are invisible until the production deployment fails.

The Pipeline Compiles, the Demo Works, and the Seams Are Quietly Broken

· 8 min read
Matthias Broecheler
CEO of DataSQRL

Part 1 of 4: How a data engineering harness eliminates the AI coding agent errors that survive review.

Introduction

"Why do I need that? Isn't Claude Code good enough?"

We get that question a lot. We are building an open-source data engineering harness, the tooling and guardrails that a coding agent uses to build data pipelines. Claude Code, Codex, and OpenCode already write plausible data pipeline code. So what is the harness for?

A data pipeline spanning multiple systems with broken seams at the boundaries between them.

This series answers that. It looks at where general-purpose coding harnesses fail on data engineering work, and why those failures survive code review.

Part 1 is about the seams. A pipeline spans multiple data systems, and the same fact (a type, a name, an encoding) has to be restated in each one. Restating facts consistently across systems is strict rule-following. The thing doing the restating is a probabilistic model. It gets most of them right. The ones it gets wrong compile cleanly, pass the demo, and surface in production as overflowed numbers and fields that were never there.

A transpiler removes that entire class of error. It derives every boundary asset from one logical model, so the systems cannot disagree. The agent also writes less code, which means fewer tokens and fewer duplicated schema definitions cluttering its context.