That's his entire point. I think you're conflating software engineering (i.e. the art and practice of engineering a piece of software) and coding (the part of it that was typing text in programming languages, to incarnate the abstract ideas you developed at those more abstract levels of software engineering that precede coding itself).35mm wrote: Sun Jul 19, 2026 10:10 pm It can be useful as a dev. when you send it off to do a bit of coding for you, especially DSP or something complicated, but you always have to go through and check it, or at least fix it. But, it's useful for pushing the pen around. It certainly is a time saver for coding, but you have to be able to tell it what to code. I think that's where non coders fall down.
He meant that, while the majority of actual work/effort/time in software engineering as such was coding itself, even in senior roles, and that era is absolutely gone, and now the new normal is that the majority of the work/effort/time in software engineering has become architecture, planning, choosing technologies and design patterns, and setting contstraints and contracts that narrow the scope for the LLM tools enough so that they churn out exactly the type of code that software developer otherwise would.
Having said that, coding, as such, isn't entirely gone. A good developer already knew that the job is 80% reading code and 20% writing it. They're now learning to offset about half of the former, and vast majority of the latter, to an LLM. But you still need to read what it wrote to evaluate it (or find bugs) and write code (to fix those that are much easier/quicker for you to fix by writing code then telling the agent to do it).
