>> Defining exactly what the product is supposed to do is the hard part, writing code is the easy part.
There is a massive difference between a spec, which defines what the product should do, and code, which defines exactly how it should do it. Moving from the former to the latter is not "the easy part". Anyone who genuinely believes that either works on easy and straightforward problems, or is some sort of programming god. Because translating specs to code can still be difficult and exhausting.
> Defining exactly what the product is supposed to do is the hard part, writing code is the easy part.
> There is a massive difference between a spec, which defines what the product should do, and code, which defines exactly how it should do it.
He states: The difficult part is figuring out the details so LLM doesn't save much time.
You state: If LLM is able to correctly assume the details that saves you a lot of time.
Case 1:
Part of the spec describe some basic feature based on a popular framework and industry standards, everything is trivial.
You are right, he is wrong.
Case 2:
Part of the spec describe some niche feature and/or uses some not popular framework and/or require deviation from industry standards and/or cutting edge performance/latency requirements and/or uses a bunch of proprietary non-googlable data.
You are wrong, he is right.
The more senior engineer are the less time they spend on case 1, those are easy, they don't spend much time on it, it is the 2nd which is much more time consuming.
There is a massive difference between a spec, which defines what the product should do, and code, which defines exactly how it should do it. Moving from the former to the latter is not "the easy part". Anyone who genuinely believes that either works on easy and straightforward problems, or is some sort of programming god. Because translating specs to code can still be difficult and exhausting.