wiremine

Nvidia selling more GPU's at the cost of it's datacenter business is pretty close to Kodak selling digital cameras at the cost of film.

This assumes a) AI is a zero-sum game, and b) we're actually talking about on-prem AI will replace cloud-based AI. I think neither statements are true.

AI is like compute: we'll need all sorts of it, in various sizes, everywhere. I'm sure Nvidia whats to own all the workloads.

On the other hand, I do think open weight, like open source, will win in general.

It might feel interesting, but it's sort of the crux of the issue. Average or below average prompts will produce average below-average results. The model can't make up for that.

Not saying every problem can or should be solved but AI, but mastery of the tools is kind of important when evaluating the tools. It's like complaining that vi or emacs is slow to use because of the bindings are complicated.

It's a good write up, but it's lacking some details, the most important one is: which Claude model was used?

The second issue is: what was tooling and the prompt approach?

(To be clear, I have no problem with the premise of the write up. But without some details like this, it's sort of like saying "I had a bad board on my deck, and my tape measure wasn't able to help me remove the nails. What a bad tape measure."

Music is about connecting to human emotions, not poor facsimiles of it

"art is in the eye of the beholder."

I listen to a lot of EDM, which can be very mechanical, but I personally have strong emotional connection to. I personally would welcome AI-generated music as an alternative to human-made.

To be clear: I do agree a "human-verified" system would be great, but I don't think it would be black and white. And I would guess that eventually AI music will be better than a lot of human made music.

I ran a fairly large experiment last week, and the token usage wasn't bad at all. What softs of use cases are you seeing large token usage by GLM 5.2?

I've been using GLM 5.2 extensively for the last few days. It is slower, and the lack of multimodality is a bummer.

But, it produces solid results for a fraction of the price. Worth checking out if you have the time.

One of my goto "tests" of a new frontier models is having it rebuild a programming language from scratch. For GLM 5.2 I had it rebuild the old Rebol language in Rust:

https://github.com/mhs/rebol-clone-glm-5.2

It did a fairly good job roughing in the language for a low token cost.

Nice! What are some hardware platforms that leverage these models?

This looks really interesting... I think I grok the basic value prop.

However, I'm confused on the open source vs. commercial offerings. How do they differ? How do they work together?

This is great advice, and I appreciate the opening sentence to frame it as a "yes, and" sort of situation. We took our teenagers to London and Paris last year (we're from the upper midwest in the states) and it was a joy to see them experience a) a different culture and b) art and architecture they never would have experienced otherwise.

But visiting local destinations is also such a joy. I'm a mile from one of the best BBQ joints in Michigan, in a "blink and you miss it" village. I try and make sure I don't take it for granted.

Oh thank you, I came here to make that joke. Great show.

I'm not sure, but it might be recursive: above-average managers can tell the difference, and so we won't need as many below-average managers. But this requires above-average leadership, and the market will need to reward those organizations.

You know, I hate that this is a world where I have to ask myself if this is LLM written because it is one of those patterns.

Lol, nope, I just sound that way. :-)

then what can we expect from AI steered by the sort of humans that produced poor quality code.

Great point, and I think that's my argument: above-average engineers can now produce more above average code. We don't need as many (any?) below-average developers moving forward.

The code they [LLMs] produce is often fine. It works. It passes tests. It might ship as-is.

I don't disagree, but I've been thinking about this a bit: a lot of _human_ written code was/is less-than-fine. And a lot of human devs didn't understand the context when they wrote it.

I'm not advocating that we fire devs, or evangelizing that LLms are awesome. But I do wish there was a slightly more honest take on the pre-LLM world: it's not just about cost reduction, it's about solving some long-term structural deficiencies of industry.

I totally agree: This feels like Claude Code created it. It's the new, AI version of "It was clearly built with Bootstrap"

As a cheese lover, I don't care too much. :-)

My first computer was a 486sx 25Mhz [1] The rig (tower, monitor, etc.) cost around $3,000. We got the SX instead of the DX because it was $500 cheaper. And I wanted a 16bit sound card. (Note that this is in 1992 dollars. Today it would cost over $7,000)

My parents didn't have a lot of money, but my great-grand father passed and they used some of the inheritance to buy the computer. I was instantly hooked. In hindsight I see how much of a gift my family gave me.

The announcement reminded me of article John Dvorak wrote around the same time. 1GB hard drives had just come out, and he asked what all the extra space would be used for. Even as a young teenager, I remember thinking how short sighted that comment was. That was before I realized how the tech press tends to get stuck in local optimizations, and can't understand the bigger picture.

It's all a good reminder that cutting edge today doesn't stay cutting edge very long, and the world figures out how to squeeze every ounce ounce of power out of hardware. (Also, yes, that leads to bloat...)

[1] https://en.wikipedia.org/wiki/I486SX

[2] https://en.wikipedia.org/wiki/John_C._Dvorak

Oh, man, does that bring back the memories!

Thanks for sharing. :-)

