We're deprecating Tinybird Code, our AI-powered CLI that could build complete Tinybird projects from natural language prompts. If you haven't used it, Tinybird Code was an agent embedded in the CLI that knew ClickHouse® deeply, understood Tinybird's entire surface area, and could define schemas, write and optimize SQL, build API endpoints, run tests, and deploy to production.

It was good. People used it. And we're sunsetting it.

This might sound like we're walking back from AI. It's the opposite. Building Tinybird Code was one of the most valuable things we've done, not because of the product itself, but because it forced us to understand what developers (and agents) actually need.

Every phase taught us something

We've been through every phase of AI-assisted developer tooling in the past year. Each one built on the failures of the previous one.

Phase 1: AI-assisted commands. We started with the basics. tb create --prompt "..." scaffolded a project. tb mock generated synthetic data. Useful, but limited. They were mostly code generators that ran once and gave you a starting point. They couldn't iterate, debug, or learn from the context of your project.

Phase 2: Explorations. We gave an LLM deep context about your workspace and let it answer questions conversationally. Great for data exploration. You could ask "why did signups drop last Tuesday?" and get an answer with SQL to back it up. But the agent lived inside Tinybird. It couldn't see your code, your IDE, or the broader context of what you were building.

Phase 3: Tinybird Code. The full agentic experience. An AI agent in the CLI that could handle the entire development lifecycle: schema design, query optimization, data mocking, testing, deployment. We encoded ClickHouse best practices, Tinybird conventions, and hard-won production knowledge into a single tool.

Tinybird Code was the culmination of everything we'd learned. And while we were building it, the world moved.

The ground shifted

When we started building Tinybird Code, coding agents were nascent. Models needed heavy hand-holding: detailed system prompts, domain-specific instructions, careful guardrails to prevent hallucination. Building a custom agent with deep domain knowledge was the only way to get reliable results.

That's no longer true.

In the span of a few months, coding agents have matured fast. Claude Code, Cursor, and Codex don't need a custom wrapper to work with your platform. They need something simpler and more fundamental: good primitives.

A well-designed CLI with clear error messages. Skills they can load into their context on demand. A typed SDK with discoverable methods. Consistent APIs. Good documentation. These are the things that make coding agents effective with any platform, including Tinybird.

The realization hit us gradually, then all at once: we shouldn't be building an agent. We should be making Tinybird work with every agent.

What Tinybird Code taught us

Deprecating Tinybird Code doesn't mean building it was a mistake. The process fundamentally improved Tinybird as a platform. We wouldn't know what we know today if we hadn't gone through every one of those phases.

Better error messages. When an AI agent runs your CLI and gets a cryptic error, it hallucinates a fix. That's bad for agents, and it's equally bad for humans debugging at 2am. Building Tinybird Code forced us to rewrite error messages across the CLI to be specific, actionable, and machine-parseable. If an agent can understand your errors, your developers can too.

Agentic-friendly architecture. We restructured how the CLI reports results, how APIs surface errors, and how documentation maps to actual commands. Every surface of Tinybird got cleaner because we were looking at it through the eyes of a system that needed to understand it without ambiguity.

Understanding what agents actually need. We assumed agents needed deep domain context hardcoded into system prompts. What they actually need is what every good developer tool provides: clear interfaces, predictable behavior, and useful feedback when things go wrong.

These improvements are permanent. They're baked into the CLI, the SDK, the docs, and how we think about developer experience. That's the real output of Tinybird Code.

Skills over agents

Instead of maintaining a custom agent, we've extracted Tinybird Code's domain knowledge into portable Agent Skills, structured rules and best practices that any coding agent can load.

When a skill-equipped agent detects Tinybird files in your project, it automatically loads the relevant context. It knows how to structure datasource schemas, how to order sorting keys for query performance, when to use AggregatingMergeTree, how to build test fixtures. The same knowledge that powered Tinybird Code, available in whatever agent you already use.

This has clear advantages:

• It works where you already work. You don't switch tools. Your agent gets smarter about Tinybird inside your existing workflow.
• It improves with every model update. When Claude gets better at reasoning or Cursor ships a new feature, your Tinybird experience improves for free. With a custom agent, we'd have to build and maintain all of that ourselves.
• It compounds. Skills can be updated independently, combined with skills from other tools, and shared across teams.

The data mocking example captures this well. With Tinybird Code, we built a custom flow for generating mock data. Now, an agent with the mocking skill knows to create a .sql file, run tb sql, and append the results with tb datasource append. Same outcome, the agent orchestrating standard tools with knowledge from the skill. Less fragile, more composable.

The TypeScript SDK and CLI as agent interfaces

Skills give agents knowledge. But agents also need tools they can execute.

Our CLI and the TypeScript SDK serve this role. Every tb command is a tool an agent can call. The TypeScript SDK provides type-safe methods that agents can discover and invoke correctly. Combined with MCP, which exposes every Tinybird workspace as a remote server agents can connect to, any agent has what it needs to do productive work with Tinybird, without Tinybird-specific agent code.

Skills give agents the knowledge. The CLI and SDK give them the tools. MCP gives them access. That's all an agent needs to be productive with Tinybird.

Don't build agents, build for agents

If there's one principle from this journey, it's this: don't build custom agents. Make your platform work with all of them.

That means investing in clear CLIs, typed SDKs, structured error messages, documentation that's both human-readable and machine-parseable, skills that encode domain expertise, and MCP servers that expose your platform's capabilities to any LLM.

This is the same insight the Next.js team arrived at when they sunset their in-browser agent: treat agents as first-class users of your platform and meet them where they are. The answer isn't another agent. The answer is making your existing tools agent-friendly.

We would never have arrived at this understanding without building Tinybird Code. It was necessary to go through the custom agent phase to see what really matters. But now we see it clearly.

What's next

We're expanding Agent Skills to cover more of the Tinybird surface area. We're improving the CLI's output for agent consumption. We're building eval frameworks to measure how well agents perform with Tinybird, so we can systematically improve the experience.

Tinybird Code will remain available during a deprecation period, so nothing breaks if you're using it today. But we'd encourage you to try the skills approach: install tinybirdco/tinybird-agent-skills in your preferred agent and see how it compares. We think you'll find it's a better experience, because it's your agent, your workflow, with Tinybird expertise built in.

The future isn't a Tinybird agent. It's every agent being good at Tinybird.