Post #1991136
2026-05-04 02:47 UTC
Replies (9)
-
@aburka@hachyderm.io 2026-05-04 02:48
@regehr I hope the main thrust of that course syllabus was "don't do it"
-
@gwozniak@discuss.systems 2026-05-04 03:04
@regehr To me, this is the key point of contention when I talk about these things. "Contrary to the current narrative that is being espoused, we didn’t necessarily need to write code faster. Especially code we didn’t fully understand, and particularly in huge swaths that we couldn't review in reasonable time frames." For those of us that have serious problems with LLMs for programming, this part is important. But for those who push them there is no issue. Generating more code is all that matters. The result can be bad or half-baked. It doesn't matter. All that matters is that something was produced and shipped.
-
@addison@nothing-ever.works 2026-05-04 03:49
@regehr@mastodon.social I appreciate the design and pedagogical elements here. Even if they were resolved (which I don't think they can, because, as it notes, the surrendering of control in exchange for a management position is the point), I would still be uncomfortable using these tools because of their incredibly numerous externalities. I've considered outright leaving the field if we end up steering towards these tools being not just commonplace but expected because I can't justify these other effects. This essay alludes to some practice changes outside of the context of LLMs that I think people inherently understand as important. Perhaps our abstractions are just not good enough yet and people don't feel equipped to "mold the clay" in software development easily without surrendering control to a tool that does it for you. Perhaps there are ways we can teach programming better to be more intuitive. I'm staying around because I hope to chip away at these problems, and that people will slowly get better at relying on themselves than learning helplessness.
-
@samth@mastodon.social 2026-05-04 04:59
@regehr good essay. I should pick your brain about the course; I'm teaching one like it this fall.
-
@dan@discuss.systems 2026-05-04 05:16
@regehr thanks for this, would be interested to hear the conclusions from your class
-
@mrtazz@chaos.social 2026-05-04 06:12
@regehr for the part about the future being everyone just supervising agents I often come back to this quote from Bainbridge in the Ironies of Automation paper from *checks notes* the early 80s: "There is some concern that the present generation of automated systems, which are monitored by former manual operators, are riding on their skills, which later generations of operators cannot be expected to have."
-
@n_dimension@infosec.exchange 2026-05-04 07:31
@regehr ... In reading article. The some comments I would disagree is with. 1) You can reduce token budget by up to 95% (Depending on your code and use case) 2) Its different if you develop one shot or maintanable platform, if its the former SDD is perfectly fine. You don't need to know your code. Black box is fine. Developers are afraid to let go of code. 3) I think "agentic" is misused/misunderstood here. In my understanding an agent is one that goes off and performs a whole sequence of tasks. ClaudeCode on the other hand works under your supervision. We also have to remember this is nascent tech. Not mature in any way or form. What #vibecoding will look like in 10 years is nothing like today. Also, there was little if any notion about the .md files which I use extensively to shape how my #ClaudeCode works. (E.g. Backups, thesis updates, authorisation for commands)
-
@happyborg@fosstodon.org 2026-05-04 12:16
@regehr Most of what you wrote is spot on, views that I've held and raised to no effect for a long time. I think you underestimate the deskilling of yourself in the 'healthy' way you described towards the end. For example, only asking #LLMs to do something you could do yourself means you don't refresh that ability, and miss opportunities to learn how to improve on how you did it last time. 1/
-
@malwareminigun@infosec.exchange 2026-05-04 19:52
@regehr I see similar effects on vcpkg edits. We have to deal with a lot of vendored dependency hell and cannot practically review actual code for all 2800 things in the registry. Throwing the LLM at new ports therefore sometimes discovers bits we did not expect because we would not even try. Because we get reasonable results we break things less often which is a kind of indirect improvement but it’s not like we can meaningfully review at a higher per-PR velocity which my bosses have not appreciated :/ It’s higher quality because we break less often but not faster.