When I'm encountering some WoT like that, I'd like to have a button like "view source", but for "view prompt".
Most ai generated messages or docs are unnecessarily verbose and just reading the prompt would suffice. I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text.
It just wastes my time. And probably only makes it look like it took more effort than it actually did (it may be the exact opposite).
> I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text.
Simple: It looks like you did more work.
Before everyone had ChatGPT, a long document meant that someone sat at their computer and invested more effort than someone rattling off a list of partially formed bullet points. In the process of writing the doc they usually refined the idea.
Now anyone can dump the bullet points into ChatGPT and get and expand them into a document which gives the illusion of being well thought out. They can now occupy the same space as everyone who was doing a lot of work in the past, but without having to do the work.
That's only going to work until people start absorb the fact that you can now generate unlimited amounts of grammatical text for free. Shouldn't be long now.
Next, the recipient of the wall-of-text throws it into another LLM to "summarize" it to bullet-points, adding another hop of the game of telephone as it mutates what was already a fake artifact of thinking that was never done. *sigh*
I very much dislike this behavior, personally dont do this and want it stopped.
people that I like to be nice to have done this to me. I dont have a good response that wont trigger them.
They chose to do this cz its easy. I now have to choose : read that garbage and make sense and ask questions or reject it asking for your opinions not claude's.
Former leads to more walls of text. Latter makes me come across as not-nice and get broad stroke painted as an AI hater (which I'm not). Not many where I work will voice any of their discontent about anything AI. Its the hotness.
The irony of that article having an AI smell is not lost on me
> ...probably only makes it look like it took more effort than it actually did
I think you've hit on why people would do this in a work environment. It's a low-effort way of looking like they're engaged at work and know what they're talking about.
> I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text
Probably people who have never wanted to put the required thinking effort in a simple, structured response to a question, and now think that "a lot of words" magically solves that skill issue.
While Blaise Pascal, he of triangle and foundations of evil, may have indeed written something like that--though probably in 1600s French--it is almost certain that he did have the time. he just so not want to use it to edit his letter to be shorter.
The question before is now is now is whether the letter contains any quotable quotes that have survived 400 years other than his critique of style.
Wheel of Time is still some of the finest fantasy you will ever read. I'm personally tired of the digs at the last few books that Robert Jordan wrote before passing the baton to Brandon Sanderson.
Wide open Throttle. Aka puttin the pedal to the metal, or twisting the throttle to the max on a bike, or pressing the lever as far is it will go on a jetski/quad.
I wish the copy button for a response included the prompt (unless it's code). So many times I'm reading a response that starts running assuming the context of the prompt and I'm left wondering what it's about for the first half.
In that case I still want to see exactly this prompt. Then I know that the person didn't even think about my question thoug I asked _them_ for their opinion and I could have asked ChatGPT myself (and already probably have).
There is something about the asymmetry of effort that is particularly galling. If a person couldn't be bothered to write something, then I can't be bothered to read it.
If someone contributes a software component, they are responsible for it whether they developed it properly or slop coded. The difference is that I will refuse to look at the slop, much less debug it or help with troubleshooting.
People who blindly copy paste from agents are completely replaceable, and should be at the top of the list when layoff season hits. They drag the whole org down.
Zig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with.
Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident.
In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.
Most of my vibe coding is in zig, and it has been my experience that Claude and Codex both keep up with zig changes just fine. Every now and then I catch them writing outdated code that they burn some tokens on, but my experience says your local codebases’s idioms will influence what gets generated enough to stop this from being a problem.
I am building an S3 client [1] where I have a test matrix that tests against common S3 implementations, including RustFS.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
I am writing an s3 server, just checked, have detailed tests for content-length-range. I found that Ceph was the only open source implementation with decent tests, and I ported these as my first stages of implementation, although I have since added a lot more. Notionally rustfs say they use the ceph test suite, but not sure how often and completely, they certainly had big conformance gaps.
What matters for LLMs is what matters for humans, which usually means DX. Most Microservice setups are extremely hard to debug across service boundaries, so I think in the future, we'll see more architectural decisions that make sense for LLMs to work with. Which will probably mean modular monoliths or something like that.
Aren't libraries just "services" without some transport layer / gateway?
You should only ever have a separate "service" if there's a concrete reason to. You should never have a "service" to make things simpler (it inherently does not).
Libraries on the other hand are much more subjective.
But debugging mutable state is much easier than debugging a distributed system. Even in C if some global gets mishandled I can just use: gdb, dtrace, strace or even just look at a core dump and know that whatever caused the problem will be discoverable. I have no such guarantee debugging an issue across a distributed systems service boundary.
> It's really not. A service adds complexity. If you have no reason to add it besides to "reduce complexity" - that is an oxymoron.
No, it really is. I can just as easily say that a system is simpler when it's composite parts are isolated, or that a system is simpler if I can take one component and reason about it in isolation, etc.
Similarly, I could say that libraries add or reduce complexity by making similar appeals like "a single unit of code is simpler" or "separate, smaller units are simpler" etc.
> No, it really is. I can just as easily say that a system is simpler when it's composite parts are isolated
No, a system can not be simpler because you moved A' to B and introduced C (complexity - an added network, gateway, communication layer) for no reason besides to make the entire system simpler.
It is not simpler! You did nothing besides introduce C (complexity)!
> the only viable use cases were compute-heavy workloads like codecs and crypto,
I tried using it for crypto, but WASM does not have instructions for crypto. So it basically falls back to be non-hw-accelerated.
Tried to find out why and the explanation seems to be that it's not needed because JS has a `crypto` API which uses hw intrinsics.
Bun added `trustedDependencies` [1] to package.json and only executes postInstall scripts coming from these dependencies. I think this is something that should be supported across all JS package managers, even more than version cooldowns.
How can you know that a dependency you trust won't be hacked? At best it slightly reduces the risk, but it's not even close to the effectiveness of version cooldowns that just block 100% of fresh updates.
Compiling native extensions that link against libraries that can’t be included in the package for license reasons. That’s probably the one reason that simply can’t be removed.
So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell?
Would probably be hard to guess since the process may not have opened any file once it started.
I've used (see: example) to handle applications that just dump pointless noise into stdout/stderr, which is only useful when the binary crashes/fails. Provided the error is marked by a non-zero return code, this will then correctly display the stdout/stderr (provided there is <64KiB of it).
Most ai generated messages or docs are unnecessarily verbose and just reading the prompt would suffice. I don't really get why some people seem to think that it's somehow better to have their bullet point prompt as a huge text.
It just wastes my time. And probably only makes it look like it took more effort than it actually did (it may be the exact opposite).