LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
I'm sorry if I gave the impression I think programming is just typing. For me "programming" is the whole activity of creating software with code, you can do programming without the literal action of typing.
> Writing the code and thinking about the exact logic you want to apply and all its implications are part of the same problem solving process in my mind.
That's really interesting perspective to me, as these two activities for me are two completely things, and "thinking about the exact logic" happens way before I actually write any code at all, sometimes weeks/months even.
> putting things together in code is a very satisfying and IMHO is the actual building part of the job.
I agree that it's satisfying, but I guess "putting things together in code" still for me is more about being able to mash two concepts together in an elegant way, and none of that actually requires actual typing still.
> LLMs move me away from the implementation, which is more a managerial role, something I personally have zero interest in.
This is also interesting, because it feels like LLMs give me the opportunity to do more implementation, and not get stuck in the minutia so much, but rather focus on how the design and architecture actually fits together. Refactoring no longer is "I want to but also I don't want to spend the time nor get stuck in more rabbit-holes", so being able to focus on architecture/design more feels like it lets me care more about the implementation than before.
Maybe they just like doing it the old fashioned way. You can both exist.
Unless you’re getting a commission to sell LLMs to people I struggle to understand what you’re trying to achieve.
It's not bothersome, I'm not bothered by it at all, everyone gets (in my mind) to do things that makes sense to them. When I write comments here disagreeing with others, it's more from a "Please explain further your perspective so I can understand it, which hopefully I trigger by challenging it" view than anything else, not "You should do as I am doing things".
> Maybe they just like doing it the old fashioned way. You can both exist.
Completely fair if that is the perspective, just to re-iterate, I'm not trying to convince anyone of anything, only to understand other perspectives better.
In the past when my junior engineers were fighting with a bug all week, I always told them the dopamine hit of solving the bug is what keeps you coming back to work for 20 years. Half joking, but the dopamine hit of from the satisfaction getting complex working software in a weekend is like crack to me, we'll see how that plays out long term :)
Your take is so reductionist it's hard to believe you actually like to solve problems.
Beyond the typing though, I find enjoyment in perfecting the structure of the code, thinking deeply about how the pieces fit together. I enjoy the process of iteratively refining the code so that it clearly represents the program using the optimal level of abstraction and minimizes superfluous code/syntax. I find that using an LLM eliminates all of this and produces code that lacks all of the elegance and readability that I aspire to in my own code.
Some people fall to that temptation instead of using LLM to just do the menial stuff and do the fun stuff themselves.
The problem at least I have is... when something goes wrong, often enough even you as the original author / LLM slave-driver have no idea what is going on where, and completely forget trying to dig into someone else's pile of vibe-coded garbage. For every single problem you now are completely beholden to the AI agent.
With code, I'm not planning everything down to the finest detail before I start writing. I know what I ultimately want my code to do but there are many unknowns I hadn't considered. Coding with an LLM is different depending on how you use it. When I'm using code completion, that's usually just helping me prevent syntax errors or to write an efficient snippet of code without having to check docs. But when I tell Claude "I want a web app that does xyz" and it creates it whole-cloth, that takes away the challenge of learning something new and building. I'm not a web developer and anything I could create is going to take me a long time to make (and it probably won't work well or look good) but Claude cranks it out with ease. I get to play software project manager and let the expert do the technical work. It's kinda fun being able to quickly get resulrs. Rather than debugging individual lines of code and thinking about the best way to implement code, I get to test features and think about better ways for the overall system to operate.
Goes into what? Into typing code or into creating LLMs?
Overall I'm not sure what point you're trying to make, nor why you feel bad about it. Mind explaining to a simpleton like me with simpler words and concepts?
Software can be about the beauty in an algorithm, the elegance of an implementation. This is very similar to the type of beauty and elegance one finds in Mathematics.
For many, writing software is more about crafting a beautiful design than typing lines of code.
Getting things done is not about crafting, though (although crafting IS about getting something done).
Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop". They get things done.
Yes, I count myself as one of these people, hence not caring much about the actual typing part.
> Getting things done is not about crafting, though (although crafting IS about getting something done).
I'd say it is, I like getting things done, hence I care about high quality code and proper design/architecture of the software itself and its concepts. Without caring about those things, you can "get things done" initially but as the thing grows, it gets slower and more complex. I like when "get things done" is applicable over years and as the software grows, then you need to carefully deliberate about almost every change and be vigilant about the design and architecture.
> Thus the big clash when suddenly you can get things done well enough, without the craft part, with LLMs. Even if beauty and elegance are in there, most would not see it, because most do not want to review "LLM slop".
Right, but no one is forcing you to go down that path. You can tell the LLM "Build a calculator" or you can come up with the design then tell the LLM to implement the design exactly, the choice is up to you. Since I care about the abstractions, design and cohesive architecture, I do the latter, and if you too do not care about the typing but the crafting, I'd advise people to also make that latter choice instead of the first.
LLM spaghetti code is unacceptable.
LLM code with a complex pile of overlayed abstractions only someone with a PhD in Software Engineering can debug or even get to compile years later when public APIs change is also unacceptable.
Same thing with human engineered software abstractions.
But I get you. Human directed AI is the only way to go ... for now ...