Coding with an AI pair programmer: Getting started with GitHub Copilot

Summary

In this insightful presentation, Christopher Harrison, a senior developer advocate at GitHub, delves into the capabilities of GitHub Copilot, a suite of AI-powered tools designed to enhance coding efficiency. Harrison emphasizes the importance of treating Copilot as a tool, not magic, and offers practical tips for optimizing its use. He covers the tool's behind-the-scenes operation, discusses the significance of context in code suggestions, and introduces the concept of 'prompt crafting' to guide developers in phrasing their code and comments effectively. Through a demo using Python and Django, Harrison illustrates how to leverage GitHub Copilot for code completion, highlighting the need for clear intent, specificity, and flexibility in interactions with the tool.

Takeaways

• 🌟 GitHub Copilot is a suite of tools primarily focused on code completion, providing suggestions based on the context of the code and comments you write.
• 🛠 It's important to remember that GitHub Copilot is a tool, not magic, and optimizing its use can enhance your development workflow.
• 🤖 Behind the scenes, GitHub Copilot sends the context of your code and comments to an AI model, which then generates suggestions tailored to your coding task.
• 📄 The 'context' includes the entire file you're working on, as well as other open tabs in your IDE, focusing on those most relevant to your current task.
• 🔍 There can be confusion about what data is sent to GitHub Copilot, but it primarily uses the open file and related open tabs to inform its suggestions.
• 💡 Prompt crafting is a technique to effectively communicate with GitHub Copilot by being clear, specific, and intentional in your comments and code.
• 📝 Describing the goal at the top of the file helps set the context for GitHub Copilot and can improve the relevance of its suggestions.
• 🔄 Being flexible with GitHub Copilot's suggestions is crucial, as the AI's responses are probabilistic and may vary.
• 📚 Providing examples in your comments can guide GitHub Copilot to understand and replicate the patterns you're looking for in your code.
• 🔑 Good coding practices, such as proper naming conventions, can help GitHub Copilot generate more accurate and useful suggestions.
• 🛣️ Going with the flow and adapting to GitHub Copilot's suggestions can lead to a more efficient and productive development process.

Q & A

Who is Christopher Harrison and what is his role?

Christopher Harrison is a senior developer advocate at GitHub, and he is excited to talk about GitHub Copilot and how to maximize its utility.

What is GitHub Copilot?

GitHub Copilot is a suite of tools primarily focused on code completion. It provides suggestions for code and comments based on the context of what the user is typing in their integrated development environment (IDE).

How does GitHub Copilot generate suggestions?

GitHub Copilot sends the context of what the user is typing to its servers, where it uses OpenAI's technology to understand the user's intent and generate relevant suggestions that are then sent back to the user's IDE.

What context does GitHub Copilot consider when generating suggestions?

GitHub Copilot considers the entire file the user is working on, including the content from the beginning to the end of the file, as well as the tabs that are open in the user's IDE, focusing on those most relevant to the current task.

Why is it important to understand that GitHub Copilot is a tool?

Recognizing GitHub Copilot as a tool helps developers to manage their expectations and spend time learning how to use it effectively, rather than expecting it to perform magical or perfect tasks.

What is the concept of 'prompt crafting' mentioned in the script?

Prompt crafting refers to the method of phrasing and typing comments and code in a way that maximizes the effectiveness of tools like GitHub Copilot, by providing clear context, intent, clarity, and specificity.

Why should developers be flexible when using GitHub Copilot?

Developers should be flexible because GitHub Copilot operates on a probabilistic model, meaning it may provide different suggestions in the same scenario at different times. Being flexible allows developers to rephrase or adjust their approach to get the desired suggestions.

What is the significance of proper variable naming in getting good suggestions from GitHub Copilot?

Proper variable naming is significant because GitHub Copilot reads and interprets variable names to understand the context and provide relevant suggestions. Clear and descriptive variable names help the tool to generate more accurate and useful code completions.

How can providing examples help GitHub Copilot to understand a developer's intent?

