Live data from Hacker News

Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

twitter.com

181–190 of 231 posts

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#181
post #176

Earlier quoted context omitted.

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

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#182

Earlier quoted context omitted.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#183
post #176

Earlier quoted context omitted.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#184

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 th…

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?

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#185

Earlier quoted context omitted.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#186

Earlier quoted context omitted.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#187

Earlier quoted context omitted.

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.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#189

Earlier quoted context omitted.

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.

Re: Lost my phone at the office. Claude suggested tracking Bluetooth signal strength

#190
post #3

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 s…

> 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.
Post reply on HN