INTRODUCTION

ChatGPT was introduced a few weeks ago and since then it has been one of the main topics in the IT industry. In this blog post, we’ll take a closer look at what GPT is and the potential applications of this powerful technology in the hands of software engineer. GPT-3 is the third and newest generation of GPT models and it is one of the most powerful language so far. It is trained with a big amount of text data from multiple sources which include websites and books. It can be still fine-tuned for a wide range of tasks, including text summarization, extracting data from documents and question answering in one of the many specific domains.

ChatGPT, on the other hand, is the most recent specialized version of the GPT-3, tailored to the needs of chatbot applications. Reinforcement Learning with Human Feedback (RLHF) was used to improve the model’s outputs by incorporating human feedback during training. By learning from human corrections and preferences, the model’s output can become more accurate. In many cases this model can be generally faster and more efficient than GPT-3 and that’s why it can be a better choice for use in real-time use-cases. However, in general it may be not as powerful as the source model which can be additionally fine-tuned. They both seems to be designed for different purposes.

There are also other GPT-3-based (older) models that are specifically designed to work with code rather than general natural language. OpenAI Codex is pre-trained on a large dataset of code, which allows it to ‘understand’ the structure and semantics of code. One of the most popular Codex-based tools is Github Copilot that uses this model to suggest code and entire functions in real-time even from IDE.

That’s some theory. But can we efficiently work with code, at least in some way, using the newest solution – ChatGPT instead of Codex-based ones?

PLAYING IN THE PLAYGROUND

#CASE 1

In the first step, we checked how the model deals with modelling domain classes and incorporating the Domain Driven Design (DDD) approach (at least in very basic version). In short, Domain-Driven Design (DDD) is methodology that aims to bridge the gap between business and software by aligning the structure of the code with the business domain it represents. DDD utilizes principles and patterns to create a clear mapping between the business and software, making it easier for developers to understand the code and for domain experts to understand the software.

Input: Give me an example of using Domain Driven Design. Let this be an example of a car booking system. There we should have reservations, users and cars. Indicate what could be Value Object, Entity, and Aggregate.
Output:

ChatGPT correctly generated classes for the domain objects we specified, assigned them some useful properties and methods, and correctly marked value objects, aggregate roots and entities. No errors, no code smells.

#CASE 2

Input: Write a C# method with a string parameter that returns a Base64 version of the input GUID.
Output:

All lines of code seem to be at least correct again. But it’s important to handle exceptions in any method that deals with input that can be malformed or otherwise invalid. In fact, there is a place where exception could be thrown. All we have to do is just ask for changes.

Input: What about handling exceptions?
Output:

#CASE 3

Input: Prepare a simple .NET API which returns current weather in a specified city.
Output:

GET method asynchronously calls an external API – OpenWeatherMap to retrieve temperature and description. It also does understand that we need to generate our own API key. In the next lines there is a mapping from JSON to Weather class. It does not use any mapping library nor does it manually, instead it makes some workaround using JsonSerializer. It seems like a fully acceptable solution.

SUMMARY

In many cases, picking the right model is a matter of preference. It seems like Codex/Copilot is more responsive, while ChatGPT is more proactive at work. Copilot can be a good choice for preparing short snippets or scanning all your code, and everyone else’s, and coming up with little adjustments on the fly. It learns style conventions and will adapt to suggestions. It really speeds up the amount of characters on the page and makes refactoring easier as well.

But ChatGPT is good to get broad architectural outlines and answer our questions. It’s easier to use this model for inspiration / exploratory work because we can specify what parts we don’t like and how we would like to change them. It’s more like an AI assistant where you can enter a piece of code and ask it to optimize or refactor it.

Both solutions work in different way but in many cases provide optimal answers if we ‘ask’ them in a proper way. Codex-based tools work more like a tactical advisor, making our tasks done faster and in a more effective way, while ChatGPT can possibly provide us improvements and alternative methods. From a practical point of view they both still are great choice for one-off utilities and functions.

What we have presented here is only a teaser, there is much more to explore. Technologies like these can help software engineers to be more productive by automating tasks that are typically time-consuming or repetitive, such as writing code, documentation and debugging, which allows programmers to focus on more complex and creative tasks.

Overall, GPT-like models can be a valuable tool for programmers when used in conjunction with other programming tools and best practices, but it’s not a complete replacement for a human software engineer. Sometimes they can be wrong and we have to keep that in mind.

In Inero Software we build digital products for digital logistics of tomorrow. We connect active aproach to analysis of business needs and combine with cutting edge technologies and AI/ML.

Artykuł ChatGPT – A developer’s point of view pochodzi z serwisu Inero Software - Software Consulting.