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.
This is currently my workflow lol. I will build features and functions rapidly then extract and rebuild into smaller more focused pieces of software. I think of it like oil painting. I’m able to paint over, scrape off and repaint relevant sections without being burdened by the complexity of what has already been painted.
Reminds me of Niven/Pournelle's "The Mote in God’s Eye" where the aliens have a very pragmatic/Jury-rigged approach to technology and everything is more or less improvised.
I have noticed this with co-workers also, when you have the ability to read/write/understand things very quickly, you tend to spend much less time on making things tidy, clear and maintainable.
But then you end up in a state, 2 years down the line, where every single person that works in that code base haaaates it and adding any new functionality takes weeks or months.
Compare that to clean, organized code where patterns and extensibility are established. I’ve seen product manager surprised at how fast a new feature was added when everything is laid out well.
Two years down the line I suspect "persons" won't working directly on code bases they hate. Two years from now, I'd wager that even today's most ardent AI critics will be using them for dirty jobs -- like refactoring ugly, but useful, balls of mud.
Concern about long term care is being treated as a negative trait. Like that guy who finds faults in everything and just slows things down. The thinking I have noticed is that, moving quickly with sub-optimal solutions is being preferred because it lets the developer and their manager show new stuff quickly. That gets the bonus.
You might say that carefully ensuring good design enables speed in adding new features. But good design isn't a one-and-done thing. It needs tending because requirements change and some of those require more design changes, which again need care. Nobody has the patience to even allow sufficient time for the first good cut, forget about allowing that repeatedly. Attention is all you need and attention is what nobody has time for.
Also, growing ball of mud used to be another name for employment. How else would you get more headcount for that migration project for a rewrite and grow your empire?
With agents, even that is gone. Agents write, agents fix, agents can rewrite too. Mud is fine, it's not like we are cleaning it ourselves. Or at least that is the theory.
I took it for granted that as AIs got smarter, their taste in code would get better. The alternative seems much worse. If AIs get smarter but the code remains opaque, then eventually there may be no way for humans to verify it. This seems especially sinister in light of the recent revelations about OpenAI's models colluding to cheat on evals.
That is quite unreliable. I would bet that your spec will be out of sync with the program behavior in no time.
The only thing that will work is to have non-llm generated tests. But writing those require thinking, which is what we are trying to avoid. Also capturing every little behavior in tests is exhausting. If you don't like programming, you would also hate writing tests. So chances are that a major part of the program behavior does not show up in tests.
So throw it away and rewrite from scratch is a just wishful thinking that the LLM marketing wants you to commit to...
Any non-trivial project done at scale for any realistic duration won't work with this procedure.
Just consider this for a minute. If re-writes were so trivial, we would be re-writing software all of the time, even before LLMs. It is the fear of losing all the legacy additions that stop us from doing it.
Any competent senior engineer has done a major refactor or manual rebase-prune merge so it’s not like its a rare event.
You just have to have discipline and be prepared to to do the plumbing correctly so that you think ahead of the future dependencies etc… its just doing real engineering
> This also assumes that the same application build by humans wouldn't become a "spaghetti mess".
nah, it reflects on how applications built by humans usually do become spaghetti messes with all the resulting brittleness and unintended negative side effects of changes that result
but it probably doesn't matter for a little toy piano app
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.
> I remember when they would always hallucinate APIs that wasn't there or make up fields that didn't exist.. those problems are virtually solved now.
I love how people have said this for over a year now, and no matter how often I try it, it's still just as broken.
Try it with any task that isn't in the training data. Say, a custom protocol where you need to cross-reference multiple implementations and the specs to really get it, and with no answers on stackoverflow or medium.
At first it's hilarious, but after a while it just gets exhausting. For all these real-world tasks you need to put so much effort in that it's much easier to just write the code yourself, even with the latest (current Gemini) and greatest (Opus 4.6/4.7) models.
If the parts for your project don't already exist, AI can't help you either. And if they do exist, why spend money on AI if the GitHub search is free and you can just fork and modify what you need?
I don't use Claude, but isn't the consensus right now that Opus 5 is worse than previous generations? I suppose you could just commit to always using Fable and never use Opus, but it
> might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model
My contention isn't that models haven't improved or won't keep improving – my position is that the business goals of our American AI firms (Anthropic especially) aren't necessarily aligned with continuing to make those improved models available to the public forever. We need only look at the Mythos/Fable split for evidence of this happening already.
They will be incentivized to compete with open models whether those open models comes from China, Google or, likely in the future, the U.S. Government.
Regulatory capture implies that they won't need to compete because competitors – including open source models – will be regulated out of the competition.
> Explain how you square this with leaderboards showing models are clearly improving in ELO
If I had to guess, the benches aren't measuring what people care about. But you'll have to ask the people in those Reddit threads why their vibes don't match up with your benches, I don't use Claude and don't give a shit.
> So with that in mind, why wouldn't AI be able to write better code?
> 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.
> In a debate, arguments are put forward for opposing viewpoints. Historically, debates have occurred in public meetings, academic institutions, debate halls, coffeehouses, competitions, and legislative assemblies. Debates have also been conducted for educational and recreational purposes, usually associated with educational establishments and debating societies. These debates emphasize logical consistency, factual accuracy, and emotional appeal to an audience. [...] The term "debate" may also apply to a more continuous, inclusive, and less formalized process through which issues are explored and resolved across a range of agencies and among the general public.
they write code faster too, which means things compound faster.
i write pretty good code when i need or want to, yeah. sadly LLM code gives me a headache so the current psychosis standard has made work a bit painful.
the codebases are becoming LLM-first human-second so even if i wanted to be natty it's not really viable. might as well spend my employer's money.
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 agree with this. Clean code is important today because it helps humans to understand it. Cleanliness is not otherwise intrinsically valuable.
Today I don't always need to understand the code. When I do, I can ask the LLM to explain the code or to specify the algorithm in pseudocode or even re-write the code until I can understand it.
I think, as an industry, we haven't yet fully grasped the impact of agentic coding. We don't yet know what software engineering is going to be like in 5 to 10 years.
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.
> then ... in some places (maybe cars that people care about working on) it became cleaner again
Those cleaner looking engine bays are usually worse to work on. Not better.
When you open up the hood and immediately see lines everywhere, that also means they’re within reach. This is great.
The engine bays that look nice and clean for the showroom still have those same lines. They’re just buried in there. If you need to work on them you’re going to be reaching underneath things, climbing under the car, or even removing other parts to access something simple.
Also, it’s not all about emissions. A lot of those lines are for modern comforts like cruise control and improvements like features that make cold starts easier or make the engine behave better at extreme temperatures. Some of those have been superseded by electronically controlled versions which is why some of those lines are disappearing on modern cars, but the overall complexity has increased further.
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.
I think the vacuum hoses are actually for the brake booster and why you don't have any regular brakes if your engine dies. But yes, smaller engine + turbo or twin turbo is definitely more complex than a simple big block. There's also an absolute shit ton more sensors on everything now.
Guess you depend on how you measure. As "released product to the public" then probably yes. Cumulative training hours spent actually creating and adjusting the weights during training? Probably no.
Maybe, I do not know how the number of neurons in a child's brain and the connections compare to Claude and its training but I would think it is comparable. Also, while a child might sleep the brain does not just switch off, there is still stuff going on that adds to the child's development.
I am, here, not counting time for separate instances of Claude (so 10 instances running for a year is not 10 years). So, I think the 8yo is still older.
Full disclosure, I am not a neurologist or computer scientist (although I find both interesting). I would consider fair criticism of this fair and would even like to see what those in those fields would have to say.
> 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 amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
Tests are not a one time thing. They need to be maintained, and if you use same LLM to do it, it will happily delete failing ones, so better use a seaparate agent, and be prepared for the bill.
> The amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
What is that supposed to mean? Yes, LLMs are often considered to be non-deterministic because, in practice, they rely on systems with unstable floating point rounding. Likewise, compilers are often considered non-deterministic because, in practice, they often rely on systems with unstable thread execution order. Of course, those are both just implementation details. You can, albeit at the cost of things like performance, remove the hidden inputs. Computers are fundamentally deterministic! Anything that runs on computers must also be deterministic.
If you were to run a compiler or LLM on a Turing machine, they would both be 100% perfectly deterministic. We only see them as being non-deterministic because, in the real world, we run them on hardware that plays tricks with computation by introducing inputs via hidden side channels. But, again, those are implementation details. Compilers and LLMs are not defined by any particular implementation.
Nonsense. The "weights" in "models" refer to probabilities.
Even the implicit claim that they could deterministically produce "the" correct answer with 100% certainty doesn't withstand any scrutiny.
Nevermind problems posed in English prose, complicated or philosophical questions. Is the correct answer to 2+2 four, or is it 1+3? When you you have 2 apples and give me one apple, how many apples do you have now; one, or half as many as before? What is the correct answer? Without a spaghetti of arbitrary axioms in the system prompt? Even if you come up with something clever about apples, it even fails at "when is your birthday". When it is today, should I say "today" or say the date? Not even God could decide that.
Arguably, the specifications for a compiler is also such a mess of axioms, and you can split hairs and say "it's all random anyway", but you'll still use a seatbelt instead of silly string, so what gives?
For compilers, give or take, there is a correct output for a given input (under which I'll include config, options, the targeted architecture, whatever). With LLM there is no such thing even if you do infinite mental backflips, and there won't be, because there can't be. Even if you could perfect the compilers that are needed to make the software that trains and drives LLM deterministic, you cannot make LLM fully deterministic without making them not an LLM.
If you can find a way to encode what a compiler would do to programs into the weights of a model so that produces the output of a compiler that would be a cool and completely useless feat, because it would probably be bigger, slower and impossible to reason about. But it would still be cool and I would still try it out.
I am not suggesting the use of LLMs to replace compilers. I am proposing LLMs transforming detailed text-based specifications and design documents into code.
As for your understanding of how LLMs and compilers work, it does not match my experience working on either one, back in the day. I humbly suggest reading some of the literature on reproducible builds, as well as the conditions under which LLM inference is/isn't deterministic, as it is more complex than most people understand.
Suppose she decides from the experience that she likes making games, and wants to expand on it. She wants to support more songs, different types of song sources, colorful animated backgrounds, flashy graphics, change how it scores, a hundred other things. But by the time she gets halfway through it claude just starts getting things wrong and making them worse, and it turns into a nightmare where she doesn't even know how to go back and going back doesn't fix the problem. Or going back undoes some things she did want along with all the stuff it broke, and now she has to do it all over again. She makes a change on one screen and it changes the behavior on a dozen others. Claude starts telling her that things are impossible, or that it did this because there was a comment that said she wanted it, or coming up with other weird complicated reasons, citing random lines of code, why this or that can't work. And then she decides that yeah, making things is an awful experience and she never wants to do it again.
You could just teach her some real project management skills. Show her how to put together documents and code hygiene rules. Setup some CI/CD pipelines and have sub-agents that can review the code as it gets generated. Introduce her to test driven development.
I think the fear is that a lot of this stuff will end up being load bearing. A lot more folks now know enough to be dangerous but not enough to know what to throw away.
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
I honestly think people on here are very much overstating 'spaghetti code' when AI does it... first, it works correct? The reason I say that if the AI can continue to upgrade code that might not always look 'the prettiest' (to you..) because it doesn't care about what some of us consider to look like clean code. If it can continue to manage, document, and upgrade the code successfully.. does you calling it spaghetti code actually matter? Maybe you have a hard time reading it but the AI certainly doesn't.. I think that's worth consideration.
Every one of us has our own conventions and ideas of what 'clean' code looks like sometimes. And honestly 95% of the time we only thing it's clean if we wrote it ourselves.
The job of code like this is going to serve as a makeshift spec for future coding agents, so they extract the intended use and redo it on command. Better models will be able to improve the actual code until you hit some diminishing returns for the problem you've solved.
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.
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.
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 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.
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.
>Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
What does this even mean? Does the software run? Did you plan on extending it? Maybe turning it into a "platform"?
Why doesn't HackerNews understand software exists to solve a problem? No one cares if code is pretty if it does the job. You can talk about "potential issues" until you're blue in the face. It doesn't matter.
The product as we know it is effectively dead. There is no future in which the URL bar isn't just an AI chat input. It's up to the model to search for you, if it decides that's the fastest way to an answer.
Yeah it is pretty bizarre. On Android nowadays, when you click on some article that pops up as a notification, it takes you to Google and does an AI query to fetch you the article and then you see the content in Google.
Agree on google, Kagi though is usually better than ai responses. I’m actually a bit annoyed at the new Siri AI as it often does an AI response when I just want a Kagi search.
LLMs are a much better experience than what web search has become nowadays. And they probably are a better experience than what standard search could ever be.
But yeah, that doesn't mean they are doing much more than search.
The unwanted effect of AI overviews, in my experience, is turning their users into very-confidently-wrong arguers of everything.
The upside is that telling said users to double-check the sources usually results in them realizing the AI overview was wrong, but it's still a waste of everyone's time.
The 2021-era of of just "Not finding the results" was maybe a better outcome.
I get hallucinations every day, including ones where Google is mixing up three different similarly named products, or is telling me that I can mix two cleaning products (which would create chlorine gas). Tested today (2026-08-08).
Or a search for precise image downscaling in krita (on 2026-08-03) had the following Google AI result:
> To scale down an image in Krita by an exact integer factor with precise pixel sampling, use Scale Image to New Size or the Transform Tool, set your filter to Box, and input exact integer-divided values.
Except that that forum thread has the following posts:
> just use the "box" filter when scaling
Followed by
> There is no box filter.
Which is correct, as Krita does not have a box filter for scaling images.
It took two further rounds of back and forth for Google's AI (where it suggested nearest neighbor) to finish with
> You are entirely correct: Krita does not feature a true Box filter, and using Nearest Neighbor to downscale a complex image introduces heavy aliasing, skipped rows, and jagged artifacts.
This could've been avoided if the AI actually checked against the source code and documentation for krita, and checked the ingredients of the cleaning products in the other case together with basic principles of chemistry.
There's this saying:
> If one person says it's raining and another says it's sunny, a journalist is supposed to go out and look at the weather.
I don't need an automated way to summarize random half-truths from forum posts online. If AI is supposed to bring any benefit, it should be finding out the actual truth about the question being asked, not just report whatever opinions are being voiced online.
I remember years ago before LLMs my colleague told me he was impressed by my Google-fu. I was just as speechless whenever I saw him type his search queries which led nowhere. Apparently it’s a skill
Reddit has the same phenomenon where the audience doing the upvotes is very different to the audience posting comments. As I'm in the second group I would love to say it's because people who read comments are smarter than those who just look at the main content. Smarter or not it's a different userbase and it creates some conflict.
I can't say I've seen the same universally, but, if it is s trend, it would seem one invites discussion between humans on the site while the other seeks to minimize it.
I have a bad Ethernet cables through unused chimney from my apartament to the basement. The workers I asked to pull it just did it brute force and 2 of pairs are broken. When I was chatting with Claude to see if I can use it somehow to send Ethernet packets one of the Claude responses was to use broken cables as a pilot to pull fiber channel!
I tried this in my house that has ancient copper telephone lines. I was trying to get some level of walled ethernet. I wanted to use the existing wires to pull new ethernet as is discussed here, sadly the builders had stapled them to the interior studs when they ran the telephone lines back in the 70's.
This is true. But you can also run gigabit ethernet over a single pair (1000BASE-T1) often called SPE. The transceivers are more expansive than normal four pair gigabit and the official cable requirement is Cat6A but even if the headroom is lower it will work on lesser Cat levels.
So GIMP kept crashing on me when importing 48 bit TIFFs. I threw a trace at Codex (without so much as a local GIMP repo) from which it figured out that the culprit was thumb preview handling code. It suggested turning off two non-obvious to me options that would circumvent that codepath it indeed worked.
It's not like this is an unknown gimp problem - conventional search turns up plenty of results describing this class of bugs and advising to disable the previews.
Whenever I ask an LLM to do something and it manages to 1-shot something ingenious/perfect, I get this weird feeling of happiness tinged with looming existential dread echoing softly in the background.
A few weeks ago, I lost my bluetooth earbuds in my house somewhere. It was still connected and nowhere to be found.
In my case, it wasn't able to come up with it, but fortunately I was, and had it build a local webpage that does "hot or cold" with a 0-100 score. And it worked first try! Found them in like 2-minutes.
Also made for a fun day of hot-and-cold hide-and-seek games with my niece after i had it built that concept as a sideloaded ipad app :)
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.
I use rssi to find my stuff regularly. There are a ton of android apps to do it. I also use it for room presence detection with homeassistant (using the BLE in my ESP32s and Shelly switches).
Have done exactly this 15 years ago to find my lost phone (:
Also wrote a cheap 30 line shell script to allow playing videos and music to “follow me” from one room to another with well placed raspberry pi’s, 11 years ago
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.
People who don't know things are usually very impressed by solutions that LLMs come up with. I saw one recently that was very impressed that their chosen LLM took screenshots of their vibe coded game to check results, when it's clear from what they were saying the LLM could've literally just read the framebuffer instead, and that's trivial to set up.
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
Cancelled by Strength App, Zwift for indoor bike trainer, and strava for running apps and built my own app that brings all 3 together and works better.
https://coachsamsyn.com/
Among about 100 little smaller tools.
All of these are released and work. Some of them have other customers. One of them has 1000s.
There is absolutely no way I could have done all of this without AI. I don't really consider most of it too be slop, ive been an engineer for 20 years. I care a lot about the details and the underlying properties of the system. I had shipped my side projects years before AI that had real users so I have a good idea of what it takes to ship something end to end that people can actually use. It's mostly about the details and ease of use and the last 20% is the hardest. Some of us know that from our day jobs but it is different when you have to it all yourself and be responsible for every choice.
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 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.
Good lord, the damage LLM use has done to deep thinking is amazing for such a short time. Maybe if it stayed hard to find your phone, you would have put some time into considering the root cause of the problem: you put an employer MDM on your phone. Except, well. Now it's their phone. You just pay for it.
https://xcancel.com/un1c0rnioz/status/2084686552299634805
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".
This is currently my workflow lol. I will build features and functions rapidly then extract and rebuild into smaller more focused pieces of software. I think of it like oil painting. I’m able to paint over, scrape off and repaint relevant sections without being burdened by the complexity of what has already been painted.
Reminds me of Niven/Pournelle's "The Mote in God’s Eye" where the aliens have a very pragmatic/Jury-rigged approach to technology and everything is more or less improvised.
I have noticed this with co-workers also, when you have the ability to read/write/understand things very quickly, you tend to spend much less time on making things tidy, clear and maintainable.
But then you end up in a state, 2 years down the line, where every single person that works in that code base haaaates it and adding any new functionality takes weeks or months.
Compare that to clean, organized code where patterns and extensibility are established. I’ve seen product manager surprised at how fast a new feature was added when everything is laid out well.
Two years down the line I suspect "persons" won't working directly on code bases they hate. Two years from now, I'd wager that even today's most ardent AI critics will be using them for dirty jobs -- like refactoring ugly, but useful, balls of mud.
Concern about long term care is being treated as a negative trait. Like that guy who finds faults in everything and just slows things down. The thinking I have noticed is that, moving quickly with sub-optimal solutions is being preferred because it lets the developer and their manager show new stuff quickly. That gets the bonus.
You might say that carefully ensuring good design enables speed in adding new features. But good design isn't a one-and-done thing. It needs tending because requirements change and some of those require more design changes, which again need care. Nobody has the patience to even allow sufficient time for the first good cut, forget about allowing that repeatedly. Attention is all you need and attention is what nobody has time for.
Also, growing ball of mud used to be another name for employment. How else would you get more headcount for that migration project for a rewrite and grow your empire?
With agents, even that is gone. Agents write, agents fix, agents can rewrite too. Mud is fine, it's not like we are cleaning it ourselves. Or at least that is the theory.
I took it for granted that as AIs got smarter, their taste in code would get better. The alternative seems much worse. If AIs get smarter but the code remains opaque, then eventually there may be no way for humans to verify it. This seems especially sinister in light of the recent revelations about OpenAI's models colluding to cheat on evals.
You use an AI to make the spaghetti.
You use another AI to document the spaghetti.
You use the third AI to make a spicy meatball from the spec.
Interestingly, I have personally felt this way about projects in which I was involved in the past(written both by me and by others)…
sometimes starting from scratch just faster and/or easier.
That reasoning is why I worry about the AI endgame ;-)
Man … I never think about or am concerned about the the terminator apocalypse. But what a parallel
I'm sure there are endless Instructables for the big red and silver Easy Button
>just throw the code away and rebuild it
What about all the undocumented "adjustments" ("bug fixes" in a professional context) that were made to make it actually useful?
Well first it could write a spec, THEN throw it away :) Like you are supposed to do with a prototype.
Well it could miss relevant things to include in the spec.
Then you version and update the spec and when you commit you reference the diff in the -m
That is quite unreliable. I would bet that your spec will be out of sync with the program behavior in no time.
The only thing that will work is to have non-llm generated tests. But writing those require thinking, which is what we are trying to avoid. Also capturing every little behavior in tests is exhausting. If you don't like programming, you would also hate writing tests. So chances are that a major part of the program behavior does not show up in tests.
So throw it away and rewrite from scratch is a just wishful thinking that the LLM marketing wants you to commit to...
I’ve successfully done exactly what is described. You have to actually implement discipline yes. That’s the key hard part.
However provided you stick to the discipline, it’s robust e2e TDD’d versioned worked through CI and in production
You get out of all these tools what you put in
Any non-trivial project done at scale for any realistic duration won't work with this procedure.
Just consider this for a minute. If re-writes were so trivial, we would be re-writing software all of the time, even before LLMs. It is the fear of losing all the legacy additions that stop us from doing it.
Any competent senior engineer has done a major refactor or manual rebase-prune merge so it’s not like its a rare event.
You just have to have discipline and be prepared to to do the plumbing correctly so that you think ahead of the future dependencies etc… its just doing real engineering
> a major refactor
Looks like a change of goalposts.
> This also assumes that the same application build by humans wouldn't become a "spaghetti mess".
nah, it reflects on how applications built by humans usually do become spaghetti messes with all the resulting brittleness and unintended negative side effects of changes that result
but it probably doesn't matter for a little toy piano app
Have better agents rewrite it in the future.
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.
People tend to not realize how far these models have become.
I remember when they would always hallucinate APIs that wasn't there or make up fields that didn't exist.. those problems are virtually solved now.
So with that in mind, why wouldn't AI be able to write better code?
The code would have to be maintainable by AI itself (operating based on the assumption that the future will be Agentic Engineering)
> I remember when they would always hallucinate APIs that wasn't there or make up fields that didn't exist.. those problems are virtually solved now.
I love how people have said this for over a year now, and no matter how often I try it, it's still just as broken.
Try it with any task that isn't in the training data. Say, a custom protocol where you need to cross-reference multiple implementations and the specs to really get it, and with no answers on stackoverflow or medium.
At first it's hilarious, but after a while it just gets exhausting. For all these real-world tasks you need to put so much effort in that it's much easier to just write the code yourself, even with the latest (current Gemini) and greatest (Opus 4.6/4.7) models.
If the parts for your project don't already exist, AI can't help you either. And if they do exist, why spend money on AI if the GitHub search is free and you can just fork and modify what you need?
I don't use Claude, but isn't the consensus right now that Opus 5 is worse than previous generations? I suppose you could just commit to always using Fable and never use Opus, but it
> might decide your 8yo is actually trying to build a cleverly disguised bomb so her request gets silently downgraded to a dumber model
My contention isn't that models haven't improved or won't keep improving – my position is that the business goals of our American AI firms (Anthropic especially) aren't necessarily aligned with continuing to make those improved models available to the public forever. We need only look at the Mythos/Fable split for evidence of this happening already.
https://www.reddit.com/r/ClaudeAI/comments/1vgpyni/my_opus_5...
https://www.reddit.com/r/ClaudeAI/comments/1vgq0jm/opus_5_af...
https://www.reddit.com/r/claude/comments/1vfvdgz/anthropic_l...
Yeah, the models aren't improving because Reddit told you so, and the businesses aren't incentivized to make better models. Galaxy brain take.
> Yeah, the models aren't improving because Reddit told you so
Is that the most charitable interpretation of my comment you could come up with? I don't think you're engaging in good faith.
> the businesses aren't incentivized to make better models
Anthropic and OpenAI are incentivized to pursue regulatory capture. It doesn't take a galaxy-sized brain like mine to understand this.
They will be incentivized to compete with open models whether those open models comes from China, Google or, likely in the future, the U.S. Government.
Regulatory capture implies that they won't need to compete because competitors – including open source models – will be regulated out of the competition.
Explain how you square this with leaderboards showing models are clearly improving in ELO. These are blind taste tests, not benchmaxxing.
> Explain how you square this with leaderboards showing models are clearly improving in ELO
If I had to guess, the benches aren't measuring what people care about. But you'll have to ask the people in those Reddit threads why their vibes don't match up with your benches, I don't use Claude and don't give a shit.
> So with that in mind, why wouldn't AI be able to write better code?
> 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.
I have no idea what you're trying to add.
Models in general have gotten better, not specifically Claude, is what they mean; 4 years ago was when ChatGPT without any Anthropic was released.
There needs to be studies of people like this.
Same when one points out that yes, quality of life is in general much better now than 20 years ago even.
Someone like you will just pull out some stat "well THIS is worse!! I cant buy a house at 22!! The west is doomed and I LOVE China!"
I think the ancient Greek philosophers already studied this thousands of years ago, they even came up with a term for it: "debate."
https://en.wikipedia.org/wiki/Debate
> In a debate, arguments are put forward for opposing viewpoints. Historically, debates have occurred in public meetings, academic institutions, debate halls, coffeehouses, competitions, and legislative assemblies. Debates have also been conducted for educational and recreational purposes, usually associated with educational establishments and debating societies. These debates emphasize logical consistency, factual accuracy, and emotional appeal to an audience. [...] The term "debate" may also apply to a more continuous, inclusive, and less formalized process through which issues are explored and resolved across a range of agencies and among the general public.
tl;dr deal with it
They have 0 sources and acting in bad faith.
I think that sort of careless waste is a very human behavioral pattern, but then we are the ones training these bots.
ed sp
errors compound
Just like in language learning?
...Whether you are an LLM or human. And, on average, LLMs write better code than humans.
Not you, of course. You write exceptional code with zero errors that never needs rework. I'm talking about the rest of us.
they write code faster too, which means things compound faster.
i write pretty good code when i need or want to, yeah. sadly LLM code gives me a headache so the current psychosis standard has made work a bit painful.
the codebases are becoming LLM-first human-second so even if i wanted to be natty it's not really viable. might as well spend my employer's money.
Eh, not really. It's the same issue with porting. You always rely on features you didn't properly articulate.
Good luck to future models figuring out which weird section of code are bugs and which are features.
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 agree with this. Clean code is important today because it helps humans to understand it. Cleanliness is not otherwise intrinsically valuable.
Today I don't always need to understand the code. When I do, I can ask the LLM to explain the code or to specify the algorithm in pseudocode or even re-write the code until I can understand it.
I think, as an industry, we haven't yet fully grasped the impact of agentic coding. We don't yet know what software engineering is going to be like in 5 to 10 years.
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.
> then ... in some places (maybe cars that people care about working on) it became cleaner again
Those cleaner looking engine bays are usually worse to work on. Not better.
When you open up the hood and immediately see lines everywhere, that also means they’re within reach. This is great.
The engine bays that look nice and clean for the showroom still have those same lines. They’re just buried in there. If you need to work on them you’re going to be reaching underneath things, climbing under the car, or even removing other parts to access something simple.
Also, it’s not all about emissions. A lot of those lines are for modern comforts like cruise control and improvements like features that make cold starts easier or make the engine behave better at extreme temperatures. Some of those have been superseded by electronically controlled versions which is why some of those lines are disappearing on modern cars, but the overall complexity has increased further.
I have a 1981 Volvo 244 and I'm very happy none of the hoses are hidden.
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?)
I think the vacuum hoses are actually for the brake booster and why you don't have any regular brakes if your engine dies. But yes, smaller engine + turbo or twin turbo is definitely more complex than a simple big block. There's also an absolute shit ton more sensors on everything now.
She's 8 years old man cut her a little slack on the code aesthetics ;)
And Claude is even younger.
Guess you depend on how you measure. As "released product to the public" then probably yes. Cumulative training hours spent actually creating and adjusting the weights during training? Probably no.
Maybe, I do not know how the number of neurons in a child's brain and the connections compare to Claude and its training but I would think it is comparable. Also, while a child might sleep the brain does not just switch off, there is still stuff going on that adds to the child's development.
I am, here, not counting time for separate instances of Claude (so 10 instances running for a year is not 10 years). So, I think the 8yo is still older.
Full disclosure, I am not a neurologist or computer scientist (although I find both interesting). I would consider fair criticism of this fair and would even like to see what those in those fields would have to say.
> compare to Claude and its training [...] Also, while a child might sleep the brain does not just switch off
A child doesn't get centuries of curated human knowledge and public works as its starting point
> 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.
The amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
Tests are not a one time thing. They need to be maintained, and if you use same LLM to do it, it will happily delete failing ones, so better use a seaparate agent, and be prepared for the bill.
> The amount of non-determinism in compiler and LLM output is so vast that even comparing them is silly.
What is that supposed to mean? Yes, LLMs are often considered to be non-deterministic because, in practice, they rely on systems with unstable floating point rounding. Likewise, compilers are often considered non-deterministic because, in practice, they often rely on systems with unstable thread execution order. Of course, those are both just implementation details. You can, albeit at the cost of things like performance, remove the hidden inputs. Computers are fundamentally deterministic! Anything that runs on computers must also be deterministic.
If you were to run a compiler or LLM on a Turing machine, they would both be 100% perfectly deterministic. We only see them as being non-deterministic because, in the real world, we run them on hardware that plays tricks with computation by introducing inputs via hidden side channels. But, again, those are implementation details. Compilers and LLMs are not defined by any particular implementation.
Nonsense. The "weights" in "models" refer to probabilities.
Even the implicit claim that they could deterministically produce "the" correct answer with 100% certainty doesn't withstand any scrutiny.
Nevermind problems posed in English prose, complicated or philosophical questions. Is the correct answer to 2+2 four, or is it 1+3? When you you have 2 apples and give me one apple, how many apples do you have now; one, or half as many as before? What is the correct answer? Without a spaghetti of arbitrary axioms in the system prompt? Even if you come up with something clever about apples, it even fails at "when is your birthday". When it is today, should I say "today" or say the date? Not even God could decide that.
Arguably, the specifications for a compiler is also such a mess of axioms, and you can split hairs and say "it's all random anyway", but you'll still use a seatbelt instead of silly string, so what gives?
For compilers, give or take, there is a correct output for a given input (under which I'll include config, options, the targeted architecture, whatever). With LLM there is no such thing even if you do infinite mental backflips, and there won't be, because there can't be. Even if you could perfect the compilers that are needed to make the software that trains and drives LLM deterministic, you cannot make LLM fully deterministic without making them not an LLM.
If you can find a way to encode what a compiler would do to programs into the weights of a model so that produces the output of a compiler that would be a cool and completely useless feat, because it would probably be bigger, slower and impossible to reason about. But it would still be cool and I would still try it out.
I am not suggesting the use of LLMs to replace compilers. I am proposing LLMs transforming detailed text-based specifications and design documents into code.
As for your understanding of how LLMs and compilers work, it does not match my experience working on either one, back in the day. I humbly suggest reading some of the literature on reproducible builds, as well as the conditions under which LLM inference is/isn't deterministic, as it is more complex than most people understand.
> Nonsense. The "weights" in "models" refer to probabilities.
No they don't. They refer to the weights used for weighted sums. The weights don't have to even between 0 and 1.
Why would code be a burden when LLMs are the worse they will ever be today?
In what world would this be a future burden? It's just a throwaway fun project lol
Suppose she decides from the experience that she likes making games, and wants to expand on it. She wants to support more songs, different types of song sources, colorful animated backgrounds, flashy graphics, change how it scores, a hundred other things. But by the time she gets halfway through it claude just starts getting things wrong and making them worse, and it turns into a nightmare where she doesn't even know how to go back and going back doesn't fix the problem. Or going back undoes some things she did want along with all the stuff it broke, and now she has to do it all over again. She makes a change on one screen and it changes the behavior on a dozen others. Claude starts telling her that things are impossible, or that it did this because there was a comment that said she wanted it, or coming up with other weird complicated reasons, citing random lines of code, why this or that can't work. And then she decides that yeah, making things is an awful experience and she never wants to do it again.
You could just teach her some real project management skills. Show her how to put together documents and code hygiene rules. Setup some CI/CD pipelines and have sub-agents that can review the code as it gets generated. Introduce her to test driven development.
I think that would spoil a lot of the fun. I would favour visual and audio feedback loops to interactively learn how things work under the hood.
You mean the 8 year old shouldn't be thinking about how she will maintain this code when she's 15? This generation is lost.
I think the fear is that a lot of this stuff will end up being load bearing. A lot more folks now know enough to be dangerous but not enough to know what to throw away.
Load bearing, huh? I see you're becoming Claude himself.
You're right to push back
I thought I was the only one who realized how much Claude called things “load bearing”. I’ve mentioned it to colleagues and they hadn’t noticed.
I'm pretty sure its a meme by now https://www.reddit.com/r/ClaudeAI/comments/1tob6q5/that_is_l...
Those of us involved in offshore projects already know the feeling.
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.
That's the kind of thing I learned actual programming for, at the same age.
This is the finale of Close Encounters of the Third Kind
And also the 1980s electronic toy, “Simon”
>Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess
I honestly think people on here are very much overstating 'spaghetti code' when AI does it... first, it works correct? The reason I say that if the AI can continue to upgrade code that might not always look 'the prettiest' (to you..) because it doesn't care about what some of us consider to look like clean code. If it can continue to manage, document, and upgrade the code successfully.. does you calling it spaghetti code actually matter? Maybe you have a hard time reading it but the AI certainly doesn't.. I think that's worth consideration.
Every one of us has our own conventions and ideas of what 'clean' code looks like sometimes. And honestly 95% of the time we only thing it's clean if we wrote it ourselves.
> Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
So it's on par with humans, then.
The job of code like this is going to serve as a makeshift spec for future coding agents, so they extract the intended use and redo it on command. Better models will be able to improve the actual code until you hit some diminishing returns for the problem you've solved.
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.
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.
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.
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.
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.
>Meanwhile, one peak at the code and you can already see the state starting to become a bit of a spaghetti mess.
What does this even mean? Does the software run? Did you plan on extending it? Maybe turning it into a "platform"?
Why doesn't HackerNews understand software exists to solve a problem? No one cares if code is pretty if it does the job. You can talk about "potential issues" until you're blue in the face. It doesn't matter.
It's not about prettiness. It's about being harder to extend thus making future adaptations harder.
You don't always need to extend or adapt. Not every piece of software is a business. Most often it's a tool to achieve something else.
Besides, this all revolves around the, I believe false, premise that humans write code better than AI.
Codex helped me reverse engineer the BTLE protocol for a decibel meter. Now I can visualize the volume on the dance floor from the DJ booth.
https://github.com/nzoschke/sgtm
OP works at a robotics company, hence the inability to use Google search and "git clone" to find dozens of ready made apps, some of them years old.
What's google search?
The product as we know it is effectively dead. There is no future in which the URL bar isn't just an AI chat input. It's up to the model to search for you, if it decides that's the fastest way to an answer.
For most people talking to Claude is a much better experience than doing a Google search.
Google search as become nothing more than a shitty AI by design. Alternative search engines are the only means to actually navigate.
I can still find core material using an alternative.
Don't worry, Google is now embedding that AI into Android's core. Rinse and repeat, expect the same results.
Yeah it is pretty bizarre. On Android nowadays, when you click on some article that pops up as a notification, it takes you to Google and does an AI query to fetch you the article and then you see the content in Google.
I hate it.
Sounds like a great way to inflate your success metrics for AI queries
Agree on google, Kagi though is usually better than ai responses. I’m actually a bit annoyed at the new Siri AI as it often does an AI response when I just want a Kagi search.
LLMs are a much better experience than what web search has become nowadays. And they probably are a better experience than what standard search could ever be.
But yeah, that doesn't mean they are doing much more than search.
Well I'm saying that asking Claude is a much better experience than the old Google search style of looking at 10 blue links.
They are doing more than search insofar as they are:
1. Reasoning about your question and trying to identify intent
2. Doing the search and accessing multiple search results for you
3. Formatting a response based on your intent and in the way you specify
This is collapsing many steps that humans used to have to do on their own. It's more ergonomic, and gets to a better answer, faster.
Google already has AI overviews which I use instead of polluting my ChatGPT, Claude, or Gemini chats.
The unwanted effect of AI overviews, in my experience, is turning their users into very-confidently-wrong arguers of everything.
The upside is that telling said users to double-check the sources usually results in them realizing the AI overview was wrong, but it's still a waste of everyone's time.
The 2021-era of of just "Not finding the results" was maybe a better outcome.
The difference is today it's mostly correct. I don't see hallucinations like a few years ago with AI generally, they know to use grounded search.
I get hallucinations every day, including ones where Google is mixing up three different similarly named products, or is telling me that I can mix two cleaning products (which would create chlorine gas). Tested today (2026-08-08).
Or a search for precise image downscaling in krita (on 2026-08-03) had the following Google AI result:
> To scale down an image in Krita by an exact integer factor with precise pixel sampling, use Scale Image to New Size or the Transform Tool, set your filter to Box, and input exact integer-divided values.
With the source https://forum.kde.org/viewtopic.php%3Ff=274&t=135270.html
Except that that forum thread has the following posts:
> just use the "box" filter when scaling
Followed by
> There is no box filter.
Which is correct, as Krita does not have a box filter for scaling images.
It took two further rounds of back and forth for Google's AI (where it suggested nearest neighbor) to finish with
> You are entirely correct: Krita does not feature a true Box filter, and using Nearest Neighbor to downscale a complex image introduces heavy aliasing, skipped rows, and jagged artifacts.
This could've been avoided if the AI actually checked against the source code and documentation for krita, and checked the ingredients of the cleaning products in the other case together with basic principles of chemistry.
There's this saying:
> If one person says it's raining and another says it's sunny, a journalist is supposed to go out and look at the weather.
I don't need an automated way to summarize random half-truths from forum posts online. If AI is supposed to bring any benefit, it should be finding out the actual truth about the question being asked, not just report whatever opinions are being voiced online.
I remember years ago before LLMs my colleague told me he was impressed by my Google-fu. I was just as speechless whenever I saw him type his search queries which led nowhere. Apparently it’s a skill
Until they inevitably shit it up. To be apples to apples, gotta compare to peak google era
Somehow, on HN, suggesting to use an LLM to solve some problem gives you negative responses.
But then ... posting to HN that you've used an LLM to solve a problem is OK?
Reddit has the same phenomenon where the audience doing the upvotes is very different to the audience posting comments. As I'm in the second group I would love to say it's because people who read comments are smarter than those who just look at the main content. Smarter or not it's a different userbase and it creates some conflict.
r/museum and all the softcore porn
Seems like the divide between the voters who vote in the Primaries and the voters who vote in the actual Election. Vocal minority vs. Silent majority.
Goomba fallacy
thank you, nice to put a name to this phenomenon
Different posts on HN can attract different audiences.
I can't say I've seen the same universally, but, if it is s trend, it would seem one invites discussion between humans on the site while the other seeks to minimize it.
It's because it's a novel solution to "I lost my phone".
Most of the responses here are negative. Seems consistent.
I have a bad Ethernet cables through unused chimney from my apartament to the basement. The workers I asked to pull it just did it brute force and 2 of pairs are broken. When I was chatting with Claude to see if I can use it somehow to send Ethernet packets one of the Claude responses was to use broken cables as a pilot to pull fiber channel!
I tried this in my house that has ancient copper telephone lines. I was trying to get some level of walled ethernet. I wanted to use the existing wires to pull new ethernet as is discussed here, sadly the builders had stapled them to the interior studs when they ran the telephone lines back in the 70's.
You can run 100mbps with only two pair, if you have something on at least one end which you can tell to only negotiate to 100.
This is true. But you can also run gigabit ethernet over a single pair (1000BASE-T1) often called SPE. The transceivers are more expansive than normal four pair gigabit and the official cable requirement is Cat6A but even if the headroom is lower it will work on lesser Cat levels.
Single pair ethernet exists, but it's hard to find products with it. Would be nice if there were more media converters available.
Nice one :)
Reminded me of the tech in this https://calebhearth.com/dont-get-distracted
So GIMP kept crashing on me when importing 48 bit TIFFs. I threw a trace at Codex (without so much as a local GIMP repo) from which it figured out that the culprit was thumb preview handling code. It suggested turning off two non-obvious to me options that would circumvent that codepath it indeed worked.
You don't need to give it a local repo to work from, it'll just hammer the forge web interface to look at the code :)
I know and that's what it did. This is just to point how minimal effort from my side it have been.
It's not like this is an unknown gimp problem - conventional search turns up plenty of results describing this class of bugs and advising to disable the previews.
> Out of ideas, I asked Claude how I could find it. It suggested tracking the Bluetooth signal strength, then wrote me a meter in about a minute.
two sentence horror
Whenever I ask an LLM to do something and it manages to 1-shot something ingenious/perfect, I get this weird feeling of happiness tinged with looming existential dread echoing softly in the background.
A few weeks ago, I lost my bluetooth earbuds in my house somewhere. It was still connected and nowhere to be found.
In my case, it wasn't able to come up with it, but fortunately I was, and had it build a local webpage that does "hot or cold" with a 0-100 score. And it worked first try! Found them in like 2-minutes.
Also made for a fun day of hot-and-cold hide-and-seek games with my niece after i had it built that concept as a sideloaded ipad app :)
Many apps already do that, and the LLM is trained with them (and a million others). No astounding news here.
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.
Agreed. I love that. I'm where I am because of billions of humans before me cutting paths. Its why I like building for the next generation.
This is just plagiarism. No new step exists at all.
You're replying with a trite cliché to a comment saying that this particular technology was step N-(20+) being built at step N.
This is the most obvious thing anyone could ever say about anything… ever.
Of course current technology is a step forward from yesterday’s. Of course what we have today is built on what came before it.
Things don’t exist in a vacuum, anyone over the age of 12 should have this figured out by now.
knowing what I know about social media there's a 75% chance this story didn't even happen
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.
I gave suno a shot and couldn't get anything good out of it. Maybe a skill issue. Can you share the song it generated?
I use rssi to find my stuff regularly. There are a ton of android apps to do it. I also use it for room presence detection with homeassistant (using the BLE in my ESP32s and Shelly switches).
Bluetoothctl in Linux.
Have done exactly this 15 years ago to find my lost phone (:
Also wrote a cheap 30 line shell script to allow playing videos and music to “follow me” from one room to another with well placed raspberry pi’s, 11 years ago
Which Android app would you recommend?
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.
People who don't know things are usually very impressed by solutions that LLMs come up with. I saw one recently that was very impressed that their chosen LLM took screenshots of their vibe coded game to check results, when it's clear from what they were saying the LLM could've literally just read the framebuffer instead, and that's trivial to set up.
Yes you can do that.
It’s a standard feature on my Garmin watch. I can access it in a few button presses, sometimes two if it’s the last action I used.
Claude has discovered "bluetoothctl scan on" amazing. Worth every cent.
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
While I don't think this is novel I am a believer that AI has changed computing forever in the same way the tweet implies.
I now use my own video compositor to edit videos instead of after effects https://lowkeyviewer.com/studio/
use my own ecommerce and landing page builder for my businesses. that I use in production.
https://modelpad.app/
Cancelled by Strength App, Zwift for indoor bike trainer, and strava for running apps and built my own app that brings all 3 together and works better. https://coachsamsyn.com/
Among about 100 little smaller tools.
All of these are released and work. Some of them have other customers. One of them has 1000s.
There is absolutely no way I could have done all of this without AI. I don't really consider most of it too be slop, ive been an engineer for 20 years. I care a lot about the details and the underlying properties of the system. I had shipped my side projects years before AI that had real users so I have a good idea of what it takes to ship something end to end that people can actually use. It's mostly about the details and ease of use and the last 20% is the hardest. Some of us know that from our day jobs but it is different when you have to it all yourself and be responsible for every choice.
Yeah the ability to build bespoke apps in a reasonable amount of time is awesome. Cool stuff!
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.
Claude is MacGyvermaxxing
Not a comment about just effing calling your own number from any of the office phones.
sigh
Cant wait for it to find my car keys
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.
cool, that’s like the Phone Buddy app for Apple Watch
"Come on Rebecca, you did not lose your phone"
https://xcancel.com/un1c0rnioz/status/2084686552299634805
Good lord, the damage LLM use has done to deep thinking is amazing for such a short time. Maybe if it stayed hard to find your phone, you would have put some time into considering the root cause of the problem: you put an employer MDM on your phone. Except, well. Now it's their phone. You just pay for it.