Agreed, I wasn't advocating on using LLMs, even "open" or "local" ones.

You can also run a computer at home but you cannot even make a 486 from scratch at home, let alone something released more recently.

I agree on the SaaS side of the story, that's why it is so important to have open models.

Ah well don't despair there are already alternatives e.g. https://www.crowdsupply.com/mnt/reform

OSS/Linux is "our" software. It's made by us for us (or others if you don't contribute).

Your software can be made by you, for you. It can be open source/free software if you want. Others can contribute to it, if you want but it can be open source without accepting external contributions also.

My point was to highlight that having software made by you for your machine is not new. Arguably the way to do so changed but I would say the principle remains.

> Basically, I am prepared to accept that there is a friction that LLMs lubricate away, but what is the source of the friction, and why am I (and a bunch of other colleagues) not feeling that friction daily in our practice?

You must be extremely talented and fast if LLMs make no difference for you.

For people like me though, it's another story: I've been doing this professionally for 25 years and of course, like many, I have been writing custom software for my own use all this time, on personal time. But with LLMs I get better results, faster and with very little effort. And that is the difference between another item in my list of unfinished software that consumed too much of my weekends and a cool utility/toy/useful thing I got after a few fun and interesting chat sessions.

> I find it hard to believe that there is a demographic of people that were yearning to write code, but simply could not because they lacked LLMs.

We didn't lack LLMs, we lacked time and energy.

I still vaguely remember how difficult man pages were to understand when I first started reading them. I'm pretty sure the biggest obstacle is the fact that most documentation is written for people who already know the standard computer science terminology. I have a generally negative opinion of LLMs, but one thing they do very well is function as a "reverse dictionary". You can input a idiosyncratic description of something you want and get the standard terminology. This is a new and valuable capability.

It's a question of time and priorities.

I work 8-10 hours a day and outside those working hours I want to spend time with my family, my friends, and my hobbies.

At the same time, during those 8-10 working hours I don't want to spend time fiddling around with different programming languages or software patterns just to spit out a quirky little tool that would make my job a bit easier.

For example, I wanted a local to-do list software that I could easily integrate with my workflow. Spent some time trying to find one, but not a single one worked the way I wanted. So, one morning, I spent 5 minutes detailing what I wanted, prompted it to Claude and let it rip while I was working. 30 minutes later, it was ready.

> I find it hard to believe that there is a demographic of people that were yearning to write code, but simply could not because they lacked LLMs. Is it the price?

Yes, because the price is measured in time.

With LLM tooling I’ve churned out idiosyncratic tools that fit my use cases quickly. Takes maybe a day instead of a week. A week instead of months. The fast turnaround changes the economics of writing custom tools for myself.

If you are saying that what we had previously was actually as easy as literally writing "make me a web app for arranging seats at a wedding and put it on Vercel" then you are very divorced from reality.

I know how to do all of these things and even find them easy, but it's just much faster now. These are personal one task toy apps, but they are useful.

Not speaking for the OP. But my biggest constraint is time. Now with agentic coding, I can work in 5 to 15 minute bursts a few times/day, and make meaningful progress on projects, where as before I would have never been able to context shift from my day job long enough on a personal project.

Given how often younger people find my typing speed startling, I think it has been somewhat forgotten (US high schools had "keyboarding" classes at one point but that seems to have fallen off...)

Well, I’ve been writing code for decades so I know because there was a time ( when I was younger ) where I did just this.

I also know that these days, for all kinds of reasons, I do not have the time to write the tools I’m writing now without AI. I don’t lack the ability, and I could - it will simply be multi months side projects that I can’t / won’t complete.

I have been writing my own custom software for myself for over 30 years. But in the last six months I have written a lot more of it because the language models make it so much faster and easier to do so.

> I don't know how to tell you this, but people have been writing custom software for personal use for decades. I've been doing it since at least 2009!

GP never claimed otherwise.

As for the rest of your comment, it's frankly a bit patronising: are people too cheap, are people too lazy to read, are people unable to type...?

No, people are busy, a fact which GP made abundantly clear in the very first paragraph.

> I would never have done this if it weren’t for AI - I simply don’t have the time otherwise.

There's a whole lot of people who want software to do certain things but whos job isn't programming and life requirements don't allow the time for all the book reading, tutorial running, and practice to write useful code.

I'm a long time ops guy. I script, but I spend most of my time configuring, patch testing, and keeping the low level infra running much of which doesn't require "coding" per say. Infra as code is in the grand scheme relatively new and still not ubiquitous despite what silicon valley would have you believe. I never had a need to learn to code to a level to do many of the things I'd like to see happen and find useful. Now I can make those software desires a reality without having to alter my career, preferred hobbies, or much of anything else about my life.

