Georgi has been in the software industry for almost 20 years, starting his career as a junior programmer. He is currently a software team manager and has been in this role for more than 10 years. He is a supporter of innovation in the industry, both in technical and organizational aspects. His passion and strength lie in building and developing teams and people. On a personal level, he enjoys spending time with his family and playing sports.

What is your perspective on the hybrid work model?

The hybrid work model should be understood both as an opportunity to balance work and personal time, and to strengthen collaboration, teamwork, and social-professional engagement. I’m not claiming it’s the optimal approach for everyone. However, like in any other work arrangement, mutual trust and professional accountability are essential.

What works well and what doesn’t in the hybrid work model?

If the goal of introducing a hybrid model is achieving work-life balance, then flexibility in its implementation is key to its success.

What do you think is the optimal balance between office and remote work for software teams?

Personally, I believe a healthy balance is around half of the time. I’m not a fan of extremes – I don’t think 5/5 office presence yields better results than 4 or 3 out of 5 days.
On the flip side, 1 out of 5 is the least productive setup in my experience. People spend most of the time socializing over lunch and coffee, and that day ends up with near-zero productivity. A possible mitigation of this effect is using that day for team meetings like PI planning or scrum ceremonies.

Can you give an example of when being in the office led to a faster or more creative solution to a problem?

Any developer would think of pair programming situations. But personally, I believe any decision-making scenario is resolved much faster when people are physically together – full communication dynamics are activated, and a psychologically safe environment is created.

Have you noticed a difference in how junior or new engineers develop in a hybrid setup compared to fully remote?

For newcomers in the profession, being close to more experienced colleagues – mentors, buddies, and the team – is much more productive. Like any beginner, they often face “reinventing the wheel” challenges, and it’s much more effective to get immediate help from the person at the next desk than to lose days trying on their own or waiting for replies through digital channels.

Are there aspects of engineering work (e.g., code reviews, pair programming, architecture discussions) that are better in person?

All communication phases are more productive in person because they include emotion and body language. This helps build a psychologically safe environment where participants are more open to sharing ideas and solving problems.
In contrast, when everything happens behind screens, there’s always room for misinterpretation – of both words and potential emotions. Using a second language adds another layer of complexity due to language barriers.

What does your team do to make in-office time meaningful rather than “presence for the sake of presence”?

We use the time for discussions and decision-making – whether part of scrum ceremonies. Morning meetings are always stand-ups.
Lunch and especially short coffee breaks provide regular opportunities for team bonding and getting to know each other. These small but consistent interactions are more valuable than they seem – they let us see each other through all seasons, at different times of day, and in varied emotional states.
After all, we’re all human outside of work and face similar everyday challenges. When someone realizes their own issues are shared by the colleague next to them – both desk neighbours and team members – they feel more understood and accepted. The result: a safer and more productive work environment.

The material and images are provided by Paysafe

The code it suggests may not always work or even make sense. While we are working hard to make GitHub Copilot better, code suggested by GitHub Copilot should be carefully tested, reviewed, and vetted, like any other code. As the developer, you are always in charge.

GitHub Copilot doesn’t actually test the code it suggests, so the code may not even compile or run … GitHub Copilot may suggest old or deprecated uses of libraries and languages. You can use the code anywhere, but you do so at your own risk.

Developer Nick Shearer spotted that one of the examples of Copilot’s output on its own homepage was the auto-completion of an algorithm that processes expenses. It suggests using a floating-point variable for a monetary value. Generally speaking, floating-point variables are not suited for currency, unless you want values like $9.99000001 going through your system. Copilot may find other ways to ruin your day. GitHub explained:

The technical preview includes filters to block offensive words and avoid synthesizing suggestions in sensitive contexts. Due to the pre-release nature of the underlying technology, GitHub Copilot may sometimes produce undesired outputs, including biased, discriminatory, abusive, or offensive outputs.

GitHub calls it AI pair programming. But, right now, as it stands, Copilot is more like AI armchair programming, or backseat programming, than pair programming. This is not a team of equals. You, the human, are still ultimately and solely responsible, and that makes Copilot more autocomplete than a robot programmer.

A spokesperson for GitHub told us the Copilot team benchmarked their tool by making it complete functions in Python. The model generated the correct code 43 per cent of the time on the first try, the PR rep said, and 57 per cent of the time when allowed 10 attempts. We’re assured it’s getting better. The spokesperson added that developers should use Copilot with the usual run of tests and security tools and apply their best judgment.

Copilot is straightforward to use: it’s available in Visual Studio Code as an extension or GitHub Codespaces, once you’ve been accepted into the preview. Type away and Copilot will suggest the next line of code, or fill in the blanks for a particular function you’re trying to write.

You can also write comments to coax the software into generating blocks of code. A GitHub spokesperson told us Copilot understands both programming and human languages, which allows developers to describe a task in English, and the tool will then try to provide the corresponding code.

At the heart of it is OpenAI Codex, which a GitHub spokesperson told us was a machine-learning system created by OpenAI, and that an API for using Codex programmatically will be made available this summer along with more details. We were also told that Codex is significantly more capable than OpenAI’s text-generating GPT-3.

Teaching neural networks to write code has been tried again and again; there are a few startups like TabNine and Kite that have similar products to Copilot, as well as big tech companies like Amazon. GitHub Copilot shouldn’t come as too much of a surprise because the code management platform is owned by Microsoft, which has a close relationship with, and billion-dollar investment in, OpenAI.

Garbage in, garbage out

Copilot was trained on massive amounts of natural-language text as well as public code repositories. GitHub said the output of the tool is owned by the user, much like you own the output of a compiler from your source code, though it estimated 0.1 per cent of suggestions may contain code that was in the training set, which you may or may not be allowed to use. Again, you’ll have to check Copilot’s output thoroughly.

In one example, GitHub Copilot produced multiple lines of TypeScript that parses JSON data into a data structure that maps names to collaborators, all based on a comment containing example input JSON. Copilot can handle all sorts of programming languages though it performs best with Python, JavaScript, TypeScript, Ruby, and Go. It learned to output code by learning common patterns in people’s use of programming languages, just like GPT-3 picked up on grammar from the written word. That said, Copilot is not flawless. It’s likely to get confused if your codebase is thousands of lines of code or more.

Written in grey are the comments. The code highlighted in blue was generated by GitHub Copilot. Photo Credit: GitHub

We could see it being used to automate easy, repetitive tasks – such as generating boiler-plate code – and suggesting library or framework functions you’re not familiar with to save you the trouble of looking through documentation. The tool lets GitHub know, via telemetry, whenever its suggestions are accepted or rejected; this information will be used to improve the software, we’re told. It’s even claimed Copilot can adapt from the changes you make to the source, and learns to match your coding style. The Microsoft-owned biz said:

“We use telemetry data, including information about which suggestions users accept or reject, to improve the model. We do not reference your private code when generating code for other users.”

A GitHub spokesperson told us Copilot uses high-performance GPUs to perform its inference. They added that hundreds of engineers, including many of its own, have already been using GitHub Copilot every day; alpha testers were also given a run at it. You can join the waitlist to try out Copilot here.