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

Not sure how you're missing it. He's making a distinction between the concept of a Project and a Product. I agree with the distinction and he seems to be saying that the author has the wrong concept of what a product is but to answer your parent comment is saying that there's no difference between a vibe coded thing and a 'real' product so long as there has been some satisfactory transfer of agency and an exchange between user and product creator at any scale. So he's essentially saying that the author may be conflating vibe coded PROJECT (with a vibe coded PRODUCT) and that if so comparing a vibe coded PROJECT with any 'real' (whatever that means) product is an unfair comparison and on the flip side if they're comparing vive coded PRODUCT with a real PRODUCT then they're one and the same thing from the perspective that there was an transfer of agency and utility has been exchanged between user and product creator. I happen to agree with parent comment. It's an airtight argument that it doesn't matter how yu made it. The distinction between vibe coded and 'real' product is fuzzy at best. The real distinction lies between a PROJECT and a PRODUCT.

Thank you.. Good luck, cuh!

Absolutely ABSOLUTELY love the idea and the first thought I had was Virtual Desktops! If that's a correct way to think about it then I can absolutely see myself using each tile (Desktop/Monitor to me) to contain a single thread of work.

I don't use agents at all and I think that building agent/Ai-first is gonna push away people like me (who don't want to deal with agents or any related concept or even git tbh). I'd genuinely say generalise into a Virtual Desktop typer thing.

In your blog, you mentioned that each tile is sorta like a computer (sandbox?) in itself actually containing AND running the work. That's brilliant! Now, if you could make it possible that one single tile could fill the entire screen, like a typical desktop view, on demand. Incase I just want absolute focus on one thing (I'm not always looking across all three monitors) and not be in 'Canvas mode' seeing all my Virtual Desktops.

I could also see myself working across three (or more) tiles where I've got docs in chrome, vs-code open in another and something else (more docs? Terminal? Doesn't matter). Fact is that the infinite canvas literally replaces me having to buy two - three monitors to get the same feel. I could now buy a single large curved one and have infinite monitors.

I had an inkling of this feeling when I saw Omarchy (A tile-based Linux distro from Basecamp / 37signals). What I thought was missing was infinite-ness and a little spatial something? I actually literally thought, what if those tiles didn't squish together like that and the BG were a 2D infinite canvas?

