To AI, or not to AI: a GIS developer’s soliloquy
Automation using AI can certainly be powerful, but using it without exercising geographic discernment carries with it the same risks that copied code and inherited tools do. Modern GIS developers need to be comfortable not just with using AI tools, but also deciding when they are best used and assessing their output. In this blog post, Esri Canada senior certified ArcGIS instructor André Piasta discusses why it’s critical for GIS professionals to exercise their discernment in the age of AI.
Key takeaways
- Automation using AI can certainly be powerful, but using it without exercising geographic discernment carries with it the same risks that copied code and inherited tools do. Modern GIS developers need to be comfortable not just with using AI tools, but also deciding when they are best used and assessing their output.
- The question is not whether AI will write GIS code—it already does. Instead, the question is whether GIS professionals will remain the owners of geographic expertise, informed as they are by critical thinking, judgment and experience.
To AI, or not to AI: that is the question—
Whether ’tis nobler in the codebase to suffer
The joins, the loops, the scripts run late at night,
Or to take arms against a sea of rasters,
And by automation end them.
If Shakespeare’s Hamlet were a GIS developer, he would not pace the battlements of Elsinore, but the blue-lit edge of a dual-monitor desk: Python on one screen, a stubborn map draw on the other. The ghost that visits him would not be his father’s spirit, but an inherited script—an old ArcPy workflow, brittle as glass, whispering of deprecated tools, hard-coded paths, silent assumptions and projections applied without comment. “Remember me,” it murmurs from a geodatabase no one dares refactor.
Consider this ...
Modern GIS developers stand at a familiar crossroads. On one side lies craft: understanding spatial joins, coordinate systems, geoprocessing environments, data lineage, precision, scale, topology and why a buffer that appears correct in one projection may mislead in another. On the other side stands AI: ready to draft scripts, suggest SQL, classify imagery, generate tests and turn a plain-language request into a runnable workflow before the coffee cools.
The temptation is real. Why hand-code feature extraction when a model can sketch the workflow in minutes? Why wrestle with parameter order, regular expressions or repetitive schema checks when an assistant can produce a first draft on demand? For overworked GIS teams, AI and automation can feel like deliverance: fewer manual steps, faster pipelines, cleaner logs, more time for analysis and less time spent asking why a dissolve produced ten thousand features instead of one.
And yet, herein lies the rub. GIS code is never merely code. It is geography expressed as logic. A script may run and still be wrong: the wrong coordinate system, the wrong datum transformation, the wrong distance unit, the wrong analysis extent, the wrong join cardinality, the wrong assumption about null geometry, privacy, access or data sensitivity. In GIS, a successful execution message is not the same as truth.
To run code one does not understand is to invite a quiet kind of treachery. It may not fail dramatically. It may not throw an error. It may produce a map, a table, a service, a dashboard or a decision layer with every appearance of authority. But if the developer cannot explain what the code does, why it does it, what assumptions it makes, what inputs it trusts, and what damage it could cause, then the code has become Claudius: crowned by convenience, unexamined, and dangerous.
As GIS professionals, we are often haunted by the ghostly remnants of our predecessors.
AI-generated GIS code can hallucinate libraries, invent tool parameters, misuse coordinate systems, omit exception handling, overwrite outputs, expose credentials, mishandle tokens or ignore permissions. It can recommend shortcuts that work in a tutorial but fail in production. It can process sensitive spatial data as though all data were harmless. It can mistake a plausible workflow for a defensible one. And because it often writes with confidence, it can make uncertainty look finished.
Nor is the danger limited to AI. The same peril lives in copied scripts, borrowed notebooks, anonymous snippets, old ModelBuilder exports and tools passed from colleague to colleague like relics from a former age. To use any tool without understanding its purpose, limits, dependencies and consequences is to mistake possession for mastery. A geoprocessing tool, like a sword in Hamlet’s hand, must be understood before it is drawn.
Think about it: as a GIS professional, you don’t just operate software. Every day, you’re assessing inputs for quality and fit, flexing your geographic knowledge and interpreting results.
The wise GIS developer, therefore, must be both coder and critic. Let AI draft, but do not let it decide. Read every line. Trace every input. Confirm every output. Validate coordinate systems and transformations. Test edge cases: empty features, multipart geometry, dateline crossings, mixed units, missing attributes, unexpected permissions and malformed paths. Log what happened. Handle errors with intention. Protect secrets. Review dependencies. Run code first in a safe environment, not against production data, and never against data whose sensitivity has not been considered.
“To be, or not to be”, Hamlet asks. In our case you might also ask, “to do, or not to do”.
Hamlet’s tragedy is not thoughtfulness; it is paralysis. GIS developers who reject AI entirely may suffer a similar fate, watching others automate quality checks, generate test cases, document workflows and prototype responsibly at speed. AI, used well, is not a usurper king. It is a squire. It carries boilerplate, offers alternatives and sharpens learning—while the developer remains sovereign over intent, evidence, ethics and spatial truth.
So, what is the answer? To AI, yes—but not only to AI. Use it to explore approaches, draft scripts, explain unfamiliar functions, generate tests and reveal possible failure points. Ask not merely “what code should I run?” but “why this code, for this data, in this coordinate system, under these constraints, with these risks?” Let AI write the first version if it must, but make the final commit your own.
In the end, the question is not whether AI will write GIS code. It already does. The deeper question is whether GIS professionals will remain authors of spatial reasoning—or become ghosts, haunting automated pipelines they no longer understand. For in GIS, as in Denmark, something is rotten when power outruns comprehension. Balance, scrutiny and judgment are the difference between automation and abdication, between tragedy and mastery.
Want to deepen your spatial reasoning capabilities and automate processes in ArcGIS in a way that leverages your decision-making capacity? Explore related courses: