Short answer: no. Longer answer: it replaces a part of the job that was never the valuable part, and it makes the valuable part more important. Here is our honest take after a year of rolling out Gemini in Looker and Conversational Analytics for clients.
What Conversational Analytics does well
Conversational Analytics lets a business user type "what was revenue by region last quarter, and how does it compare to the quarter before" and get a table, a chart and a plain-English summary. On a well-built Looker explore it is genuinely good at:
- The long tail of simple questions. The requests that used to arrive as "can you just add a filter for X" tickets. Most of them never needed a developer; they needed a person who knew which field to pick.
- Translating business phrasing to fields. Given good labels and descriptions, it finds
orders.total_revenuewhen the user says "sales" andusers.regionwhen they say "territory." - First-draft visualizations. Chart type selection, sensible sorting, a summary paragraph.
- Follow-up questions. "Now just the west" works, because the conversation keeps the context.
Gemini's developer-facing features help too: drafting a LookML view from a table, suggesting field descriptions, explaining an unfamiliar explore. None of this is magic, but it removes typing.
Where it fails without a curated model
The failures are consistent and they all trace back to the model, not the model of the LLM kind, the LookML kind.
Ambiguous metrics. A model with revenue, gross_revenue, net_revenue, revenue_usd and total_revenue produces five different answers to "what was revenue," and the assistant's choice depends on wording. Dashboards had this problem too; they just hid it behind a tile someone had chosen years ago.
Unhidden implementation fields. Surrogate keys, ETL timestamps, _fivetran_synced, boolean flags with cryptic names. The assistant will happily group by customer_sk when the user asks for "customers."
Explore sprawl. Forty explores, half of them abandoned, several joining the same tables different ways. The assistant has to pick one, and the one it picks determines the join path and therefore the number.
Missing defaults and guardrails. No always_filter on a date means "show me orders" scans five years. No access_filter means an AI answer can cross a row-level boundary a dashboard would have respected, if permissions were enforced in the dashboard rather than the model.
No ground truth. Teams roll out the assistant, users get plausible numbers, nobody compares them to the finance pack, and trust evaporates the first time a VP quotes a wrong figure in a board meeting.
None of these are solved by a better language model. They are solved by a better semantic layer, which is to say by a Looker developer.
The new job description
The Looker developer's job in 2026 looks like this:
Semantic-layer curation. One canonical measure per business metric, with alternates hidden or removed. label and description written as a business user would phrase the question, because that text is now the interface. hidden: yes on everything a user should not see. A small number of curated explores, with always_filter, conditionally_filter and sensible sql_always_where, and the rest hidden from the assistant.
Evaluation. A question set (thirty to fifty real questions from real users, with expected answers taken from trusted reports) that runs against the assistant after every model change. Pass rate is the metric the team reports. This is new work, and it is the work that separates a demo from a rollout.
Guardrails. Row-level security enforced in the model (access_filter, user attributes, required_access_grants) rather than in dashboards, so it applies to every path including AI. Explicit decisions about which explores are exposed to natural-language querying.
Cost and performance. AI-generated queries are less predictable than dashboard tiles; aggregate awareness, caching and partition-friendly dimensions matter more, not less. See Looker + BigQuery cost optimization.
Everything that was already the job. Joins, fan-out, PDTs, embeds, CI, migrations. Gemini does not do any of that.
What shrinks is the ticket queue of "add a filter," "change the chart," "can you pull this number." That was the part of the job developers liked least, and the part that made business users wait.
Hiring implications
If you are hiring a Looker developer now, the questions to add are about curation and evaluation, not just LookML syntax: how would you prepare a model for Conversational Analytics, how would you measure answer accuracy, what would you hide. We updated our interview question list accordingly.
If you are deciding whether to replace a developer with the assistant, look at where your numbers come from. If the answer is "a model one person maintains," that person just became more important, because every AI answer now depends on the quality of their work.
Our position
Gemini in Looker is worth rolling out, and it will reduce the volume of simple requests reaching your data team. It will also expose every shortcut in your model. Budget for the curation and evaluation work before the rollout, not after the first wrong number. If you want help with either, that is exactly what our AI & Gemini in Looker service is for; we also wrote a hands-on tutorial on the Conversational Analytics API. Contact us.