5 ms·

It just depends on what you are doing. A green field react app in typescript with a CRUD API behind? The LLMs are a mind blowing assistant and 1000t/s is crazy.

by dust42 11mo ago

It just depends on what you are doing. A green field react app in typescript with a CRUD API behind? The LLMs are a mind blowing assistant and 1000t/s is crazy. You are doing embedded development or anything else not as mainstream as web dev? LLMs are still useful but no longer mind blowing and often produce hallucinations. You need to read every line of their output. 1000t/s is crazy but no longer always in a good way. You are doing stuff which the LLMs haven't seen yet? You are on your own. There is quite a bit of irony in the fact that the devs of llama.cpp barely use AI - just have a look at the development of support for Qwen3-Next-80B [1]. [1] https://github.com/ggml-org/llama.cpp/pull/16095 https://github.com/ggml-org/llama.cpp/pull/16095

almostgotcaught 11mo ago
I've said it before but no one takes it seriously: LLMs are only useful if you're building something that's already in the training set ie already commodity. In which case why are you building it???
- whiterook6 11mo ago
  It's not that the product you're building is a commodity. It's that the tools you're using to built it are. Why not build a landing page using HTML and CSS and tailwind? Why not use swift to make an app? Why not write an AWS lambda using JavaScript?
- mythz 11mo ago
  "LLMs are only useful..." Is likely why no one takes you seriously, as it's a good indication you don't have much experience with them.
  - deleted 11mo ago
    [deleted]
- nurettin 11mo ago
  Do you avoid writing anything that the programming community has ever built? How are you alive???
- antonvs 11mo ago
  The obvious point that you're missing is that there are literally infinite ways to assemble software systems from the pieces that an LLM is able to manipulate due to its training. With minor guidance, LLMs can put together an unlimited number of novel combinations. The idea that the entire end product has to be in the training set is trivially false.
- becquerel 11mo ago
  Because I'm getting paid to.
- philipp-gayret 11mo ago
  It's true, when I was working with LLMs on a novel idea it said sorry I can't help you with that!
- dboreham 11mo ago
  Historically big AI skeptic here: what you say is very not true now. LLMs aren't just regurgitating their training data per se. I've used LLMs on languages the LLM has not seen, and it performed well. I've used LLMs on code that is about as far from a React todo app as it's possible to get.
- energy123 11mo ago
  Bell Labs should have fired all their toilet cleaners. Nothing innovative about a toilet.
