One issue I can find with this workflow is tunnel vision, making ill informed decision because of the lack of surrounding information. I often skim books becaus

One issue I can find with this workflow is tunnel vision, making ill informed decision because of the lack of surrounding information. I often skim books because even if I don't retain the content, I can have a mental map that can help me find further information when I need them. I wouldn't try to construct a complete answer to a question with just this amount of information, but I will use that map to quickly locate the source and have more information to synthesize the answer. One could use the above workflow in the same way and argues that natural language search is more intuitive than keyword based search. But I don't think that brings any meaningful productivity improvement. > Being able to "reason" effectively over long context inputs (particularly useful for understanding and debugging larger volumes of code) is another. Any time I saw this "wish" pop up, my suggestion is to try a disassembler to reverse engineer some binary to really understand the problem of coming up with a theory of a program (based on Naur's definition). Individual statements are always clear (programming language are formal and have no ambiguity). The issue is grouping them, unambiguously define the semantic of these groups, and find the links between them, recursively. Once that's done, what you'll have is a domain. And you could have skipped the whole thing by just learning the domain from a domain expert. So the only reason to do this is because the code doesn't really implement the domain (bugs) or it's hidden purposefully. So the most productive workflow there is to learn the domain first to find discrepancy (first case) or focus yourself on the missing part (second case). In the first case, the easiest approach is writing tests, and the more complete one is to do a formal verification of the software.