The EO community probably does not need your weekend package
Spectral Reflectance
SubscribeSign in
Developer's Orbit<br>The EO community probably does not need your weekend package<br>Weekendware, zero forks, and the open-source stack underneath.
Akis Karagiannis<br>May 25, 2026
Share
The weekendware Monday. Image generated with AI.<br>Every Monday, or at least it feels like every Monday, I open LinkedIn and see another post announcing a new Earth Observation tool, Python package, dashboard, wrapper, or “AI-powered workflow”. Maybe it is not always Monday, but in my head it has become a very specific kind of Monday post: the README is clean, the name is neat, there are a few screenshots, maybe a demo notebook or a small Streamlit app, and the whole thing has that familiar “I built this over the weekend” energy.<br>Very Garfield of me, I know, but I have started to hate those Mondays.<br>Not because people are experimenting. Most of us learned by building small, messy things that nobody else used, and I still think that is one of the best ways to learn. You try something, you break it, you misunderstand the library, you go back to the documentation, you fix one thing and accidentally break another, and somewhere in that loop you start to understand what you are doing. I also do not have a problem with people using LLMs. I use them too. A lot. They are useful, they save time, and they can make several steps of a project much less painful.<br>What bothers me is what often happens after the experiment. A learning exercise gets a name, the name gets a logo, the logo gets a GitHub repository, the repository gets a package structure, the package gets a launch post, and before anyone has really asked whether this thing should exist as a tool, it is being presented as one.<br>A GitHub portfolio does not mean what it used to
The old advice about building a GitHub portfolio probably needs updating. For years, graduates and early-career developers were told to build public projects because it would help them stand out, and for a long time that advice made sense. A small GitHub project usually showed that someone had spent time with the problem, even if it said very little about whether they were a brilliant engineer. They had written code, fought with dependencies, read documentation, tried to understand an API, and pushed a small idea far enough that it ran on their machine. It also gave them something concrete to talk about in an interview: what they tried, where they got stuck, what they changed, and what they understood by the end.<br>With Claude Code, Codex, Copilot, ChatGPT, or any similar tool, a weekend can now produce something that looks like a finished project before the person has really worked through how it should be built. Examples, tests, documentation, a demo app, and even a confident explanation of what the project is for can appear very quickly, giving the repo the shape of something more mature than it really is. From the outside, it becomes harder to tell whether someone understands the code, or whether they managed to prompt their way to something that runs.<br>Someone can still learn a lot by building with an LLM, especially if they read the code, change it, test it properly, and understand the trade-offs. The repo, though, is only the visible part. What I would want to know is whether the person can explain what they built: what the model generated, what they changed, why they chose those dependencies, what breaks when the input data changes, which assumptions they made, and why this should be a new package rather than a pull request, a tutorial, or a small example added to an existing project.<br>Using the tool without skipping the science
Oddly enough, this makes me think of Star Trek. The characters had access to absurdly advanced tools. They could ask the computer things, run simulations, scan atmospheres, translate languages, diagnose systems, and get answers that hid a lot of work behind the interface. But Spock still knew the science, and Scotty still understood the engineering. The tools made parts of the work easier, but they did not remove the need to understand the work itself.<br>That is how I want coding with LLMs to feel, useful and fast and sometimes surprisingly helpful, but never a shortcut around understanding what we are building. If that happens, we are not really becoming more capable; we are mostly getting better at making unfinished work look finished.<br>A nice RGB composite, a green NDVI layer, a few polygons on a basemap, a simple dashboard, a STAC search box, a cloud-free-looking image — in EO, all of this can make a method look like it works before anyone has looked too closely. How is nodata handled? Which CRS assumptions are baked into the workflow? What happens with mixed resolutions? How are clouds and shadows masked? What resampling method is used? Are sensor differences being ignored? Is the metadata complete? Does the method work outside the one AOI used in the demo? Can it scale beyond a...