I have written multiple IRC bots in the last 20+ years. It's my go-to project to test a new language, mostly because I know the protocol inside and out and it has some gotchas that languages can't handle comfortably (managing a bunch of open TCP sockets with threads/subprocesses mostly).

Have I tried to write my own IRC client yet? Nope. Because even though I know how to, the time spent wouldn't have been worth it. Getting from zero to feature parity would've taken me weeks or months of evenings doing nothing else.

I've got my own irccloud/thelounge clone running now, took me two weeks of calendar time and I spent maybe 6-7 evenings on it and a few hare-brained ideas with Claude on my phone.

The amount of "lubrication" LLMs have given me in going from idea to something good enough just for me is completely bonkers.

>Are people simply too cheap to buy books?

Yes, definitely, though I'm unsure what it means being cheap here.

Not everyone has SV incomes and infinite time to read all the books that would allow to buy, let alone integrate the lessons at a practical implementation level. Plus people might have other interest in life, and family and friends they want to dedicate time and warm attention to.

Speaking for myself, it's less of a yearning to write more code, than it is a yearning for tools that work a specific way.

I write plenty of code at my job, and generally don't have the desire to write more code as a hobby, except in rare cases when the mood really strikes.

Since roughly 1995 or so we've been in a world where quality tooling was provided by on the order of 1,000s of developers, mostly open source. GNU, Xorg, Apache, emacs, nginx, and so on. Or you could opt in to the Microsoft ecosystem.

The ~20 years prior to that we were in a world where you chose to align with either Microsoft's tooling, IBM, or shops providing Unix tooling from proprietary vendors.

I elide a nearly infinite amount of detail, obviously.

What's new now is that you can get your own window manager written to spec in under a week, perhaps much more quickly, not just choose one of a few major window managers and configure it in accordance with the chosen configuration options delivered by the large developer team.

I learned it in the math context - a sphere eversion is a 3 dimensional process that ends with the inside of the sphere becoming the outside.

I had to check it up too. Appears to be a synonym for "inverting" used in some fields like biology and medicine.

To take this further, don't LLMs justify lowering the "barrier to attention"; i.e., if it only takes Claude's and not the hacker's eyeballs on the software, won't people find vulnerabilities in custom software for one too?

Besides that, one could easily imagine software created for similar purposes ("make me a file editor") by the same tool or handful thereof (claude and a very small "etc" for completeness) might share similar vulnerabilities, so this kind of broad net might be even cheaper to cast than one might imagine at first.

I had the exact same thought. Pretty low probability that there's going to be a script-kiddie exploit for your custom tools. Pretty decent probability that there will be vulnerabilities present if someone cares enough to target you.

> This of course would assume that vulnerabilities are in fact unique (which is admittedly questionable).

Yeah, I don't think all that generated software will be as unique as people expect.

Considering it will be generated with the same LLMs that all share roughly the same training data we will se patterns of vulnerabilities will also be similar and so easily exploitable.

We should expect the same automated personalization to be used offensively and for that personalization to be packaged into tools anyone can run (natural language interface, likely.)

(Appreciate your counterpoint for its own sake. It’s an interesting idea.)

If a vulnerability of the common not individualized ancestor software is found, how quickly do people patch their individual versions of the software?

But your browser will invite outside software into your network, to run on your machine. So you have to be up to speed with community knowledge.

I need Claude Max in any case for my work, so the cost is effectively null. And I do creative stuff in my spare time regardless, and I don't really think about my hourly rate when I play with my kids either ;)

> That's insanely impressive.

literally every app they need, except the browser, at least have 10 alternatives that are FOSS, much more mature, better structured and prone to be bug free... or do you really think the OP with months/years of use won't need some other feature and will re-invent the wheel on software that is around for more than a decade with hundreds of bug reports done (i3 wm was released in 2009)

Did you miss a factor of 10 in that time-cost calculation?

As a hobby, normal rates don’t apply, but just not to be misleading on the equivalent cost.

Can't speak for their usage, but I calculated my token use with Copilot, my employer paid 22$ for >2000$ in tokens. Given estimates margins, Github is paying 98-99% of the costs for us. I imagine Claude max etc is similar. So it's not sustainable at all

No idea. Probably quite expensive. I usually run 4-5 concurrent CC sessions, so hard to pinpoint for just CHasm and Fe2O3

Come on, bro. Why you gotta be like that?

I mean, I'm a gwern fan, but...can't you just let people enjoy things?

