21–30 of 206 posts
Could've outsourced a long time ago to humans, if I wanted to deal with reading code most of the time instead of writing it.
It remains unclear to me why my ability to read and review code (the majority of my job for years now) will atrophy if I continue doing it while writing even less code than I was before. If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding? The act of writing code by hand seems to be on a trajectory of irrelevance, so as…
> The act of writing code by hand seems to be on a trajectory of irrelevance It does not. English (or any human language) is an awful language to write specifications in, because it is not as precise as code. Each time you "compile" your prompt into a program, LLMs spit up something a little bit different. How is it a good thing? > so as long as I maintain my ability to reason about code (both by continuing to read i…
Because that’s not how it works. How can we have a discussion about this topic if we don’t have a mutual understanding of how the tools even work?
The code is not replaced by English prompts. The code still exists.
[dead]
The biggest problem is it’ll teach you bad habits. For example, Claude and gpt love to use fallbacks. They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient. If you don’t have past knowledge you might just think that’s how it is. Now before someone says that junior devs make the same mistakes, yes, to some extent.
This leads to the idea that LLMs with existing languages can't really learn new idiomatic patterns.
For new engineers I think new paradigms will emerge that invalidate the need to know the current set of design patterns and idioms. Look at the resurgence of unit tests or the new interests in verification systems.
It remains unclear to me why my ability to read and review code (the majority of my job for years now) will atrophy if I continue doing it while writing even less code than I was before. If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding? The act of writing code by hand seems to be on a trajectory of irrelevance, so as…
Even before AI, I’ve witnessed at Google plenty of L6 and L7 software engineers atrophy. They stop writing code, start reviewing code, until they find that their code reviews catch fewer issues than a junior engineer’s reviews. They have become accustomed to thinking only at a high-level, and when met with low-level details they can’t tell good from bad any more. Their coding skills, both reading and writing, have at…
I don’t get paid to write code, and you probably don’t either.
Claude will, when given a task off the beaten track, churn through tokens for a while, then produce a completely incorrect answer. (Most recent anecdote: fixing a barostat in an MD sim)
Specifically: How does Spotify, a music streaming service, improve due to AI agents producing code all night? What is improving or being fixed which needs that much abstract code and problem solving? I am guessing the AI code is just building more messy architecture on top of the messy architecture which is causing so much work to be generated.
I would suggest leaving the keyboard, going outside and getting some real highs. Perhaps also leave behind all your technology and try to experience a non-connected life.
What is the world coming to when folks get a high from prompting a complex algorithm.
Oh well, it probably proves that “human intelligence” isn’t that complex. It seems fairly simple to simulate.
> Software used to be deterministic
Ah, someone fortunate enough to have never coded a heisenbug or trip over UB of various causes.
I've written plenty of well structured, well thought out mostly-deterministic software, then spent hours or days figuring what oversight summoned the gremlins.
(There is one low priority bug I've occasionally returned to over the last two-three years in case experience and back-burner musing may result in insight. Nope. Use gcc, no bug, use clang, bug, always, regardless of O level, debug level, etc. Everything else, all of it far more complex, works 100% reliably, it's just that one display update that fails.)
(It occurs to me that that is a bad example, because it IS deterministic, but none of us can pinpoint the "determiner".)
Earlier quoted context omitted.
Goethe answered this in Faust. The answer is always: your soul.
Can you be more precise?