Hacker Newsnew | past | comments | ask | show | jobs | submit | analog_daddy's commentslogin

Yes, it is not optimized for reading.

What many devs have pointed out in personal conversations is: The cost of maintenance is no longer just tied to engineer’s salary. just the sheer scale of code, comments and documentation generated by agents is huge for a person to review, which most likely will lead to people having to resort to agents to understand and fix code. Currently, even with subsidies on personal subscriptions, enterprise costs do add up with the token usage.

Atleast when it costs money, self hosting is considered seriously for large orgs


I think I have some tendencies to do so as well. More specifically, I have the itch to just spend some time, knowing or understanding the tools I use better. It Has paid dividends for me, since the tools we typically use for $work are super buggy yet powerful and like any good proprietary tool, abstracted behind an obscure shitty API. Experimenting with crazy things just allows me to run into bugs early on when, I have the patience to solve them.

But, it’s the first time in my short career, i have shied away from being on bleeding edge of tooling. Specifically, LLM tooling. Firstly, since LLM’s are not yet needed or good in my field of $work, but; even in my programming hobby, whenever I venture out to explore, it all feels too snake oil to me. And do I even need to begin why the f*k people curl | bash??

I dunno maybe its just old habits, but I can’t bring myself to download a skill or whatever without going through its contents.

And then it just is too much to keep up.

For instance, for a period of time, everyone on hn were glazing claude and then after having a great UI experience on their ios app, i got a simple one month subscription, but by that time, hn already was making friends with codex and pi. My searches for blog posts written by ‘AI/LLM’ normies using it for reasonable tasks, has been disappointing, and just too polluted with people completely vibing and not reviewing any code. And then you have power users whose entire purpose is to try out new stuff, rather than stay consistent on one toolchain and maybe also share a perspective of if the tool is degrading or not.

Sadly, amongst all the agentic hype, the autocompletion mode seems to have fallen behind which I enjoy a lot more since it allows me to architect things in a particular fashion without bugging myself with nitty gritty details.

Hopefully, as these things start costing more money, things will get streamlined to the point where few camps will emerge similar to how the text editors work. I am looking for an update to ‘what the vim of llm tooling look like’ blog post any day now.


Yes tldr, navi cheatsheets are essentially a great set of how to do X using Y for terminal utilities. Pretty well curated set of commands for majority of the tasks, so are great training material. And great work! Love it

Yep! And it works well on iOS too. Safari sucks and stutters with some of these single file html and I haven’t been able to figure out why, but my god this is awesome and also fun to play with!


Ohh, sadly I relate with this feeling too much.

For all the agentic loops people seem to have come up with, the research loop or as I call it the “Desperate 10th page on Github’s crappy search results” is still not up to the mark.

Either it might be genuine rate limiting these LLM’s face or just that, they are trained to focus on implementing a solution which would be faster and user acceptable solution. (which seems to be a true looking at people pushing LLM generated code as is).

At least in my personal experience with niche projects and heck even with well documented and famous libraries, along with fancy mcp’s, llms.txt and skills; RTFM has been more relevant than usual for code that I have asked an agent to generate, since it is too eager to reimplement functionality which already exists, only if it RTFM!!


I too have the same experience with LLM generated code. I just get burnt out reading it and all the verbosity it has. I eventually gave up reading through it and keep it as a archive of previous work, while handwriting the code. If I get stuck somewhere, I asked the agent to generate a snippet based on my archived code and what i need to achieve and manually copy paste it.

I wish inline completions would have gotten better but it seems no effort is being put into it and it is frozen in time right now. Thankfully, the stuff i use this code for is simple and small scale. I can’t even begin to imagine how actual programmers are feeling about this.


Disclaimer: This is a user’s perspective rather than a programmer’s perspective.

valid point. I am usually okay with LLM generated code since even if it might not be architecturally sound It is usually well commented and has tests and documentation for helping another agent/human debug any issues.

But, just the painful experience of debugging any dlopen related crashes and/or intermittent bugs; and the sheer amount of tokens burnt by an LLM chasing tangents when shown a stack trace; I wouldn’t touch this at least as a packager/consumer of certain apps for personal usage on older distros. So far, AnyLinux-Appimages seem to be a mature solution with great support from the developers, in case anyone lands here for packaging applications to run on older distros.


Modern models, when properly managed with a human in the loop, write higher-quality code than humans and introduce significantly fewer bugs. Therefore, it's quite the opposite - you should expect fewer "dlopen-related crashes and/or intermittent bugs."


> Modern models, when properly managed with a human in the loop, write higher-quality code than humans and introduce significantly fewer bugs.

I don't think anybody believes this, and interjecting it into every thread is not really convincing anyone.


where is the study confirming this?


> So far, AnyLinux-Appimages seem to be a mature solution with great support from the developers, in case anyone lands here for packaging applications to run on older distros.

The Linux ecosystem already settled on containers to solve the problem. Namely Docker, Flatpak, Podman ec.


They require admin privileges. A consumer on an enterprise servers might not have them, which is where I would guess glibc might not be latest one. If you are an admin then sure those solutions can be feasible.


You don't need admin for Flatpak, Podman etc.


https://github.com/pkgforge-dev/Anylinux-AppImages/blob/main...

Wanna see those containers running in those old systems. Good luck getting flatpak to run on a kernel without PR_SET_NO_NEW_PRIVS.


> kernel without PR_SET_NO_NEW_PRIVS

So basically no mainstream distro.


This is awesome!! Another great addition to awsm-wasm!


That used to be the case, and I loved the empty feed. But, i noticed that it started showing me the default feed of all the AI slop people post which linkedin thinks is relevant to my field. The current way that worked for me was to select ‘Chinese - Simplified’ as the language and since I don’t understand it, I am not remotely curious to read the cringe. I now Only see if there is any messages i receive (which aren’t translated). Basically, in and out of the website in 15 seconds if no messages/connect request! Works like a charm for now.


I feel people who like this type of blogs and want to try something like a static website would love Styluslabs’ Write https://www.styluslabs.com/

Handwriting is better as SVG if you are writing digitally, and while everyone has their own vector ink based proprietary formats, I like the simplicity and openness of SVG’s!


SVG is completely unsuitable for recording pen stroke data, and fairly unsuitable as a publishing format for handwriting. It’s capable of representing a technical pen/fineliner with opaque, constant-width stroke tolerably well, but nothing else. For all other pen styles, you need variable stroke width (for which you have to switch to using a filled instead of stroked path, bloating it hugely and making it essentially uneditable), and also want some degree of variable opacity and/or texturing of the stroke (both impossible in SVG).


Yeah i think you have a valid point. I did have this issue come up where i was trying to vectorize an indexed png and no amount of playing with different engines and settings gave me a good enough reduction in size. It was essentially treating my handwritten strokes as variable width.


Very intresting, thank you for sharing!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: