dltHub's AI harness writes the pipeline, Snowflake's CoCo takes over after data landed. Together they ✨
TL/DR: dltHub's commercial AI harness and Snowflake's Cortex Code (CoCo) sit on opposite sides of my pipelines. The former enables coding agents to build and maintain ingestion pipelines into a lakehouse... like ❄️ Snowflake. The latter is such a coding agent, specialized on working in said lakehouse. Together they ✨
The dynamic duo #
dltHub's commercial offering includes a coding-agent harness: skills, rules, and MCP tools for Claude Code, Codex, Cursor, etc., running the full pipeline lifecycle through it (ingest, transform, explore, operate). Ten toolkits, forty skills. The whole thing ships as a .md file agents can pull straight into context:
Snowflake (among many other things 😅) sells CoCo. It is a coding agent too, but a specialized one: it understands a live Snowflake account and has deep knowledge around all things Snowflake, integrated into the agent out of the box. It executes SQL, reads schemas, profiles tables, and (per Snowflake's own benchmark) beats general-purpose coding agents specifically on data engineering tasks, because it doesn't first have to gather context from a README.
Neither vendor frames it this way, but placed side by side a difference becomes clear:
What actually happens when combined #
About 6 months ago, I ran a few dozen dlt ingestion pipelines in Snowflake Container Services (SPCS): one Docker image and YAML spec per pipeline, external-access-integrations to allow ingress, and a compute pool to keep an eye on. All of it got torn down when dltHub launched. The only memory is the changelog entries in a Snowflake few tasks that used to call EXECUTE JOB SERVICE and now call TRIGGER_DLTHUB_PIPELINE() instead.
Ingestion (from Salesforce, our ERP, Jira, Confluence, SharePoint, Microsoft Graph, half a dozen ad platforms, Swiss federal statistics, and many more) now runs as dltHub Runtime jobs out of a single workspace. That migration alone carries most of the value prop: commercial dltHub swapped infrastructure work for authoring work plus integrated observability (soon including agentic monitoring and auto-healing 🤫). On a one-person data team, fewer moving parts is always better.
However, this setup could be done with any coding agent, really. Or without any if one prefers 😅 The real magic trick comes next...
The part dltHub's harness doesn't reach #
dltHub's harness equips a coding agent to write and deploy pipelines. But on top of this, it also enables getting tons of (meta) information out of the pipeline. Since dlt accesses the source system and "sees" the data in transition, the harness enables a coding agent to derive the structure of the source data, its taxonomy, build an ontology based on this and even scaffold a canonical data model.
And now hand all of this over to CoCo...
Equipped with the knowledge on what dltHub inserted into Snowflake, CoCo can do all kinds of really useful things:
- Label the tables and their columns in Horizon catalog,
- build a data model on top using Dynamic Tables or dbt,
- design SPCS-hosted Streamlit apps visualizing that model, or
- and this is my personal favorite -
- build a Semantic View.
Semantic layers require an infusion of "meaning" for an analytical agent to understand the data well. A commented raw layer is good, a descriptive layer including relations and rules is better.
The boundary is gone #
Would building all of this in Snowflake be possible with a different coding agent than CoCo? Of course!
Would it then happen behind Snowflake's security and accountability perimeter? Not so much.
And again, on the ADE-Bench (built by dbt Labs for realistic data-engineering tasks), CoCo scored 72.1% against 65.1% for both Claude Code and Codex, while burning 51% fewer tokens and requiring 8% less time than Claude Code (on Opus 4.7). A gap attributed to native Snowflake tool calls instead of falling back to bash or scratchpad scripts. Whether that margin holds outside a vendor benchmark is its own question, sure, but the design direction is legit: less shelling out, more direct API calls into the systems that matter.
And then, 🧊-berg #
Just as an extra cherry on top: dltHub's commercial tier does more than deploy pipelines that write to Snowflake. It ships a Snowflake-specific destination "Snowflake+", that creates Apache Iceberg tables through Snowflake SQL and syncs them into Snowflake's Horizon (or Apache Polaris) catalog automatically.
[destination.snowflake]
external_volume = "my_external_volume"
iceberg_mode = "all"
catalog_sync = "my_open_catalog_int"
Small config, big consequence: ingestion layer and table format are no longer two separately maintained things bolted together, because both dltHub and CoCo are aware of Snowflake's own Iceberg catalog mechanics.
The combined value prop #
dltHub's commercial harness made pipeline authoring an agent-first workflow, my own SPCS-to-dltHub migration is the receipt. Snowflake's CoCo is the only coding agent in with standing authority to say what's actually working best in Snowflake. Tied together, the two systems share tons of valuable knowledge about the data and the systems around it 🤓