The success of Copilot: How gitHub and OpenAI work together
How can AI effectively support us in product development? In software development, we already have a first impression of this. gitHub is a platform for team-based software development. In mid-2021, the platform released Copilot, an AI-based tool that completes software code for developers during programming. Copilot now has over one million paying users. What can we learn from this for systems engineering?
Microsoft, gitHub and OpenAI
In 2018, I reported here on the Acquisition of gitHub by Microsoftwhich I rated positively, also for the Open Source-communities that had their home there. But just one year later, in mid-2019, Microsoft invested one billion dollars (US) in OpenAI. We can assume that the Group had strategically planned these two steps from the outset. Because Copilot is based on a Variant of GPT-3 (Codex). Codex would not have been possible without the gigantic amounts of data from gitHub that were used to train the language model.
Microsoft acquired gitHub in 2018 to enable Copilot with OpenAI technology.
Developers can also use Copilot without gitHub. They install Copilot in the IDE (development environment) of their choice. Recently, this has increasingly been Visual Studio Code (Code for short). Code is available for many operating systems, including Linux. That would be in the days of Steve Balmer would have been unthinkable!
How does Copilot work?
Copilot generates code based on natural language. Incidentally, you can also do this without Copilot in ChatGPT which also generates software code for programming questions. But what makes Copilot special is its good integration into the IDE. In particular, the natural language that describes the task of the code is not lost. This is because the developer specifies this in the form of a comment, which is then retained in the code.
This also roughly describes the use of Copilot: The developer formulates the problem to be solved. This is typically the result of a function or a code fragment. When writing the comment, Copilot makes suggestions for the comment text and allows the code to be adapted to implement what is described.
A (moving) picture is worth a thousand words. The following video shows this in 90 seconds:
Why does Copilot work so well?
This question is not meant to be technical, but rather substantive: Why does Copilot generate such a high benefit? Well, there are several.
First of all, the context in which the user is working is not only precisely known, but also formally defined. The IDE knows which programming language is used, which libraries are used, knows the scope of the project and even knows which files are open in the editor. This context severely restricts the possible answers, which increases the relevance of the result.
Another reason is that there is no innovation at this level (several lines of code). Instead, the focus here is on best practices and Development pattern. Best practices and design patterns are not worth protecting. But they ensure high code quality and maintainability.
Copilot works because it understands the context and supports best practices and design patterns.
The result: Copilot passed the million user mark at the beginning of 2023 - and is always subject to a charge.
Copilot for Systems Engineering?
Unfortunately, we do not have a platform comparable to gitHub in Systems Engineering. The activities in systems engineering are also nowhere near as homogeneous as in programming. These two points mean that a co-pilot for systems engineering will still be years away.
At the moment, the hype is all about Large Language Models (LLMs). There is a good reason for this: language is extremely flexible and at the same time based on comparable structures, regardless of whether it is a human language or a programming language. I therefore expect AI technologies to find their way into areas where text is used. These are requirements.
However, comments in software code do not usually contain intellectual property, whereas requirements do. We can respond to comments with development patterns that are not product-specific. In systems engineering, we normally operate in the context of a specific product and must also draw on the organization's knowledge.
I therefore think that for a long time we will only see company-specific "co-pilots" who have to be trained for the company. These will initially focus on textual requirements, or on Traceability. We will certainly also see applications here that incorporate external but generic material, such as standards and regulations.
Conclusion
We will certainly have to wait a while before we see anything comparable in systems engineering. In the meantime, we can try to shift the ratio of hardware to software in our products in favor of software. Because we can already use Copilot there today.
Photo by Arif Riyanto on Unsplash
