jlkuester7

> LLMs, and their respective harnesses, are actors in a system. Code is just an output.

This tracks well with my experiences integrating AI into a software dev pipeline. Sure the output of an LLM is not deterministic in the same sense as a compiler (at least when the LLM has the typical configuration). However, that just means the LLM should not be solely responsible for the final product of your pipeline.

Not familiar with the details of Pi Durable, but I have tinkered a bit with different sandboxing strategies for Pi. IMHO it would be hard to trust a sandboxing layer built into a harness that is so focused on being fully pluggable/moddable/self-improvable.

When I am using Pi to write extensions for Pi, I feel better running Pi wrapped in a separate os-level sandbox. I guess Pi could do it all, but I am content with how it is.

This. I happily pay for IntelliJ software (even though basically everything else I use is FLOSS). It is not really this feature or that feature of WebStorm that makes it worth while, but just that 40+ hours of the weeks it just works. For normal stuff, for edge cases, small projects, big repos. When I need something, it just works (with out me needing to fiddle with an agent to build me some brittle scripting that will kinda work today, but break tomorrow....).

All-stack-no-heap

Isn't this kind of the point of Java's Project Valhalla or am I just confused???

Exactly. Even 32b parameter models you can run locally on consumer hardware are "good enough" at this point for some workflows!

I recommend trying pi.dev as your agent harness for local models. In my experience it has been the sweet spot of functionality (which you can and should extend with plugins) vs performance (OpenCode just swamps local models on my hardware).

> if it’s handled only within the Church then the only penalty are things like defrocking or banning from the church

To be clear, things said under the "seal of the confessional" cannot be shared by the priest with anyone else _even within the Catholic Church._ This particular situation is not a matter of the church trying to handle matters internally, but more of a recognition that the penitent is confessing their sins to God and the priest is only acting "in persona Cristi" (and thereby is prevented from pursuing other personal or societal objectives based on information revealed).

> Debuggability is much more important than marginally-better readability, for production code.

I find this take surprising. I guess it depends on how much weight you give to "marginally-better", but IMHO readability is the single most important factor when it comes to writing code in most code-bases. You write code once, it may need to be debugged (by yourself or others) on rare occasions. However anytime anyone needs to understand the code (to update it, debug it, or just make changes in adjacent code) they will have to read it. In a shared code-base your code will be read many more times than it will be updated/debugged.

> Now everyone has to ask what Microsoft, Google, AWS, Red Hat, etc. would do to avoid risking their government contracts or possible consequences for their executives

As long as executive compensation is tied to stock performance, coorperations will only care about their stock price and the kinds of things that will affect it. I do not trust them regardless of who is in the White House. Their alignment of values/incentives is diametrically opposed to mine...

The "issues" described here seem to me to be basically just run-of-the-mill aquisitions considerations. Is anyone out there buying any kind of enterprize-grade hardware in any industry and not doing the due dilligence to consider operating costs over the lifetime of the unit? All technology of sufficient complexity requires a supply chain to be in place to support it. Folks are not just waking up today and realising those F-35s they bought will need to be supported or maintained.

The only thing remotely newsworthy here may be a story around a loss in global confidence in the US "brand", but I think the actual implications of that (if any) still remain to be seen....

> Android is Open Source and therefore does have a full feature-set available free of charge.

This is assuming a pretty narrow definition of "full feature-set". It is a inacurrate to say there is feature parity between an Android phone running Google Play Services vs one that is not.

Building and maintaining a functional marketplace (e.g. through common-sense anti-trust enforcement) is about more than just optimizing for a specific outcome...