lifthrasiir 11mo ago
There aren't many things that LLMs haven't really seen yet, however. I have successfully used LLMs to develop a large portion of WebAssembly 3.0 interpreter [1], which surely aren't in their training set because WebAssembly 3.0 was only released months ago. Sure, it took me tons of guidance but it was useful enough for me. Even llama.cpp is not a truly novel thing to LLMs, there are several performant machine learning model executors available in their training sets anyway, and I'm sure llama.cpp can benefit from LLMs if they want; they just chose not to. [1] https://github.com/lifthrasiir/wah/ https://github.com/lifthrasiir/wah/
koito17 11mo ago
> You are doing embedded development or anything else not as mainstream as web dev? LLMs are still useful but no longer mind blowing and often produce hallucinations. I experienced this with Claude 4 Sonnet and, to some extent, gpt-5-mini-high. When able to run tests against its output, Claude produces pretty good Rust backend and TypeScript frontend code. However, Claude became borderline unproductive once I started experimenting with uefi-rs. Other LLMs, like gpt-5-mini-high, did not fare much better, but they were at least capable of admitting lack of knowledge. In particular, GPT-5 would provide output akin to "here is some pseudocode that you may be able to adapt to your choice of UEFI bindings". Testing in a UEFI environment is quite difficult; the LLM can't just run `cargo test` and verify its output. Things get worse in embedded, because crates like embedded_hal made massive API changes between 0.2 and 1.0 (the latest version), and each LLM I've tried seems to only have knowledge of 0.2 releases. Also, for embedded, forget even thinking about testing harnesses (which at least exist in some form with UEFI, it's just difficult to automate the execution and output for an LLM). In this case, you cannot really trust the output of the LLM. To minimize risk of hallucination, I would try maintaining data sheets and library code in context, but at that point, it took more time to prompt an LLM than handwrite code. I've been writing a lot of embedded Rust over the past two weeks, and my usage of LLMs in general decreased because of that. Currently planning to resume development on some of my "easier" projects, since I have about 300 Claude prompts remaining in my Zed subscription, and I don't want them to go to waste.
- RealityVoid 11mo ago
  > Also, for embedded, forget even thinking about testing harnesses (which at least exist in some form with UEFI, it's just difficult to automate the execution and output for an LLM). I think this doesn't have to be like this and we can do better for this. If LLMs keep this up, good testing infrastructure might become more important.
  - koito17 11mo ago
    One of my expectations for the future is the development of testing tools whose output is "optimized" in some way for LLM consumption. This is already occurring with Bun's test runner, for instance.[0] They are implementing a flag in the test runner so that the output is structured and optimized for token count. Overall, I agree with your point. LLMs feel a lot more reliable when a codebase has thorough, easy-to-run tests. For a similar reason, I have been drifting towards strong, statically-typed languages. Both Rust and TypeScript have rich type systems that can express many kinds of runtime behavior with just types. When a compiler can make strong guarantees about a program's behavior, I assume that helps nudge the quality of LLM output a bit higher. Tests then help prevent silly regressions from occurring. I have no evidence for this besides my anecdotal experience using LLMs across several programming languages. In general, I've had the best experience with LLMs when there's plenty of static analysis (and tests) on the codebase. When a codebase can't be easily tested, then I get much less productivity gains from LLMs. So yeah, I'm all for improving testing infrastructure. [0] https://x.com/jarredsumner/status/1944948478184186366 https://x.com/jarredsumner/status/1944948478184186366
RealityVoid 11mo ago
> You are doing embedded development or anything else not as mainstream as web dev? Counterpoint, but also kind of reinforcing your point. It depends on the kind of embedded development. I did a small utility PCB with an ESP32, and their libs are good there is active community, they have test frameworks. LLM's did a great job there. On the other hand, I wanted to drive a timer and a pwm module and a DMA dma engine to generate some precise pulses. The way I chained hw was... Not typical, but it was what I needed and the hw could do it. At that, Claude failed miserably and it only led me to waste my time, so I had to spend the time to do it manually.
deleted 11mo ago
[deleted]

by dust42 11mo ago

almostgotcaught 11mo ago

I've said it before but no one takes it seriously: LLMs are only useful if you're building something that's already in the training set ie already commodity. In which case why are you building it???

whiterook6 11mo ago
It's not that the product you're building is a commodity. It's that the tools you're using to built it are. Why not build a landing page using HTML and CSS and tailwind? Why not use swift to make an app? Why not write an AWS lambda using JavaScript?
mythz 11mo ago
"LLMs are only useful..." Is likely why no one takes you seriously, as it's a good indication you don't have much experience with them.
- deleted 11mo ago
  [deleted]
nurettin 11mo ago
Do you avoid writing anything that the programming community has ever built? How are you alive???
antonvs 11mo ago
The obvious point that you're missing is that there are literally infinite ways to assemble software systems from the pieces that an LLM is able to manipulate due to its training. With minor guidance, LLMs can put together an unlimited number of novel combinations. The idea that the entire end product has to be in the training set is trivially false.
becquerel 11mo ago
Because I'm getting paid to.
philipp-gayret 11mo ago
It's true, when I was working with LLMs on a novel idea it said sorry I can't help you with that!
dboreham 11mo ago
Historically big AI skeptic here: what you say is very not true now. LLMs aren't just regurgitating their training data per se. I've used LLMs on languages the LLM has not seen, and it performed well. I've used LLMs on code that is about as far from a React todo app as it's possible to get.
energy123 11mo ago
Bell Labs should have fired all their toilet cleaners. Nothing innovative about a toilet.

lifthrasiir 11mo ago

There aren't many things that LLMs haven't really seen yet, however. I have successfully used LLMs to develop a large portion of WebAssembly 3.0 interpreter [1], which surely aren't in their training set because WebAssembly 3.0 was only released months ago. Sure, it took me tons of guidance but it was useful enough for me. Even llama.cpp is not a truly novel thing to LLMs, there are several performant machine learning model executors available in their training sets anyway, and I'm sure llama.cpp can benefit from LLMs if they want; they just chose not to. [1] https://github.com/lifthrasiir/wah/ https://github.com/lifthrasiir/wah/

koito17 11mo ago

> You are doing embedded development or anything else not as mainstream as web dev? LLMs are still useful but no longer mind blowing and often produce hallucinations. I experienced this with Claude 4 Sonnet and, to some extent, gpt-5-mini-high. When able to run tests against its output, Claude produces pretty good Rust backend and TypeScript frontend code. However, Claude became borderline unproductive once I started experimenting with uefi-rs. Other LLMs, like gpt-5-mini-high, did not fare much better, but they were at least capable of admitting lack of knowledge. In particular, GPT-5 would provide output akin to "here is some pseudocode that you may be able to adapt to your choice of UEFI bindings". Testing in a UEFI environment is quite difficult; the LLM can't just run `cargo test` and verify its output. Things get worse in embedded, because crates like embedded_hal made massive API changes between 0.2 and 1.0 (the latest version), and each LLM I've tried seems to only have knowledge of 0.2 releases. Also, for embedded, forget even thinking about testing harnesses (which at least exist in some form with UEFI, it's just difficult to automate the execution and output for an LLM). In this case, you cannot really trust the output of the LLM. To minimize risk of hallucination, I would try maintaining data sheets and library code in context, but at that point, it took more time to prompt an LLM than handwrite code. I've been writing a lot of embedded Rust over the past two weeks, and my usage of LLMs in general decreased because of that. Currently planning to resume development on some of my "easier" projects, since I have about 300 Claude prompts remaining in my Zed subscription, and I don't want them to go to waste.

RealityVoid 11mo ago
> Also, for embedded, forget even thinking about testing harnesses (which at least exist in some form with UEFI, it's just difficult to automate the execution and output for an LLM). I think this doesn't have to be like this and we can do better for this. If LLMs keep this up, good testing infrastructure might become more important.
- koito17 11mo ago
  One of my expectations for the future is the development of testing tools whose output is "optimized" in some way for LLM consumption. This is already occurring with Bun's test runner, for instance.[0] They are implementing a flag in the test runner so that the output is structured and optimized for token count. Overall, I agree with your point. LLMs feel a lot more reliable when a codebase has thorough, easy-to-run tests. For a similar reason, I have been drifting towards strong, statically-typed languages. Both Rust and TypeScript have rich type systems that can express many kinds of runtime behavior with just types. When a compiler can make strong guarantees about a program's behavior, I assume that helps nudge the quality of LLM output a bit higher. Tests then help prevent silly regressions from occurring. I have no evidence for this besides my anecdotal experience using LLMs across several programming languages. In general, I've had the best experience with LLMs when there's plenty of static analysis (and tests) on the codebase. When a codebase can't be easily tested, then I get much less productivity gains from LLMs. So yeah, I'm all for improving testing infrastructure. [0] https://x.com/jarredsumner/status/1944948478184186366 https://x.com/jarredsumner/status/1944948478184186366

RealityVoid 11mo ago

> You are doing embedded development or anything else not as mainstream as web dev? Counterpoint, but also kind of reinforcing your point. It depends on the kind of embedded development. I did a small utility PCB with an ESP32, and their libs are good there is active community, they have test frameworks. LLM's did a great job there. On the other hand, I wanted to drive a timer and a pwm module and a DMA dma engine to generate some precise pulses. The way I chained hw was... Not typical, but it was what I needed and the hw could do it. At that, Claude failed miserably and it only led me to waste my time, so I had to spend the time to do it manually.

deleted 11mo ago

[deleted]