Wait, are you implying I used an LLM to write my comment? Sorry if I'm misreading what you're saying.

Related tangent: https://smolmachines provides microvms with cold-start bootup times around 200ms, and a "pack" utility and format to create self-contained binaries. No affiliation, but I just discovered it a few days ago, sharing bc I find it kind of exciting.

I feel like using an LLM to do serious work is a bit like us using our brains language centre for the same job - like a very elaborate collection of stock phrases. I'm impressed that it works at all but it doesn't really feel like the right tool for the job. I think the robot of the future will have some more logical cortex doing the thinking, with an LLM in front of it handling the communication.

I was in the second camp until last summer, having been hand-writing code since 1979.

Your analogy is not really apples to apples though, is it?

More close is: if there was a table making machine, you just push a button and something like a table comes out, would you still be a woodworker? You haven't planed, nor measured, nor cut, nor jointed, you've only pressed on "make me a table"

I don't think the analogy works. You're focusing on the "how", not the "what". Using a mechanical planer, you still need to dial in numbers yourself. You design your own table, the more modern tools just make it easier to realize your vision.

Another example: I enjoy writing with a good pen. But whether I write by pen or on a keyboard, it's still me writing it.

However, AI does basically all the real work, only leaving you to guide it. Make a table? AI gives you one with 2 legs. More legs? Guess I can live with 5 legs.

And you wouldn't be making that table, AI is. You cannot have pride in something that you never made yourself. It's the same as 3D-printing something from Thingiverse and claiming you made it.

People who create AI blog posts are not writing. Those that prompt their way to a piece of software are not doing software engineering. The ones that generate AI images are not being artists.

My guess is you're likely to waste more cycles on development time, and on suboptimal algorithms because the implementation is harder, than you would waste on rust-related bloat.

Still a cool project, thanks for sharing.

I have wondered about having LLMs output machine code directly and skipping the compiler/assembler altogether. Then you'd just commit your spec/prompt and run it through the LLM to get your binary.

I know this comment will get ignored by the true believers, and likely pasted directly into Claude by the author in order to "further improve" the code, but here's some small excerpts from the terminal emulator (glass.asm, 19360 lines, 555 KiB):

    cmp dword [rax], 'XAUT'
    jne .rxa_next
    cmp dword [rax+4], 'HORI'
    jne .rxa_next
    cmp word [rax+8], 'TY'
    jne .rxa_next
    cmp byte [rax+10], '='
    jne .rxa_next
    ; Found XAUTHORITY=path

Okay, this is setup code that only runs once at startup - but that would be a reason to optimize it for size and/or readability! REPE CMPSB exists, and may not be the fastest, but certainly the most compact and idiomatic way to compare strings. Or write a subroutine to do it!

This pattern is used everywhere for copying or comparing strings, this was just one example of it.

There's a state variable that's used to keep track of whether the input is text to be displayed or part of a control sequence. It's a full 64 bits, probably not because we need 18 quintillion states? Here's how it is evaluated:

    ; Dispatch based on state
    mov rcx, [vt_state]
    cmp rcx, VT_ESC
    je .vtp_esc
    cmp rcx, VT_CSI
    je .vtp_csi
    cmp rcx, VT_CSI_PARAM
    ...

In total, there are 7 compares + conditional jumps, one after another. Compilers would generate a jump table for this, and a better option in assembly might be to make vt_state a pointer to the label we want to go to. Branch predictors nowadays can handle indirect jumps, and may actually have more trouble with such tightly clustered conditionals as seen in this code.

This code is on the "slow" path, there's a faster one for 7-bit ASCII outside of control sequences, with a lengthy comment by Claude at the top on how it optimized this. Even this one starts with a bunch of conditionals though:

    cmp qword [vt_state], 0            ; VT_NORMAL == 0
    jne .vtp_loop_slow
    cmp dword [utf8_remaining], 0
    jne .vtp_loop_slow
    cmp byte [pending_wrap], 0
    jne .vtp_loop_slow

These could likely all be condensed into a single test or indirect jump via the state variable, by introducing just a few more states for UTF-8 decoding and wrap. Following this, here's a "useless use of TEST" (the subtraction already set the flags):

    mov rbx, [grid_cols]
    sub rbx, [cursor_col]              ; rbx = cells left on this row
    test rbx, rbx
    jle .vtp_loop_slow                 ; no room (or already past)

This also again shows the compulsive use of 64-bit registers and variables for values that should never be this big. It's not the "natural" data size on x86-64 at all, every such instruction requires an extra prefix byte.

I freely confess that I'm a "Luddite", and was explicitly looking for bad (and obviously so) code, but this took me just a few minutes of scrolling through the nearly 20K lines in this file, so it should be somewhat representative of the whole.

