There’s plenty of people that know the fundamentals of the system. It’s a mistake to think that understanding specific technical details about an implementation is necessary to understand the system. It would make more sense to ask questions about whether someone could conceivably build the system from scratch if they have to. There’s plenty of people that have worked in academic fabs that have also written verilog and operating systems and messed with radios.
strongly disagree with this article. I think using the tools can actually directly lead to a junior engineer getting closer to a senior engineer. Telling junior engineers that they have to get better at typing out code in order to be better engineers misses what actually makes someone a better engineer.
It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture. the combination of these two makes you a better problem solver. talking to other people helps you figure out your blindspots and forces you to reduce complex ideas down to their most essential parts. the loop of solving a problem and then seeing how well the solution worked gives you an instinct for what works and what doesn't work for any given problem. So how do agents make you better at these two things?
If you are better at explaining what you want, you can get the agents to do what you want a lot better. So you'd end up being more productive. I've seen junior developers that were pretty good problem solvers improve their ability to communicate technical ideas after using agents.
Senior engineers develop instincts for issues down the road. So when they begin any project, they'll take this into account and work by thinking through this. They can get the agents to build towards a clean architecture from the get go such that issues are easily traceable and debuggable. Junior developers get better at architecture by using agents because they can quickly churn through candidate solutions. this helps them more rapidly learn the strengths and weaknesses of different architectures.
People don't develop the ability to solve algebraic equations when they see a professor solving it on the whiteboard. That's just the introduction to the methodology. The way people develop problem solving is by solving problems themselves.
This is why everyone's thirsty for senior/staff engineers who are AI powered right now, because their entire work experience was the typical SWE experience.
I cannot wait for the industry to have a highly skilled SWE drought in the next 5 years, so I can sweep in and become the AI powered engineer who saves the day because other junior-mid SWE's outsourced their problem solving way too early, either due to falling for the "don't be left behind" narrative (which is absurd because what about people who will get into CS in 6 years from now? Do they miss some metaphorical train?) or because their manager forced them to adopt the tools.
What comes to mind is Java vs assembly. Claude is just a reallyreally high level language compiler. I work with senior Java devs who have never written assembly.
On the learning front, I spend the weekend asking Claude questions about Rust, and then getting it to write code that achieved the result I wanted. I also now have a much better understanding of the different options because I've gotten three different working examples and gotten to tinker with them. It's a lot faster to learn how an engine works when you have a working engine on a dyno than when you have no engine. Claude built me a diesel, a gasoline and an electric engine and then I took them apart.
> It's worth actually being specific about what differentiates a junior engineer from a senior engineer. There's two things: communication and architecture.
Uhhh… also skills and abilities? You won’t develop either of those by repeatedly asking an AI to solve problems for you.
I think it's important to note that there's nothing forbidding LPU style determinism from being used in training. They just didn't make that choice.
Also tenstorrent could be a viable challenger in this space. It seems to me that their NoC and their chips could be mostly deterministic as long as you don't start adding in branches
You're right but my understanding is that Groq's LPU architecture makes it inference-only in practice.
Like Groq's chips only have 230MB of SRAM per chip vs 80GB on an H100, training is memory hungry as you need to hold model weights + gradients + optimizer states + intermediate activations.
Interesting twist on automated curriculum learning. This paper is using an LLM for the environment and the policy. Other papers use LLMs for policy/value fn. Would be cool to see other reward strategies tying all these threads together
The author's motivation for writing this is well-founded. However, the author doesn't take into account the full spirit of rust and the un-constructive conclusion doesn't really help anyone.
A huge part of the spirit of rust is fearless concurrency. The simple seeming false positive examples become non-trivial in concurrent code.
The author admits they don't write large concurrent - which clearly explains why they don't find much use in the borrow checker. So the problem isn't that the rust doesn't work for them - it's that a central language feature of rust hampers them instead of helping them.
The conclusion for this article should have been: if you're like me and don't write concurrent programs, enums and matches are great. The language would be work better for me if the arc/box syntax spam went away.
As a side note, if your code is a house of cards, it's probably because you prematurely optimized. A good way to get around this problem is to arc/box spam upfront with as little abstraction as possible, then profile, then optimize.
Yeah, the author's theoretical "Rust but with garbage collector" would gain a whole bunch of concurrency bugs. It wouldn't be Rust anymore, just c# with a more functional syntax.
"Fearless concurrency" is one of the best things the borrow checker gives us, and I think a lot of people undervalue it.
