We Turned 10 Years of LookML Knowledge Into an AI-Powered Dev Workflow. Here's How.

The Developer Experience Gap

Most LookML developers have a tab problem. Schema browser open in one window, the Looker IDE in another, an Explore running in a third to verify whether a join is actually behaving the way you think it is. Add the Looker docs for whatever explore_source parameter you use twice a year, and you've got a four-tab workflow just to write a derived table.

That's not a complaint about LookML. The semantic modeling layer is doing genuinely useful work — separating business logic from SQL, making joins reusable, giving non-technical users a way to ask questions without writing queries. The reason teams invest in it is because it pays off. The friction is in the developer workflow around it, not the language itself.

There are also places where LookML rewards experience disproportionately. Fan-out from a missing primary key that inflates revenue metrics for two weeks before anyone notices. A query_timezone setting on a persisted NDT that breaks a build quietly overnight. Two explore_source columns mapped to the same dimension that silently collapse into one. None of these surface clearly in documentation — they're the kind of thing you learn from having seen them in production.

Every project also starts with some version of the blank page problem. You either begin from scratch, or you start from auto-generated LookML that technically works but takes longer to clean than to rewrite properly. Either way, the first few days of a new project involve a lot of rediscovering things you already knew.

What Changed in the Last Few Months

For most of the AI coding assistant era, the tools were autocomplete with better vocabulary. Useful, but fundamentally reactive — you write, the agent suggests the next line of code. You're still the one holding all the context.

What's different now with tools like Claude CLI and Gemini CLI is that the AI agent sits directly inside your repository and reads your project structure, your conventions, your existing files, and your documentation before it does anything. It can call external APIs, write and commit files, run validation commands, and ask clarifying questions when the path forward is ambiguous.

It's less like a spell-checker and more like a developer who reads all the existing code and documentation before they open a new file. The output quality is directly proportional to the quality of what they were given to read first.

Both Claude CLI and Gemini CLI support a project-level instruction file — a plain markdown file that lives in your repository and tells the agent how to behave in this specific project. Not generically, but specifically: what warehouse you're on, what naming conventions you follow, what validation steps are required before a deploy, what patterns have caused problems before. The agent reads it at the start of every session.

For LookML development, that instruction file — and the skill library it points to — is where most of the value lives. Because the Looker API gives you programmatic access to schema metadata, connection information, table structures, and column types, a well-configured agent can move from a blank project to a scaffolded set of views, explores, and derived tables without a browser open. Not perfectly on the first pass, but consistent with your conventions from the first file. The Looker API has always made this theoretically possible. What changed is that the agent layer is now good enough to use it meaningfully.

Skills, Not Documentation

The word "documentation" undersells what we're talking about here. This isn't a README or a wiki — it's a library of invokable skills that the agent calls on-demand while it's actively developing LookML on your behalf via the Looker API.

The distinction matters. A README tells a human developer what to do. A skill file tells the agent what to do, step by step, at the exact moment it's performing the task — which tables to query in INFORMATION_SCHEMA, which LookML patterns to apply, which steps to run before committing. The agent doesn't read the whole library upfront. It pulls the relevant skill into context when the task requires it, the same way you'd reference a playbook for a specific situation rather than keeping every decision in your head.

In our case, from the command line, this looks like:

/create-views — reads the connection, queries INFORMATION_SCHEMA, generates views /derived-tables — walks our NDT vs PDT decision tree, writes the right pattern /validate — runs our full validation sequence before any deploy

Each of those is a skill file we wrote. When you invoke one — either explicitly with a slash command or implicitly by describing what you're trying to build — the agent reads the relevant file, applies the logic to your specific context, and uses the Looker API to execute. You're reviewing and refining output, not building from scratch.

The behaviors you get out of the agent are entirely a function of what you put into the skill files. Out of the box, Claude CLI and Gemini CLI are capable general-purpose agents — they don't know your naming conventions, your preferred derived table patterns, or how your team handles a deploy. That knowledge only enters the workflow when you encode it.

A few categories that matter most:

- Decision frameworks with real tradeoffs, not just conclusions. Not just 'use a PDT' when performance requires it, but a decision tree that walks through whether persistence is warranted, which trigger strategy fits the use case, and what can go wrong with each option. When this lives in a skill file, the agent applies the reasoning in context rather than defaulting to whatever pattern it's seen most frequently in the wild.

