An average enterprise uses ~40 developer tools, all of which are usually from different vendors. Choosing the best-of-breed tools instead of settling on one giant tightly integrated stack is not a new phenomenon in the developer world.

So, when developers write code, they must consider how that code will interact with all these disparate tools. For an API service, how will the API be consumed in code? What kind of log output would a piece of code produce for a logging service? How does a piece of code represent the corresponding design artifact for a UI component? For a bug fix, how does the change address the problem described in the bug report? And so on.

Gathering this context from different tools—whether to write or review code—has to be one of the more complex tasks in software development. That is why we (Sourcegraph) are bullish on the idea of Contextual Software Development—bringing all of the context, not just from code but from any relevant tools in the stack, right to the place where the developer most needs it.

This additional context not only makes AI smarter but also makes humans smarter by allowing them to visualize their code in terms of what it will actually produce (debugging without a debugger). I would argue that improving humans' comprehension of code (by providing additional context) is even more critical, given that humans will be required to validate tons of AI-produced code for the foreseeable future.

The other key aspect of Contextual Software Development is quickly integrating new context producers (docs, design, PM tools, logs, etc.) and context consumers (Editors, Browsers, CLI, etc.) with minimal work. The only way to enable that is through open standards, thereby opening the doors for anyone to build for and benefit from these additional sources of context.

This is why I am so excited about OpenCtx - it enables contextual software development built on an open protocol.