[prisenco]

My question is why use AI to output javascript or python?

Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal?

If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction.

Which means its incapabilities in C and ASM don't disappear when using it for higher-level languages. They're still there, just temporarily smoothed over due to larger datasets.

[lynx97]

My small-program success story with genAI coding is pretty much the opposite of your claim. I used to use a bash script with a few sox instances piped into each other to beat-match and mix a few tracks. Couldn't use a GUI... Then came gpt-5, and I wanted to test it anyway. So I had it write a single-file C++ program that does the track database, offline mixing, limiter and a small REPL-based "UI" to control the thing. I basically had results before my partner was finished preparing breakfast. Then I had a lot of fun bikeshedding the resulting code until it felt like something I'd like to read. Some back and forth, pretending to have an intern and just reviewing/fixing their code. During the whole experience, it basically never generated code which wouldn't compile. Had a single segfault which was due to unclear interface to a C library. Got that fixed quickly.

And now, I have a tool to do a (shuffled if I want) beat-matched mix of all the tracks in my db which match a certain tag expression. "(dnb | jungle) & vocals", wait a few minutes, and play a 2 hour beat-matched mix, finally replacing mpd's "crossfade" feature. I have a lot of joy using that tool, and it was definitely fun having it made. clmix[1] is now something I almost use daily to generate club-style mixes to listen to at home.

[1] https://github.com/mlang/clmix

[headcanon]

One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal.

I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well.

I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.

[fud101]

Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.

[moron4hire]

I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?

[lelanthran]

We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.

It's going to take the same amount of time creating a program in C as it does in Python.

[tverbeure]

The premise of your question is wrong. I would still write Python for most of my tasks even if I were just as fast at writing C or ASM.

Because the conciseness and readability of the code that I use is way more important than execution speed 99% of the time.

I assume that people who use AI tools still want to be able to make manual changes. There are hardly any all or nothing paradigms in the tech world, why do you assume that AI is different?

[pona-a]

The promise of the original definition of vibe coding was you treating code as disposable, no more valuable than LLVM build cache.

You aren't supposed to make corrections, review it, or whatever.

[simonw]

They've got good at C now. I can't speak for ASM.

Here's a C session that I found quite eye-opening the other day: https://gisthost.github.io/?1bf98596a83ff29b15a2f4790d71c41d...

[nl]

I had it write a new stdlib implementation (wasm<->JS) for a custom web based fantasy console I'm writing.

It did ok at that.

We'll - Doom runs so ok enough for what I wanted anyway.

No, it's not a copy of other WASM stdlib implementations.

[danielmarkbruce]

It cuts to training data and effort. A lot of effort has been put in to optimize for python, even down to tokenization.

[mrocklin]

If you read on in the post you might be interested in the section titled

Drop Python: Use Rust and Typescript

https://matthewrocklin.com/ai-zealotry/#big-idea-drop-python...

[kermatt]

Isn't it also because LLMs are trained on existing software, and the programs we would write in Python or JS have few examples in C ?

[albedoa]

Yes. That is what the commenter means by "mechanical reproduction" and "temporarily smoothed over due to larger datasets".

[Leynos]

I pretty much do most of my AI coding in Rust. Although I do still use Python or Typescript where appropriate.

[sph]

I don't get this. AI coders keep saying they review all the code they push, and your suggestion is to use even harder languages the average vibe coder is unable to understand, all in name of "performance"? Faster code maybe, and exponentially increasing the tech debt and amount of bugs that slips through.

It wasn't even long ago that we thought developer experience and capacity for abstraction (which is easier to achieve in higher level languages) was paramount.

[simonw]

> AI coders keep saying they review all the code they push

Those tides have shifted over the past 6 weeks. I'm increasingly seeing serious, experienced engineers who are using AI to write code and are not reviewing every line of code that they push, because they've developed a level of trust in the output of Opus 4.5 that line-by-line reviews no longer feel necessary.

(I'm hesitant to admit it but I'm starting to join their ranks.)

[wiseowise]

Because you want to modify those later instead of having read only blob?

[oneeyedpigeon]

Wouldn't the AI that wrote the original code be in a better position to modify it too?

[bflesch]

That's a very good example.