It seems like their long term bet is that people who use LLMs to build in the niceties and extra polish will attract more customers, and the race to do this increases overall usage. As if they're saying "subscribe or your competition will eat your lunch".
And until the cost of running LLMs exceeds the cost of someone's salary, people will continue their subscriptions.
But they do more than enable the superfluous add-ons, and have been inserting themselves as being mission critical in securing software. "Subscribe. Or else!"
I'm locally hosting variants of Qwen and Gemma 4. I've also tried inference services such as baseten and novita, but wasn't satisfied with inconsistency in performance and pricing.
For software dev, I primarily use my own harness/orchestrator (that I shared recently), and sometimes Pi. I switched away from Cline + VS Code primarily because code is being generated so fast that I needed to optimize for review.
My harness is modeled similar to my day job: dev team works on stories, tracked on a kanban, and I'm a code-review gate. For example I scrutinize control surfaces, but instead of reviewing the implementation: I skim it and ask questions.
Every now and then I check to see if other harnesses have what I'm looking for, but none seem to have a combination of:
- Strong sandbox
- Particular UX (for mobile, code-review, basic IDE, and task management)
- Code checkpoints
- Great compatibility with local models
Napkin math comparing a cluster with a single latest gaming GPU at a generous ~200t/s shows that the cluster pushes about 9 million times more tokens per day. And the cluster runs a more powerful model.
While everyone gets to act like a PE, I'd encourage junior engineers to build a pet project manually. Primarily to develop the skill to know "where to ask for the details".
Or maybe keep manual coding to build confidence, so that one can say "I've done that before..." and be able defend or take apart a particular strategy.
This is interesting advice. When I was coming up as a sysadmin, the advice was always "run a home lab it's the best way to learn all the details". So I did and it was helpful.
But you never heard someone say "you should still code in assembly so you can understand what your compiler is doing".
Is this more like case one or case two? Will it matter if you understand in a few years?
But you never heard someone say "you should still code in assembly so you can understand what your compiler is doing".
Would I routinely code in assembly today? Not for (almost) any new project.
Can I understand assembly and have I used that skill to understand performance problems or debug unexpected behaviour (including some that really did turn out to be caused by bugs in popular compilers)? Absolutely.
I'm not generally a fan of the comparison between what LLMs do and what compilers do. Compilers might vary in their output for given source code but they still follow (hopefully) well-defined specifications. Their behaviour is deterministic and the behaviour of their output is deterministic. With sufficient understanding you can reason about that output or diagnose faults in the compiler behaviour if you ever need to. None of this is true for LLMs.
Neither are compilers? But you still trust your JIT compiler. Determinism is unimportant, likelihood of correctness is what matters. Plus agents are deterministic, no?
Even if we accept your premise that the likelihood of correctness of more important I still don't think that the two scenarios are similar. I have seen more incorrect outputs from LLMs in the past week than I have seen incorrect outputs due to compiler bugs in my entire career. And without determinism there is no way to be sure that ratio will ever change.
I'm not sure. That is also my experience, but I'm not completely sure that isn't my fault and the compiler comparison would be totally valid if I just used the tool better. When I actually write fully fleshed out specifications and have the LLM handle the implementation, I rarely encounter bugs.
I don't think I've seen a Sol 5.6 or later model fail at a task with a verifiable outcome.
It's when I try to do too little of the defining that I get LLM bugs. In which case maybe programming hasn't changed that much, LLMs really can be reliable compilers, and we're all just being lazy.
You can debug a compiler. If an LLM writes code you don't like, how would you debug that? You wouldn't. You'd just ask again and hope it does a better job.
Not 1 in 1000 software engineers has the ability to debug a compiler. And you can absolutely debug agent failures, but similarly almost no does. In both cases for the mast majority of engineers, they are black boxes.
Could you go into more detail about how you'd debug LLM output?
I don't really care about what "most engineers" do. I did phrase it lazily but I am trying to point out something fundamental about LLMs and compilers.
You look at the inputs to the model at the trace level to root cause context construction vs model deficiency. You collect examples of the failure cases, build eval sets, and run ablations. That's black box debugging, but systematic debugging nonetheless.
I mean debugging within the model, not the harness. Harnesses are software like any other.
The model itself is more or less a black box - if tokens come out that you don't like, it seems like there's no equivalent to "this LLVM release fixed a code generation issue on platform X relating to situation Y".
I'm not sure why people are so motivated to say these are the same thing when they are clearly not.
And yes, rigorous approaches can be taken to systems built on and with LLMs, as you say. That doesn't make them the same as compilers.
Why is an LLVM release any different than a frontier model release? Well known, concrete issues get identified, evaluated against, RLVR'd on, and a new release comes out that doesn't have that issue. Or you can do that process yourself on an open-source model if you have the resources.
LLMs are not magic things that are out of your control, they are simply complicated. But there are concrete issues that are identified, people sit down and decide to fix it, build evals, run ablations, and they produce a model without that deficiency. It happens every day.
Would you reject the characterisation of model weights as a black box then?
I suppose if LLVM's source code has a similar size in bytes then it would be similarly difficult to work with. However, it would still remain source code readable by a human, not binary data with no semantic content when examined plainly.
Yeah... my program covered basically everything from raw theory to architecture to assembly up to [insert n others] Python and Haskell.
But it was a CS program, not a SWE program, the two of which the industry has confused for all of time (though there was an actual Software Engineering course offered as well).
https://www.youtube.com/@MoritzKlein0 has revolutionized my understanding of audio signal processing in software. Understanding what the voltages do is absolutely amazing.
i spent a few weeks coding assembly at the beginning of my career. really enjoyed it and feel like it helped me understand CPUs a lot better. i'd still recommend it to early career engineers
Exactly. This is only needed in the early days IMO, unless your work doesn't require the understanding of such low-level features or you enjoy doing it.
You should only have a high-level understanding and be able to orchestrate things, plan, and make choices. AI do the details.
Coding in assembly is absolutely fantastic for understanding how programs execute, and different chip architectures.
It's also a lot of fun to do on tiny 8 bit microcontrollers like the AVR. It's really neat to be able to understand exactly how many clock cycles some code will use. This came in super handy for me once when I wrote a small bit-banging serial interface and had to debug why some characters would randomly be wrong.
But you never heard someone say "you should still code in assembly so you can understand what your compiler is doing".
That's true but a similar advice that is given to junior developers in their early career is to actually reinvent the wheel, so that they can learn from the pain and then rip the profits of using reusable components. That's unvaluable. You have to read through thousands of lines of code and write some more yourself to get good at programming.
Both provide first-hand perspective though, which is hard to gain unless practiced.
Advice about a homelab might be more more common since it's more practical. I'd also value the opportunities it presents for general experience. For example when running a homelab you're organizing and putting together systems, or maybe balancing resource management and budgeting to find the right hardware.
The specific details probably won't matter in the long run (except maybe during a certain flavor of trivia night). But I think having some knowledge about what came before helps build intuition about how new things are put together, which makes a lot of tech look less like magic and more personally achievable.
I like the assembly analogy, but it’s not quite _that_ abstracted from the higher-level language, yea? At least not for prompt-to-webapp.
It’s perhaps important to learn the consequences of certain design and impl details? Because Sonnet-class models can often miss these more easily than Fable-class.
That said, refactoring and bug-fixing is faster than ever. So I’d argue LLM coding is actually quite a bit different than having a compiler. In ways we’re still seeing ?
How many times do you think the average programmer have noticed that their compiler have introduced a bug? And how many times do you think the same developer have found a bug in the code that their AI have implemented?
Stop drinking the cool aid and compare compilers with ai models.
I love Software Rendering too! I'd add Unreal Tournament to the list of "Games worth trying", though not sure what the multiplayer scene is like nowadays.
And until the cost of running LLMs exceeds the cost of someone's salary, people will continue their subscriptions.
But they do more than enable the superfluous add-ons, and have been inserting themselves as being mission critical in securing software. "Subscribe. Or else!"
reply