Andrea Giammarchi's Standup
Archive

14th of May, 2026

Hello there, “long time no see”, I know, which is why today I’ve decided to take some time to follow up on my most recent errands.

For a change, not everything I’m writing about is work-related. This time I’d also like to share some thoughts around AI, not because it’s kinda mandatory to talk about AI these days, but simply because I’ve been using AI for months and I think it’s worth sharing my current take on it.

This post is therefore split into two major areas: my latest work and OSS updates, and some personal thoughts about AI.

My latest projects and work

  • PyScript - I am not sure anyone is following me there, but I am mostly working on an improved PyEditor. These days we’re trying to bring it internally and I cannot share much more, but while making it, I’ve realized so many obvious things were missing, including:
    • the ability to run arbitrary Python code right before a click on the Run button happens, now possible thanks to the onbeforerun pseudo attribute, which can contain any one-liner Python code that will execute before the rest. No line numbers affected in your code!
    • the ability to show the code ASAP, instead of waiting for the setup node to be initialized. This improves the user experience by far because people won’t stare at a blank spot on the page if the runtime, and its dependencies, take seconds to install … you see instantly what you get!
      • this point made me realize the console.warn around deadlocks that shows in devtools is misleading in this case because it’s expected for click to effective code execution to take more than a few seconds. I am trying to decide whether I should relax the logic behind that warning or tell people “heh, something is taking a long time to run, be patient, please!”, which might be OK too
    • the ability to target not just the terminal but the whole output node, also something that wasn’t possible before
    • the ability to define the maximum amount of rows shown per editor: that is not just a resizable textarea, as textareas cannot really be styled in a cross-browser way that works reliably (or maybe they can, but it requires a huge refactoring of the whole component). It makes no sense for it to take all the space it can when shown examples might be thousands of lines of code. Use the rows attribute like you would on a textarea and see that applied to the output as the max height of that component/editor.
  • other projects - this is a quick list of things I’ve worked on for various reasons, and most of these things are work-related too, but hopefully I don’t need to go deep into details:
    • Shadow Observer - makes any element, within any framework or library, observable even within closed ShadowDOM resources. It’s essential for both polyfills and libraries that would like to handle any node they need, control, or create, with ease
    • QSA Observer - updated to use Shadow Observer so that now you can observe any DOM node through CSS selectors, not just id or tag type
      • element-notifier now passes shadow option to be compatible with Shadow Observer fields
      • the nonchalance project has been updated to reflect the latest/greatest Shadow Observer possibilities
      • elements followed up accordingly … honestly folks, give these primitives a chance, they are AWESOME!
    • utils - a collection of “too small” utilities I always need here or there (used in PyScript too, of course) that is now providing all the most common libraries that might not need their own dedicated space, including:
      • all, which is now utils/all
      • sticky-module, which is now utils/sticky and more detached from that model suffix, as it can be used for anything else too
      • other common enough utilities I always need in PyScript and other PyScript related projects too!
    • @ungap/structured-clone - it had a possible CWE-94 security concern and it got fixed, after deprecating everything before the latest version
    • flatted-view - which had the exact same CWE-94 gotcha, and it got fixed accordingly. This is the ideal successor to structured-clone because it’s faster, better, extensible, and all of that. This is already used in previous Positron and PyScript work, and it will be used as the default encoder and decoder for coincident and/or reflected-ffi/encoder because it’s really another level of binary format and compression that makes me extremely happy.
    • gen-q - basically an efficient and minimalistic event loop implemented out of JavaScript. While this might sound nonsensical, it’s the perfect abstraction/layer to handle streams returned by MCP or any AI related project: you just await a for loop for entries, it delivers!
    • Krueger - this was a 5-minute thing I realized I needed … it basically helps Linux users forget about background tasks (AI, downloads, you name it) when they close their laptop lid:
      • krueger on means the machine cannot sleep anymore
      • krueger off means the machine can sleep again any time it wants/needs to
      • if you don’t get the reference around this silly, yet helpful, AUR only (so far) package name, there you go
    • weakerable - is my latest attempt to fix performance and bloat around the fact that sometimes I really need to iterate over a WeakSet or WeakMap without risking leaking values around. This implementation does literally the bare minimum to achieve that
    • ds4 - I’ve found this project extremely useful but it lacks CORS capabilities, so I couldn’t query my DGX Spark over my intranet and I got “mad”, so I filed a PR to make it possible to pass a --cors flag while starting the server, in order to have the cross-device ability to query that machine via browser, not just via CURL

And that’s a wrap. If you have any comments or questions, please feel free to reach out to me by any means 👋

My opinion around AI

As humble as I can be, whoever has followed me over these 25+ years knows that I am usually “a few years ahead” of the industry:

  • patterns that nobody thought about before
  • libraries that nobody thought about before
  • solutions that nobody thought about before
  • API proposals that nobody thought about before
  • thoughts around tech that nobody thought about before (ok, ok, here I’ve maybe stretched my ego a bit too far … bear with me)

While feeling personally, and I am not saying ahead but surely on top of current trends and tech innovation, I’ve been extremely skeptical about AI “anything” related to my work, especially in the early days:

  • AI didn’t know anything more than I already knew
  • AI made so many mistakes all over the place I wanted to kill it already
  • AI couldn’t invent, solve, or fix anything more complex than a “Hello World”

