There is a moment every developer recognizes. You've been deep in a complex Snowflake build for two sessions. You return on Monday morning, open your terminal, and realize: you have no idea where you left off. Not roughly — precisely. Which schema decisions were finalized. Which SQL ran on the wrong environment. Which beautiful pattern you invented last Thursday that you'll spend an hour reinventing today.
The AI didn't forget. The AI was never there on Friday. Each session starts clean.
This is the problem CocoPlus is built to solve. Not the capability problem — Coco is already capable. The structure problem.
The Real Failure Mode of AI-Assisted Development
When AI-assisted development goes wrong, we tend to blame the model. The SQL was wrong. The schema was off. The subagent hallucinated a function that doesn't exist.
But look closer at how those failures actually happened. The SQL was wrong because nobody inspected the target schema first. The schema was off because the spec was never written down — it existed as a mental model in the developer's head, and the developer and the AI were operating from different mental models. The subagent hallucinated because it was asked to build something without a validated plan.
The model is rarely the problem. The absence of structure is the problem.
CocoPlus is an opinion, rendered in software, about what structured AI development looks like for Snowflake engineers.
An Opinion, Not a Framework
"Framework" implies neutrality. A framework gives you tools and lets you decide what to build. CocoPlus is more opinionated than that.
CocoPlus says: you should spec before you code. It says: parallel workstreams need isolated execution contexts. It says: production environments should be protected by something harder than a language model's judgment. It says: every session should leave behind documentation, not just output.
These aren't features you can mix and match. They form a coherent worldview. You can disagree with the worldview. But if you work within it, you get a system that compounds rather than accumulates debt.
The alternative — and every developer has tried it — is to use the AI like a very fast search engine. You throw problems at it, it throws answers back, and you stitch together an output. This works, for a while, until the project is complex enough that the absence of structure becomes the dominant cost.
CocoPlus is for the moment when you've crossed that threshold.
What CocoPlus Actually Is
CocoPlus is a plugin for Snowflake Cortex Code CLI (Coco). It runs entirely inside Coco's native architecture — no external services, no databases, no side-car processes. Everything it does, it does through Coco's own mechanisms: skills, subagents, hooks, and a single configuration file.
It adds nineteen capabilities to Coco, organized around a central idea: your development lifecycle has phases, those phases have natural transitions, and a good tool should make those transitions visible and deliberate.
The phases are: Spec, Plan, Build, Test, Review, Ship. Not novel. Versions of this sequence have been in software engineering for decades. What CocoPlus adds is the discipline to actually follow them inside an AI session — where the temptation to skip ahead is constant and the cost of skipping is invisible until it isn't.
Around this lifecycle, CocoPlus adds:
- Specialist agents — because a single generalist AI produces mediocre results across every domain.
- Memory — because rediscovering something you already knew is waste, and waste compounds.
- Safety — because not every mistake is recoverable, and the ones that aren't deserve harder protection than a strongly-worded prompt.
- Intelligence capture — because every session produces patterns worth keeping and anti-patterns worth documenting, and neither should be allowed to evaporate.
- Independent critique — because a plan reviewed only by the model that wrote it is a plan reviewed by a single perspective.
The Snowflake Context Matters
CocoPlus is not a general-purpose AI productivity tool. It is built for Snowflake engineers.
That specificity is deliberate. Snowflake has a particular shape: schemas that matter, production environments that are genuinely expensive to break, data products that sit at the intersection of engineering and business, semantic models that require a specific kind of domain expertise to design correctly. The CDO persona exists because someone needs to think architecturally about the whole data estate. The Data Steward persona exists because governance isn't an afterthought — it's a discipline.
A generic plugin would have none of this. CocoPlus names the domain it serves and builds specialist depth into the system.
The Design Constraint That Drives Everything
There is one constraint that shapes every CocoPlus decision more than any other: token economics as architecture.
Context window space is finite. Every line added to the ambient configuration file, every monitor activated globally, every agent loaded by default, has a cost. That cost compounds across hundreds of iterations. A system designed without token discipline becomes unusable by iteration thirty.
So CocoPlus makes choices. AGENTS.md — the file loaded into every session — is capped at 200 lines. Skills are loaded on demand, not pre-loaded. The background analyst (CocoCupper) uses Haiku because its job is pattern recognition, not reasoning. The CDO uses Opus because strategic architectural decisions require depth.
These are not arbitrary choices. They are a coherent stance: use the cheapest model that does the job well, and design the system so you know which model that is.
What CocoPlus Is Not
It is not a governance layer. It does not report compliance to anyone. It does not restrict what developers can build.
It is not a replacement for developer judgment. The Safety Gate blocks obviously destructive SQL, but the developer makes every substantive decision.
It is not a dependency. Remove it, and Coco still works. Install it, and Coco works better.
It is not finished. The pattern library grows with use. The memory system learns from sessions. The system gets more useful the longer you work with it — not because it has more features, but because it has accumulated more of your specific project's knowledge.
That accumulation is the point.
Structure enables speed. Not the speed of individual keystrokes — the speed of a project that doesn't collapse under its own complexity.