> Less memory footprint. No reliance on libs.

rust can do that. You can run a hyper stripped down rust that was made for embedded devices specifically because those devices don't have room for a runtime.

+3.5h extra battery life is a real measurable result! well done.

Many people care, with good reason. We learned to notice LLM-isms is because they are, in fact, a very strong predictor that a piece of text is in fact garbage that's not worth your time reading.

I usually stop reading at the first LLM-ism, but I found the premise of this post interesting enough to keep going - and guess what, the entire article was literally just "I prompt CC to make software tailored for me" blown out to 8 sections.

>But the incessant “AI was used here, thus is it garbage” is long past time to enter the grave.

Nah, that rule is more relevant and true now than it was a year ago.

> Who cares?

I care, because it landed on the front-page of a website that I thought was about engineering and hacking, not prompting a no-code tool and spending 400 bucks on it, to get something nobody else wants.

That no one cared enough to write it is usually a good indication that I should not care to read it either.

> Who cares?

The parent comment does. Why do you care that they care?

^^ some anti-luddism right there

[dead]

[flagged]

I agree, yeah

Yes, but it should be fairly easy to "simply" attack the common technologies that LLMs keep parroting. NextJS, or some Rust tools, or whatever other tools LLMs "love" using, are all great targets.

Once millions of completely unskilled developers have "workflows" that consist of asking an LLM to make a thing, followed by those LLMs pulling in the same 100 (often outdated versions of) dependencies, you have a beautiful attack vector.

Yes, it's "easy" to attack something like Obsidian. It's probably easier to attack a couple hundred dependencies LLMs like to use, or to test what LLMs commonly do to implement things from scratch, and attack those weaknesses.

We are just lucky that enough real, smart, people engineered things that actually work, are well understood, and keep us safe, like firewalls.

I am imagining some poor sod working for NSA TAO trying to hack a bespoke web microservice stack. He spends dozens of hours slaving away at the keyboard, skipping sleep and eating terrible meals at his desk, desperate to get RCE as quickly as possible, because he needs to traverse all the way to the DB layer and exfil data or his boss will pass him over for his next promotion.

At day 9, right as he is getting ready to deploy his beautifully crafted shell code, the clock hits midnight UTC. The website shuts down for maintenance.

"This is it" he thinks. "As soon as the backups finish I'm getting in. No problem."

Minutes tick by. He gets up, stretches, sits back down, watches the clock impatiently. Then, as he prepares to start refreshing the site he recollects, "I'm glad I begged so hard to get authorization to use this PHP 0day."

His partially obscured terminal window has the script ready to launch, all arguments pre-populated, waiting for the link and session token to be pasted in and executed.

The site comes back up. But the url of his launch point returns 404. Undaunted, he returns to a previous url. It is also 404. He curses aloud. Beginning to perspire, he goes to the homepage and prepares to navigate back to the launch point.

The link isn't there. Well, it's there, but it has changed.

"What the....!" The link is no longer a PHP url. He mouses over other links. NO links say PHP anymore. Starting to panic, he clicks on links at random. Not a single one appears to be PHP.

The following morning he schedules an urgent meeting with his supervisor.

"How's that project coming along. Got anything yet?"

"No. I, uh...I'm going to need a bit more time."

"Oh?"

"Yeah. Uh. The site. It got..." He mutes his microphone and, for the 22nd time since midnight, he screams in frustration. Unmuting, he continues:

"It got rewritten. Completely. In Nim."

"What??"

"Yeah. It's some esoteric language that just got a new web framework. I guess somebody decided they wanted to mess around with it. So they vibe coded a complete translation. The whole front end is nimlang now. None of the PHP attacks are going to work on it."

His supervisor expresses his disgust and ends the call.

11 days later the process repeats itself, this time with Rust.

The TAO engineer submits an application to change jobs to the DoD's procurement division, then requests an appointment with a mental health counselor.

It is significant if you don't want to sit at a computer all day just to MAYBE get basic functionality, then find you've backed yourself into a corner because you didn't know some esoteric detail and have to spend another day doing a refactor, etc etc

I don't want to sift through docs and man pages and debug cryptic compiler and runtime errors in my spare time.

There are far richer things for me to do with my life.

I want to use my computer to get my tasks done and be done with it. Slogging through technical details an LLM could crush in minutes is a much better use of my resources.

You might find it fun to hack. Others don't.

Also I don't want to take someone's existing project and change it. They have too much cruft and don't work Just The Way I Like It.

That's why we create custom stuff from scratch.