Comment by horsawlarway
1 month ago
Just to poke at this a bit -
Isn't this a bit like saying you love storytelling, but you don't value actually speaking the words?
Because this feels very close to skating across a line where you don't actually understand or value the real medium.
Basically - the architectural equivalent of this leads to things like: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse
Where the architects are divorced from the actual construction, and the end result is genuinely terrible.
Not typing every line of code myself doesn't divorce me from the construction.
I frequently find that the code I write using agents is better code, because small improvements no longer cost me velocity or time. If I think "huh, I should really have used a different pattern for that but it's already in 100+ places around the codebase" fixing it used to be a big decision... now it's a prompt.
None of my APIs lack interactive debugging tools any more. Everything that needs documentation is documented. I'm much less likely to take on technical debt - you take that on when fixing it would cost more time than you have available, but those constraints have changed for me.
But... that's exactly the kind of thing I'm referring to.
You're blanket replacing chunks of code without actually considering the context of each one.
Personally - I still have mixed feelings about it. The Hyatt Regency walkway was literally one of the examples brought up in my engineering classes about the risks of doing "simple pattern changes". I'm not referencing it out of thin air...
---
Havens Steel Company had manufactured the rods, and the company objected that the whole rod below the fourth floor would have to be threaded in order to screw on the nuts to hold the fourth-floor walkway in place. These threads would be subject to damage as the fourth-floor structure was hoisted into place. Havens Steel proposed that two separate and offset sets of rods be used: the first set suspending the fourth-floor walkway from the ceiling, and the second set suspending the second-floor walkway from the fourth-floor walkway.[22]
This design change would be fatal. In the original design, the beams of the fourth-floor walkway had to support the weight of the fourth-floor walkway, with the weight of the second-floor walkway supported completely by the rods. In the revised design, however, the fourth-floor beams supported both the fourth- and second-floor walkways, but were strong enough for 30% of that load.
---
Just use a different pattern? In this case, the steel company also believed it was a quick pattern improvement... they avoided a complex installation issue with threaded rods. Too bad it killed some 114 people.
But I am considering the context of each one. It's just quicker not to modify the code by hand.
I'm going to use a human comparison here, even though I try to avoid them. It's like having a team of interns who you explain the refactoring to, send them off to help get it done and review their work at the end.
If the interns are screwing it up you notice and update your instructions to them so they can try again.
2 replies →
I share your concern. I'm flummoxed by the prevalent sentiment that code is the nasty underbelly of software. To me, a programming language is a medium both for precisely directing a computer's behavior and for precisely communicating a process to fellow programmers (cue the Alan Perlis quote [1].)
I will concede that mainstream code is often characterized by excessive verbosity and boilerplate. This I attribute to the immaturity of today's crop of programming languages. Techniques like language-oriented-programming [2] hint at a path I find appealing: DSLs that are tailored to the problem while promising more precision than a natural language specification could.
To speculate, I could see LLMs helping during the creation of a DSL (surfacing limitations in the DSL's design) and when adding features to a DSL, to help migrate code written in the old version to the new one.
Perhaps DSLs aren't the future. However will there be as much interest in designing new and superior programming languages now that code is seen as little more than assembly language?
[1] https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
[2] https://beautifulracket.com/appendix/why-lop-why-racket.html
No, I don't think so. But my context is different as is anyone's reply about their LLM usage.
I'm still creating software but with English that's compiled down to some other language.
I'm personally comfortable reading code in many languages. That means I'm able (hopefully!) to spot something that doesn't look quite right. I don't have to be the one pressing keys on the keyboard but I'm still accountable for the code i compile and submit.