alt Hacker NewsFor years many in management believed our value to the company was "just" in our ability to produce code. You could see it from how they would "resource" projects and write job descriptions and manage. The output of the job, to them, was code written / bugs fixed / features implemented. In organizations like this, software was a cost centre, and it was treated that way.
LLMs can write code. They're actually pretty good at it. So problem solved, right? Cost centre cost reduction. Bam!
In reality the more competent in the job were really good at understanding business problems and holding domain specific knowledge, working with the other people on the team to translate that into a problem a computer could solve, and with understanding and diagnosing what was happening in the broader system, not just in a "program."
Someone needs to write the prompts given to the LLMs and decide if what they came back with even makes any sense. Someone needs to respond to pages in the middle of the night. Someone needs to be able to look at the system and have a bigger picture understanding of how it fits with the business' needs, etc. etc. That's a software engineer.
I honestly think not enough in middle and upper management really understand what software development actually is.
Replies
This comes across strongly any time you hear management talking about "fungibility of engineers". Everyone is a full stack everything engineer, and AI makes that even easier for them to trick themselves into believing.
If anything, I feel like AI has made domain expertise more important, not less, as the "confidently wrong" error case for agents has no one able to sanity check it. At least before AI a human would dip their toe in the water and usually realize that having no idea what they were doing, and not even being able to understand what the comments mean, was a sign that they need to go find someone more experienced to help.
> For years many in management believed our value to the company was "just" in our ability to produce code.
Yeah, this is nuts because at every company I've worked at it's assumed that engineers are thinking about things like product market fit, how a feature would be sold/ the "value" of the feature itself, how we would support the feature (not just the code, but how support would manage it), etc.
I don't think people realize how much of a hand engineers have in these conversations because we don't champion that, but we think a lot about the product as a whole. Obviously we don't spend as much time thinking about how the product will be sold as a sales person will, but we absolutely think about it, in my experience.
We think a lot about the business, like a massive amount about the system as a whole across these organizational boundaries.