m12k

Friend of mine built a startup around this, allowing non-techies to "query their database using natural language": https://www.blazesql.com/ Not sure how he achieved it (if TFA is to be believed), but it's my impression that his query generation and results are fairly robust.

I experienced this too, when I started reading out loud more. At first, it was just that my eyes would scan ahead a bit from what I was saying, to help me get the right emphasis by knowing where the sentence was going. It felt like I had "handed off" saying the words out loud to a "subroutine", so my attention could be on what I was reading. Then that "readahead" extended to a whole sentence. And at that point it was like I was so far ahead of what I was saying that I had time to think about it a bit. And then at some point it was like the "reading the words" part got handed off to a "subroutine" too, so my attention could mostly stay on whatever I was thinking

Siri is how I set timers, alarms and reminders on my iPhone. Every once in a while, I'll try to use it to play something on Spotify via my Sonos, then give up and do it manually in the app instead.

Reminds me of this old joke: No ethically trained software engineer would ever write a destroyBaghdad function - they’d write a destroyCity function to which you could pass Baghdad as a parameter.

The intuition I've built is that you can't talk about a false positive rate being high or low on its own - it's always relative to the actual occurrence rate of positives in the tested population. E.g. if there's a 1 in 10000 risk of a false positive, but real positives also are only 1 out of 10000 tested cases, then a positive case will have a 50/50 chance of being a false positive (because for every 10000 tests, you'll have on average one false positive and one real positive). So a false positive rate can only be said to be low if it's significantly lower than the real occurrence rate of positives.

Connecting voyeurs and exhibitionists is already a great business idea - don’t know why we need to add robots to the mix.

I don't know about the rest of Europe, but in Denmark, universities get a part of their funding based on the number of graduates. So the university has an incentive to help student actually graduate instead of kicking them out. That may or may not matter to the bureaucrat responding to an appeal - but I'd certainly not just assume that "I'm close to graduation, just let me do this one more exam attempt" isn't a good enough reason for them to let you try.

I’m not sure if you’re aware, but Claude Code’s built in remote control feature already lets you respond to permission prompts from the Claude app on your phone.

I feel genuinely conflicted: On the one hand I get the "authoritarian overreach heebie-jeebies", that I think a lot of people on HN probably share. On the other hand I'd also really like the West to harden its election processes from election interference by its adversaries (e.g. Russia) - and shoring up dysinfo on e.g. Facebook by requiring users to prove their identity with a government ID is one of the only ways to truly effectively combat this at its source (fact-checking just can't keep up with a firehose of dysinformation). Ideally I'd want "real id requirements" to be limited " partake in public discourse" (mainly Facebook and Twitter). But the slippery slop argument just feels pretty strong here too - once a mechanism like this is in place, its use will only ever expand, and it's much easier for a new government to commit overreach if it's already there and just needs expanding. And of course all this "think of the children" nonsense needs to stop.

Douglas Adams summed it up eloquently:

“I've come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.”

Reminds me of this writeup that I read recently about using a different noise function (not Perlin) to emulate terrain erosion: https://blog.runevision.com/2026/03/fast-and-gorgeous-erosio...

In case anyone is wondering, the quote "Before enlightenment, chop wood, carry water. After enlightenment, chop wood, carry water" is an ancient Zen Buddhist proverb. It speaks to how the life you live, and actions you perform, before and after enlightenment are not materially different. But how and why you do and experience them changes, becoming more mindful and less mired in “attachment” and overthinking.

If I was doing all this ad hoc, it might just be. But I’ve had Claude save this as three “skills” (standard workflows) that chain together (review-branch, triage-findings, apply-fixes) so all I need to do is say “review the branch”, make judgment calls on truly ambiguous decisions, and then “apply the fixes”. It’s effort-full but not for me

