I would disagree that "the grievances" are not fundemantel. The _profession_ of the programmer is about to cease to exist, much like the human computer. Sure, you can still compute without a computer and perhaps enjoy it, but you will not find anyone to pay you to do it. Whatever you think "babysitting an LLM" is, it's not programming, even if presumably programmers are fairly well suited for it.
That is, unless you treat the agents as if they were people and thus the true engineers, of course. I think that's a fascinating philosophical topic despite ultimately disagreeing, but to say the least it's incredibly controversial to even consider the personhood of agents, much less endorse it.
This is all moot anyway, so apologies if I'm rude or overly dismissive of your comment that I agree with the general thrust of. No point starting fights over deck chairs...
The title "software engineer" is just a bullshit name that sounds more important - for the same task. Very few programmers work like real-world engineers. There is no licensure or liablity, there is no legal code. If a real-world engineer makes a mistake in a design that causes structural failure, they're on the hook.
We sure added lots of processes and practices to make it seem like we're more diligent about what we're doing, but none of these are empirically verified (or verifiable in practical terms).
I disagree. It remains an engineering job. Us software engineers got confused about what the engineering part always was. The engineering part of chemical engineering isn’t cutting piping, welding shit, or rolling metal. The engineering in civil engineering isn’t pouring the concrete, or grading the site.
Yet somehow it’s a prevailing idea that the engineering part of software engineering was typing on keys and naming variables.
We took advantage of the typing time to also think, and in many ways typing code served a similar purpose to drafting your thoughts on paper. With an LLM you still think a lot and those thoughts turn into specs, prompts, plans, or whatever workflow you prefer.
You are conflating designing the system and instantiating it with code. This is exactly what I’m talking about.
Typing characters absolutely is cutting pipe and pouring concrete. It is not where the engineer was or is.
> I know Machine Learning
Knowing a thing and knowing how to use the think well are not the same.
> Cognitive impact
This is probably the greatest concern and it requires vigilance or routines to counter it.
> The quality of the output is not that great > Maintainability is a nightmare
Neither are my first prototypes. Refactor them using AIs.
> I like writing code
I like designing a system before coding it and the AIs are pretty good idea bouncing partners.
LLMs are absolutely capable of writing beautiful code, the important step here is telling it what beautiful is. You need to have an opinion and describe it articulately to an LLM. You need to be a Rick Rubin of code; he plays no instruments, can’t read sheet music, but his opinions are what matter.
I have been trying to perfect a workflow where the human is engaged and doing what they love and the LLM is kept away from what it’s bad at. This is essentially a pair programming setup where the human is in control but will pass the conch to the LLM from time to time when they don’t wish to type something, the rest of the time you should be asking it questions.
We will need to start thinking about our human engagement as a resource that is expended on a dial. I have a fixed amount per day and it doesn’t need to be evenly distributed, but it needs to be dense in areas that “matter”. What matters is subjective and where your Rick Rubin skills come in. The metric of quality is the difference in the distribution you have decided and a “true” distribution of what matters. So yes, maybe I don’t need to fully understand all the code for some control panel I’ve built or a blob of test code the LLM spit out, but I absolutely need to know and have an opinion on how the core machinery of the codebase works.
There is no going back to writing code the old way. I don't see that happening in the industry, ever.
The grievances listed here are 100% real, but not fundamental - with some practice you can prompt an LLM to great effect without it taking the reins from you. If you let it write the code, it does become a management job more than an engineering job. That said, I do believe that there must be a way to structure your workflow such that the LLM becomes your read-only pair programmer/rubber duck while you yourself get to do the fun parts of coding.