Well either way, the infosec folks are going to have the time of their lives printing write-ups and lots of money on both sides.

I can see the sandbox escapes, remote code exection paths, exfiltration methods and all the vibe coded sandcastles waiting to be knocked down because we have folks openly admiting that do not know a single line of code they are prompting to the AI.

I don't think we know the scale of the amout of security issues we will see because of the level of hubris there is with AI taking care of all of the coding.

How about Six PS6's

> But now that most code is written by LLMs

Am I in the Truman show? I don’t think AI has generated even 1% of the code that I run in prod, nor does anyone I respect. Heavily inspired by AI examples, heavily assisted by AI during research sure. Who are these devs that are seeing such great success vibecoding? Vibecoding in prod seems irresponsible at best

> But now that most code is written by LLMs, it's as "hard" for the LLM to write Python as it is to write Rust/Go

The LLM still benefits from the abstraction provided by Python (fewer tokens and less cognitive load). I could see a pipeline working where one model writes in Python or so, then another model is tasked to compile it into a more performant language

> But now that most code is written by LLMs

Got anything to back up this wild statement?

100% of my LLM projects are written in Rust - and I have never personally written a single line of Rust. Compilation alone eliminates a number of 'category errors' with software - syntax, variable declaration, types, etc. It's why I've used Go for the majority of projects I've started the past ten years. But with Rust there is a second layer of guarantees that come from its design, around things like concurrency, nil pointers, data races, memory safety, and more.

The fewer category errors a language or framework introduces, the more successful LLMs will be at interacting with it. Developers enjoy freedom and many ways to solve problems, but LLMs thrive in the presence of constraints. Frontiers here will be extensions of Rust or C-compatible languages that solve whole categories of issue through tedious language features, and especially build/deploy software that yields verifiable output and eliminates choice from the LLMs.

> But now that most code is written by LLMs

Is this true? It seems to be a massive assumption.

I generally use LLMs to generate Python (or TypeScript) because the quality and maintainability is significantly better than if I ask it to, for example, pump out C. They really do not perform very well outside of the most "popular" languages.

> Python/JS/Ruby/etc. were good tradeoffs when developer time mattered.

First I don't think this is the end of those languages. I still write code in Ruby almost daily, mostly to solve smaller issues; Ruby acts as the ultimate glue that connects everything here.

Having said that, Ruby is on a path to extinction. That started way before AI though and has many different reasons; it happened to perl before and now ruby is following suit. Lack of trust in RubyCentral as our divine new ruler is one (recently), after they decided to turn against the community. Soon Ruby can be renamed into Suby, to indicate Shopify running the show now. What is interesting is that you still see articles "ruby is not dead, ruby is not dead". Just the frequency of those articles coming up is worrying - it's like someone trying to pitch last minute sales - and then the company goes bankrupt. The human mind is a strange thing.

One good advantage of e. g. Python and Ruby is that they are excellent at prototyping ideas into code. That part won't go away, even if AI infiltrates more computers.

I have certainly become Go-curious thanks to coding agents - I have a medium sized side-project in progress using Go at the moment and it's been surprisingly smooth sailing considering I hardly know the language.

The Go standard library is a particularly good fit for building network services and web proxies, which fits this project perfectly.

I agree with this. Making languages geared toward human ergonomics probably won’t be a thing going forward.

Go is positioned really well here, and Steve Yegge wrote a piece on why. The language is fast, less bloated than Python/TS, and less dogmatic than Java/Kotlin. LLMs can go wham with Go and the compiler will catch most of the obvious bugs. Faster compilation means you can iterate through a process pretty quickly.

Also, if I need abstraction that’s hard to achieve in Go, then it better be zero-cost like Rust. I don’t write Python for anything these days. I mean, why bother with uv, pip, ty, mypy, ruff, black, and whatever else when the Go compiler and the standard tooling work better than that decrepit Python tooling? And it costs almost nothing to make my scripts faster too.

I don’t yet know how I feel about Rust since LLMs still aren’t super good with it, but with Go, agentic coding is far more pleasurable and safer than Python/TS.

> But now that most code is written by LLMs

I'm sure it will eventually be true, but this seems very unlikely right now. I wish it were true, because we're in a time where generic software developers are still paid well, so doing nothing all day, with this salary, would be very welcome!