If you pull this off just right and actually focus on getting the desktop version right first (I believe that's where your users are), I believe you may have stumbled onto a different kind of operating system paradigm for a workflow issue we try to solve with even more physical monitors.

I never shut off my PC so I can imagine long lived virtual monitors wayyy off in the canvas ether with all that work still open and waiting until I'm ready for that frame of mind.

I don't have anything to say about the disappearing message except that it's cool as a way to ping or get someone's attention but a dedicated chat box? window? Just a little foldable flourish in the bottom left or right corner so yu can directly 'chat' with someone persistently who's in your space (or you're in theirs) is way more healthy for a serendipity than a disappearing message where it's kinda like an implicit race condition and loses the asynchronous nature of letting me consider a text before I reply especially in work settings. I'd also not want to give access to my entire canvas ether as opposed to selectively allowing access to specific virtual desktop lol

As for 3D? Meh I don't know. Don't need that but other people may like it. I'm just approaching this from a workflow angle. Love the whimsy regardless.

I absolutely want this, I would absolutely pay for this, I think this is a great product in the Figma range and I absolutely wish you all the best of luck because this is awesome. Just focus on the operating system /workflow angle for a desktop use-case first. I couldn't try it (don't have a Mac) but I got the idea from the video.

Good luck, guys! And ykw? I wonder if I could fork around with Omarchy and give it infinite canvas since it's already 95% there. Never mind the social feature or 3D graphics yet.

I kno you're not suggesting the visual system would drive coding at all or that it'd be a way to visually code (see: scratch). You seem to mean it as a visualization of the current code base. I'm hoping Google's code wiki is the first step in this direction. One thing I always thought was a problem with visual systems like this was understanding the codebase's architectural design at a level yu can't programmatically get out via a syntax tree analysis. Google's code wiki seems to be using an LLM to figure out the high-level structure of the code and then building the flowchart and diagrams from that understanding. Obviously there's gonna be issues and misunderstanding but I think that's the first step in the direction you're talking about. First it's text, mermaid diagrams and 2d. Next it's a 3d visual world of your codebase. AWESOME stuff. Someone @ Google.

No, it's called not throwing more shit at an already shitty wall just to add feature x_2.

Thank you soo much!

Looove your kitten... How could I make one? I'm basically asking permission before I go raid your elements (inspect site)

yaaay... More fuzzy 'me vs them'-ism.

I see your angle now. Thanks for the conversation!

Yeah you're right. It's an oversimplification to say components in physical engineering domains have no memory. I was thinking about how logic gates are reasoned about. But that's not the exact point... It's that the argument is usually that OOP cannot decrease coupling. I can't see how exactly. OOP seems to strike a balance between good enough modularity and expressive power enough to keep your system directionally loosely coupled. Infact, I'd say that, I my experience, lots of the coupling between modules is inherent to the 'specifics' of the system's design requirements itself. This is where sometimes within the same logical subsystem/component you could find multiple design patterns all deployed in the bid to reduce coupling. I don't think this is OOP's fault directly as opposed to the 'devil that is in the details'. But maybe I don't have enough experience or exposure yet (I'm a 2nd-year junior)

'in->func()->out' work cleanly for physical engineering domains because blocks of computations (or functions) have no memory basically. There's no DB and there's usually no global state in the way you'd mean with classes. I've observed that when you work on complex software, you could play by the ear to enforce 'high cohesion and loose coupling' up to the point to where you've now got a data store holding system state. Based on what I've worked on, this system state is actually user data and then some derivative of the system's own interaction on this user data, both of which are necessary for the 'continuity of system runtime'. For example, working with redis as the primary data store, I extracted different types of redis calls for specific keys, (like set [specific_key], get [specific key], etc.) into functions, then I put these functions into a StateStore class so I can simply call StateStore.get_user_data() or StateStore.set_user_data() etc from any module across the entire system. From first principles, this is great modularity and high cohesion but it's very tight coupling around a single module i.e. StateStore. Any change in that module means I'd have to find all references for that updated function and cross check for any contract violations. It's difficult for me to see how software can purely be 'High Cohesion and Loose Coupling' regardless of paradigm or architectural pattern. There's always gonna be an unavoidable and inevitable principle violation that's simple a result of a large complex system actually doing many little things that come together to actually do one big thing. The software itself, no matter how complex, IS the blackbox where data goes in and something comes out but that's the user perspective not ours as the programmer. I think the idea I'm trying to hint at is that software cannot have every module independent of every other one. That's impossible. If nothing depended on anything else, the system wouldn't do anything. Rather than have every module know redis keys, States tore actually concentrates coupling into one place, which is exactly what high cohesion tries to accomplish. I think that's the idea I'm chasing.

Yes! That's exactly true. I have a very real experience on this. I got introduced to Anthropic's family of models with Claude3.5. I fell in love with the specific personality of Sonnet, the model. I can't remember if back then Opus wasn't public yet but I remember very clearly trying out Opus several times when it became touted as best-in-class and actually recoiling from the foreign feel of the Opus model. I remember very well that my problem was that it was way too eager and pretty hard to steer. I returned to Sonnet and I've used ONLY Sonnet ever since. I have/had access to Fable and Opus4.8 but I never once tried them. In the early days with Sonnet3/4.5, I bought ChatGPT, I also remember thinking that it was a great teacher but a lazy coder. You'd get the scaffolding and then '# rest of code block' not full implementation so unless you wanted to learn the concept, weigh trade-offs, ask clarifying questions or jump into a rabbit hole... You had to go code it yourself. ChatGPT generally as a model is a very good teacher so much so that the free version is enough and I use the free in combination with the most advanced Sonnet model for actual SWE day to day. And whenever there's an Opus release I'm actually very excited because it means there's a smarter Sonnet model OTW. I'll actually be veryyy very sad if the Sonnet line gets sunset. There has been no Sonnet upgrades since even as other family lines get improved.

Do note that I only use LLMs in the ChatUI, I never use agents. I don't believe having a blackbox codebase managed by entities with a half-life of 'delete conversation' or 200k tokens is a responsible idea. In ChatUI, I lay the ground rules, kill assumptions about our working relationship, give it foundational context on the problem and codebase we're working on, explain the problem and then we have a conversation about it and I gradually disclose more logically context as it becomes relevant. So, to directly answer your question, maybe I'm missing out on a ton of upside by not using the absolute best but I'd say familiarizing yourself with a specific model has all the benefits of having a human friend you've grown up with... except your buddy's a savant and would absolutely love to help!

*siiiighhh... Slop automation. Removing self from loop, automating brainstorming. It's madness. No way that code is any good, shippable beyond 2 users or even maintainable beyond auto-slapping on more slop. Sad.

This is really interesting 'vibe research'. I also really like the term as well, it points to how much more easy exploration has become with these tools. Anyway, this idea of context sculpting is something I’ve been circling for a while too, especially since the edit button appeared in chat UIs. The takeaway is similar to yours but leans closer to something like user-side auto-compaction.

What tends to happen is that I’ll reach a junction with Claude where I’m reading its output and starting to manually make changes yeah?. The output is usually already very good, close enough to what I want that it's way more efficient for both of us if I just carry it the rest of the way myself. Or I 'ruin' the clean flow by veering off into questions, clarifications, or broader changes. After a while of this back-and-forth review process, after definitely attaining an 'improvement checkpoint', I scroll back up to what I think of as a 'conversational context checkpoint' and then summarise all the changes we’ve converged on as succinctly as possible including the 'why' (verrry important to always tell them the why). I edit that checkpoint message, and that becomes a new branch of the conversation starting from there. All the noise, all the intermediate negotiation, disappears, and what remains is a compressed version of only what I want the model to carry forward.

Sometimes, if the changes are too extensive to easily summarise, I go even further back, one message above where Claude started generating files. I edit that instead, rebuild the context with only what matters, and then present the corrected output as if I authored it myself sometimes even saying something like, 'So Claude I tries to implement this myself, what do you think? Does it match what we agreed on? Do you disagree with anything or have questions or see issues?'. It works surprisingly well up to even catching new subtler problems in that improved code. It’s very close to your idea of context sculpting, just executed through manual, human-intuited branching rather than model-side compaction.

The interesting constraint I want to point out is judgement. The model doesn’t really have it in the human sense. Knowing what is important is exactly the hard part. Prompting it into the right shape figuring that out for itself is almost like an art form, whereas for the human there’s already an intuitive sense of... salience? running underneath everything. That's the sauce really. You, the human, are the most efficient and effective OUTER_MODEL

Another difference is structural. In this workflow, you are effectively editing your own message and then forking the conversation from that point downwards. It behaves more like a git branch than a linear chat.

I’ve never fully bought into agents either, at least not in the sense of something that meaningfully replaces the human in the loop. I don't want to either 'cause what then? Even if agents work, the question becomes who maintains the code, who understands it deeply enough to extend it without decay. So even this manual technique still depends on full human involvement. Each prompt is modular, structured, information dense, and intentionally non-open-ended. That non-open-endedness is like avoiding a circular dependency where groups of related contexts are littered all over and yu can't pick a proper checkpoint for the chunk of work you're currently doing. This again assumes you're solving problems in logical bite-sizes anyway.

But I consider prompting as less like conversation and more like maintaining modular, versioned intent. It should feel like a sciency discipline rather than purely improvisation Al. Steer it, don't let it steer and never append either; wipe the slate with an edit or new conversation but an edit keeps more of the nuances of that specific model instance. It's very interesting research you've done here. Well done to yu and codex!

EDIT: typo!

I think I come at this from a very different angle. I grew up around books, so I default pretty hard to being reader-first. I don’t really factor in the author’s effort when I decide if something was worth reading. It’s almost entirely about whether the work holds my attention and/or gives me something.

So the idea of feeling tricked based on how much effort went into it feels foreign to me. If I got something out of it, that's enough. Even if it took the author and a model no time at all.

The ‘feeling tricked’ part, to me, suggests a kind of adversarial framing with AI outputs that I think is curious. I’m just engaging with the text in front of me, whether it’s a story, a README, or a wall of technical writing. If it communicates clearly and has substance, I don’t think much about where it came from. I think much of this just comes down to what people think they’re engaging with when they read, the work itself or the mind behind it.

And tbh, filtering what’s worth the attention has always been on the reader. There’s plenty of human written slop too. I tend to judge everything the same way on my way to deciding whether to keep reading or drop it.