saint-evan

yes, that makes sense. Thank yu so much!

Well... yeah but at the cost of halting your entire program? As opposed to logging?

I don't get it... What's the problem? I too prefer getting None as opposed to a key Error which would prolly necessitate a try..catch as opposed just checking for None. I'm having trouble reasoning up a situation where raising a keyError would make any sense over a None for data structures like dicts that could return a value or no value! Help?

Being a student myself, I really have no opinion on LLM-use in academia, for studying or creative authorship. I believe we're all still figuring it out and there isn't enough data yet. BUT I think the parallel with programming, and specifically the comparison between compiler-use and LLM-use is just that... parallel (two line that never meet).

It's been said repeatedly and at the risk of sounding like a broken record: the compiler is a deterministic tool and LLMs are not. And they most likely won't ever be deterministic for certain things sometimes so deeply subjective such as programming, where even different humans could come up with varying solutions to the same problem.

BECAUSE the compiler is so painfully deterministic, yu can be hands-off, knowing that some of the smartest people in the world continue to dedicate a dizzying amount of focus and brain-power to making sure that given x, the output is always z (it's obviously more complex but yu get the idea). I'd say that while determining the correctness of a compiler requires specialised knowledge, it is less mentally taxing to trust BECAUSE it is deterministic. And so, theoretically, yu can dig in directly and see that given these combinations of inputs, the compiler always produces that output... Again, whether the output is right or not is specialised knowledge and can usually be mathematically be verified.

This is very different from LLM-assisted programming which is a subjective endeavour that has now separated code-generation from intention where previously the act of actually writing the code embedded the author's intent by virtue of the author having to decide every single character that survives. This is why documentation feels boring because it feels like writing the code twice (depending on your disposition as a programmer anyway).

If I directed a team and they use LLMs, I'd want them to personally carry responsibility for their LLM-generated code to the extent that they've exhaustively verified that the code itself carries their intent, rather than just that the output matches what was expected. This would be an absurd thing to do with a compiler (i.e. verifying the generated assembly code), and I strongly believe that the difference is in the determinism of the generative process. If every generative run is unique, then every generated output must be very carefully verified EACH TIME to the extent which the human begins to naturally feel personally responsible for the code itself not just the final result.

And the idea that

> Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it.

is something I completely agree with, but c'mon, let's be honest... that's the same old documentation practice all over again. Amusingly, LLM-assisted coding is now making traditional programming practices even more important to adhere to. Anyway, it's always been easier to read the documentation than the code itself (for me atleast, I'd like to generally understand the general idea before I go eat granite).

I guess I'm disagree-ing with the article where it seems to say 'peeling of the sticker and calling it homemade' is the wrong thing to do with LLM-assisted programming because we don't do that with compilers (i.e. claiming authorship over the generated asm). I think that comparison shifts us dangerously into being purely result-focused, like we are with compilers.. where we only care about the results of the computation and our high-level input, and ignore the outputted ASM except in very special cases.

I posit that the indeterminism of LLM-generated code requires us to care very very deeply about the output of the model. A reliable signal of that care is when a human has painstakingly seen to it that the output aligns with their intention, to the point where they claim direct ownership of not just the results of computation, but the generated code itself. I think we should encourage that instinct especially if yu want to hold a programmer accountable for their failing code and expect them to feel personally responsible for it, rather than pointing back at the model. I believe this is what Indradhanush Gupta may be gesturing at.

Afterall, what is slop? Didn't read the code, only interested in the results of computation.

no biggie... I just like how 'yu' looks. It's an aesthetic.

That's a fun idea but take python (very familiar)... It's very deeply dynamic and even if yu run imports at the top of your code yu still have many large libs with lazy code execution baked deep inside their internal functions so that assumes yu actually know what code paths the application will hit later. More importantly this goes in the opposite direction of Python's lazy imports thingy.. basically you've got a bomb and yu wouldn't wanna do that. Also, imagine the startup time for large apps. I'd just put a statically-linked binary in front and proxy back to the dynamically-linked process if I can't rewrite the main app in something like Go or Rust.

Failfs is a pretty cool pseudo-filesystem where every path lookup fails. So if yu place a statically-linked process into failfs with ONLY pre-allocated file-descriptors at process birth, close down unneeded sockets and enforce a default-deny firewall discipline, compromised applications are effectively isolated and unable to access local files or spawn shells during an exploit. An attacker can NOT move adjacently from the exploited process to other parts of the system because to do so they'll need to navigate from root and that would fail since yu set root as failfs and you've got yourself a pure, isolated data-processing pipe that can only interact via the exact file descriptors it was given!!

Unfortunately, yu can't use dynamically-linked apps anyway since failfs would break absolute path resolution loading system libraries.

EDIT:: But I guess yu could put a statically linked app on the socket, wrap it in failfs and gave it proxy requests to a dynamically-linked app process if your app must use something like python.

haha.. Couldn't have worded it any better. I was excited too.

unwittingly said 'yaaay' when I saw the Sonnet 5.5 entry. lol I love Sonnet so much. Loved it since 3.5 and never really liked Opus even when I tried to use it for technical work. Once we had two back to back anthropic releases neither of which was a Sonnet upgrade from 4.5 (4.6?) and I was getting kinda sad that they're considering discontinuing it. These are weird reactions I'm having to these tools even when I mostly use them for technical work considering I prefer talking to GPT and Gemini is just a blunt, very powerful hammer.

Machines eliminate drudgery, freeing up time for better, more important things and doing things efficiently creates abundance. Simplicity is romanticised, I'd like to let things that can do themselves go do themselves allowing me more time for the fun parts. That's not to say 'turn off your brain' but backbreaking and mind numbing work isn't fun or noble. Whoever's doing it would rather not do it or has the option to NOT do it but chooses to. Those aren't the same thing.

Hate the fact that when someone dreams up an article such as this [nasty word] where the central premise is that, '[SW engineering constraint] is no longer an issue anymore'... it's always because the solution is to turn off your brain and ask the LLM. It's almost similar to, 'because computers have gotten faster and memory's cheaper, we can write [nasty word] software' but this time it's, 'proper code architecture don't matter anyway because ain't gonna read it'. Jesus! I am very certain, without evidence, that even LLMs have an upper bound for the shittiest, most warped code even they can understand and explain. How sad is it that we're going from 'this engineering constraint has been solved' to 'that's [LLM provider]'s problem'. There is a finite amount of context, a finite amount of signal that can be extracted from that context, and a finite amount of inferential reliability. Give the freaking chatbot a bizzare enough monstrosity and eventually the model's explanation becomes an increasingly plausible reconstruction rather than a reliable model of the program. This is the goddamned wall these damned idiots are about to run into... Taking on debt, pushing architecture in the OPPOSITE direction of human understanding AND banking on a neutral-at-best external entity to keep doing YOUR job for (essentially) free! And what's crazy is that I'm the absolute furthest thing from an Ai-hater AND I'm a 23yo JUNIOR PROGRAMMER but these sentiments are getting ridiculous asf on both ends of the AI preference spectrum.

sometimes, I really do wonder if 'slop' slingers like yourself are just rage baiting. Are yu rage baiting? Or this is just an excuse for not being able to read without pictures?

We got RISC-V support before an official 3.14t docker image.

Oh shut it *eyeroll

Not to be critical but I clicked thru to another article, 'Ai makes sitting with discomfort shameful' and I still don't get it. I don't understand the need to cry about a completely optional tech. Especially when, if yu love it so much and are forced to use it at work, yu can just ionno use it whenever else you have more control over your own agency? Coding and learning is hard but now they both got easier. What's all the romanticising the grit around programming when yu can very optional still go eat granite of that's what you're into. Really, it's beginning to feel like, 'turn on your camera with tears in your eyes and talk about how you're crying' No offence truly but crying over 'optional' is weird