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.
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?
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 ?
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
You should only have a high-level understanding and be able to orchestrate things, plan, and make choices. AI do the details.
Any quality CS program will have you do that for a year or so, plus theory.
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).
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.
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.
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.
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.
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.
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.
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.
https://www.linkedin.com/pulse/coding-agents-idea-compilers-...
Stop drinking the cool aid and compare compilers with ai models.
I don't think llms are an abstraction - they're a delegation.
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.
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.