Except the cooks don't exist anymore as they all have become head chefs (or changed careers) and the food is being cooked by magical cooking black boxes
Would you consider drudgery the in-depth thinking that's required to actually go and write that algorithm, think out all the data ownership relationships, name the variables, think the edge cases for the tests?
For me, the act of sitting down and writing the code is what actually leads to true understanding of the logic, in a similar way to how the only way to understand a mathematical proof is to go trough it. Sure, I'm not doing anything useful by showing that the root of 2 is irrational, but by doing that I gain insights that are otherwise impossible to transfer between two minds.
I believe that coding was one of the few things (among, for example, writing math proofs, or that weird process of crafting something with your hands where the object you are building becomes intimately evident) that get our brains to a higher level of abstraction than normal mammal "survival" thinking. And it makes me very sad to see it thrown out of the window in the name of a productivity that may not even be real.
> Would you consider drudgery the in-depth thinking that's required to actually go and write that algorithm, think out all the data ownership relationships, name the variables, think the edge cases for the tests?
For 99% of the functions I've written in my life? Absolutely drudgery. They're barely algorithms. Just bog-standard data transformation. This is what I love having AI replace.
For the other 1% that actually requires original thought, truly clever optimization, and smart naming to make it literate? Yes, I'll still be doing that by hand, although I'll probably be getting the LLM to help scaffold all the unit tests and check for any subtle bugs or edge cases I may have missed.
The point is, LLMs let me spend more time at the higher level of abstraction that is more productive. It's not taking it away!
I do agree with this, and in fact I do often use LLMs for for these tasks! I guess my message is more intended towards vibe-only coders (and, I guess, the non-technical higher ups drooling at the idea of never having to hire another developer).
I see junior PM types glowing about being able to lead teams of agents, doing their bidding without putting up a fuss or argument. Short term, developers are in for a world of hurt. Long term, we're going to need a lot more to clean this crap up.
Noone will clean it up, it's a societal problem. The koolaid is produce more, like we need another app for X . We are celebrating owning nothing, as a liberating act. People hate mental load yes, this is the perfect drug. You don't need to think or challenge anything. If the model says it's okay, it's okay. Local models will never be able to democratise this. People will do as they are told, and another generation of consumers will follow. The matrix won't be a prison, it will be a prompt from birth to death. And y'all clapping cause you can have X number of agents running around burning tokens like kids looking at the fire cracker on their hand about to blow up, giggling. The world was always mad, and this is proof it will always be mad while people are still around.
I think there is room for a hybrid approach. You can delegate most of the "drudgery" to AI, but keep the parts that require creative solutions for yourself. There is undoubtedly a lot of crappy work we have to do as engineers. This is stuff that needs to be done but has also been done many times before.
This is a great plot for a B movie or a trashy military action book. “The bad guys are jamming GPS uplink and we only have two weeks until the almanacs are out of date and the whole system breaks down. Millions of innocent Americans will drive into rivers by accident.”
More to the point, to do that to this number of satellites on this big an area you'd need nuclear power plant levels of power, and it would only degrade GPS a bit (their clocks slowly desync when uplink is blocked)
My understanding was that each satellite broadcasts a coarse ephemeris for the whole network, and that that “almanac” isn’t accurate for very long (on the order of weeks). Without uploads to the satellites, those almanacs will go stale.
I don’t think the almanacs are necessary for the system to work, in theory. But I believe they’re commonly used by receivers to narrow down the range of possibilities when trying to find a PRN match for a signal they’re getting.
(I’ve dealt with GPS and similar navigation signals for work but am not an expert, this is just the impression I’ve gotten over a few years)
Exactly, for the thing that has been done in Github 10000x times over, LLMs are pretty awesome and they speed up your job significantly (it's arguable if you would be better off using some abstraction already built if that's the case).
But try to do something novel and... they become nearly useless. Not like anything particularly difficult, just something that's so niche it's never been done before. It will most likely hallucinate some methods and call it a day.
As a personal anecdote, I was doing some LTSpice simulations and tried to get Claude Sonnet to write a plot expression to convert reactance to apparent capacitance in an AC sweep. It hallucinated pretty much the entire thing, and got the equation wrong (assumed the source was unit intensity, while LTSpice models AC circuits with unit voltage. This surely is on the internet, but apparently has never been written alongside the need to convert an impedance to capacitance!).
This kind of stuff could trigger the next revolution in computing, as the theoretical energy consumption of computing is pretty insignificant. Imagine if we could make computers with near-zero energy dissipation! A "solid 3D" computer would then become possible, and Moore's law may keep going until we exhaust the new dimension ;)
As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec<u8, MAX_BUFFER_SIZE>, behind a embassy Mutex.
The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.
You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.
So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.
One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?
I think the key is that the LLM is having no trouble mapping from one "embedding" of the language to another (the task they are best performers at!), and that appears extremely intelligent to us humans, but certainly is not all there's to intelligence.
But just take a look at how LLMs struggle to handle dynamical, complex systems such as the "vending machine" paper published some time ago. Those kind of tasks, which we humans tend to think of as "less intelligent" than say, converting human language to a C++ implementation, seem to have some kind of higher (or at least, different) complexity than the embedding mapping done by LLMs. Maybe that's what we typically refer to as creativity? And if so, modern LLMs certainly struggle with that!
Quite sci-fi that we have created a "mind" so alien we struggle to even agree on the word to define what it's doing :)
