{"id":203,"date":"2026-03-04T11:27:58","date_gmt":"2026-03-04T10:27:58","guid":{"rendered":"https:\/\/stefanescu.lu\/?p=203"},"modified":"2026-03-04T11:30:35","modified_gmt":"2026-03-04T10:30:35","slug":"well-on-the-wee","status":"publish","type":"post","link":"https:\/\/stefanescu.lu\/?p=203","title":{"rendered":"Well on the Wee!"},"content":{"rendered":"\n

Introducing my new, early-morning-before-the-kids-wake-up, AI-assisted project: Wee.lu<\/a><\/href><\/strong> (Wee<\/strong> means “path” in Luxembourgish).<\/p>\n\n\n\n

\"The<\/figure>\n\n\n\n

In June 2025, I came across the story of the Zebra30<\/a><\/strong> project. ZUG<\/a><\/strong> (Zentrum fir Urban Gerechtegkeet) had crowdsourced information about dangerous crossings in the city \u2014 and when the city refused to share its own analysis on crossing compliance, ZUG took them to court. After nearly four years of legal proceedings, they won, and turned that hard-won data access into a map letting residents see how they’re affected \u2014 giving them the power to pressure the administration into fixing things. The win mattered on multiple levels: it’s how many people first heard about ZUG (myself included), and it exposed just how far public data access still has to go. It may also have paved the way for broader access, establishing that: “A database that describes ‘a factual situation at a specific moment in time’ is public”<\/em>(see here<\/a><\/strong>).<\/p>\n\n\n\n

Around the same time, I “attended” the SciNoj #1<\/strong><\/a> virtual conference and was struck by Heather Moore-Farley’s session on “The Impact of Lane Reductions”<\/a><\/strong>. She showed how detailed, accurate public data \u2014 specifically, California crash data \u2014 analyzed and visualized with Clojure could help a community drive real change and improve safety. After 23 years of building software professionally, and all the talk about how “software is eating the world,” the belief that software could genuinely change things for the better \u2014 the very idea that had drawn me into this field \u2014 had somehow quietly faded. This talk, and the energy of the conference in general, rekindled that original spark.<\/p>\n\n\n\n

What I felt the Zebra30 map was missing was traffic context: a way to measure the real consequences of current conditions, to show how risky each area truly is. A dangerous crossing in a quiet, remote corner of the city is arguably less urgent than one right next to a known accident hotspot. I wanted to add that layer \u2014 so I started looking for data on the geographical distribution of accidents across Luxembourg.<\/p>\n\n\n\n

Luxembourg has an open data policy (mandated by the Law of 14 September 2018), and several administrations do publish data for open access. Yet I couldn’t find detailed, historically accurate accident location data. There’s simply no public view of where accidents happen across the Grand Duchy.<\/p>\n\n\n\n

And yet… this data does exist. Accidents are traffic events, and traffic events are reported in real time by multiple sources in Luxembourg: acl.lu, cita.lu, rtl.lu\/mobiliteit\/trafic. What’s missing is the memory<\/em> of these events \u2014 specifically, when and where they happened. Someone needs to record that; someone just needs to remember. And memory is everything: LLMs, if nothing else, have made abundantly clear over the past few years just how essential full context is to correctly planning the next step.<\/p>\n\n\n\n

But transforming live, real-time events into context \u2014 assembling that memory \u2014 used to take money, skill, and serious effort. At least, that used to be the case.<\/p>\n\n\n\n

“The Cloud” has spent the last decade driving down the cost and technical barrier to running persistent services and storing large amounts of data. Between GitHub Actions (thousands of free minutes) and Google Cloud Storage (tens of GB for a few cents), cost is no longer a barrier. And complexity? You used to need a machine somewhere, Linux skills, the whole deal. Now most of it is a few clicks or a few lines of YAML.<\/p>\n\n\n\n

The resources are there. The serverless platforms are ready. The storage is waiting. But you still needed to write the code, test it, and know how to handle every layer of a working solution: back-end, front-end, operations, design, security. Even if you were comfortable with some of it, chances are you dreaded the rest \u2014 or simply weren’t good at it.<\/p>\n\n\n\n

Enter Claude Code, Codex, Cursor, and friends. They don’t dread any of it \u2014 if anything, they’re a little too<\/em> eager, sometimes reaching for things they shouldn’t touch. They’re not perfect at everything, but if you don’t rush, don’t try to do it all in one go, and force them to stay within guardrails \u2014 steering them with your real-world experience of what actually works (and what doesn’t), which is now the main missing ingredient \u2014 they’ll help you build all the pieces of a working solution.<\/p>\n\n\n\n

The emphasis has shifted slightly: less about raw energy, skill, and curiosity; more about clear vision, experience with the full software development cycle, and a method adapted to these new tools. Not that the first set no longer matters \u2014 it’s just increasingly offset by what the tools can do. And there’s a useful side effect of carefully managing context and history for your code assistant: you can always pick up right where you left off, whenever you have a spare hour. That’s ideal when your project only gets early mornings.<\/p>\n\n\n\n

Where things stand (early March 2026):<\/strong><\/p>\n\n\n\n