- Anti-patterns with explanations of why they fail. The cross-region PDT failure on BigQuery is a good example — the error message is unhelpful, the root cause is not obvious. Write it down once with the fix, and neither the agent nor any future developer on your team debugs it from scratch. The skill file is the institutional memory.

- Workflow checklists encoded as agent behavior, not just reference material. Our validation sequence before a deploy — LookML Validator, Content Validator, Data Tests, manual Explore check — exists as a skill file. Because we built our agent to follow it, it runs through that sequence before proceeding. That's a deliberate choice we made, not something the tool does by default.

- Routing logic that reflects how your team actually works. A fresh build looks different from a POC cleanup, which looks different from adding a new data source to an existing model. We built our agent to ask where you are before it starts writing LookML, because starting from the wrong assumption costs more time than the automation saves.

The point isn't an exhaustive encyclopedia. It's capturing the 20 percent of knowledge that prevents 80 percent of repeated mistakes — and structuring it so the agent can apply it at the right moment rather than requiring you to remember to apply it yourself.

What the Workflow Actually Looks Like

The most honest description: the early stages of a new project are faster, and the repetitive parts of any project are less tedious.

Before: a new BigQuery connection, a new schema to explore. You open a browser, navigate to the Looker SQL Runner to understand table relationships, open another tab for the IDE, start writing view files by hand — checking primary keys, adding dimension groups for every timestamp column, writing the same filtered revenue measure you've written a dozen times. A full day to do it properly.

After: from the command line, you invoke the create-views skill. The agent authenticates against the Looker API, queries INFORMATION_SCHEMA for column metadata, and generates view files consistent with the conventions in your skill library. Primary keys set. Foreign key dimensions hidden. Dimension groups for timestamps with the standard timeframe set. Filtered measures on revenue fields. The output isn't production-ready — it never is on the first pass — but it's directionally correct and consistent. You're reviewing and adjusting, not building from zero.

The derived table workflow is another good example. A developer needs a user lifetime value aggregation. Without a skill library, that's a 20-minute exercise in reconstructing whether this should be an explore_source NDT or a SQL derived table, whether it needs persistence, what trigger strategy fits, whether the BigQuery region is going to cause a problem. We built a derived table skill that encodes exactly that decision tree. The agent walks through it, flags the relevant constraints for the specific situation, and writes accordingly. The developer's job becomes reviewing the output, not reconstructing the reasoning every time.

Document Everything So You Don't Forget It — Then Let AI Use It

There's a version of this that makes a big claim about the future of AI in data workflows. That framing misses something more immediate and more useful: the act of building this kind of skill library improves how you work before the agent touches a single file.

When you're forced to write down a decision framework — really write it down, with the tradeoffs and the failure modes and the cases where the standard approach doesn't apply — you understand it more precisely than you did when it lived in your head. We found this repeatedly when building our own library. Writing the NDT persistence decision tree revealed gaps in our own reasoning that hadn't surfaced in practice because experience had compensated for them. The skill file is better than the undocumented heuristic it replaced, and that's true regardless of whether an agent ever reads it.

What's changed is that well-structured skill files can now do double duty. A markdown file that explains when to use a datagroup trigger versus a sql_trigger_value — with the decision logic, the examples, and the failure modes — is useful to a developer reading it directly. It's also directly useful to an AI agent that applies it in real time, in context, through the Looker API, on any project. The same file serves both purposes because good reasoning, written down precisely, is useful to anyone — or anything — that needs to act on it.

The tools to do this are available to any LookML developer today. Claude CLI and Gemini CLI are not specialized Looker tools — they're general-purpose AI agents that work well in any domain where you pair them with a structured skill library and API access. The Looker API has been there for years. The agent layer finally makes it practical to drive real development through it.

The investment is modest. Start with the things you find yourself reconstructing consistently. Write them as skill files — specific enough that the agent can act on them, not just reference them. Organize them by workflow stage: setup, views, explores, derived tables, validation, deploy. Put them in your repository.

The compounding effect is real. Every failure mode you document, every decision framework you formalize, every workflow step you encode makes the next project faster — and makes the agent's output on that project more consistent with how your team actually works. It's not a one-time investment. It's a library that grows with your experience and earns its keep on every project that follows.