Time passes, and we’re in a completely different era (and while I know nothing about evolutionary theory, AI is surely, during my lifetime, something that evolved, for once, almost literally at the speed of light … “similar to a virus?” … welp …).

Long story short, I’ve recently reviewed (and re-adapted) my thoughts around AI, at least the AI that matters to me, the one that helps me program, ‘cause I don’t talk to bots or ChatGPT while on the toilet, you know … I am trying to use it for something more noble than that 😅

So here is my list, after months of using it, of things I think have improved my coding, or contribution, practices by far:

  • unknown contributions - everyone is (rightly so) concerned about slop-based contributions that add nothing to the repository, and I’ve been a victim myself here and there of such tragedy. Yet when I needed to contribute to repositories I knew nothing about, AI greatly helped me understand, find my contribution points, and present possible solutions in a way that would have taken “ages” before, simply because I wouldn’t have known where to start … RTFM? That takes time for a simple extra flag/feature/fix I am proposing … so thanks AI there!
  • JSDoc TS - I quickly prototype in JS because I know JS inside out, and I know TS is not always up to speed with the latest APIs, features, updates, or behaviors. In there, instead of requiring a transpiler, thinking about types while prototyping and whatnot (I know you used the any type that time, I am watching you!), I just code, test, validate, code, and once I am happy, I ask AI to write JSDoc TS for me. This way I don’t need TS, I test what I wrote with no other indirection, and I can change files, refresh, and test again without steps in between. I’ve found love again for developing with the PL I love most, caring zero about TS extremists because they’ll get their types, everything will work as they expect, types will be awesome for my future self too, yet the code is JS as it was meant to be (or exactly as I meant to write it) 😎
  • tests - oh gosh this is a huge one! I can put a couple of comments around methods and things and AI will write for me all the tests needed to validate the code it understands and the comments I’ve hinted around … these days I am like “100% code coverage or GTFO” and AI would never complain about me stating that … wonderful!
  • algorithms - 25+ years in the field and still sometimes I forget the basics … a good routine I have is to ask AI: “what do you think can possibly go wrong within this code and its logic/intent?” … it sounds like a “sarcastic” question but it’s never as obvious and pointless as it sounds: on more than one occasion AI showed me cases where my logic could’ve failed. Edge cases? Maybe … Rightful concern? Absolutely! I wouldn’t even care much about the suggested solution (read more about this), but I am glad something less obvious I might have forgotten, or didn’t think about, was shown to me. That surely helps a lot, and it boosts my confidence that I didn’t miss any specific detail around my intents or logic. That’s the best pair programming I could imagine, as I don’t need to spend time introducing the project, its scope, its goals, its tests, how it looks in practice, and so on!
  • documentation - if you don’t use AI to improve your README.md or any other contributing-related page, and you are not using AI to validate that all examples you are showing actually work, all the words make sense, and all the points that should best describe your project are in there, you’re just missing out on market and potential contributors. AI’s best task is to read, summarize, and fix text content … more than code, more than image or video editing, more than audio, it’s just excellent at text and you should abuse it every time you can. I am not gonna lie, I’ll ask AI to fix everything I’ve written right now and never look back: communication is key, and the better, more accurate result is the best we can obtain out of such effort/channel.

There is also a dark side of this chapter though, and I’ll try to formalize my experience around it too:

  • hallucinations - it’s inevitable, especially with code-related tasks, that a “too smart” AI will add, remove, or change arbitrary code that had nothing to do with your original quest. That’s basically the slop AI in OSS everyone is talking about. AI might just decide that a test should be removed because it didn’t like it, that some other code should be changed because it’s trained after bloody linters that would never mind their own business, and so on. It’s our responsibility to read and review literally every single byte AI vomited out, because if we don’t do that, this wave of “everything has more bugs and security issues every day” can only increase, instead of fading away. On top of that, the next AI model will know how to break the previous AI’s conviction that the code was super robust/secure. That’s where we, developers, become even more responsible, not less … watch out, this is mandatory to consider!
  • awful source - this is the sad part I’ve learned on my skin in the last months of random contributions: if the repository documentation is half abandoned, not maintained, full of assumptions nobody around has any clue about, and AI keeps failing at trying to reproduce what your README.md stated, as in “just type make things and things happen” when nothing literally works for anyone new involved in that project, please fix that README.md and verify it like you would with tests and everything else! It’s very hard otherwise, and a waste of everyone’s time for whoever joins that project tomorrow. The sad story here is that I can already imagine a lot of companies thinking “if AI can run it, we’re all good” without understanding that quite possibly AI cannot run it, because you never cared about making that page genuinely useful to anyone. You thought having reasonable docs reachable by everyone was a waste of time, the same way junior developers think having regression tests and code coverage is a waste of time. How about we use this AI era instead to make all these easy-to-fix pain points something everyone can laugh about from the past?
  • wrong answer - no need to stress this much: AI doesn’t know it all (yet?) and we need accountability for proposed changes, even if it’s our own project we’re vibe-coding. Knowing programming languages, or what these represent in terms of intents, is still key. I am afraid whoever believes developers are not needed will smash into that wall sooner rather than later 🤷