I've stumbled on the same workflow. Except for one thing: If I just do as OP does, Claude Code will tend to overengineer. For example it'll build complex solutions to super rare race conditions that have trivial fallout. But I've found that all it takes is a "skeptical pass". Here's how it goes: After having a bunch of specialist subagents review the (plan/implementation), after doing the deduplication/synthesis of their findings, the main agent will bucket them into A) Trivial/obvious fix B) there's multiple possible resolutions, but the LLM had a strong lean, so it went with it on its own C) Genuine ambiguity, where it asks me what to do (and presents its lean) and D) Wontfix. Crucially, after doing this, I have it run a "skeptical pass" where it takes a hard look at these findings and see if maybe some of them deserve to be downgraded. Generally, a lot of things make their way into wontfix this way. I find, I don't need to push back against overengineering, I can have the LLM do so itself, and it'll actually do a decent job of it.

As software engineers we’ve now suddenly become a sort of “god of the gaps” - our existence is only justified in the (fewer and fewer) situations where the AI can’t do the job just as well on its own

The typescript team themselves rewrote the compiler in Go to get better use of coding agents.

Headquartered in Stockholm, so "bear-yet" should get you fairly close.

So we've basically taken the concept of branch prediction from CPUs and applied it to LLMs?

https://brandur.org/nanoglyphs/015-ruby-typing#ruby-typing

I feel like this article leaves out the latest research pointing to acetaminophen having a negative effect on fertility, hindering embrionic development and potentially also also follicular development in baby girls. It's a trade-off for sure, but if you're trying to have a baby, you may want to swing back to ibuprofen.

[1] https://pubmed.ncbi.nlm.nih.gov/40819833/

[2] https://ddeacademy.dk/ddea/what-new-research-reveals-about-p...

Not my comment but my guess is they might be referring to the research that shows that intermittent fasting has various health benefits. And one of the most popular ways to do intermittent fasting is 16:8 (16 hours where you fast, 8 hours where you eat), typically where you only ever eat from 12 noon until 8 in the evening, and then fast from 8 pm until noon the next day. Under those conditions, breaking the fast with a breakfast means losing out on the health benefits, and you're better off waiting until lunch.

Remember, having the dot com bubble burst did not prevent the internet from being integrated more and more in society over the next couple decades. What it did was stop the headless investment where money was thrown at anything that tangentially could be called "online". We went from "nobody knows what this is, but everyone wants a piece of it" to "we know what it is, and we sure did pursue a lot of bad ideas when we didn't". Expect something similar to happen with AI - having the bubble burst will not stop it in its tracks, but it will change what gets invested in.

I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual changes. I used to think this would require a new version control system that encodes the semantics of the changes in the commits, in order to have them available at merge-time. But these days, it seems much more realistic to stick to git, but loop in LLMs when merging, to re-create the semantics from the textual changes.

Fair point, though I think that when it's low rez enough, it becomes less apparent that it's not in screenspace, and it gets closer to a retro look: https://youtu.be/EzjWBmhO_1E?t=102

There's a follow up video with variations of the technique (some of them with color) demonstrated in a game: https://www.youtube.com/watch?v=EzjWBmhO_1E

But yes, there's still the issue of oblique angles looking different that still remains open AFAIK.

If you find this interesting, you might also be interested in this video of someone diving even deeper into how to make the dither surface stable: https://www.youtube.com/watch?v=HPqGaIMVuLs

I just wish more of these projects would be a bit more ambitious and put more focus in their communication on being good at what they do, rather than being free and made by idealists. They're branding themselves in a way that only really appeals to other techy idealists, while accidentally putting off a lot of potential users who are neither technical nor philosophical enough to know or care what a term like libre means. There's a lot of good, free software that is selling itself short by communicating more about being the latter than the former.

Right, I get what you're saying, but in git-flow, the master branch isn't just "stable", it's "literally the last release we made". Which you can also get from the tags (i.e. checking out master or checking out the highest numbered release version tag will give you exactly the same commit). So I'm not sure I see the functional difference. Either you have "develop is messy, master is stable", or you have "master is messy, latest release tag is stable". I mean, sure, there's a bit of mental work involved in "which of these tags has the highest number". But surely that's less than the work involved in maintaining two long-running branches instead of one? I'm not really arguing for one way of working (or level of stability at integration) or another, I'm arguing that the one that git-flow supports can be implemented in a functionally equivalent, but simpler way, with naming that is more consistent with usage elsewhere.