Has anyone tried creating a language that would be good for LLMs? I feel like what would be good for LLMs might not be the same thing that is good for humans (but I have no evidence or data to support this, just a hunch).

My intuition from using the tools broadly is that pre-baked design decisions/“architectures” are going to be very competitive on the LLM coding front. If this is accurate, language matters less than abstraction.

Instructions files are just pre-made decisions that steer the agent. We try to reduce the surface area for nondeterminism using these specs, and while the models will get better at synthesizing instructions and code understanding, every decision we remove pays dividends in reduced token usage/time/incorrectness.

I think this is what orgs like Supabase see, and are trying to position themselves as solutions to data storage, auth, events etc within the LLM coding space, and are very successful albeit in the vibe coder area mostly. And look at AWS Bedrock, they’ve abstracted every dimension of the space into some acronym.

LLM should generate to terse and easy to read language for human to review. Beside Python, F# can be a perfect fit.

> But now that most code is written by LLMs...

Pause for a moment and think through a realistic estimation of the numbers and proportions involved.

The quality of the error messages matters a _lot_ (agents read those too!) and Python is particularly good there.

I'm not sure that LLMs are going to [completely] replace the desire for JIT, even with relatively fast compilers.

Frameworks might go the way of the dinosaur. If an LLM can manage a lot of complex code without human-serving abstractions, why even use something like React?

> LLMs still can't write Gleam

Have you tried? I've had surprisingly good results with Gleam.

I was also thinking this some days ago. The scaffolding that static languages provide is a good fit for LLMs in general.

Interestingly, since we are talking about Go specifically, I never found that I was spending too much typing... types. Obviously more than with a Python script, but never at a level where I would consider it a problem. And now with newer Python projects using type annotations, the difference got smaller.

Agree on compiled languages, wondering about Go vs Rust. Go compiles faster but is more verbose, token cost is an important factor. Rust's famously strict compiler and general safety orientation seems like a strong candidate for LLM coding. Go would probably have more training data out already though.

If you asked the LLM it's possible it would tell you Java is a better fit.

> assuming enough training data

This is a big assumption. I write a lot of Ansible, and it can’t even format the code properly, which is a pretty big deal in yaml. It’s totally brain dead.

> LLMs still can't write Gleam/Janet/CommonLisp/etc

hoho - I did a 20/80 human/claude project over the long weekend using Janet: https://git.sr.ht/~lsh-0/pj/tree (dead simple Lerna replacement)

... but I otherwise agree with the sentiment. Go code is so simple it scrubs any creative fingerprints anyway. The Clojure/Janet/scheme code I've seen it writing isn't _great_ but it gets the job done quickly and correct enough for me to return to it later and golf it some.

Peak LLM will be when we can give some prompt and just get fully compiled binaries of programs to download, no code at all.

People are still going to want to audit the code, at the very least.

I wouldn't speak so quickly for the 'uncommon' language set. I had Claude write me a fully functional typed erlang compiler with ocaml and LLVM IR over the last two days to test some ideas. I don't know ocaml. It made the right calls about erlang, and the result passes a fairly serious test suite, so it must've known enough ocaml and LLVM IR.

or maybe someone will use an LLM to create a JIT that works so well that compiled languages will be gone.

I think you're missing the reason LLMs work: It's cause they can continue predictable structures, like a human.

The surmise that compiled languages fit that just doesn't follow. The same way LLMs have trouble finishing HTML because of the open/close are too far apart.

The language that an LLM would succeed with is one where:

1. Context is not far apart

2. The training corpus is wide

3. Keywords, variables, etc are differentiated in the training.

4. REPL like interactivity allows for a feedback loop.

So, I think it's premature to think just because the compiled languages are less used because of human inabilities, doesn't mean the LLM will do any better.

Astronaut 1: You mean... strong static typing is an unmitigated win?

Astronaut 2: Always has been...

I love golang man! And I use it for the same thing too!!

I mean people mention rust and everything and how AI can write proper rust code with linter and some other thing but man trust me that AI can write some pretty good golang code.

I mean though, I don't want everyone to write golang code with AI of all of a sudden because I have been doing it for over an year and its something that I vibe with and its my personal style. I would lose some points of uniqueness if everyone starts doing the same haha!

Man my love for golang runs deep. Its simple, cross platform (usually) and compiles super fast. I "vibe code" but feel faith that I can always manage the code back.