Providing examples gives GitHub Copilot concrete instances of what the developer is trying to achieve, which helps the tool to understand the specific requirements and generate suggestions that align more closely with the developer's intent.

What is the recommendation for handling the comments used to guide GitHub Copilot after the code has been written?

The recommendation is to leave the comments behind as they serve as artifacts of how the code was generated. They can be helpful for future reference and for fine-tuning the model later on.

What are some best practices for using GitHub Copilot effectively?

Best practices include describing the goal at the top of the file, being flexible with the suggestions provided, providing examples to guide the tool, naming variables properly, following best practices in coding, and going with the flow by being adaptable and open to the tool's suggestions.

Outlines

The video is abnormal, and we are working hard to fix it.
Please replace the link and try again.

Keywords

💡GitHub Copilot

GitHub Copilot is a suite of tools developed by GitHub that primarily focuses on code completion. It integrates into a user's code editor, providing suggestions for both code and comments based on the context of what the user is typing. In the video, it's highlighted as a powerful tool that can help developers write code more efficiently by suggesting what they might be looking for, thus keeping them in the 'zone' and reducing the need to look up syntax or other information.

💡Code Completion

Code completion refers to the feature within GitHub Copilot that suggests possible code snippets as a developer types. It's designed to enhance productivity by reducing the time spent on writing repetitive code or looking up specific syntax. In the script, code completion is exemplified through the automatic suggestions that appear as the developer describes their intentions in comments or code.

💡Context

In the context of GitHub Copilot, 'context' refers to the information that the tool uses to generate accurate suggestions. This includes the entire file a developer is working on, as well as the open tabs in their editor. The script emphasizes the importance of context in helping GitHub Copilot understand the developer's intent and provide relevant suggestions.

💡Probabilistic

The term 'probabilistic' in the video describes the nature of GitHub Copilot's suggestions. It means that the tool provides suggestions based on probabilities and patterns, rather than deterministic outcomes. This is illustrated in the script when the speaker mentions that the same prompt might yield different suggestions on different days, reflecting the tool's learning and adaptation over time.

💡Prompt Crafting

Prompt crafting is a technique discussed in the video that involves carefully phrasing comments and code to elicit the most useful suggestions from GitHub Copilot. It's about being clear, specific, and intentional in how one communicates their coding needs to the tool. An example from the script is when the developer specifies the creation of a 'speaker' model with 'name', 'email', and 'LinkedIn' to guide Copilot's suggestions.

💡IDE (Integrated Development Environment)

An Integrated Development Environment (IDE) is a software application that provides comprehensive facilities for software development. In the video, the IDE is where GitHub Copilot operates, sending context to and receiving suggestions from GitHub Copilot. The script mentions that developers can accept, reject, or modify the suggestions provided by Copilot within their IDE.

💡Django

Django is a high-level Python web framework that enables rapid development of secure and maintainable websites. In the script, Django is used as an example to demonstrate how GitHub Copilot can assist in building models and views for a web application. The video showcases how Copilot can generate Django model code and understand the framework's conventions.

💡Regular Expression

A regular expression is a sequence of characters that defines a search pattern, which can be used for string matching and manipulation. In the context of the video, GitHub Copilot generates a regular expression to enforce a specific format for a model field, such as ensuring an abbreviation consists of three uppercase letters.

💡F-string

An F-string (formatted string literal) is a feature in Python that allows for easy and readable string formatting. The video script mentions F-strings when discussing how GitHub Copilot automatically uses this feature to format strings in a specific way, which can be adjusted by the developer for more specificity if needed.

💡Best Practices

Best practices refer to the recommended methods or techniques in a particular field or activity. In the video, the speaker emphasizes following best practices in coding, such as using clear and descriptive variable names, as a way to improve the effectiveness of GitHub Copilot's suggestions. The script illustrates this with examples like using 'LinkedIn' instead of an abbreviation, which helps Copilot understand the developer's intent.

Highlights

The video is abnormal, and we are working hard to fix it.
Please replace the link and try again.

Transcripts

Good morning.

