We found a bug in one of our production datasets yesterday. By the afternoon we had diagnosed it, fixed it, checked the fix against imagery in two metros, updated the client PDFs, and committed the change. A corrected reprocessing run across 198 metro areas was already underway — rasters differenced, polygons rebuilt, geodatabases mirrored, metadata regenerated, ArcGIS Pro projects patched, delivery packages re-zipped.
One GIS professional was involved. His job wasn’t writing the code. It was looking at maps and deciding what was right and what wasn’t.
Most of what gets written about AI and GIS is either a prediction about the future or a demo that makes a simple map. I’d rather describe a normal day. We run our production geoprocessing pipelines with an AI coding agent — Claude Code, driving Python, arcpy, and open-source geospatial libraries. Here’s how that goes.
Who does what
The split that works isn’t “AI does the GIS work.” It’s this:
The GIS professional notices things and makes the calls. “These frontier polygons are sitting on a subdivision that’s clearly finished — here’s a screenshot.” “These slivers look like noise. Should we drop them?” “The heat map re-renders every time I zoom.”
The AI figures out why, writes the fix, and runs it everywhere. It reads the code, comes up with theories, writes throwaway scripts to test them against the real data, implements the fix, runs the pipeline, and checks the result at the exact spot the analyst flagged.
Every real improvement to our Ground Pulse product this cycle started with a GIS professional looking at a map and saying “that doesn’t look right.” None of them ended with that same professional writing code. You can learn more about our Ground Pulse data product in this article on the Boise metropolitan area.
It digs deeper than you’d normally pay for
The bug that started our day is a good example. A reviewer noticed polygons labeled “no buildings present” sitting on top of finished subdivisions. The obvious answer was a stale building dataset — annoying, nothing to be done, case closed. A busy analyst would have written that in a caveat and moved on.
The AI kept going. It wrote a quick script joining the shipped polygons against the raw building data and found something that didn’t add up: 260 building points inside polygons whose stored building count was zero. The data had been there when the pipeline ran.
So it dug into the pipeline code and found the real problem, a pandas index-alignment trap. A GeoDataFrame had been filtered without resetting its index. Later, a new frame paired one column by position while pandas matched the geometry column by index label. The result: none of the building points carried the right geometry, and 19.7% of them were quietly NULL. Every classification downstream of that was wrong — wrong in a believable way, which is why it had survived visual review across a whole product line.
Two things worth taking from that. First, this kind of bug — a quiet mismatch that produces answers that look fine — is everywhere in dataframe-based geoprocessing, and it’s exactly what an AI agent finds and a human often doesn’t. Second, how it found the bug matters. It didn’t reason its way there in the abstract. It wrote small scripts and ran them against the real data, the same way a good analyst would, just faster.
Python is the way in — including the parts nobody documented
All of this works because modern GIS is programmable from end to end. Our pipeline uses:
- geopandas, shapely, and pyarrow for the heavy vector work: spatial joins across a million building footprints, dissolves, percentile filtering, reading GeoParquet straight from S3
- rasterio for differencing national land-cover rasters and vectorizing the change
- arcpy for the Esri-specific last mile: file geodatabase mirrors, ArcGIS Pro project edits, layout exports
- the CIM (Cartographic Information Model) for everything arcpy doesn’t expose
That last one is where the agent surprised me. Bookmarks are the example. arcpy can create them — MapFrame.createBookmark and MapView.createBookmark have been there since Pro 3.2 — but they build a bookmark from a map frame or view’s current camera, one at a time. What we needed was hundreds of bookmarks written from extents we’d already computed: one overview per metro, one per county, one per top development site, across every project in the library. So the agent unzipped an .aprx file, found each map’s JSON definition, and wrote the bookmark entries straight into the CIM. It used the same approach to repoint layout map frames and pin the heat-map renderers so they stop recalculating on every zoom. If a setting exists in the Pro interface, it exists in the CIM, and anything that can read a JSON schema can set it.
The broader point: the more of your work is reachable through code, the more an agent can do. Shops that live entirely in point-and-click have nothing for it to grab. Shops with even a little Python get a lot back.
It reasons about the domain, not just the code
The skeptic’s line on AI coding is “fancy autocomplete.” Here’s a case that isn’t.
After we pinned the heat maps to a fixed intensity so they’d stop re-rendering on zoom, they came out washed out. The agent’s first attempt had scaled the intensity ceiling by each metro’s average point density compared to a reference metro. Fixing it took an actual cartographic insight: how prominent a heat map looks depends on its peaks, not its average. A metro whose growth is spread across a wide valley has a high average density but ordinary hot spots, so scaling by the average pushes the ceiling too high and mutes everything. The agent rewrote the calibration to estimate peak kernel density on a grid and scale by the peak ratio instead. The maps came back looking much better.
That’s not autocomplete. It’s thinking about density estimation, renderer behavior, and how the eye reads a map at the same time. GIS is full of problems like that, because the field sits between statistics, cartography, and software.
The unglamorous part: planning
None of this works as a free-form chat with a bot. Here’s the structure that made it work:
Write the spec first. Every product has one: data sources, methodology, output schema, known caveats, a verification checklist. The AI reads the spec before it touches code, and updates it in the same change when the behavior changes. The spec is what keeps 198 metros consistent, and it’s what lets a session six months from now pick up where this one stopped.
Pilot before you sweep. Nothing runs library-wide until it’s been checked on one or two metros. Today’s order: fix, run Denver and Boise, have a reviewer look at the actual maps at the exact spots that prompted the complaint, adjust, then start the 198-metro run. The pilot caught two design problems — a layout extent choice and the heat-map calibration — that would have been expensive to find after a full run.
Make every stage safe to re-run. Each stage caches its inputs, notices when they’re stale, and can run again without breaking anything. When you’re running eleven stages across 198 metros overnight, some will fail. (Two of ours always do: Alaska and Hawaii fall outside the land-cover dataset.) Being able to re-run turns a failure from a disaster into a line item on the morning report.
Keep a project brief in the repo. A CLAUDE.md file tells the agent the conventions, the questions that are already settled, and when to stop and ask (“if the specs disagree, come find me”). It’s the difference between an agent that follows your architecture and one that reinvents it every session.
Put people where only people work. The agent proposes, the analyst decides. Which sliver threshold is right? Should the frontier layer include land that’s graded but not paved? Is this layout extent better? Those are product decisions, made by whoever knows the customers. They go fast, because the agent brings numbers to each one: a 2-acre floor drops 92% of the features but keeps 62% of the area.
What it doesn’t do
Check the work. The agent verified every fix at the coordinates the reviewer flagged, and the reviewer still looked at the maps afterward. Geoprocessing that nobody inspects is a liability, not an asset.
Data licensing is on you. An agent will happily pull in a dataset whose license forbids commercial redistribution. Ours is told to flag licensing questions, but the responsibility doesn’t transfer.
The real world gets in the way. Files lock while ArcGIS Pro has them open. A background run can’t save a project someone is looking at. Your automation plan has to account for the humans, literally.
Bad specs scale too. A wrong method applied to 198 metros gives you 198 wrong deliverables. That’s why the pilot rule isn’t optional.
What this means for the GIS professional
You’re not out of a job. You’re doing a better one.
Every hour this saved on debugging pandas indices and zip-patching project files went to work that actually needed a geographer: recognizing that a “frontier” polygon was really a finished vehicle storage yard, deciding what to tell a customer about building-footprint lag, judging whether a layout tells its story at a glance.
The job is moving from writing the automation to directing and checking it — supplying the observations, the judgment, and the standard. The people who do well will be the ones who can look at a map and say exactly what’s wrong with it. That skill just became the hardest input to find.
If you want this in your own shop
Building AI-assisted geoprocessing workflows is one of the main things our consulting arm, Location3x, does for clients. Everything in this post — the spec-first structure, the pilot-then-sweep discipline, the project brief that keeps an agent inside your architecture, the arcpy and CIM work that reaches the parts of ArcGIS Pro the Python API doesn’t — came out of the same practice we bring to consulting engagements. We do this work for government agencies and private teams: Python automation, data science, Experience Builder, and AI integration.
We’re not selling a tool. We help your staff set up pipelines they can run, audit, and hand off, using their data and their standards. If your team is doing repetitive geoprocessing by hand, or has scripts nobody trusts enough to run library-wide, that’s the conversation to have.
Location3x is the consulting arm of Geospatial Training Services. We build AI-assisted geoprocessing pipelines, Python automation, and GIS data products for government agencies and private teams — including Ground Pulse, our satellite-measured development data for 198 U.S. metros. If you’d rather learn to do it in-house, our training arm covers the same ground. Contact us for more information at sales at geospatialtraining.com or location3x.gis at gmail.com.
