selridge

This is correct. They will A/B test titles AND update the title w/o warning over time, often 3-6 times per article post publication.

They used to change the URL a bunch of times after publication! Seems crazy because it is but they did. Caused a whole problem on Wikipedia because “title + day + work + url” suddenly wasn’t stable.

This is the way. Gl; hf.

And being willing to be wrong and to be misled; finding ways to contain that or build forcing functions against it.

In a strange way that's exciting, because it forces me to learn. And sometimes forces me to confront whether stuff I had was domain knowledge or portable as experience.

We DEEPLY do not.

That's not, IMO, a "skills go down" position. It's respecting that this is a bigger maybe than anyone in living memory has encountered.

We do automate lots about flying, not just take-off and landing. It's why a 4-engine aircraft in the 1960s required flight crews of 6-8 people just to fly the thing when they can be routinely flown with 2-3 today.

Precisely, especially because habits have been bound up in the high (and difficult to measure!) cost of code. We got precious about it, really.

Here is what I said:

“ This shift is an analogous to how we took having to do computer arithmetic out of the hands of programmers in the 80s. There used to be a substantial part of programming that was just a computer arithmetic. Now, almost nobody does that. Nobody in this thread could build a full adder if their life depended on it or produce an accurate sin function.”

It is truly not my fault that you proceeded to lecture me for multiple posts just to reach the conclusion that I SET OUT FOR YOU: standardization of computer arithmetic is good and makes it so that someone doing math on a computer doesn’t need to become an expert on how the computer does math.

As I said when you first insinuated yourself: I don’t need your help to be an engineer or a developer, thank you. You persisted anyway and embarrassed yourself.

Who is this we, kemosabe?

Looks really cool. Thank you for sharing!

I said this situation is reminiscent of how we took computer arithmetic out of the hands of programmers in the 80s and you gave me a big lecture about how easy it was to make your own sine function which concluded in you explaining that every computer (mostly) uses IEEE floats.

No shit.

What do you think we did in the 1980s to take computer arithmetic away from working programmers? We standardized computer arithmetic so instead of needing a numerical analyst on hand you just need to read that Goldberg article you’ll run off to Google now.

You live in the land of milk and honey and you dare lecture someone about effort. You have absolutely no clue what world we left behind, but you’re happy to talk about who is and isn’t learning.

"Oh, IEEE 754 double precision floating point accuracy?"

Ok, so we do agree! You DON'T want to go back to a system where everyone had to do their own arithmetic just to make a program! That's fabulous. I'm glad that we're in agreement.

It's it SO MUCH NICER to just have the vagaries of one arithmetic we've already agreed upon to deal with, instead of needing to become an expert in numerical analysis just to get along with things.

>This is exactly why API-level access matters more than consumer subscriptions for production workloads. Consumer plans are subsidized with the assumption of interactive, low-volume usage. The moment you programmatically route through them, you break the economic model they're built on.

EXACTLY.

Google also did this when DALL-E Mini and Stable Diffusion got big.

On whose arithmetic?

You’re just showing me the blackboard approximation. How about just on x86? What are the bounds and how do you know?

It's just a category of an error of a piece.

You can't conclude anything reliably from their choice of electron over native apps. You can't. You can ASSERT things like the author does, like "The state of coding agents can be summed up by this fact: Claude spent $20k on an agent swarm implementing (kinda) a C-compiler in Rust, but desktop Claude is an Electron app." That's a fine assertion. It's just not a fact or knowledge about any kind of design decision.

The whole argument revolves around knowing that electron is a compromise because one could just make multiple native apps without asking if "make multiple native apps" serves a design need the developers had at all! If the developers (like many others who use electron) did not declare "we want to make native apps" or have a need that caused that to become a desire, then inferring that using electron is a compromise at all is groundless. It may never have been a compromise to begin with!

He's quite good sometimes. But we don't always need to reach for that kind of writing if we struggle. If you want something from that era which is written by a young man who is trying to set the world on fire, you should try: https://en.wikipedia.org/wiki/Preliminary_Discourse_to_the_E...

This dude, Diderot, is gonna make a new encyclopedia of the world with his friends which breaks the monopoly on printed and well-regarded learning that was held by the traditional humanities. He wanted articles about the trades, about objects and engineered things, and he was PISSED OFF that he had to fight for it.

Is this guy's idea of how to organize knowledge "right"? Probably not. Will it light your brain on fire and make you grumpy or nosy or suspicious about categories of knowledge that persist still? YEAH.

Was it a good thing for anyone writing software which included those things to need to not only work out how they are on a blackboard but how they are on the real machine in question? And how they are on the next machine over?

Do you yearn to return to that world? I suspect most people don't. It's not just knowing your own machine, but any machine the code could run on. It's also not just reaching for some 2nd year bachelor topics when the matter at hand is much more complicated. Where does your sine approximation fail? How do you know? Can you prove that? Does the compiler or the hardware decide to do things behind your back which vitiate any of those claims?

