Comment by gherkinnn
1 month ago
> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.
Speak for yourself, OP. I have my gripes with LLMs but they absolutely can and will help me create and understand the code I write.
> At least, they value it far less than the end result.
This does not appear to apply to OP at all, but plenty of programmers who like code for the sake of code create more problems than they solve.
In summary, LLMs amplify. The bad gets worse and the good gets better.
The thing that gets me is the assumption that we're not complex creatures who might each value different things at different times and in different contexts.
As for me, sometimes I code because I want something to do a specific thing, and I honestly couldn't be bothered to care how it happens.
Sometimes I code because I want something to work a very specific way or to learn how to make something work better, and I want to have my brain so deep in a chunk of code I can see it in my sleep.
Sometimes the creative expression is in the 'what' - one of my little startup tasks these days is experimenting with UI designs for helping a human get a task done as efficiently as possible. Sometimes it's in the 'how' - implementing the backend to that thing to be ridiculously fast and efficient. Sometimes it's both and sometimes it's neither!
A beautiful thing about code is that it can be a tool and it can be an expressive medium that scratches our urge to create and dive into things, or it can be both at the same time. Code is the most flexible substance on earth, for good and for creating incredible messes.
I'll argue the the LLM can be a great ally when "I want to have my brain so deep in a chunk of code I can see it in my sleep" because it can help you see the whole picture.
[dead]
Right - it's not that I don't value "the act of creating & understanding the software" - that's the part I care about and enjoy the most.
The thing I don't value is typing out all of that code myself.
I think I can get on board with this view. In the earlier LLM days, I was working on a project that had me building models of different CSV's we'd receive from clients. I needed to build classes that represented all the fields. I asked AI to do it for me and I was very pleased with the results. It saved me an hour-long slog of copying the header rows, pasting into a class, ensuring that everything was camel-cased, etc. But the key thing here is that that work was never going to be the "hard part". That was the slog. The real dopamine hit was from solving the actual problem at hand - parsing many different variants of a file, and unifying the output in a homogenous way.
Now, if I had just said, "Dear Claude, make it so I can read files from any client and figure out how to represent the results in the same way, no matter what the input is". I can agree, I _might_ be stepping into "you're not gonna understand the software"-land. That's where responsibility comes into play. Reading the code that's produced is vital. I however, am still not at the point where I'm giivng feature work to LLMs. I make a plan for what I want to do, and give the mundane stuff to the AI.
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.
4 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.
[flagged]
I think you’re in the pleading stage. The AI tools this year will do the whole process without you. Reading the code will be a luxury for little benefit.
[dead]