4 ms·
It feels like retracing the history of software project management. The post is quite waterfall-like. Writing a lot of docs and specs upfront then implementing.
by bonoboTP 8mo ago
It feels like retracing the history of software project management. The post is quite waterfall-like. Writing a lot of docs and specs upfront then implementing. Another approach is to just YOLO (on a new branch) make it write up the lessons afterwards, then start a new more informed try and throw away the first. Or any other combo.
For me what works well is to ask it to write some code upfront to verify its assumptions against actual reality, not just be telling it to review the sources "in detail". It gains much more from real output from the code and clears up wrong assumptions. Do some smaller jobs, write up md files, then plan the big thing, then execute.
- 0x696C6961 8mo agoThis is exactly what I do. I assume most people avoid this approach due to cost.
- le-mark 8mo agoPlease explain what do you mean by “cost”?
- 0x696C6961 8mo agoYou burn a lot of money on tokens for a solution that you throw away.
- nurettin 8mo agoIt makes an endless stream of assumptions. Some of them brilliant and even instructive to a degree, but most of them are unfounded and inappropriate in my experience.
- jerryharri 8mo ago'The post is quite waterfall-like. Writing a lot of docs and specs upfront then implementing' - It's only waterfall if the specs cover the entire system or app. If it's broken up into sub-systems or vertical slices, then it's much more Agile or Lean.
- deleted 8mo ago[deleted]