I agree about the shepherding role. But, I'm not sure about how hands-off the shepherding will be at well-run companies. I work on pricing software for a regulated industry. If I were to start over again from scratch on some of the systems I work on, I could certainly get AI to create a black box that prices per a spec while showing its work. I would iterate on the system and validate the output with the help of an LLM. I would make sure all edge cases are covered and lock in the behavior with "unit" tests. I'd continue to monitor the system in production.
The problem that I see with a black box approach is a lot of uncertainty about how long it will take to get the initial system reliably producing the correct output with acceptable performance. I could deal with that, but the bigger problem I see is the unpredictability of future effort to make changes to the system as my company grows (more traffic to the system, more/changed territory specific laws, more features). This uncertainty could be mitigated by an experienced software engineer guiding what gets built inside of the box. This guiding would include a familiarity with how the code is structured.
Even if one assumes a black box approach, what the box should actually do still requires the mindset of a good software engineer. Many product managers or non-technical parties requesting software won't think through and find problematic inconsistencies or gaps in the business rules they asked for. They won't anticipate how to frame the problem in a way that makes expanding upon the capabilities later easier.
So, I think the role would look like a blend of software/system architect + product manager + dev/LLM ops + QA. At least this would be true at a company that I would want to work for. I've always preferred working in small, strong teams where everyone has a lot of ownership. There will always be the LLM day equivalent of software produced by offshore teams in the early 2000s. I'm sure their modern-day ilk will excrete something that's good enough. I don't want to work for this type of company.
The problem that I see with a black box approach is a lot of uncertainty about how long it will take to get the initial system reliably producing the correct output with acceptable performance. I could deal with that, but the bigger problem I see is the unpredictability of future effort to make changes to the system as my company grows (more traffic to the system, more/changed territory specific laws, more features). This uncertainty could be mitigated by an experienced software engineer guiding what gets built inside of the box. This guiding would include a familiarity with how the code is structured.
Even if one assumes a black box approach, what the box should actually do still requires the mindset of a good software engineer. Many product managers or non-technical parties requesting software won't think through and find problematic inconsistencies or gaps in the business rules they asked for. They won't anticipate how to frame the problem in a way that makes expanding upon the capabilities later easier.
So, I think the role would look like a blend of software/system architect + product manager + dev/LLM ops + QA. At least this would be true at a company that I would want to work for. I've always preferred working in small, strong teams where everyone has a lot of ownership. There will always be the LLM day equivalent of software produced by offshore teams in the early 2000s. I'm sure their modern-day ilk will excrete something that's good enough. I don't want to work for this type of company.