Good afternoon. Good evening.

Depending on where in the world you happen to be, my name is Christopher Harrison.

I'm a senior developer advocate at GitHub and I'm really excited to talk today

about GitHub Copilot and about how to get the most out of this tool.

That one thing that we will sometimes forget when we're looking at

these tools is the fact that they are tools.

They can often feel like magic.

I type out a few words and while I've got this really, really cool thing,

but at the end of the day, it's a tool just like our IDE,

and we should spend a little bit of time seeing how we can get the most out of it.

So I want to start off by talking a little bit

about GitHub Copilot and how it works behind the scenes,

and then we'll get into some tips and tricks

that you can start to implement as you get in and explore the tool.

So what is GitHub

Copilot ? So GitHub.

Copilot is a suite of tools.

I'm going to be primarily focused in on code completion.

So this is the embedded experience inside

of your idea, inside of your editor, where as you add in comment,

as you add in code, it's then going to generate suggestions, generate

what it thinks that you are looking for based on that information.

So how does it do its thing behind the scenes?

Well, as you're typing out your code, as you're typing out your comments,

context is sent up to GitHub.

Copilot I'm going to talk about that context in just a moment,

but from right now, let's focus in on that processing

so that context is sent up to GitHub Copilot.

GitHub Copilot then uses the OpenAI allow them

behind the scenes, sees what it is that you're trying to do and then in turn

generate suggestions and send those sends those down to your I.D.E.

You can then accept those, reject those, accept and modify,

use that as the foundation.

And it really does help keep you in the zone and help

you avoid having to go off and maybe look up obscure syntax and things like that.

Now, let's talk a bit about that context, because a lot of times

there's some confusion about this, exactly what is going to be sent up to GitHub

Copilot? Well, the first and kind of the most obvious is the file that you are

currently working on, and that's going to include the entirety of the file.

So it's not just from where my cursor is and everything above it,

but rather it's the start of the file, the bottom of the file,

the middle of the file.

So if I'm going in and I'm making updates, I'm adding new code,

I'm making changes.

It's going to look at the entirety of the file, not just from the cursor

and above.

The next big thing is the tabs

that are open inside of your idea.

This sometimes cause and causes confusion and I'll admit for me personally,

it also caused a little bit of confusion because I honestly did think

that it summed up the entirety of my project.

And if we stop and think about that, that would be an awful lot of context

for Copilot to try and figure out,

try to parse out, try to figure out what's most important.

Because like, if I think about, you know, reading

a very long article, I want to focus in on what's most important.

And if there's like, you know, 5000 words

and this is really the only section that I'm interested in

for this moment, the rest of that becomes a little bit superfluous.

So we want to focus GitHub Copilot's attention on what's most important,

and that's where those tabs come into play.

It's going to focus in on what's most important based on those tabs.

Additional.

It's also going to start from the outside our inside and work its way out.

So the tabs it will start with are the ones that are closest

to the tab that I am currently working on. Now,

one thing that sometimes people will do

is they'll get a little bit too focused on trying to control the tabs,

on trying to control the context that's going to be sent up.

And honestly, if we think about the way that we typically write code,

that if you're anything like me and I know I am, that

I will open up a file, I'll make some modifications.

I'm going to open up a related file,

I'm going to make some modifications, I'm going to open up another related file.

And this is normally the way that we wind up doing our work.

So by having GitHub Copilot focus in on those tabs,

it's typically naturally automatically going to get the files

that are already most related to what it is that I'm doing now.

If I'm shifting tasks, if I'm maybe going to be taking a look

at something that's a new feature that I'll be implementing

or if I know that I'm going to be working with a library or framework

that Copilot has never seen before, then I might go ahead and

very specifically open up a file, open up some representative example

of what it is that I'm building, or maybe I'm switching tasks,

or maybe I am not getting the suggestions that I'm looking for back

from GitHub Copilot.

Then at that point I might take another look at the files

that I have open and maybe readjust at that point.

But again, I really do want to highlight the fact that you will find

