This is akin to sticking to hand tools after the development of the electric motor.

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.

This is where I’m aiming for now. We’re not going to put away our power tools, but we also should not be using a circular saw to carve inlay panels.

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.

I felt like the post for a while but ramped up on it since.

> 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.

> If you let it write the code, it does become a management job more than an engineering job.

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.

I guess it's because throughout the lifetime of this profession, we have not witnessed a development like this. We went from punchcards to assembly to compilers to javascript, but at no point was it a process that would just "keep going" until you turned it off, much like a motorized machine.

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.