Making deck.gl AI-Ready: What Seven Frontier Models Taught Us About Maps
This week I spoke at the Open Visualization Collaborator Summit at ETH Zürich, where the maintainers of deck.gl, kepler.gl, luma.gl and the rest of the vis.gl projects meet every year under the OpenJS Foundation. My talk asked how well AI models and agents work with deck.gl today, and what the project should change now that most code is written with AI assistance.
To answer that we ran seven frontier models (Claude Opus 4.8 and Fable 5.1, GPT-5.6 Sol and GPT-6 Astra, Gemini 3.1 Pro and 3.8 Flash, and the open-weight GLM 5.3) through a set of mapping tasks, rendered every result in a headless browser and reviewed every file. The slides, prompts, raw model outputs and harnesses are public at jatorre.github.io/deckgl-ai-ready.
Why deck.gl matters to CARTO
Every map CARTO draws runs on deck.gl: CARTO Builder, the maps embedded in customer applications, the maps an agent renders inside Claude or ChatGPT through the CARTO MCP Server, and the applications developers build with CARTO for Agents. We chose it for its rendering capabilities and for how it handles very large data volumes on the GPU, and we have invested in it for years. CARTO contributors led the MVTLayer in deck.gl 8.1 and created the @deck.gl/carto module in 8.3, then extended it with direct connections to BigQuery, Snowflake, Redshift and PostgreSQL, fetchMap for rendering Builder maps in any application, native H3 and Quadbin spatial indexes, and cluster and heatmap tile layers. When the team behind Procedural GL joined CARTO, colleagues like Felix Palmer became deck.gl maintainers and joined the vis.gl steering committee. We co-maintained deck.gl 9, with its move to TypeScript, WebGPU readiness through luma.gl 9 and the Sources and Layers architecture, and this month’s 9.4 release gives every layer in the official catalog a WebGPU path. At the summit, Felix and the rest of the steering committee presented what is coming in deck.gl 10, and several of the proposals below are aimed at that release.
So when agents started writing maps, how well they write deck.gl became our problem too. The talk covered five questions.
1. What do models recommend when someone asks for a map?
Ask for “a map that shows 2 million GPS points” and all seven models answer deck.gl. Ask for “the best library for a React app in 2026” and all seven answer MapLibre. Ask for five markers in one HTML file and all seven answer Leaflet. Older models such as GPT-4o, Haiku 4.5 and GPT-5-mini answered Leaflet for anything simple, Mapbox for React, and deck.gl 8. The frontier models have converged on MapLibre for the basemap, deck.gl for the data.
They do not know today’s deck.gl, though. Asked for the latest version, the answers ranged from 9.0 to 9.1. The actual release is 9.4.0, published four days before the talk. Six of seven install the MapLibre integration that 9.4 just renamed, and one invents a class name. Users rarely question the model’s choice, so they inherit the mistake.
Some of the confusion comes from deck.gl itself. Its MapLibre page offers three integration modes, two packages and two React roots. Across 75 generated maps that put deck.gl on MapLibre, the models took four different routes, and 12 still carried a v8-era shim. deck.gl needs one deck.gl + MapLibre story: one path per environment, stated in one place, with v10 as the moment to retire the rest.
2. How well do frontier models write deck.gl?
We gave each model five maps to build, one prompt each, no tools and no documentation: world airports as styled points with a tooltip and legend; a choropleth of 4,627 Vancouver census blocks with skewed data; 3D hexagons of 140,000 UK road accidents with a radius slider; animated New York taxi trips with play and pause; and an open brief, “the most impressive deck.gl visualization you can build.” Each file was rendered headless, screenshotted at 3, 8 and 14 seconds, and scored by a model judge on a fixed rubric. Then we reviewed every one by hand.
Almost every map works. Six of the seven models scored between 54 and 61 out of 68 on the four fixed tasks. GLM 5.3 scored 32: it mutated layer props instead of replacing layers and shadowed the library global, so several of its maps rendered empty.
The open brief is where they differ
The fifth task left the design to the model. The prompt, in full:
Build the most impressive, polished, single-page deck.gl visualization of this data that you can. You decide the design. Ideas, not requirements: animated trails, 3D buildings, lighting, a cinematic camera, a legend, a control panel. Must animate on load, centered on Manhattan, dark token-free basemap, no console errors. Judge yourself as a demanding visualization designer would.
The data was 996 New York taxi trips from the deck.gl examples. From that single prompt, Fable 5.1 produced the page below: animated trips over lit 3D buildings on a CARTO Dark Matter basemap, a slowly orbiting camera, a control panel with play, seek, speed and trail-length controls, and no console errors. It scored 16 out of 17. Press play to run the file the model returned, unedited.
Loads deck.gl 9.0 and MapLibre from a CDN, about 1 MBGPT-5.6 Sol and GPT-6 Astra were close behind, each with its own design. The weaker results had an invisible basemap or trips too faint to see. Every page below is the file the model returned, hosted as is.
The seven answers to every task, with scores and judge notes, are in the Mapbench results.
The more important finding is that the generated code is a generation behind. Most files load a deck.gl 8.9 bundle or use v8 patterns; the Fable page above pins 9.0.35. Only one model used the current overlay integration. The hexagon and trips tasks pulled every model toward the official example’s stack, palette and defaults, v8 included. Every choropleth is YlOrRd quantiles, skewed data goes unhandled, and legends disappear when the prompt does not demand them. The official examples are the training data, and they are years old. We have to update them.
3. How can agents drive deck.gl interactively?
This is closest to what we build at CARTO. Most agent use of maps is not “write me an app” but “show me”, “filter that”, “color it by income”, on a map that is already running. deck.gl has had the right interface for that since 2018: the agent writes declarative JSON and @deck.gl/json renders it. Ib Green’s 2018 RFC described “a growing need to generate powerful visualizations directly from the backend, without having knowledge about how to code front-end applications.” Replace “backend” with “agent” and the sentence describes 2026. SQLRooms, pydeck, kepler.gl configs, noodles.gl and CARTO all build on this idea.
CARTO does it two ways in production. The assistant inside Builder has about 27 tools that edit the running map one call at a time: stateful and precise, but every rule lives in prose and nothing checks it. Our MCP App has the agent write a complete @deck.gl/json spec that renders inside the conversation, in Claude or ChatGPT: stateless and portable, but the agent never sees the result. Both are in production, and both run into the same limitation.
Going in, we send the agent 36 KB of rules on every call, because the spec has no schema and every rule about what will render lives in prose. Half of it lists ways to get an empty map with no error. Coming back, the agent gets nothing: no errors, no viewport, no counts, no clicks. An unknown layer type is logged and replaced with null, and the map renders without it. The agent reports success and the user sees an empty map.
We also tested whether frontier models can write the spec directly. Every model got the syntax and the view right. The failure is always in the same place, the data-driven color. Four wrote a valid expression, one used CARTO’s helper vocabulary, which only exists in our registry, and two invented a helper function that does not exist. The result is a map with no fill and no error.
Our proposal is to make @deck.gl/json v2 the agent interface. A JSON Schema generated from Zod, including the compatibility rules, so we get validation, structured outputs and editors for free. A conversion report instead of warn-and-drop. State read-back: viewport, layers with counts, the picked object, an optional screenshot, finishing the back-channel the 2018 RFC left open. Patch semantics for multi-turn editing, a data-source concept for SQL, tiles, Arrow and cloud-optimized GeoTIFF, and registry profiles so vendors like CARTO can publish their layers with their schemas.
Two provocations for v10: accept Mapbox-style expression arrays as accessors, which with GeoArrow data and luma.gl’s new GPGPU module could compile to GPU transforms instead of per-row JavaScript; and one color-scale vocabulary in core instead of several vendor ones. CARTO will help drive this, and our open-source agentic deck.gl library is where we prototype it.
4. Does the website and documentation work for AI?
luma.gl, maintained by the same technical steering committee, ships llms.txt, a Markdown version of every page, an agent skill and a “Working with AI” guide. MapLibre publishes nine official agent skills. Mapbox has llms.txt and MCP servers. deck.gl’s llms.txt returns a 404. The consequence is measurable in questions one and two: every model stops at 9.1 and most generated maps load v8.
Our suggestion is to copy luma.gl, and we opened the pull requests before the talk: llms.txt and page Markdown for 185 documentation pages (visgl/deck.gl #10677), and a deckgl agent skill plus a “Working with AI” page built from the mistakes above (#10678). Both were reviewed by independent agents before we opened them, and both disclose the AI assistance.
5. How do we handle AI contributions?
The contributions are already AI-assisted. The median pull request description in visgl/deck.gl was about 400 characters through mid-2025 and has been 1,200 to 2,500 since late 2025. Four of the six most active contributors quadrupled theirs within two quarters. The OpenJS Foundation adopted a Policy on Use of AI Coding Assistants on 27 March 2026 that binds every vis.gl repository, and the contributing guides and PR templates say nothing about it. We proposed writing it down: the policy plus ten practices from Node.js, MapLibre, LLVM and the Linux kernel, in visgl/tsc #20, with a companion for deck.gl in #10680.
Disclosure is the easy part. Everybody is AI-assisted now, and naming the tool in a foundation’s commit history mostly advertises the vendor. Assume every PR is AI-assisted and judge what the author verified. The harder question is the project’s posture. When pull requests arrive faster than anyone can review them, some opened for social validation and some from autonomous agents that fix bugs and improve performance without anyone asking, what do we do? At CARTO we already run agents like that on our own code. For security, automation is not optional: the issues in a library like this will be found by agents first, and the only defence that keeps up is agent-driven too. How do agent contributions plug into deck.gl? Verified how, tested how, budgeted how, reviewed by whom?
Five asks for the community
- Adopt
@deck.gl/jsonv2 as a TSC priority, with a schema and a conversion report. CARTO helps drive it. - Ship
llms.txtand an official agent-skills repository this quarter. - Improve the documentation and examples now, with AI.
- Adopt the OpenJS AI policy into the vis.gl developer process, with disclosure.
- Decide whether we are OK with automatic development, and who pays for it.
Each ask comes with the analysis and a reviewed pull request, so the discussion can start from something concrete. This talk, the experiments and the PRs were themselves built with AI agents, and every PR says so.
Agents are deck.gl’s newest users and its newest developers. They already like it. Let’s make it easy for them to be right.
What this means if you build with CARTO
The same findings shape what we ship. CARTO for Agents gives coding agents the current @deck.gl/carto patterns through skills, so a vibe-coded application does not inherit a v8 bundle. The CARTO MCP Server renders agent-written deck.gl maps inside Claude, ChatGPT and Copilot, and the read-back and validation we are proposing for @deck.gl/json v2 will land there first. The agentic map-making workflow in Builder is the stateful half of the story, where the agent edits a running map one verb at a time.
If you build maps with agents, or agents that build maps, we would like to compare notes. The slides, experiments and raw model outputs are at jatorre.github.io/deckgl-ai-ready, the proposals are open for review on GitHub, and CARTO for Agents is available to every CARTO user today. Thank you to the summit organisers at ETH Zürich and the OpenJS Foundation, and to everyone who pushed back in the room.
