Comment by sarchertech
9 hours ago
Only if you assume that all software works the way that product managers think it does.
They come up with the features and the implementation is an unimportant detail in realizing their designs.
In reality implementation details frequently drive design and in most cases they are at least highly intertwined.
I can’t count how many products and features I’ve built that ended working completely differently than the initial design, or how many times I was able to simplify a workflow after spending a days thinking about the implementation details.
You can kinda do something similar by spending days or weeks going back and forth with an LLM, but at least in my experience that doesn’t really save much time and I don’t understand the problem quite as well by the end of it.
I don't disagree with the points you've made but what are they rebutting?
The economic value is still the product you delivered. Your understanding of the implementation meant you participated in the work of the "product manager". I think most good devs do. That might be an argument for devs to transition into designer/PM roles. That is effectively happening already, whether or not role titles have caught up.
But in any case the value isn't in the understanding itself. It just happens that the understanding still helps create better block box products. Also, I wouldn't count on this "human advantage" lasting long. I hope it does, but ime LLMs are now good enough to do this "co-design" too, and will only get better.
This:
> In the pre-LLM era, the economic value of "understanding" and "shared knowledge" about the programs themselves was only that it made maintenance and changes cheaper.
This only holds if there is a bright line separation between the problem, the solution, and the implementation of the solution. And that is not the case.
Understanding the implementation frequently improves your understanding of the solution, which improves your understanding of the problem, which leads to better solutions. Sometimes it leads to realizing that there is a completely different problem you should be solving.
So what I’m refuting is that there is no value to understanding the program.
But beyond that black box products that users know how to use but don’t understand is also a vast oversimplification.
Frequently software is useful specifically because it forces users to adopt a process not just because it allows them to do something they were previously doing faster. In those cases the process is usually informed by the implementation, so the user needs to understand parts of the implementation even if it’s indirectly.
Yes, you're right, understanding informs the constraints and the possible solution spaces. That should be added to the list.
Practically speaking, I don't think the "black box" metaphor is as broken as you're saying, though I like the point you made. There is still a ton of software (the majority, I think -- crud apps of all flavors) where an unthinking, untechnical PM wants something they can specify, and an LLM can give it to them, and it will more or less solve their problem. It won't be the best possible thing, but it will be good enough.