Spec-Driven Development with Snowflake CoCo

This article is adapted from a talk with the same title, which I delivered at the Snowflake User Group in Montreal on September 24th, 2026

Coding agents are good at writing code. That's not really in question anymore — Google says three-quarters of their new code is AI-generated, and anyone who's used Claude Code, Cursor, or similar tools for more than a week knows the "write the code" step isn't the bottleneck anymore. What's shifted is where the friction lives: planning and requirements on one side, testing and deployment on the other.

Anthropic's AI-native SDLC playbook suggests solving this on the pre-build side through collapsing planning and design into a single prompt session: you hand the agent an intent file, and it writes the requirements and design spec itself.

However, when it comes to data modeling and transformation code, only intent is not enough, especially when your pipelines depend on business context the agent has no way of inferring: what your company means by "revenue," which deals count, who owns a KPI. Before agents, that context lived across systems of record, business documents, or simply in the head of the stakeholders or dev team. Now it has to get into the agent's context window in a form it won't misinterpret or hallucinate around.

In my opinion, for data developers, a great way to solve this issue is in creating a detailed spec of your requirements. I've tested this with dbt Wizard before, and the results were clear: with a spec, the agent grounded the project in real requirements, applied regression tests against the business figures I gave it, documented the reasoning behind decisions, and captured meaningfully more KPIs, — including things like gross margin percentage that only fell out correctly because the pipeline had the right context.

And if any data coding agent could get away without a spec, it's the one that already knows your warehouse: Snowflake CoCo.

Why CoCo: a coding agent that already knows your Snowflake warehouse

I wanted to try Snowflake CoCo for the obvious reason (I was giving a talk at a Snowflake meetup) and a less obvious one: it's the hardest case for my argument that coding agents perform better with a spec that captures how your organization operates. Most coding agents start out blind to your warehouse, while CoCo doesn't.

CoCo comes in two forms; the CLI is a developer platform extensible with custom commands, tools, subagents, and hooks, and a standalone subscription makes it available even if you don't run workloads on Snowflake today. Snowflake Labs ships a skill that routes Snowflake operations from Claude Code, Cursor, Codex and others to the Cortex Code CLI in headless mode. Snowflake isn't trying to replace your general-purpose agent. It wants to be the specialist that your agent calls whenever the task touches Snowflake. For analytics engineering, this tells us that while CoCo brings platform knowledge it still lacks business knowledge.

When trying out CoCo in the CLI, a few things stood out:

• Deep Snowflake awareness. It listed connections by name, found schemas and tables, and showed output inline — full rows for small tables, sensible samples for large ones.
• It caught stale state. It noticed I'd previously built and torn down a dbt project locally but never dropped the corresponding Snowflake tables, and flagged that.
• It picked up existing skills automatically — an open-source dbt/analytics-engineering skill I already had installed for Claude Code, with no additional setup required.
• RBAC debugging was genuinely good. I gave it a read-only role by accident. Instead of just failing, it actively explored what other roles and schemas it did have access to, and came back with concrete next steps rather than a dead end.

The spec drove decisions Snowflake CoCo couldn’t have handled correctly

After building a dbt pipeline with a spec, I asked CoCo directly what the spec changed about how it built the project, and the evidence was concrete and seen at every layer of the project.

One example: the dataset had hashed values in an ID column that, without context, look like junk you'd strip out. The spec explicitly said finance relied on that hash — and the agent preserved it everywhere, calling out that filtering it would break the entire opex section. Later in the stack, a business rule about transactions posting only to leaf accounts directly shaped how it joined the fact table. That's the kind of decision that used to require a human who understood the business, not just someone who could write SQL. Finally, at the testing layer, the spec informed accepted values and referential integrity tests, increasing the robustness of data quality checks.

Where the spec was less relevant: a spec by nature has no access to raw data, so CoCo had to reverse-engineer actual column names from existing staging DDLs. And Snowflake-specific deployment mechanics — role and schema ownership grants — aren't business knowledge, so those got figured out at runtime rather than being pre-specified.

Spec for the business, Snowflake CoCo for the platform

Coming back to where I started: coding agents have already solved the "write the code" problem. What they haven't solved, and can't solve on their own, is knowing what your company means by revenue, which edge cases matter, or which decisions are still genuinely unresolved. That's not a model limitation you fix with a bigger context window. It's missing information, and the fix is to systemically capture it with a spec.

That's the case for spec-driven development, so we can move an agent from "technically correct SQL" to a data pipeline grounded in how your business operates

CoCo specifically earns its keep wherever Snowflake environment knowledge compounds the problem: tangled RBAC, deploying dbt as a native Snowflake object, anything where "understand the platform" and "understand the business" both matter at once. Pair Snowflake Coco with a spec, and you get a data coding agent working from a genuinely complete picture instead of filling gaps with plausible guesses.