most of the time just through your normal usage patterns

of an idea of your editor, that you'll just inherently be opening up

the files that are most closely related to what it is that you are working on.

Now let's get in and start to

kind of build upon that and see how we can get the most out of this tool.

And I'm going to potentially introduce a term that's that's new

you a thing called prompt crafting.

And in a nutshell, this is really about how it is

that we are going to phrase and type out our comment phrase

and type out our code phrase and type out our prompts

to get the most out of these tools that, as I highlighted at the start,

I is a tool and I really do want to make sure

that I've spent a little bit of time learning how to get the most out of it.

Just like with my idea this is what prompt crafting is all about.

Now, if we break this down into a couple of components

about how it is that we can help GitHub Copilot help us.

The first is going to be the context.

This is that surrounding information.

What is it that we're trying to build?

How is it that we are trying to build it

to start to then drill a little bit further down?

The next is the intent.

What is it that I'm doing?

How is it that I'm trying to do?

Why is it that I am trying to build that out?

Next is the clarity.

As a friend of mine likes to joke,

don't use a big word when a diminutive one would use that.

As I'm typing in my comment, as I'm trying to describe what it is

that I'm doing, I want to make sure that I'm clear

so I might start to avoid a lot of vernacular.

I might try to avoid maybe abbreviations that make sense to me internally,

but might not be as clear, might not

define truly what it is that I am trying to build.

Last but not least, is specificity.

This is where I'm going to get in

and identify exactly what it is that I want.

Let's take, for example, the phrase Go get me some ice cream.

Now I've provided enough information to complete that task.

You know that you should go off and go grab some ice cream.

That's wonderful.

But what flavor of ice cream?

What vessel should there be?

Sprinkles. Don't know.

So have I given enough information to complete the task?

Yeah.

Am I going to be satisfied with the result?

Maybe not, because I'm going to be looking for salted caramel in a waffle cone.

And the answer is always sprinkles.

Yes, always sprinkles.

So what I really wanted to do, if I was going to craft that out, say

using Prime crafting, is make sure that I'm providing all of that

specificity, all of that information upfront.

And this is one of the big mistakes that I see developers make

when they first get in and start playing around with copilot

that they assume, I can just type out a couple of words, I can type out

a couple of sentences, and voila, I'm going to get this very big thing.

That's not really how it works that we want to make sure

that we're providing good, clear prompts.

I think the best way to do this is really start to put it into action.

So before I get into this demo, I promise you there's going to be a demo

here in just a moment.

Let's take a look at a couple of real quick best practices.

First up is describe the goal.

I like to view this as adding a header, if you will, to the file.

This doesn't have to be anything real in-depth per se, just three or four

quick sentences describing what it is that I'm looking to build.

If the framework isn't implied

based on the file that I'm working on, maybe I'll add that in.

You know, kind of what's the goal?

How is it that I'm trying to do this?

Just a couple, three lines up at the very top, add those in.

Next is be flexible.

We always need to remember that our tools are

probabilistic, not deterministic.

And so what this means is that I could be in the exact same scenario.

So I can type out a comment, I could type out a phrase and get one suggestion.

And then in that exact same scenario, the next day, I might get back

something different.

The tools are probabilistic.

This is simply how these work.

And that's all right.

So I just need to be a little bit flexible.

If I don't see what it is that I'm looking for the first time,

maybe rephrase, reframe what it is that I am doing.

And one big thing that you can do to really help out is to provide examples.

So let's say that I'm going to be processing data.

Let's say that I'm going to be doing some validation if I give a set of examples,

then I'm going to be very clearly defining to GitHub Copilot

what it is that I'm looking for.

So let's take a look here.

I've got an application that I'm going to be building out

using Python, Django, Python, Django, one of my favorite frameworks.

It's there to create frontend for backend databases.

And the first thing that I need to do

is to build out my models to describe my data here.

So I'm going to start

towards the top of my file here and describe what I'm doing.

I'm building out a conference website, so build out a conference website

and I'm going to have add a speaker,

a track and a talk

