Why Machine-Writing Code is the Best (and Most Dangerous) Thing for Geospatial:
The current discourse surrounding AI coding is nothing if not polarized. On one side, the technofuturists urge us to throw away our keyboards; on the other, skeptics dismiss Large Language Models (LLMs) as little more than “fancy autocomplete” that will never replace a “real” engineer. Both sides miss the nuanced reality of the shift we are living through right now.
I recently sat down with Matt Hansen, Director of Geospatial Ecosystems at Element 84, to discuss this transition. With a 30-year career spanning the death of photographic film to the birth of Cloud-Native Geospatial, Hansen has a unique vantage point on how technology shifts redefine our roles. He isn’t predicting a distant future; he is describing a present where the barrier between an idea and a functioning tool has effectively collapsed.
The “D” Student Who Built the Future
Hansen’s journey into the heart of open-source leadership began with what he initially thought was a terminal failure. As a freshman at the Rochester Institute of Technology, he found himself in a C programming class populated almost entirely by seasoned professionals from Kodak. Intimidated and overwhelmed by the “syntax wall,” he withdrew from the class the first time and scraped by with a “D” on his second attempt.
For years, he believed software simply wasn’t his path. Today, however, he is a primary architect of the SpatioTemporal Asset Catalog (STAC) ecosystem and a major open-source contributor. This trajectory is the perfect case study for the democratizing power of AI: it allows the subject matter expert — the person who understands “photographic technology” or “imaging science” — to bypass the mechanical hurdles of brackets and semi-colons.
“I took your class twice and thought I was never software… and now here I am like a regular contributor to open source software for geospatial.” — Matt Hansen to his former professor.
The Rise of “Vibe Coding” and the Fragmentation Trap
We are entering the era of “vibe coding,” where developers prompt AI based on a general description or “vibe” of what they need. While this is exhilarating for the individual, it creates a systemic risk of “bespoke implementations.” When a user asks an AI for a solution without a deep architectural understanding, the machine often generates a narrow, unvetted fragment of code rather than utilizing a secure, scalable library.
The danger here is a catastrophic loss of signal. If thousands of users release these AI-generated fragments onto platforms like GitHub, we risk drowning out the vetted, high-quality solutions that the community has spent decades building. We are creating a “sea of noise” that could make it harder for both humans and future AI models to identify the standard, proper way to solve a problem.
Why Geospatial is Still “Special” (The Anti-meridian Test)
For a long time, the industry mantra has been “geospatial isn’t special,” pushing for spatial data to be treated as just another data type, like in GeoParquet. However, Hansen argues that AI actually proves that domain expertise is more critical than ever. Without specific guidance, AI often fails to account for the unique edge cases of a spherical world.
Consider the “anti-meridian” problem: polygons crossing the 180th meridian. When asked to handle spatial data, an AI will often “brute force” a custom logic that works for a small, localized dataset but fails the moment it encounters the wrap-around logic of a global scale. A domain expert knows to direct the AI toward Pete Kadomsky’s “anti-meridian” library. AI is not a subject matter expert; it is a powerful engine that requires an expert navigator to avoid the “Valley of Despair.”
Documentation is Now SEO for the Machines
We are seeing a counterintuitive shift in how we value documentation. Traditionally, README files and tutorials were written by humans, for humans. In the age of AI, documentation has become the primary way we “market” our code to the machines.
If your open-source project lacks a clean README or a rigorous specification, it is effectively invisible to the AI-driven future of development. By investing in high-quality documentation, developers are engaging in a form of technical SEO. You are ensuring that when an AI looks for the “signal” in the noise, it chooses your vetted library because it is the most readable and reliable option available.
From Software Developers to Software Designers
The role of the geospatial professional is shifting from writing syntax to what Hansen calls the “Foundry” model. Using tools like GitHub Specit, the human acts as a designer, defining rigorous blueprints, constraints, and requirements in human language. The machine then executes the “how,” while the human remains the sole arbiter of the “what” and “why.”
Hansen’s advice for the next generation — particularly those entering a job market currently hostile to junior engineers — is to abandon generalism. Don’t just learn to code; become a specialist in a domain like geospatial. The ability to write Python is becoming a commodity, but the ability to design a system that accounts for the nuances of remote sensing is an increasingly rare and valuable asset.
History Repeats: The “Priesthood” of Assembly
This shift mirrors the 1950s, when the “priesthood” of assembly programmers looked at the first compilers with deep suspicion. Kathleen Booth, who wrote the first assembly language, lived in a world where manual coding was an arcane, elite skill. Those early programmers argued that compilers were untrustworthy and that a human could always write “better” code by hand.
They were technically right about efficiency, but they were wrong about the future. Just as the compiler was “good enough” to allow us to move “up the stack” and take on more complex problems, AI is the next level of abstraction. We might use a “Ralph Wiggum script” — a loop that feeds AI output back into itself until the task is “done” — and while it may be a brute-force method, it is often more productive than the perfection of the past.
Conclusion: The Future is a Specialist’s Game
We are moving away from being the writers of code and toward being the designers of systems. While the “syntax wall” has been demolished, the requirement for domain knowledge has only grown higher. The keyboard isn’t dying; it is being repurposed for higher-level architectural thought.
As the industry experiences a “recursive improvement” of these tools, the question for every professional is no longer about whether the machine can do your job. It’s whether you have the specialized expertise to tell the machine what a “good enough” job actually looks like. Are you prepared to stop being a coder and start being a designer?
In Conversation
From Photographic Film to Open-Source Geospatial: Matt’s Background
Daniel: You are the Director of Geospatial Ecosystems at Element 84. Before we get into the main topic, could you tell me how you got to this position? Do you have a background in software development? Did you start life as a geospatial coder?
Matt: I’ve been in this space for a while. Back in the early 90s, I got my bachelor’s degree in photographic technology at Rochester Institute of Technology — an exciting time because it was the tail end of photographic film and the beginning of the digital age. We were seeing the first sub-$1,000 digital cameras and Photoshop version one. After graduation I got a job in intelligence doing remote sensing, then went back for a master’s in imaging science, specialising in remote sensing and digital image processing. So I’ve been in the space for about 30 years.
Matt: It’s a bit of a funny story with coding. I took my first programming class as a freshman — a C programming class — and I had a terrible time of it. I had to withdraw. The next year I had to take it again, same teacher, and I got a D. I thought, software is just not for me. But later I picked up IDL — Interactive Data Language — and from there moved into C++ and Python over time, then started contributing to open-source projects around 2010. Geonode was the first one. A couple of years ago I caught up with that professor and told him the story: “I took your class twice and thought I was never going to be a software developer, and now here I am, a regular contributor to open-source geospatial software.”
Daniel: And what does the Director of Geospatial Ecosystems role actually mean?
Matt: E84 has a strong commitment to open source — we use it heavily and contribute to it, and we’re the main contributors to several libraries. I manage our public-facing code: what we maintain, where we put resources. It’s a relatively new position. On top of that I do business development and a lot of outreach and evangelism for open source and open standards. Some people know me from my work on STAC, where I developed a lot of the early ecosystem software and have been involved since the beginning.
Getting into AI Coding: From Manager Back to Builder
Daniel: What has your experience with AI coding been? What have you actually been doing with it?
Matt: I was a little slow on the uptake. AI for coding has been around for a few years now — moving from autocomplete to generating whole functions — but it wasn’t until the last year or so that I really dove in. In my position I wasn’t coding anymore, as tends to happen when you move up into management. Then I got tired of saying we needed to put resources into a certain library, so I thought: I’ll just do it myself. JFDI, as they say. I started working on a STAC browser UI and a bunch of other projects since then. It’s really gotten me back into coding. I’m not doing it full-time, but I’ve genuinely enjoyed it. It lets you go outside your comfort zone — now I can pick up any project and build a simple UI or do some DevOps without having to rely on other people.
Daniel: I really resonate with that. I’ve had ideas in my mind for a long time — things I wanted to see in the world — but didn’t have the skills to build them myself. And I can’t tell you how exciting it is to live in a world where you can just make the thing. That said, in my limited experience, you can’t just build anything. There are catch-22s, and it’s easy to get 80% of the job done. That last 20% has been difficult. But it’s amazing — I’m loving it.
Matt: It’s so much fun. I’d encourage anyone and everyone to learn these tools and start using them. Not to abandon the skills they already have — that’s not what I’m suggesting — but it’s worth learning and understanding how to use them.
The Fragmentation Problem: AI and Open-Source Signal Loss
Daniel: If we broadly say we live in a world where anyone is a developer — people like me who have next to no development skills can create software — and we take that further to tools building other tools, what does this mean for software development, and specifically for open-source?
Matt: I had the same question, and I gave a talk on this at FOSS4G in New Zealand. I was thinking: if anybody can build anything just by prompting an AI, what does that mean for open-source software? Do people need it anymore? Can I just tell the AI to create a thing and it will? Do we still need shared libraries?
Matt: We know AI can’t quite do that yet — maybe in the future — but that thinking led me to really examine the impact on open-source software. I see a danger. Overall I think this is a positive development, but I see a problem with vibe coding: it’s a partial solution. It doesn’t handle scaling. It doesn’t handle security. It could touch on these things, but it’s not a subject matter expert. And in the geospatial world, we are experts. We have domain knowledge that I think is still critically important.
Matt: I’m concerned that the rise of AI and the proliferation of public software on GitHub could drown out the signal from really good, vetted libraries, causing a fragmentation where it becomes even harder to find proper solutions. I don’t know what the future holds, but I think there are things we can do. The role of subject matter experts is more important than ever. I know a lot of people have anxiety about jobs, but this domain knowledge is really where the value lies in our space.
Daniel: So when people say “spatial is special” — is that the domain knowledge you’re talking about? Is that the wall we can hide behind to protect our jobs?
Matt: In the long run, no. AI will get better. Technology is always about working yourself out of a job eventually — you become obsolete and you have to learn new skills. The jobs aren’t all going away; they’re shifting. Software development as a job twenty years from now — no one’s going to be writing Python code — but we’ll still be designing software systems, just not by writing code.
Matt: “Geospatial isn’t special” has been a message in the community for a long time — the idea that we should integrate geospatial understanding into general-purpose software. GeoParquet is a perfect example: rather than a separate geo file format, the push was to get geospatial as a data type inside Parquet. That’s worked well. However, AI actually shows that geospatial is still special, because when you ask an AI to do something with spatial data, it still doesn’t necessarily understand all the edge cases. The anti-meridian is a great example. There’s a library Pete Kadomsky wrote at Development Seed that handles polygons crossing the anti-meridian. But if you’re just vibe coding and you don’t know about that library, the AI is almost certainly going to create its own solution — one that works for your local dataset but will fail under real-world conditions. It doesn’t really understand the geospatial data. Not right now. In that sense, geospatial is still special and still requires domain knowledge.
Documentation, Standards, and the Geospatial Expert Metaprompt
Daniel: I have a feeling this is what you mean by fragmentation — the AI creates a bespoke solution instead of standing on the shoulders of giants and using established packages. Tried-and-true geospatial software gets lost in the noise. What can we proactively do about it?
Matt: Exactly. The AI is going to default to creating bespoke implementations unless it’s directed otherwise. If you have domain knowledge and you’re using AI, great — you can direct it to use specific libraries and approach things in a certain way. But without that knowledge, the AI might not know which libraries to use. So you end up with thousands of different fragments of code, and if they’re released publicly on GitHub, we really do create a sea of noise that makes it harder in the future for AI to find the actual proper solution among all those vibe-coded fragments.
Matt: It’s the same problem Google has been addressing for years — surfacing the best answer. Search engine optimisation grew up around signals like backlinks: if lots of sites reference a particular source or piece of software, that tells Google it’s worth surfacing. The same principle applies here.
Daniel: Do you think the problem will just solve itself? Will AI figure it out?
Matt: Maybe eventually. But some days when I’m working with AI, I’m convinced there’s no way it’s ever taking my job. You go through phases: “This thing is amazing, I am useless, why am I even here?” And then you hit the valley of despair — “Oh my god, this thing is so stupid, it can’t do anything.” I go up and down.
Daniel: Same. And in my experience I’ve found I need to be very specific — “I would like to use Leaflet, do not create any custom tools, only use standard libraries.” But getting back to the fragmentation problem: assuming we’re proactive spatial professionals who don’t just want to wait and hope, what could we do? Better documentation? Marketing solutions that work? Could the community support certain solutions and make it clear to the machine that this is what people believe in and are using?
Matt: Yes, and I know people listening are probably thinking, “Great, they’re just telling me to write better documentation — engineers have heard that for years.” But it’s true, and there’s really no excuse anymore. AI is actually very good at writing documentation. One of the things I’ll be doing over the coming months at E84 is improving how we present our open-source code. You can clean up a readme really easily now. And here’s the payoff: the things that make code easier for humans to use also make it easier for machines. Two for one — a library better understood by developers and by the AI tools they’re using.
Daniel: What about the idea of creating a giant markdown file — a list of community-vetted software that people can feed to the AI?
Matt: That’s probably a pretty good idea. There are lists like that already — Awesome Geospatial and various online indexes. What we might need is a big metaprompt that includes all of these things, so you can feed it into the AI to prime it as a geospatial expert: “Here is the geospatial expert developer prompt.” Beyond documentation, though, there’s something even more important: standards. The AI is going to be able to interface with standard APIs far more reliably when there’s a single, well-documented standard with multiple implementations. Take STAC as an example: without STAC, you’d have all these different APIs with different field names, all this extra code to handle bespoke interfaces. With STAC, there’s one standard. The AI can understand it, you can point it to implementations, and they all support the same core features. Standards are absolutely critical for AI to be successful.
From Developers to Designers: The Foundry Model and the Next Generation
Daniel: Could we take the metaprompt idea one step further and have standard packages as well? Is that where we’re headed — standards for how software interfaces, plus vetted packages?
Matt: I think that still seems a little low-level to me. As we move from being developers to interacting with AI systems and designing software, it’s like moving from software developers to software designers. I’ve been promoting this idea of “the Foundry” — it’s not a specific thing, just a term I needed. The Foundry is essentially a collection of specifications. If you’re familiar with GitHub Speckit, people have been vibe coding for a couple of years now, and there’s been a push toward more rigorous specification: a formal process for describing the constraints and requirements for software. That, or something like it, might be the future. We’re going to be defining blueprints, but in human language rather than a programming language.
Daniel: That makes a lot of sense. Do you see closed-source software facing exactly the same issues as open source?
Matt: I think it’s a problem across the board. I wonder about the future of proprietary software too. If anybody can code anything in most cases, open source kind of wins, right? Linux runs the world now — thirty years ago that was an experiment. I wonder if this is going to accelerate a decline of proprietary software except for niche use cases, which is really where we still see it anyway.
Daniel: I’d agree with that. I’d also add that instead of talking about closed-source software, we might be talking more about personalised software. Why pay a $50-a-month subscription when you can build exactly what you need for yourself? It’s not one-size-fits-all. Sure, maybe it’s not as pretty, but if it’s just for you, running on your local computer, and you don’t need all the security overhead — that’s a real competitor to a lot of niche software. And of course that will feed more fragmentation: lots of packages that aren’t really usable by anyone other than a small handful of people.
Matt: Exactly. And because it’s such a low lift to make, why not push a new iteration every hour until you get it right? That’s the temptation for a lot of vibe coders.
Daniel: So you mentioned moving from software development to software design. How do people prepare for this? Let’s say someone has a daughter in her last year of a computer science degree, committed to becoming a software developer, and we’re staring into a world where AI writes the vast majority of code. What’s your advice?
Matt: There aren’t a lot of unemployed computer science graduates right now. But the domain knowledge piece is the play — that’s the value you bring. General computer science background is useful, but what will really matter in your job is being a specialist in something, not a generalist. And I’d tell her to do geospatial, because it’s cool.
Daniel: It’s a bit of a chicken-and-egg problem — do you become a software engineer and then get domain expertise, or vice versa? And can you be a software designer without ever having been a software developer?
Matt: I think you can, but I’m not entirely sure it’s really true right now. I’d be interested to see how far people who don’t have any software experience can take vibe coding — without knowing what a programming language is, or what a compiler is. When I’m using these tools, I’m not sure how someone without basic developer experience would manage. That said, this has developed and improved surprisingly quickly, and the big labs are racing toward recursive improvement. When they get there, we’ll see a lot of improvement very fast.
Good Enough Wins: The Compiler Argument and the Cost of Perfection
Daniel: Did you see the Ralph Wiggum script going around? It’s a loop using Claude Code — create this thing, feed whatever output you get back in, continue doing this until it’s done.
Matt: It sounds like a brute-force way of doing it. But tokens are getting cheaper and cheaper, and if you don’t know anything else, why not brute-force your way into a solution?
Daniel: It might end up being expensive over time, but as you say, costs are falling. And expensive compared to what? It’s probably not going to be as expensive as hiring a developer. We’re seeing that with layoffs and difficulty getting junior programming jobs. How do we end up with senior programmers in ten years if we’re cutting off the pipeline now?
Matt: That is a problem — we’re really killing our pipeline. At E84 we’re primarily a senior organisation; if you’re hiring a services firm for software development, you’re hiring for their expertise, not for junior engineers you could have hired yourself. So we don’t hire them, and I think others are moving the same way. Ten years from now there’ll probably be a cycle where we see a dearth of experienced developers and a call to send people back to school, whatever that job of the future ends up being called.
Daniel: We can look at history for perspective. In the 1950s there was a priesthood of assembly programmers — Kathleen Booth wrote the first assembly language. When compilers came along, they had all the same arguments we’re hearing today: “The compiler is untrustworthy. I can beat it by hand. My assembly will be faster.” And they were technically right about efficiency, but wrong about the future.
Matt: Exactly. The compiler was good enough to allow us to move up the stack, take on more complex things, write code that could be ported and deployed everywhere. We’re seeing the same thing now. This is going to allow us to move further up the stack, write more software, be more productive, and take on increasingly complex problems.
Daniel: I think you hit the nail on the head with “good enough.” A lot of people arguing that AI will never do their job are arguing for perfection. But in most use cases we don’t need perfection. If it comes down to cost — perfection for X versus good enough for significantly less — good enough wins.
Starting the Conversation: Why Not Talking About This Is the Only Mistake
Daniel: Matt, this has been fascinating. I appreciate you coming along and starting the conversation. You don’t have a crystal ball and can’t see the future, but your insights — grounded in thirty years of experience — are exactly what this discussion needs. I want to say: despite coming on my podcast and talking about documentation and standards, you are welcome back any time.
Matt: Thank you, Daniel. Standards — I always thought they were pretty boring. How did I end up here? I used to do algorithm development and remote sensing, and then somehow got into standards. Never thought I’d do that, but it’s so important and it’s needed to do the cool stuff. That’s how I ended up there.
Daniel: The only mistake we could make right now, to be perfectly honest, is not talking about it — sticking our heads in the sand and pretending it’s not happening. This topic tends to be very polarising: on one side people saying throw your keyboards away and just talk to your computer; on the other, people saying this is just fancy autocomplete and it’ll never take our jobs. Neither extreme is ultimately helpful. I’d rather be quietly learning how this stuff works, seeing where it benefits me, where it falls over, what I can replace — and just moving forward. Thank you very much, Matt. I’ll put links in the show notes to your FOSS4G presentation and the blog posts you have coming out. You’re welcome back any time you have something interesting to say.
Matt: Thanks again, Daniel. It’s been a great conversation and I really enjoyed talking about this at FOSS4G. I don’t claim to know what’s going to happen, but it’s an interesting ride.