This. My daughter is a high-school junior, and she's been asking for a laptop going into her senior year/college. This is exactly who Apple is going after.

That it has no fans or the fans are annoying?

I like the creativity, but I'm not sure it's needed. I've been building a large-scale database system using Opus 4.5, and targeting Rust. It's not perfect, but the Rust compiler is so helpful that Opus has solved a lot of problems on its own. I have around 100,000 lines of code, and have completed some major refactoring.

I am using a variation of spec-driven development.

This is pretty close. I once spent 4 hours in college (circa 1997) looking for an error in a C++ program. The compiler's error messages were rubbish.

It ended up being a missing semicolon in an odd spot and the compiler was just confused.

I remember walking homing thinking, "hey, if I can survive that, maybe I can just hack this CS thing..."

That's a good analogy.

To clarify my question: Based on my experience (I'm a VP for a software department), LLMs can be useful to help a team build a theory. It isn't, in and of itself, enough to build that theory: that requires hands-on practice. But it seems to greatly accelerate the process.

I suspect that there is a strong correlation between programmers who don't think that there needs to be a model/theory, and those who are reporting that LLMs are speeding them up.

I also strongly agree with Lamport, but I'm curious why you don't think Ai can help in the "theory building" process, both for the original team, and a team taking over a project? I.e., understanding a code base, the algorithms, etc.? I agree this doesn't replace all the knowledge, but it can bridge a gap.

The problem domain and programming language(s) used for a particular project may have a large impact on how effective the AI can be.

100%. Again, if we only focus on things like context windows, we're missing the important details.

Having spent a couple of weeks on Claude Code recently, I arrived to the conclusion that the net value for me from agentic AI is actually negative.

For me it’s meant a huge increase in productivity, at least 3X.

How do we reconcile these two comments? I think that's a core question of the industry right now.

My take, as a CTO, is this: we're giving people new tools, and very little training on the techniques that make those tools effective.

It's sort of like we're dropping trucks and airplanes on a generation that only knows walking and bicycles.

If you've never driven a truck before, you're going to crash a few times. Then it's easy to say "See, I told you, this new fangled truck is rubbish."

Those who practice with the truck are going to get the hang of it, and figure out two things:

1. How to drive the truck effectively, and

2. When NOT to use the truck... when talking or the bike is actually the better way to go.

We need to shift the conversation to techniques, and away from the tools. Until we do that, we're going to be forever comparing apples to oranges and talking around each other.

Another useful approach is to "cheat" and point the LLM at an existing code base that implements the algorithms or patterns you want. Something like:

"Review <codebase> and create a spec for <algorithm/pattern/etc.>"

It gives you a good starting point to jump off from.

As mentioned in the article, the big trick is having clear specs

I've been building a programming language using Claude, and this is my findings, too.

Which, after discovering this, makes sense. There are a LOT of small decisions that go into programming. Without detailed guidance, LLMs will end up making educated guesses for a lot of these decision, many of which will be incorrect. This creates a compounding effect where the net effect is a wrong solution.

Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to.

I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.

I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.

Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!

knowledge just isn't needed anymore

I would argue we still need the knowledge: the principles aren't changing, and they are needed to be truly productive in certain things. But the application of those principles _are_ changing.

I've been experimenting with model-based development lately, and this resonated strongly with me.

The section "What Even Is Programming Anymore?" hit on a lot of the thoughts and feels I've been going through. I'm using all my 25+ years of experience and CS training, but it's _not_ programming per se.

I feel like we're entering an era where we're piloting a set of tools, not hand crafting code. I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse. We'll still need to craft things by hand, but we're opening some doors to new methodologies.

And, right now, those methodologies are being discovered, and most of us are pretty bad at them. But that doesn't mean they're not going to be part of the industry.