91–100 of 336 posts
Isn’t that ChatGPT’s internal MCP tools?
Here's a full list which looks accurate to me: https://chatgpt.com/share/6977ffa0-df14-8006-9647-2b8c90ccbb...
Earlier quoted context omitted.
> 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
NP (as in P = NP) is also much lower for Python than Rust on the human side.
Earlier quoted context omitted.
NP (as in P = NP) is also much lower for Python than Rust on the human side.
What does that mean? Can you elaborate?
At that point, the legibility and prevalence of humans who can read the code becomes almost more important than which language the machine "prefers."
Earlier quoted context omitted.
By lines of code, almost by an order of magnitude. Some of the code is janky garbage, but that’s what most code it. There’s no use pearl clutching. Human engineering time is better spent at figuring out which problems to solve than typing code token by token. Identifying what to work on, and why, is a great research skill to have and I’m glad we are getting to realistic technology to make that a baseline skill.
Well, you will somehow have to turn that 'janky garbage' into quality code, who will do that then?
the next version of LLMs. write with GPT 5.2 now, improve the quality using 5.3 in a couple months; best of both worlds.
Earlier quoted context omitted.
I want to create a language that allows an LLM to dynamically decide what to do. A non dertermistic programing language, which options to drop down into JavaScript or even C if you need to specify certain behaviors. I'd need to be much better at this though.
You're describing a multi-agent long horizon workflow that can be accomplished with any programming language we have today.
Earlier quoted context omitted.
By lines of code, almost by an order of magnitude. Some of the code is janky garbage, but that’s what most code it. There’s no use pearl clutching. Human engineering time is better spent at figuring out which problems to solve than typing code token by token. Identifying what to work on, and why, is a great research skill to have and I’m glad we are getting to realistic technology to make that a baseline skill.
Well, you will somehow have to turn that 'janky garbage' into quality code, who will do that then?
The vast majority of code is garbage, and has been for several decades.
I wonder if the era of dynamic programming languages is over. Python/JS/Ruby/etc. were good tradeoffs when developer time mattered. 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 (assuming enough training data on the language ofc; LLMs still can't write Gleam/Janet/CommonLisp/etc.). Esp. with Go's quick compile time, I can see myself using it more and m…
> 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
Earlier quoted context omitted.
What does that mean? Can you elaborate?
Sorry, yes. LLMs write code that's then checked by human reviewers. Maybe it will be checked less in the future. But I'm not seeing fully-autonomous AI on the horizon. At that point, the legibility and prevalence of humans who can read the code becomes almost more important than which language the machine "prefers."
The future belongs to generalists!
Earlier quoted context omitted.
> 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
It's very good (in our experience, YMMV of course) when/llm write prototype with python and then port automatically 1-1 to Rust for perf. We write prototypes in JS and Python and then it gets auto ported to Rust and we have been doing this for about 1 year for all our projects where it makes sense; in the past months it has been incredibly good with claude code; it is absolutely automatic; we run it in a loop until a…
- Libraries don't necessarily map one-to-one from Python to Rust/etc.
- Paradigms don't map neatly; Python is OO, Rust leans more towards FP.
- Even if the code be re-written in Rust, it's probably not the most Rustic (?) approach or the most performant.
I wonder if the era of dynamic programming languages is over. Python/JS/Ruby/etc. were good tradeoffs when developer time mattered. 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 (assuming enough training data on the language ofc; LLMs still can't write Gleam/Janet/CommonLisp/etc.). Esp. with Go's quick compile time, I can see myself using it more and m…