The kinds of tools like those in the article suffer from being outside of the "main loop of coding". What is the main loop? Well, as it's defined since the ris

The kinds of tools like those in the article suffer from being outside of the "main loop of coding". What is the main loop? Well, as it's defined since the rise of interactive computing, it's typing in the editor, compiling, then testing and debugging. Thus we optimize for: 1. Typing code fast(or typing less code) 2. Compiling code fast(by doing less compilation) 3. Minimizing testing and debugging time(by narrowing our definitions of testing to that which is easy to automate). The main loop of coding is not software development. It does not study the domain problem, define new benchmarks for success, untangle communication issues, or refine principles of development. It is a path to coder flow state, feature factoryism and shipping the org chart. These things sort of resemble development - a happy coder delivering features within a definite architecture does serve someone at some point - but also manifest dysfunction. Development failing is just shrugged off as bad programming or bad management. Tools like a Whyline or Reflexion models are not in the main loop. They are an invitation to look carefully at whatever horror has been wrought and address it at a deep level. But that really needs a researching mindset, not a shipping one. In practice, the available tools very slowly move in the direction of the suggestions of research. There are improvements, but they need projects that put together the pieces and make it a goal from the language design(the main interface) upwards.