With technology, I’ve learned to just see what happens. There are several dumb ideas, like NodeJS, Python, and the iPad, that I was just completely wrong about. So when I started watching AI code in open-source projects, I hoped for the best.
After all, I grew to love the iPad as a great interface for regular users, for very specialized automation control, and for a million other things. I’ve come to quite like Python with its easy on-ramp for scientists and pathways for optimization once they’ve got their algorithms working. And NodeJS… is a thing people use.
Let’s Be Specific about AI & Coding
One problem with AI coding discussions is the lack of specificity. You hear big, big claims, and often when you dig into the details, they’re kind of meh. Given the amounts of money being thrown around, the claims have to be big.
I’ve been curious to see what this looks like when it intersects my own field. My last interaction with AI was building some figures from hand-drawn sketches. It was bad. Then I tried getting a summary of a radar data format. That was legit funny.
Now I can see how AI tools are interacting with a project I know very well. In particular, I’m seeing what AI code in open-source projects actually looks like in practice. The results are mixed.
MapLibre
MapLibre, if you’re not familiar, is a map display library for web and mobile. It’s descended from the open-source Mapbox library, and it’s a fork of the version before they went closed-source.
We work with the MapLibre project, specifically on its Native implementation for iOS and Android. Amazon has paid us to add features to the Native version for the past several years. This is separate from our weather products.
On the JavaScript side, MapLibreJS is one of the map toolkits we support for weather display with Terrier. So we’re familiar with both the Native and JS sides.
I’ve recently witnessed a good kind of AI contribution and a lot of bad ones.
Useful AI Coding Involves a Developer
The best example I’ve seen is a project that is almost perfect for what AI coding should be able to handle. There’s a new data format called MapLibre Tile Format (MLT). We have an old format, Mapbox Vector Tile (MVT), and can either translate from the old to the new format or encode directly to the new format.
There’s a whole community of projects that use the old file format (MVT), and we’d like them to switch to the new one. There are advantages, of course, but it’s probably worthwhile for those projects, and many are interested.
The first MLT encoder was written in Java. Some projects use Java, so that works well for them. But many projects are written in C or C++ and need a C++ interface.
A contributor built a C++ encoder using one of the GenAI tools, and it works pretty well! From their description, it involved a bit of iteration, some code pruning, and a lot of careful thought.
An encoder like this is a perfect use case for this kind of tool. You’ve got a well-defined format and a reference implementation. If you had the resources, you could assign a junior developer to this and achieve a similar result.
Could the developer have just done this themselves faster? I have no idea. But they did do it, and it seems to work. So that’s great!
Judging by volume, though, most of the AI code coming in by Pull Request is pure junk. On the MapLibreJS side, they’re starting to be hit by these drive-by coding agents. They presumably scan the Issues, analyze the code, and make changes.
In some ways, that’s kind of impressive. Kind of.
Drive-By Contributions
Open-source has always had a problem with drive-by contributions. What’s new is the scale. AI code in open-source projects has turned the occasional misguided contribution into something automated and constant. What you really want and need when running an OS project is real users contributing real changes.
Real users, because you want to know that they added a feature they needed or they fixed a bug they actually ran into. Maybe they didn’t run into the bug, but they’re familiar enough with the toolkit to know what’s important and what’s not. And not break it. That’s key.
I first encountered the drive-by contribution years ago on my own OS project. A new way to read textures was available on iOS. Someone was so excited about it that they contributed code to a bunch of OS projects to use the new way. I never merged it in.
It wasn’t a very useful contribution. Since they weren’t a user, this wasn’t something they expressly needed. Much more seriously, they hadn’t tested it. They also did it in a way that wasn’t exactly congruent with the toolkit’s approach. So I’d have to fix that.
Should I fix a feature that no one asked for that contributes only a minor amount and might make things less stable? No. What a waste of time.
Coding Agent Slop
Now they’ve automated the drive-by contribution. This is where AI code in open-source projects really starts to break down. Volume goes up. Signal does not. There are at least a dozen fairly useless Pull Requests by AI coding agents on MapLibre repos. These take time and effort to analyze, and they likely don’t even solve a useful problem, as they’re too simple.
Having Issues drive them is interesting, but not every Issue is worth addressing. Often, you leave some of them alone because they’re going to be too hard, or pull you in the wrong direction, or they’re just not terribly important. Some are outright bad ideas.
An agent can’t really tell the difference. Nor do its owners really care to.
AI Code in Open-Source Projects
The problems with security bounties have been addressed elsewhere. The Tailwind documentation apocalypse is well discussed, too. I’ve also seen a private AI proposal that was pure copyright theft. Thankfully, that one was turned down, but wow! My fellow engineers have some ethical lapses!
Right now, I’m feeling pretty ‘meh’ about AI coding agents in open-source. Most of what I’m seeing from AI code in open-source projects is noise, with the occasional genuinely useful contribution when a real developer is steering. I see one good contribution, strongly guided by an intelligent developer, and a lot of slop. I suspect we’re going to be seeing a whole lot more slop.