Had this song in my head, wrote some lyrics, hummed it into Suno, generated the song. I love listening to it. What a world.
I make little tools like that all the time. My GitHub is filled with these little things I write or gen once never to be used again. Some of them I use daily (GitHub.com/dexterlagan). Since LLMs became decent I make even more of these. The more we move forward, the more people make things for their own use. I think it's cool. I see a lot of naysayers, but man, I have been waiting for this kind of tech since I was 10. Let's enjoy it I say.
Yesterday my 8yo prompted (using voice recognition) Claude to make a game where it would play her a song (say Twinkle) and she had to play it back and get scored. The UI was a nice piano with visual feedback. The laptop key served as the keys until I prompted for midi support so she could use the electric piano. The whole thing took about 15 minutes.
Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
It’s a funny time to live through. A lot of code is being written and a lot of it is going to be a real future burden.
And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Sometimes it seems like they're moving very slowly. That makes sense: It's easy to get used to how they work today and it is also easy to forget how much worse they were last year.
When we look back and realize that just 4 years ago these tools didn't really exist at all, it becomes clear that the rate of progress is rather amazing.
In 4 years, we've gone from "hah, good luck with that crap!" to "little kids writing music-learning games on their own in a few minutes"
That's pretty friggin' awesome, and it's not finished yet. :)
> And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Since this is Claude, the models of the future might be more expensive, or more locked down, or might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model, etc.
AI writes faster, so the rate it incurs tech debt is proportionally higher. However it's ability to have large context kept on memory compared to humans is also a key component fighting against it. These are occasionally forgotten when code quality of AI for large code bases are discussed. So Yes I think humans also build spaghetti, but as they write slower they get to the same place a lot later. However humans can't correct it, or can't correct it fast enough. AI can.
It does somewhat depend on the application size. Seems to me that for regular software projects (that aren't enterprise SaaS) a good programmer will create better software than Claude. Maybe the dehumanizing way to say it is that humans have more efficient/improved retrieval. The amount of time I see repeat code for no reason, or code/context that has been obviously missed is absurd.
I wonder. I remember before emissions, what's underneath a car hood was relatively organized and simple. Then with emissions it became a maze of vacuum hoses and so much other nonsense.
then ... in some places (maybe cars that people care about working on) it became cleaner again. In the other places, they added a second hood to hide the mess.
There is some clean code out there, like maybe the seL4 kernel:
The purpose of a car itself didn't change. But the massive inflated demand, as our city planners decided every adult must be put in a rolling metal cage to participate in society, changed the environment it was originally designed for.
Now it's a matter of geopolitical stability, or even basic human habitability of these spaces, that a car converts as much of that chemical energy into movement, and releases as little toxic byproducts in the process. Whereas before, that cost, at scale, was small enough to neglect.
Just like a modern CPU evolved into an incomprehensible mess, even though the basic consumer needs hadn't changed much, because the politics of computing forced them to run expanding institutional cruft at reasonable speeds, on battery-powered always-on addiction machines.
PC accessories have been easy during the era of ifixit, though.
I remember installing seventy-two individual DIP chips onto an Everex 2-megabyte 8-bit ISA EMS expansion card and downloading software to make it work in MS-DOS from Intel's dial-up BBS. I remember chains of MFM drives being made to work by keying obscure commands into debug to run programs that were built into the hard drive controller card.
Oh, so many fun evenings working out which devices could share IRQs and configuring software to work around the corner cases that developed. Serial mice, PS/2 mice, plus bus mice of several different varieties. XT, AT, and PS/2 keyboards. The veritable plethora of mutually-incompatible CD-ROM interfaces.
A clock card: A whole friggin' card with a clock chip and a battery, just to keep track of wall time. (And the software to make it work.)
I even remember SCSI, which was famously renowned for the number of goat sacrifices that were required to to make it work. (Except, I remember SCSI very fondly. CD burner, reader, 7-disc Nakamichi changer, flatbed scanner, DDS tape, and a few IBM Ultrastar 9ES hard drives all sharing the same bus? Sure, why not? It worked. But it took some care to get there.)
It's simple today. Want more storage? SATA is easy (and everyone will make fun of you, but USB 3 works great for a hard drive in a desktop rig). m.2 is compact, and only has a couple of variations. Video cards -- even multiples of them -- just slot right into motherboards and they don't even have jumbers to configure. Sound cards are forgotten. RAM comes in standard forms that only change once every decade or so. Input devices, basic NICs, and video capture stuff can just plug in with USB. The USB ports themselves can be multiplied using hubs.
It's pretty good today, isn't it? Am I missing something?
lol. the original statement was that AI written code is a mess "under the hood"
And I tried to say - cars were "simple/fixable under the hood", then emissions made them a mess then some (specific) cars became simple/fixable again.
but my analogy wasn't clear, so I tried saying that computers went the same way.
started out with simple s-100 bus/pc with slots... but at some point they became no-user-servicable-parts-inside (per ifixit) but some have gotten servicable again.
in summary - I think AI can make a mess, but maybe AI can make clean/maintainable code someday.
maybe there will need to be an AIfixit.com to rate models.
Yeah, I wasn't quite picking up what you were putting down. :) And I'd apologize for writing about old computers, except I enjoy writing about old computers. I never had much experience with S-100, though; my days of hands-in computing started with PCs in the 80s and I missed the earlier eras.
Anyway, I think you're right: The bot will continue to improve. It will get simpler to operate, and it will also generate cleaner code.
But with a twist: That generated code won't become cleaner because it makes it cheaper/easier for humans to understand and work on. Instead, it will instead get cleaner because it makes it cheaper/easier for bots to understand and work on.
Picking over the theoretical maintainability of one-off tools and toys that were generated in minutes by what will soon be an outdated model, feels very...missing the forest for the trees, when it comes to speculating about the future impact of this stuff.
> Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
That is how compiler-generated assembly looks to humans, as well. Human-produced is typically much more readable. Yet, here we are. Most programmers only know the very basics of assembly programming, but the world keeps spinning just fine.
Comparing LLM output to compiler output is such a stale meme by now that it's surprising to see people still saying it. Obviously a deterministic translation of a higher level programming language to machine code is different than the slop cannon.
The fact that this is possible and works at all is mind blowing - even more mind blowing is that my 8 yo is growing up in a world where they can talk to a machine to produce a custom application in seconds and they don’t realise how mind blowing it is!
In terms of the code, it would take even less time than that to tidy it up. For this application you wouldn’t bother. That’s almost a form of “premature optimisation” unless you’re actually planning on doing more work on it.
My hunch is that what the world is about to see a lot of is much bigger bits of work, or changes to other bigger existing systems done by people without the skills to know how to contain the complexity. That’s going to come with a burden.
The downvotes are because you're just saying some devs are bad, you're not explaining how/why incorrect prompting is the only reason it's a mess. Or even the main reason.
Are these experts in the room with us right now? Because if even the creators of Claude seemingly can't prompt non spaghetti code (see: Claude Code leak), I'd like to know who can.
I can absolutely prompt AI to following established patterns and produce nice, clean output in a legacy codebase. I also have a completely separate set of skill files that I’ve been building organically by allowing the agent to do make most decisions about conventions. The latter produces code that would be a nightmare to modify by hand, but I’m still able to iterate on it many times faster than I could in the codebase where code quality is a requirement.
“Code quality” is mostly “human readability”, and I’m simply not sure that’s a valuable attribute anymore.
How do you know they weren't? Have you analyzed the prompt they used?
There's no shortage of examples of unmaintainable spaghetti AI code, Claude Code is just one of many. If you have examples of good codebases maintained by "prompting experts", I'd love to see them.
Pretty much any existing project (that started before LLMs were a thing) who accepts LLM-generated code, I would argue fits your requirement, since the PRs adhere to their existing code style and guidelines, or they wouldn't be accepted in the first place. In those cases it may be impossible to tell that an LLM was even involved.
Recent notable examples would be the Linux kernel or cURL.
I used bluez and bash to lock xscreensaver using some very minimal bash. It wasn't my idea I believe people on the Gentoo forums were doing it.
But you can just loop over something like `hcitool rssi "$MAC"` and project it somewhere, there's a variety of ways.
I like using dunstify with the -p option to persist on screen.
I think it's really impressive what these agents can do, but you should also consider whether you're asking it to burn tokens reinventing the wheel for you, or making a pretty wrapper around a wrapper.
If this happens often for you (it does for me) I can recommend a garmin watch. It also can find the phone based on signal strength.
If the app garmin app is running in the background it can also play a sound on your phone, but the signal strength part saved me many times.
I did that a few years ago when my wife lost her fitbit in the woods. She knew the approximate area, +/- 50ft. Thick brush. Using a BT meter on the phone led me right to it like a metal detector
I routinely use the RSSI indications in my UniFi WiFi (thoroughly recommended) to find various kids devices around the house. You go by AP first (each section has its own), then each room tends to give its own RSSI, give or take.
That's because people like me were doing that and writing about it 20+ years ago. Everything from Claude comes from human minds.
Yes, technology at step N is built from technology at step N-1. Always has been.
Had this song in my head, wrote some lyrics, hummed it into Suno, generated the song. I love listening to it. What a world.
I make little tools like that all the time. My GitHub is filled with these little things I write or gen once never to be used again. Some of them I use daily (GitHub.com/dexterlagan). Since LLMs became decent I make even more of these. The more we move forward, the more people make things for their own use. I think it's cool. I see a lot of naysayers, but man, I have been waiting for this kind of tech since I was 10. Let's enjoy it I say.
Yesterday my 8yo prompted (using voice recognition) Claude to make a game where it would play her a song (say Twinkle) and she had to play it back and get scored. The UI was a nice piano with visual feedback. The laptop key served as the keys until I prompted for midi support so she could use the electric piano. The whole thing took about 15 minutes.
Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
It’s a funny time to live through. A lot of code is being written and a lot of it is going to be a real future burden.
> A lot of code is being written and a lot of it is going to be a real future burden.
This assumes that the models of the future won't find it easier to just throw the code away and rebuild it
This also assumes that the same application build by humans wouldn't become a "spaghetti mess".
And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Sometimes it seems like they're moving very slowly. That makes sense: It's easy to get used to how they work today and it is also easy to forget how much worse they were last year.
When we look back and realize that just 4 years ago these tools didn't really exist at all, it becomes clear that the rate of progress is rather amazing.
In 4 years, we've gone from "hah, good luck with that crap!" to "little kids writing music-learning games on their own in a few minutes"
That's pretty friggin' awesome, and it's not finished yet. :)
> And the models of the future will surely be better than they are today. This stuff is still a very long way from maturity.
Since this is Claude, the models of the future might be more expensive, or more locked down, or might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model, etc.
AI writes faster, so the rate it incurs tech debt is proportionally higher. However it's ability to have large context kept on memory compared to humans is also a key component fighting against it. These are occasionally forgotten when code quality of AI for large code bases are discussed. So Yes I think humans also build spaghetti, but as they write slower they get to the same place a lot later. However humans can't correct it, or can't correct it fast enough. AI can.
It does somewhat depend on the application size. Seems to me that for regular software projects (that aren't enterprise SaaS) a good programmer will create better software than Claude. Maybe the dehumanizing way to say it is that humans have more efficient/improved retrieval. The amount of time I see repeat code for no reason, or code/context that has been obviously missed is absurd.
I wonder. I remember before emissions, what's underneath a car hood was relatively organized and simple. Then with emissions it became a maze of vacuum hoses and so much other nonsense.
then ... in some places (maybe cars that people care about working on) it became cleaner again. In the other places, they added a second hood to hide the mess.
There is some clean code out there, like maybe the seL4 kernel:
https://github.com/seL4/seL4/
https://en.wikipedia.org/wiki/SeL4
"with an explicit goal of enabling comprehensive formal verification..." (and lots more stuff)
maybe we can still have niches like this.
That's what happens with scale...
The purpose of a car itself didn't change. But the massive inflated demand, as our city planners decided every adult must be put in a rolling metal cage to participate in society, changed the environment it was originally designed for.
Now it's a matter of geopolitical stability, or even basic human habitability of these spaces, that a car converts as much of that chemical energy into movement, and releases as little toxic byproducts in the process. Whereas before, that cost, at scale, was small enough to neglect.
Just like a modern CPU evolved into an incomprehensible mess, even though the basic consumer needs hadn't changed much, because the politics of computing forced them to run expanding institutional cruft at reasonable speeds, on battery-powered always-on addiction machines.
It was simple because it was inefficient and archaic. Reducing pollution is not "nonsense"
Not criticizing function, criticizing elegance of the solution. Eventually with time elegance was achieved again.
another analogy would be opening some computers to add memory/ssd/hd, as judged by ifixit
PC accessories have been easy during the era of ifixit, though.
I remember installing seventy-two individual DIP chips onto an Everex 2-megabyte 8-bit ISA EMS expansion card and downloading software to make it work in MS-DOS from Intel's dial-up BBS. I remember chains of MFM drives being made to work by keying obscure commands into debug to run programs that were built into the hard drive controller card.
Oh, so many fun evenings working out which devices could share IRQs and configuring software to work around the corner cases that developed. Serial mice, PS/2 mice, plus bus mice of several different varieties. XT, AT, and PS/2 keyboards. The veritable plethora of mutually-incompatible CD-ROM interfaces.
A clock card: A whole friggin' card with a clock chip and a battery, just to keep track of wall time. (And the software to make it work.)
I even remember SCSI, which was famously renowned for the number of goat sacrifices that were required to to make it work. (Except, I remember SCSI very fondly. CD burner, reader, 7-disc Nakamichi changer, flatbed scanner, DDS tape, and a few IBM Ultrastar 9ES hard drives all sharing the same bus? Sure, why not? It worked. But it took some care to get there.)
It's simple today. Want more storage? SATA is easy (and everyone will make fun of you, but USB 3 works great for a hard drive in a desktop rig). m.2 is compact, and only has a couple of variations. Video cards -- even multiples of them -- just slot right into motherboards and they don't even have jumbers to configure. Sound cards are forgotten. RAM comes in standard forms that only change once every decade or so. Input devices, basic NICs, and video capture stuff can just plug in with USB. The USB ports themselves can be multiplied using hubs.
It's pretty good today, isn't it? Am I missing something?
> Am I missing something?
lol. the original statement was that AI written code is a mess "under the hood"
And I tried to say - cars were "simple/fixable under the hood", then emissions made them a mess then some (specific) cars became simple/fixable again.
but my analogy wasn't clear, so I tried saying that computers went the same way.
started out with simple s-100 bus/pc with slots... but at some point they became no-user-servicable-parts-inside (per ifixit) but some have gotten servicable again.
in summary - I think AI can make a mess, but maybe AI can make clean/maintainable code someday.
maybe there will need to be an AIfixit.com to rate models.
Ah.
Yeah, I wasn't quite picking up what you were putting down. :) And I'd apologize for writing about old computers, except I enjoy writing about old computers. I never had much experience with S-100, though; my days of hands-in computing started with PCs in the 80s and I missed the earlier eras.
Anyway, I think you're right: The bot will continue to improve. It will get simpler to operate, and it will also generate cleaner code.
But with a twist: That generated code won't become cleaner because it makes it cheaper/easier for humans to understand and work on. Instead, it will instead get cleaner because it makes it cheaper/easier for bots to understand and work on.
(Why use many token when few do trick?)
Picking over the theoretical maintainability of one-off tools and toys that were generated in minutes by what will soon be an outdated model, feels very...missing the forest for the trees, when it comes to speculating about the future impact of this stuff.
> Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
That is how compiler-generated assembly looks to humans, as well. Human-produced is typically much more readable. Yet, here we are. Most programmers only know the very basics of assembly programming, but the world keeps spinning just fine.
Comparing LLM output to compiler output is such a stale meme by now that it's surprising to see people still saying it. Obviously a deterministic translation of a higher level programming language to machine code is different than the slop cannon.
1. Compilation has typically not been deterministic. Even within the same exact compiler tool chain version.
2. Compilers and building tool chains change all the time. CI and automated testing catch any regressions. Tye same can be done with LLMs.
3. LLM code generation, with some work, can be made deterministic, if that mattered to somebody.
That's the kind of thing I learned actual programming for, at the same age.
Yes but it’s far better than anything anyone, let alone a small child, could make in 15 minutes
On the other hand an engineer might take a couple hours and build this in a clean way with the right prompting
These “got ‘em” ai criticism comments are getting so old
I wasn’t trying to make a “got em” comment.
The fact that this is possible and works at all is mind blowing - even more mind blowing is that my 8 yo is growing up in a world where they can talk to a machine to produce a custom application in seconds and they don’t realise how mind blowing it is!
In terms of the code, it would take even less time than that to tidy it up. For this application you wouldn’t bother. That’s almost a form of “premature optimisation” unless you’re actually planning on doing more work on it.
My hunch is that what the world is about to see a lot of is much bigger bits of work, or changes to other bigger existing systems done by people without the skills to know how to contain the complexity. That’s going to come with a burden.
The only reason it's a spaghetti mess is because it's not being prompted correctly by an expert.
100%
A novice writing code by hand could also write spaghetti code
If you've worked in enterprise software, you might have seen that even competent professionals can write spaghetti code
At this point AI really is just garbage in garbage out
Haha it’s so comical how predictable downvotes are - which is a proxy for knowing what developers sensibilities are
Wild to me that we see this even in what is a relatively more “sophisticated” forum
The downvotes are because you're just saying some devs are bad, you're not explaining how/why incorrect prompting is the only reason it's a mess. Or even the main reason.
Are these experts in the room with us right now? Because if even the creators of Claude seemingly can't prompt non spaghetti code (see: Claude Code leak), I'd like to know who can.
Speaking for myself - they may not have cared to.
I can absolutely prompt AI to following established patterns and produce nice, clean output in a legacy codebase. I also have a completely separate set of skill files that I’ve been building organically by allowing the agent to do make most decisions about conventions. The latter produces code that would be a nightmare to modify by hand, but I’m still able to iterate on it many times faster than I could in the codebase where code quality is a requirement.
“Code quality” is mostly “human readability”, and I’m simply not sure that’s a valuable attribute anymore.
> “Code quality” is mostly “human readability”
That's an extremely narrow view of programming, and shows a complete lack of experience.
How do you know they were even trying in the first place? Have you analyzed the prompt they used?
How do you know they weren't? Have you analyzed the prompt they used?
There's no shortage of examples of unmaintainable spaghetti AI code, Claude Code is just one of many. If you have examples of good codebases maintained by "prompting experts", I'd love to see them.
Pretty much any existing project (that started before LLMs were a thing) who accepts LLM-generated code, I would argue fits your requirement, since the PRs adhere to their existing code style and guidelines, or they wouldn't be accepted in the first place. In those cases it may be impossible to tell that an LLM was even involved.
Recent notable examples would be the Linux kernel or cURL.
The difference is he’s not passing judgement on it or jumping to conclusions, fyi
Nobody is jumping to conclusions. There's enough examples to come to perfectly reasonable conclusions and judgements.
https://xcancel.com/un1c0rnioz/status/2084686552299634805
I used bluez and bash to lock xscreensaver using some very minimal bash. It wasn't my idea I believe people on the Gentoo forums were doing it.
But you can just loop over something like `hcitool rssi "$MAC"` and project it somewhere, there's a variety of ways.
I like using dunstify with the -p option to persist on screen.
I think it's really impressive what these agents can do, but you should also consider whether you're asking it to burn tokens reinventing the wheel for you, or making a pretty wrapper around a wrapper.
If this happens often for you (it does for me) I can recommend a garmin watch. It also can find the phone based on signal strength. If the app garmin app is running in the background it can also play a sound on your phone, but the signal strength part saved me many times.
I did that a few years ago when my wife lost her fitbit in the woods. She knew the approximate area, +/- 50ft. Thick brush. Using a BT meter on the phone led me right to it like a metal detector
Claude is MacGyvermaxxing
cool, that’s like the Phone Buddy app for Apple Watch
I routinely use the RSSI indications in my UniFi WiFi (thoroughly recommended) to find various kids devices around the house. You go by AP first (each section has its own), then each room tends to give its own RSSI, give or take.
"Come on Rebecca, you did not lose your phone"