> What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? That's what Steve Jobs brought

> What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? That's what Steve Jobs brought to the table. Was Steve Jobs a software or hardware engineer? I would argue no—he was fundamentally doing product design and management. You can argue this is a craft as well, but it's a fundamentally different one from software engineering. > What about codebase architecture? LLMs are getting good at this too. Within a few years we may not need humans for this. If you're hoping that "architecture" will be your moat, well, I'm sorry... > The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products? Again, these are largely product design concerns. Software engineers can do them, sometimes even well, but they alone do not constitute software engineering. > Is none of this part of the artistic side of the craft? You seem to be getting hung up on my music analogy as some sort of "code as art" thing. While I agree that code can be artistic, that's not where I was going with it at all. I mean that in order to compose, a musician usually picks up and plays an instrument, or simply sings in order to play with melodies and harmonies to determine what sounds right. They set up a sort of ear/brain/muscular system feedback loop to shape how a song sounds and feels in real time. If you have them specify what kind of song they want in English, you've cut out that feedback loop. They're not really being a musician anymore, they're commissioning music. They're more of a musical director. It's the same with programmers. Programmers work and think in code. Code becomes a medium of exchange of ideas about procedure between each other, their future selves, and the machine. I learned a lot about this writing Lisp, but even in a stodgy language like Ada, I can get a lot of thinking through of a solution done by writing what types I want to be working with, in Ada. If you take the code away and say "here, specify the program you want in English", you're basically asking the software engineer to stop being a software engineer and start being a product manager or business analyst. Which is fine, you know, maybe we just don't need software engineers anymore. > I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English) No, it's not "just another layer of abstraction". It's fundamentally different. Generally speaking, software abstractions are transparent homomorphisms from the constructs in the language of expression (e.g., Java, PHP) to instructions the computer can execute. How an LLM converts your prompt into code is both opaque and unstable. I get that we're really not supposed to care about that, nor did many people care exactly how the compilers they used work. But with a compiler, if you do care, you can examine it and it'll make sense, or you can write your own. An LLM, not so much really. Again, you are no longer building the software yourself. You're asking a teammate to. It's just that your teammate exists in silico now. This becomes more true, not less, as LLMs become more capable of the grunt work of, you know, engineering, freeing you for the more important business of stating what you want in vaguer and looser terms. I guess the dream is that we'll all become business founders, with the LLM as our founding engineer, and we can just ask them to build what we think the business needs, and go through them to make refinements and changes.