and make sure that parrot

can't be deleted if there are children.

So in other words, what I'm trying to specify here is

if I have a primary foreign key relationship

and I try to delete that primary, but there are foreign keys,

don't allow those to be deleted.

So just a couple of three sentences that describe what it is that I'm doing.

Add some constraints and now I'm ready to start adding in my code

and you'll actually notice that great italicized text there.

That's GitHub Copilot and action.

It's making those suggestions.

I actually haven't done anything yet and it's already

starting to make code suggestions.

I'm going to accept what this is going to give me by hitting tab,

but I'm going to be a little bit more specific.

So I want a speaker.

Speaker should have name,

email and LinkedIn like that.

And let me just give it one quick extra return here.

And let's see, I'm speaker.

What's let's do this.

Let me be more specific here.

I'm learning from my self here.

Create a speaker model

with name, email and LinkedIn.

There we go

in this moment. Perfect.

So what you notice there is previously was saying, should I

now I'm being a little bit more specific about what it is that I want.

I'm being flexible, rolling with it.

I go back, I tell it create and now it's doing its thing.

And so now if I had Tab, now

it's got all of that information that I specified.

So it's got my name, it's got my email and it's got that linked in URL.

You might also notice it's including a little thing that I didn't ask for.

It's including that override of the SDR function.

This is something that's very common in Django and it just automatically added

that in I could, you know, remove that if I want to, but I actually like that.

That's a very common convention inside of Django.

So with that speaker created

the next thing that I want to do is let's create a track.

So let's say create track

with name and description.

Sure. And maybe an abbreviation

like that.

There we go.

Give that a moment and that will go ahead and set that up for me.

Again, it's reading that comment and then adding the rest down below.

Now, as I've highlighted, be specific.

You'll notice that I said abbreviation.

And so it said, All right, fine, I'll give you an abbreviation.

Abbreviation is probably three characters.

And that's what I'm seeing right here.

Is it set up that abbreviation with that max length of three characters.

But chances are, if I'm going to be looking for

an abbreviation, I want something that's a little bit more specific.

So I want this abbreviation to be specifically

three letters and maybe three uppercase letters.

So let's go back and just make that modification.

I'm just going to get rid of that and I'm just going to say abbreviation

should be three uppercase letters just like that.

And now it will go ahead and build that out

with that regular expression. Now,

I don't know about you, but at least for me,

I can read regular expressions and something like this

I could certainly have typed out off the top of my head,

although if I'm being perfectly honest, I do sometimes forget which is which.

If it's the carried character,

the dollar sign to pin to the beginning, pin to the end.

So it's nice not to have to always go look those types of things up.

So I was able to just describe this is what I want.

It generated that regular expression.

So I was flexible there, I was specific and it gave me back that that value there.

Pretty cool.

Last but not least, let's

go ahead and create that torque.

It's already adding in that comment.

I'm going to go ahead and hit tab to accept this.

Let me read a title description Speaker Track and date.

Perfect. Let's go ahead and accept that

and give it 2 seconds here.

Perfect.

And now we'll go ahead and put all of that in.

So now it's got my title, it's got my description,

it's got my speaker, it's got my track, it's got my date,

and then a little bit of extra stuff down at the very bottom here.

And I'm going to kind of leave that the way that it is for the moment.

But the big thing that I want to point out is that unfortunately,

it didn't quite pick up what it was that I was looking for, that if we remember

from the very beginning here, let me scroll all the way back up.

I specified in my little header

that I wanted to make sure

that a parent can't be deleted if there are children.

Unfortunately, this didn't pick up on that.

Maybe I just wasn't clear enough.

Maybe I needed to use the specific vocabulary.

Who knows?

But that's all right.

I could go back and I can modify it. Now.

Before I do that, though, I actually want to get in to the next set of tips here.

And the first is to name things properly.

I'm going to bounce back and forth a little bit

between the slide in this code here to kind of make some points.

And the first is right here on Linked In,

what you're going to notice is that when I added in that comment

of create speaker model with name, email