(self promotion? sorry about that: but created golang single main.go file project with a timer/pomodoro with websockets using gorilla (single dep) https://spocklet-pomodo.hf.space/)

So Shhh let's keep it a secret between us shall we! ;)

(Oh yeah! Recently created a WHMCS alternative written in golang to hook up to any podman/gvisor instance to build your own mini vps with my own tmate server, lots of glue code but it actually generated it in first try! It's surprisingly good, I will try to release it as open source & thinking of charging just once if people want everything set up or something custom

Though one minor nitpick is that the complexity almost rises many folds between a single file project and anything which requires database in golang from what I feel usually but golang's pretty simple and I just LOVE golang.)

Also AI's pretty good at niche languages too I tried to vibe code a fzf alternative from golang to v-lang and I found the results to be really promising too!

> Plus, I get a binary that I can port to other systems w/o problem.

So cross-platform vibe-coded malware is the future then?

Absolutely, when people discover and share there's something fun to it beyond press releases and commentary. Creative and inspiring post

why would they do that?

Claude Code for the web is kind of a persistent virtual dev environment already.

You can start a session there and chat with it to get a bunch of work done, then come back to that session a day later and the virtual filesystem is in the same state as when you left it.

I haven't figured out if this has a time limit on it - it's possible they're doing something clever with object storage such that the cost of persisting those environments is really low, see also Fly's Sprites.dev: https://fly.io/blog/design-and-implementation/

I started building something for the dioxus team to have access to mac/linux persistent and ephemeral dev envs with vnc and beefy cpu/mem.

Nobody offered multiplatform and we really needed it!

https://skyvm.dev

> I wonder when they'll start offering virtual, persistent dev environments...

A lot of companies have been wanting to move in this direction. Instead of maintaining a fleet of machines, you just get a bunch of thin clients and pay Microsoft of whoever to host the actual workloads. They already do this 'kiosk' style stuff for a lot of front-line staff.

Honestly, not having my own local hardware for development sounds like a living hell, but seems like the way we are going.

As long as "don't roll your own crypto" is considered good advice, you'll have at least a few packages/libraries that'll need managing.

For a decent number of relatively pedestrian tasks though, I can see it.

At times I wonder why x tui coding agent was written in js/ts/python, why not use Go if it's mostly llm coded anyway? But that's mostly my frustration at having to wait for npm to install a thousand dependencies, instead of one executable plus some config files. There's also support libraries like terminal ui that differ in quality between platforms.

This is like saying Wikipedia doesn't make sense because there's now Grokipedia

best to write assembly instead.

I was able to install the D language compiler DMD by providing a .deb file.

https://chatgpt.com/share/69781bb5-cf90-800c-8549-c845259c33...

Shame no c# in that list

— Why are you launching nukes? No one asked you to obliterate humanity.

— You’re absolutely right. I should not have done that. Would you like me to help undo the launch?

— Yes! Quickly! Do it!

— <completely made up crap which does not work>

https://www.newyorker.com/cartoon/a16995

This regression seems to have happened in the past few days. I suspected it was hallucinating the run and confirmed it by by asking Gemini to output the current date/time. The UTC it was reported was in the future from my clock. Some challenging mathematics were generating wrong results. Gemini will acknowledge something is wrong if you push it to explain the discrepancies, but can't explain it.

You can already do this.

exe.dev (though there are alternatives like sprites.dev etc. too)

Can you share the transcript?

That might work! You would have to figure out how to get Whisper working in there but I'm sure that's possible with a bit of creativity concerning uploading files and maybe running a build with the available C compiler.

It appears to have 4GB of RAM and 56 (!?) CPU cores https://chatgpt.com/share/6977e1f8-0f94-8006-9973-e9fab6d244...

I still like ChatGPT for search more than Claude, though I think Claude may be catching up now. Gemini is getting good at search too (as you'd hope it would!)

codex ~= Claude code

It's one of the tools that are available to ChatGPT - they're not MCP tools because ChatGPT's implementation of tools pre-dates MCP, but they work effectively the same way.

Here's a full list which looks accurate to me: https://chatgpt.com/share/6977ffa0-df14-8006-9647-2b8c90ccbb...

No root. `pip` and `npm install` don't require it.

You can not use `sudo apt install` inside it.

They use gVisor, and other container isolation mechanisms: https://ryan.govost.es/2025/openai-code-interpreter/

Given that it's within a container on a remote server, does that matter?