What would genuinely enhance productivity would be some means to co-operatively share and discuss architecture, design and implementation decisions and trade-offs in realtime while maintaining creative control over code.
For example; I'm considering where to place the code for a new feature within my application stack - should I implement it as part of the frontend application, or do I handle it in a backend service?
Multiple tradeoffs and implications fork off from this type of seemingly simple question, and they'll have performance, deployment, security, operational and organizational impacts over the course of the lifetime of the application.
Those types of questions generally bounce around in a developer's own mind -- and potentially with their team over the course of a few meetings or chats.
To be able to share questions like these with a public audience -- perhaps similar to the way that coding session interview candidates are encouraged to explain their thinking throughout -- and then to gather and debate feedback on the merits of each decision, and develop trust with each participant (based on their overall contributions, or for specific areas-of-experience) could make for a valuable platform.
As hinted previously, this could apply at architecture and design (whiteboard, conversation) levels, and at implementation-level (shared IDE screen, conversation).
Delivered correctly this could also be a useful training and educational tool; observers could learn about the tradeoffs that are made for real applications, and participants should gain a sense of achievement (and attribution; ideally in writing although also through evidence of discussion) from helping steer the course of software.
Open-minded participants would learn from the situations in which their suggestions were declined, and ineffective actors on the platform (whether asking questions or attempting to mislead discussion) would become apparent over time.
Conversely though -- it could be time-consuming and potentially incredibly distracting for architects and developers to visit and share their problem statement in this kind of environment -- letalone interact with it subsequently -- so it would likely fail unless the signal-to-noise ratio was very high and clearly added value to their project.
The main thing I miss is to be able to, as Fred Brooks says, "throw one away". It happens too often that, contrary to the second part of Brooks saying (i.e., that "you will anyhow"), something that should be a prototype ends up as the "finished" product, causing headaches down the road due to shortcuts that were made or because whatever was learned in developing the prototype is not taken into account due to time pressure. On the other hand, I work in a small company and the customers are happy enough, just too few so it might be the case that these headaches are a reasonable price to pay.