I'll try to respond to your comment in good faith, even though I find it to have a rather aggressive, ad-homimen tone:

If this pattern is so pervasive, and so many people care enough to attempt to explain it to you, yet you remain unconvinced, I’m not sure how you reach the conclusion that you are right, and correct, and that it’s such a shame that the world does not conform to how you believe that things should be.

The reason nobody has convinced me otherwise isn't that I haven't listened, but because the people I talked to so far didn't actually have arguments to put forth. They seemed to be cargo-culting the model without thinking about why the branching strategy was what it was, and how that affected how they would work, or the effort that would be put into following each part of the model vs the value that this provides. It seemed to me that the main value of the model to them was that it freed them from having to think about these things. Which honestly, I have no problem with, we all need to choose where to put our focus. But also, all the more reason why I think it's worth caring about the quality of the patterns that these guys follow unquestioningly.

Besides a bit of a puritan argument about “git gods”, you haven’t really justified why this matters at all, let alone why you care so much about it.

Apart from that (apparently failed) attempt at humor, I did in fact attempt to justify later in my comment why it matters: "instead of demoting the master/main branch to that role, when it already has a widely used, different meaning?" To expand on that, using the same names to describe the same things as others do has value - it lowers friction, allows newcomers (e.g. people used to the github branching model) to leverage their existing mental model and vernacular, and doesn't waste energy on re-mapping concepts. So when the use case for the master/main branch is already well-established, coming up with a different name for the branch you do those things on ("develop") and doing something completely different on the branch called master/main (tagging release commits), is just confusing things for no added benefit. On top of that, apart from how these two branches are named/used, I also argue that having a branch for the latter use case is mostly wasted effort. I'm not sure I understand why it needs to be spelled out that avoiding wasted effort (extra work, more complexity, more nodes in the diagram, more mental load, more things that can go wrong) in routine processes is something worth caring about.

On the other hand, the model that you are so strongly against has a very easy to understand mental model that is analogous to real-world things. What do you think that the flow in git flow is referring to?

"very easy to understand mental model"s are good! I'm suggesting a simplification (getting rid of one branch, that doesn't serve much purpose), or at least using naming that corresponds with how these branches are named elsewhere, to make it even easier to understand.

You say it's a model that I'm "so strongly against". Have you actually read my entire comment? It says "Especially when the rest of it is so sensible - the whole feature-branch, release-branch, hotfix flow is IMO exactly right for versioned software". I'm not strongly against the model as a whole. I think 80% of it is spot on, and 20% of it is confusing/superfluous. I'm lamenting that they didn't get the last 20% right. I care exactly because it's mostly a good model, and that's why the flaws are a pity, since they keep it from being great.

As for "flow", I believe it refers to how code changes are made and propagated, (i.e. new feature work is first committed on feature branches, then merged onto develop, then branched off and stabilized on a release branch, then merged back to develop AND over onto master and tagged when a release happens). Why do you bring this up? My proposal is to simplify this flow to keep only the valuable parts (new feature work is first committed on feature branches, then merged onto master, then branched off and stabilized on a release branch, then tagged and merged back to master when a release happens). Functionally pretty much the same, there's just one less branch to manage, and develop is called master to match its naming elsewhere.

I’m sorry that you find git flow so disgusting but I think your self-righteousness is completely unjustified.

Again, I don't know where you get this from. I don't find the model disgusting, I find it useful, but flawed. I don't know why you think suggesting these improvements justifies making remarks about my character.

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branch at all? If your goal is to have an easy answer to "what's the latest release?", you have the tags for that in any case. Or if you really want to have a whole branch just to double-solve that one use-case, why not make a "release-tags" branch for that, instead of demoting the master/main branch to that role, when it already has a widely used, different meaning?

It's a pity that such a weird artifact/choice has made its way into a branching model that has become so widely implemented. Especially when the rest of it is so sensible - the whole "feature-branch, release-branch, hotfix" flow is IMO exactly right for versioned software where you must support multiple released versions of it in the wild (and probably the reason why it's become so popular). I just wish it didn't have that one weirdness marring it.