Notices by Christine Lemmer-Webber (cwebber@social.coop), page 2

Here's @ridley and @dthompson talking over OCapN!

RE: https://hachyderm.io/@ridley/116273832190043203

This is WILD! @ridley has been working on an implementation of OCapN, which is the same protocol @spritely uses for communication with Spritely Goblins programs.

AND... AND!!!

@ridley got this working in interoperability with @spritely's Goblins! AND FACT @dthompson and @ridley chatted over Goblin-Chat between Dart and Guile Scheme implementations!

@jfred There's an issue for it now at least! https://codeberg.org/spritely/goblins/issues/949

Yes sometimes other tests seem to fail too, but mostly it's test-unix-domain-socket

All of the failures seem to be due to race conditions with lower level IO stuff, probably Fibers or even lower, afaict

Maddening shit, my least favorite part of working with our stack is not the abstractions of our stack itself but the challenges of the layers beneath it. It's so rare to encounter an actual race condition problem that's due to correct use of Goblins! It's all the Fibers integration and socket setup stuff etc etc...

@agentultra It doesn't happen typically in the abstraction layers we provide, but in the abstraction layers we build on top of...

Okay I guess it's too early to announce what I mean but I am ready to throw a parade and carry @ridley around on a throne this fucking rules #kindavague #itshypetho

@hannah guix gc: freed 48 GiB

you know it's never unsettling at all when you're experiencing an IO bug, and inserting print debugging to understand where it happens, and inserting print debugging makes the IO bug disappear #offtotheraces

Right now I am debugging a unit test failure that is completely fine in all architectures in a dev environment but ONLY inside of a guix build jail on aarch64, it fails

fine

if you absolutely insist I will run "guix gc"

I was hoarding that garbage

@tarsius @stibbons ooooh count me as interested!

@zkat He didn't say nukes explicitly but that is one way to accomplish what he is saying. It's not the only way.

@kaye @cwebber Deploy directly to prod from Microsoft Whiteboard™ using the power of Copilot™AI™

@kaye curse you someone has a startup for this right now don't they

Oh yeah the other caveat about using them for prototyping, as @tamzin highlights below, is that "quickly thrown together prototypes" often become production code, to their authors' dismay.

In many ways, whiteboard prototypes are much better, as they are immune from this problem.

I have to say, this is probably the scariest moment I have ever seen in terms of international politics in my lifetime. I really don't know what's about to happen. I hope Trump is bluffing.

It really doesn't look like he is.

You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.

But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.

The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.

If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.

Hell even Microsoft did it https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/

Can't tell you how many times I have heard about a friend's company needing to send an apology email to customers about downtime and flakiness due to AIgen commits that were poorly reviewed and misunderstood