Knowing the answer to that all every time you need a sine is not something 99.99% of engineers need to worry about. IT USED TO BE. But now it's not. No one is going back to that.

I mean the article is pretty short. And what it implies presents itself in the subtitle! It opens with a "fact" (a link to the author's own tweet) which says:

"The state of coding agents can be summed up by this anecdote:

Claude spent $20k on an agent swarm implementing (kinda) a C-compiler in Rust, but desktop Claude is an Electron app."

We haven't made it 100 words in and we already have the core claim. In case we missed it, the author puts it in an inset later:

>So why are we still using Electron and not embracing the agent-powered, spec driven development future?

We get to the end where the author says:

"For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern."

That's both true and and misleading. It's misleading because we can all agree with this sober-minded concluding statement and forget it's just based on "Electron bad, native good". The real logical sequence the author needs us to follow is:

Anthropic said code is free now. > Native code is harder than that for a cross platform runtime > Anthropic releases an app on a cross-platform runtime > code must not be free.

That is only true iff there's absolutely no other design tradeoff! Did they pick electron because robots are bad at the last mile? Maybe. It's pretty dubious, given the MANY MANY other people who made electron apps before AI could code. It's also not at all clear "native good, electron bad" is true at all. It reminds me STRONGLY of "jQuery bad / native good" which was also groundless.

Markedly better than six months ago.

We are in this super weird space where the comparable tasks are one-shot, e.g. "make me a to-do app" or "check these binaries", but any real work is multi-turn and dynamically structured.

But when we're trying to share results, "a talented engineer sat with the thread and wrote tests/docs/harnesses to guide the model" is less impressive than "we asked it and it figured it out," even though the latter is how real work will happen.

It creates this perverse scenario (which is no one's fault!) where we talk about one-shot performance but one-shot performance is useful in exactly 0 interesting cases.

This is really cool! Thanks for sharing. It's a lot more sophisticated than what I did w/ Ghidra + LLMs.

I also did this approach (scripts + home-brew cli)...because I didn't know Ghidra MCP servers existed when I got started.

So I don't have a clear idea of what the comparison would be but it worked pretty well for me!

>While end-to-end malware detection is not reliable yet, AI can make it easier for developers to perform initial security audits. A developer without reverse engineering experience can now get a first-pass analysis of a suspicious binary. [...] The whole field of working with binaries becomes accessible to a much wider range of software engineers. It opens opportunities not only in security, but also in performing low-level optimization, debugging and reverse engineering hardware, and porting code between architectures.

THIS is the takeaway. These tools are allowing *adjacency* to become a powerful guiding indicator. You don't need to be a reverser, you can just understand how your software works and drive the robot to be a fallible hypothesis generator in regions where you can validate only some of the findings.

They are compute constrained and they have tens of millions of dollars of free cash flow. They could’ve written that app in COBOL for God sake.

What are we to presume from the fact that they did not do that?

> "Did you check?" is the most expensive question, and one of the most feared in my experience in tech circles.

Here it’s a climb-down. Writing tests to validate translation is orders of magnitude less work (and less likely to fail or be too dull to do properly) than the alternative available prior to 2025.

The fact that they wrote tests and clearly established operational control is not some kinda gotcha! It’s how they managed to get this piece of technology to allow them to do the IMPOSSIBLE.

I am just really struggling to understand someone who reads that paper and thinks “yup, everything is still the same and we don’t need to re-evaluate any ideas” Like, if you want to say that they still need engineering discipline in order to do ISA transitions at scale then…ok? That’s true? But Gemini meant that this formerly impossible thing was now not only within reach but done.

That’s hard. Sometimes you will do that and find it prompts the model into “strategy talk” where it deploys the words and frame you use in your .md files but doesn’t actually do the strategy.

Even where it works, it is quite hard to specify human strategic thinking in a way that an AI will follow.

What does any of this have to do with choosing an electron app over a native app?

What does any of the malaise about discord have to do with their choice of runtime?

It is an untested hypothesis that if discord had a native app, all the problems that people complain about would disappear. I think people in hacker news like to just assert the hypothesis because sounds better than cross platform. But in this particular case, it is fundamentally untested. We simply don’t know that the app would be better if it were native.

Oh damn. Dilbert dude died. Pour one out for someone other than him who deserves it.

> LLM prompts and responses, if not automatically logged, can easily be automatically logged.

What will you do with what you’ve logged? Where is “the prompt” when the chat is a chat? What prompt “made” the software?

If you’re assuming that it is prompt > generation > release, that’s not a correct model at all. The model is *much* closer to conversations between engineers which you’ve indicated would be burdensome to log and noisy to review.

Is teams bad because it’s an electron app?

And how does the answer to your question bear on the claim I’m making?