and LinkedIn that it automatically set up that LinkedIn

as a new URL field, which is probably exactly what I wanted.

How did it do that?

Well, it did that because it's actually reading my variable name here.

So it sees LinkedIn.

It goes, okay, you probably want a URL and it will automatically put that in there.

Which also then means that if I'm looking for good suggestions from GitHub Copilot

that I want to make sure that my variable names are also good.

One of my pet peeves encoding

is abbreviations is single letter variable names.

Because when I go back and I take a look at that code,

it's not always clear to me what that code is supposed to be doing.

And when it comes to abbreviations, sure, maybe we've got documented somewhere

what abbreviations mean and so forth, but that's now institutional knowledge.

That's something that my developers would need to learn.

And the exact same thing would then wind up holding true with GitHub Copilot

is it's not going to have that same experience as my developers.

It's not always going to be able to pick up what those abbreviations mean.

So if I've got good code, if I'm spelling these things out,

I'm not only making it clear to my other developers, but

I'm also making it clear to get a Copilot, which going back to that analogy of

it being in a pair programmer, I kind of want to treat it as such.

I want to make sure that I'm being clear to it.

So because of the fact that I use LinkedIn here,

it was able to go, okay, I know what you're doing.

And it added in that that you are our field.

Now keeping along with that, using good code.

Let's come back down here

to where that little problem is that I highlighted a moment ago.

Right now the speaker and track are both set to cascade.

If you're not already familiar with Django, what that means

is that if I had a speaker and they had talks, I delete that speaker.

All of those talks are now going to go away.

That was not what I was looking for.

So fortunately I can change this, may actually

just get rid of that full track line right there.

And let me do sound effects help, by the way.

There we go. Perfect.

Let me go ahead and say protect.

So by saying protect what that now means

is it's going to prevent a talk

from or a speaker from being deleted if they have talks.

That was the behavior that I was looking for.

Now that I've done that, let me have return here.

And what you're going to notice

is that with track, it's going to follow that pattern.

So it's going to learn by watching me.

So it's picking up that context.

Following along, one of the most common questions that I get asked

is, Hey, we have certain conventions, that we have certain conventions

for naming our variables or whatever it is that it might be.

How do I make sure that GitHub Copilot will follow with this?

The simplest way that you can do that is show it some code

that's written, the way that you're looking for it to be written,

and it will then follow along with you,

kind of reads perfectly in to following best practices.

GitHub Copilot is going to what you're doing

and it will follow right along with that.

Last but not least is like I highlighted up at the the towards

the middle I guess is to make sure that you are opening up relevant files.

So if I'm adding in code, not quite getting what I'm looking for,

make sure that I've got my relevant files open.

All right.

Let's some keep building here and I want to create some views

to display the data that I've now got for my website.

So I need to import it a little, little bit of code here.

So GitHub Copilot sees that I'm doing Django automatically.

Pull that in.

Let me just go ahead and hit tab hit a couple of carriage returns

and now notice this next line here.

The next line that it automatically is adding in

is it's importing in my talk, my track, my speaker.

It's doing that because it's now

seeing my model's tab open.

It knows what's inside of there and we'll automatically import those in.

Let me go ahead and now start creating

views for my let's aim for my talk.

So let's go ahead and say create a list view

for my talks to become

and it will go ahead and set that up for me.

Now, what this is doing in Python, Django,

is this is specifying that the model that we're going to be working with

is talk that when I actually go to display the data, it's

going to have an object name of talks in the HTML

template that it's going to use is going to be that talk list.

Now, this is probably one of my favorite

little things about Django is because this is a framework

that is built to very quickly allow me to front ends for databases.

It includes a lot of pre baked code

for me that I don't have to go in and create.

But as with most frameworks, I would say

it's not always going to be the most performant right out of the box

that by default what this is going to do is it's going to do a thing

called lazy loading, meaning that when it goes to display

every single talk, it's going to have to go back and go get the speaker.

It's going to have to go back and get the track to display that out.

