LookML over LangChain: what I learned shipping AI in a Looker dashboard for a US nonprofit
A senior engineer at a $200M SaaS company asked me, point-blank, a question I have been chewing on for three months: “Should I rebuild our analytics on top of an LLM, or fix the semantic layer first?” The right answer surprised both of us. It is fix the semantic layer first. The LLM becomes ten times cheaper — and ten times more useful — when you do.
This is the lesson I learned shipping a Looker + RAG dashboard suite for JerseySTEM, a US-based 501(c)(3) science-education nonprofit, and it is the lesson I want every senior engineer scoping an “AI for analytics” project to hear before they spend six months and $400K building the wrong thing first.
The case for semantic-layer-first
There are three reasons the answer is “fix the semantic layer first,” and they hold whether you are a $200M SaaS company or a $5M nonprofit.
One. A large language model is, at its core, a presentation layer over a data layer. If the data layer is ungoverned — if the same metric is computed three different ways in three different dashboards, with three different names, by three different analysts — the LLM does not save you. It hallucinates the metric. It produces confident, well-formatted answers about a number that does not exist in the data the way you described it. The result looks like progress and ships like a liability.
Two. LookML is the only widely-deployed semantic layer in 2026 that is version-controlled, code-reviewed, and treated like an artifact of the engineering organization rather than a configuration file. Power BI has calculation groups, but they are not reviewable in a pull request. Tableau has LOD expressions, but they live next to the workbook. dbt has metrics, but it does not yet have the surface area Looker has for the executive dashboard a CDO or a board expects to read. LookML is the closest thing the analytics world has to production-grade code, and that is the reason it has lasted.
Three. A RAG pipeline over a governed semantic layer is cheap. You are not searching 200,000 documents. You are searching 200 fields, 50 derived measures, and a few dozen business definitions. The retrieval problem is solvable in an afternoon. The prompt problem is solvable in a week. The hallucination problem is solvable the moment the semantic layer is governed, because the model is no longer inventing the metric — it is reading it.
The result is that RAG over a clean semantic layer is one to two orders of magnitude cheaper to run, faster to ship, and more trustworthy in production than RAG over the raw warehouse. I have seen this play out three times. The fourth time, with JerseySTEM, was the case study I want to walk through.
The case study: JerseySTEM
JerseySTEM is a US 501(c)(3) science-education nonprofit. Their fundraising operations run on Salesforce Nonprofit Cloud, and the data lives in BigQuery with a Looker layer on top. When I joined, the dashboards were a manual spreadsheet workflow — the development director would export from Salesforce, paste into Google Sheets, build a chart, paste it into a board deck. The board had stopped trusting the numbers. The executive director had stopped trusting the board.
The first thing I did was not ship a chatbot. It was to read every existing query, identify which fields were silently re-derived in different ways, and codify the canonical metric in a single LookML view. Incoming anniversaries meant the same thing in every dashboard. Active sponsors meant the same thing. “Recovery email” stopped being a free-text Excel column and started being a field in the source system, populated by a RAG pipeline that classified bounce-backs from the SMTP log.
The dashboards replaced a manual spreadsheet workflow and feed the client relationship team every Monday. More importantly, the development director, the executive director, and the board now read the same number for “active sponsors.” That was not a chatbot deliverable. That was a LookML deliverable. The chatbot is coming next quarter, and it will land in a week because the data layer underneath it is finally trusted.
The non-obvious lesson
The AI hype in BI and analytics is mostly premature. The bottleneck is not “we do not have a smart enough model.” The bottleneck is “we do not trust the number.” A principal-engineer-grade semantic layer is the prerequisite, not the output, of a credible AI copilot for analytics.
If you are scoping a “RAG over our data warehouse” project, the first question is not “which model, which embeddings, which vector store.” The first question is: can a senior engineer, on a Monday morning, point at any number on any dashboard and tell you the SQL, the source, the lineage, and the last time it was reviewed? If the answer is no, the LLM will not save you. It will make the untrustworthy number more confident.
If the answer is yes — if the semantic layer is already governed, the metric is already canonical, the lineage is already reviewable — then the AI copilot is a 4-week engagement, not a 6-month one. The retrieval problem is small. The prompt problem is bounded. The hallucination problem is mostly solved by the semantic layer you already built. You ship the copilot. You measure the cycle time from “board question” to “trustworthy answer.” You win.
The closer
If you are scoping a “RAG over our data warehouse” project and the semantic layer is not already there, the right first step is not the build. It is the audit.
The audit will probably find that 60% of the model time is being spent re-deriving a metric the semantic layer should have defined. It will probably find that the same KPI is computed five different ways across five different workbooks. It will probably find that the executive team has quietly stopped trusting the numbers, and that the AI project is being scoped to fix a trust problem that no model can solve.
The senior move is to fix the semantic layer first. The model is downstream. The trust is upstream. And the engineer who can write LookML, ship a RAG pipeline, and explain to a board why the same number is now the same number everywhere — that engineer is the one the AI-for-analytics projects need.
If that is the engagement you are scoping, my calendar is open. The JerseySTEM case study is on the work page. The senior hand ships.