Obviously, I don't want all of those roundtrips to my database.

That's all right.

I can avoid that.

That what I can do is I can add in a comment

describing what I want so I can say, Hey,

select the name and ID for the track.

Oops,

I have a great memory.

It's just really short.

When I said tracked, I say name. I did.

Let me go.

Never do it yourself.

And the name and ID for speaker.

And now when I add that in

let's say pre-select.

There

we go.

Boop.

There we go.

And so now it's going to go ahead and it's going to do the select

related for my track and for my speaker.

And unfortunately pick up on that name or on that ID that is not a problem.

I can just go back and again, kind of just roll with it here, be flexible.

So I'm going to say trac,

underscore, underscore ID, and now

I'll say track name and this should pick up here.

Let me just get rid of that reproof.

There we go.

And now it's picked up on that ID

and it's picked up on that name for me.

So again, be flexible with it, kind of roll with it and it will

then help you out.

Now, that's for all of my talks.

Let me go ahead and create one for a detail for my talks.

Copilot knows where I'm going, so I'll go ahead and hit tab.

Except that

there we go and accept that.

And just like we saw before, because of the fact that I did

that pre-select previously and automatically adds that in.

So it's following along based on what it is that I am doing here.

And that's going to be one of the big takeaways again,

that I want to make sure that I highlight it will follow along with you.

Okay.

One last little thing to highlight here

is let's go back over here to

my talk and let's add in one last little thing.

So up until now, what I've been focused in on

is trying to kind of get the most out of GitHub

Copilot to build out my model, to build out my view.

And now I want to see how I could, you know, take this little talk here.

Maybe to one last little level add

in a dynamic field for my code.

So every talk should have a code.

That should be the in my case, my track,

maybe a level and then the ID for the talk.

And I'm going to build that out here.

So let me first up add in a level, add a level field

with value range

from 1 to 3,

just like that.

And so it's got my men and my max of 1 to 3.

That's perfect.

And now let's go ahead and create a

computed field called code.

Code should have

the track a dash,

the level and two digits from the ID.

Now, if you remember previously, one of the things that we talked about

is give it an example so it might be able to pick this up from.

But I don't know about you, but at least for me, I always like to see examples.

Examples are a great way to kind of describe and also to document.

So I put it in one more comment and it automatically kind of picked this up.

So it automatically added an example of in this case P by t-101

That's I'll accept that and then go ahead and hit return.

It's going to add in with my property hit return

and then now it will build out that property for me.

So now it's got that abbreviation,

it's got that level and it's got this idea of zero two.

Now in this case it already did that by utilizing F string.

Again, going back to specificity, if I want to make sure

that it does it a particular way, just ask it to do it that way.

So if it didn't give me that level of specificity, sorry,

if it didn't give me that F string,

then I can go back and be a little bit more specific.

So I kind of want to go back here

and flow back through all of this one last time.

Number one, describe the goal at the top of the file.

Add in a little quick comment.

Couple lines, three lines, four lines.

What you're doing, how it is that you're going to do it, Any relevant

information that you think that GitHub Copilot might need?

Number two, be flexible.

We saw this as we went through our demos here.

That GitHub Copilot is probabilistic that it's not always going

to give you back the exact same values in the exact same situation.

Things will sometimes change and we want to be flexible with that.

Number three is provide examples and this can be really helpful to GitHub

Copilot to be able to understand what it is that I'm trying to accomplish.

As a side note, one question that I very frequently get asked

is about those comments. Should we remove them?

Should we add them?

My personal opinion is leave them behind.

And the reason for that is because they are artifacts.

It was how my code was generated and I want to be able to see this.

And if we're later going to go back and do any fine tuning on that model,

having that text describing

what it was that was built is going to be really helpful.

Always remember, and this is kind of a universal truth,

I think that good code begets good code,

name things properly follow best practices.

When you do that GitHub, Wolf or GitHub Copilot will follow along with that.

And then finally, the most important part, probably the theme of this entire

presentation is above all else, go with the flow.

With that, I want to thank you for your time.