AI-generated code with OpenAI Codex

These models for them to be any good, for them to be productive, they've got to end up in software. And there's a reason that so much of the modern Internet infrastructure has been written in Go. It's a fairly small language. There's kind of one way of doing everything which is a struggle for people when they move into it. But after you accept that, it's just wonderful. So you can remember everything and that means you're more productive and you're less likely to create errors. I know as I've watched over the last few years, the modeling get out and be productive in all these different use cases. I think Go is a really good language for doing that. And terms of being able to get to productivity quickly with your models.

Big thanks to our partners Linode, Fastly and launchdarkly. We love Lino. They keep it fast and simple. Check them out@lino.com changelog our bandwidth is provided by Fastly. Learn more at fastly.com and get your feature flags powered by LaunchDarkly. Get a demo at launchdarkly.com this episode is brought to you by our friends at rudderstack and we're calling all data engineers to check out rudderstack Cloud and start building smart customer data pipelines. Rudderstack is is Warehouse first. No more silos. Rudderstack builds your customer data lake on your data warehouse, not theirs, enabling all functionality of a CDP with more security and retaining full ownership of your data. It's open source and API first. Rudderstack can be easily integrated into your existing development processes and because they're open source, you can see all their code so you don't have to worry about vendor lock in or black boxes. And best of all, they have transparent pricing. Stop paying your CDP a premium to store your data. Rudderstack is free up to 500,000 events and pricing scales transparently. From there, learn more and get started@rudderstack.com again. Rudderstack.com that's R U D D E R S T A C k dot com.

Welcome to Practically, a weekly podcast that makes artificial intelligence practical, productive and accessible to everyone. This is where conversations around AI, machine learning and data science and join the community and slack with us around various topics of the show@changeaw.com community and follow us on Twitter. We're @practicalaiping.

Welcome to another episode of Practical AI. This is Daniel Whitenack. I am a data scientist at SIL International and I'm joined as always by my co host Chris Benson who is a Tech student strategist at Lockheed Martin. How you doing, Chris?

Doing very well. It is Thanksgiving week as we record this and so I'm chilling out. No stress, man.

Yes. Getting the Tofurky ready.

Tofurkey. Absolutely.

Yes. I'm super pumped this week because Natalie Pastunovic is with us. Welcome, Natalie.

Thank you. Hi.

Hey.

So I met Natalie. I don't remember what year it was actually, but we were in Siberia. I do remember as well.

2016, I think.

Yes. So at a conference, 2016 in Siberia. We discussed a lot of Go and AI related things and I'm glad this has kind of come full circle. But also Natalie is a distinguished co host of our sister podcast Go Time, which is all about the Go programming language. There you go. Yeah, check that out. It's great to have some, some cross pollination, but yeah, Natalie, you're doing so much. You're a developer Advocate at Aerospike, OpenAI Ambassador, Google Developers expert, founder of various things. So very honored to have you on the show and excited to talk about all that. Maybe to start out, what's it like to be an OpenAI ambassador? What's involved in that and what do you get to do?

That's what I was wondering too.

I'm sorry, I signed an NDA. I cannot answer that.

Okay.

Right, right.

No, I'm kidding. I am getting to have a weekly sync with the other six developer ambassadors. So there's seven of us. And what we get to do is offer office hours for people who get access to GPT3 and to Codex and to all the other engines. And I get to hear all sorts of interesting ideas that people think and try to use the engines for and I get to offer them some help. And then we have a weekly sync that we chat between us, kind of interesting ideas that we saw, maybe tips that we can give to each other as ambassadors and we get to hear from the OpenAI team about what's fun and upcoming and we get to sign NDAs and we get to try all sorts of engines before they come out. So we got to play with Codex a while before it came out.

Yeah, that's awesome.

I have a follow up even to that where I'm diving into follow ups early on here. So without giving away someone's special sauce or super secret idea, what's a really cool thing that you've heard through that or that you've seen or anything?

I mean, just what interesting use case or something?

Yeah, she's having to think NDAs from.

The usage of GPT3 or Codex someone said hey, can we do this? And maybe it was like surprising to you or something. Anything like that that comes to mind?

Yeah, definitely. So one of the things that is less familiar or GPT 3 is kind of less in the tit titles 4 is that it has some endpoints that you can create your small little world of knowledge base and then ask it all sorts of questions and kind of maybe it will label things for you and so on. So one team wanted to use that to help them understand and kind of analyze cities and kind of like give them properties with that database so they kind of create their own. This is the information that I have about this city and now kind of give me back a description of it.

Very interesting. So I have to reveal I am a total biased user of GPT3 but also I recently got access to the copilot Codex stuff and have been trying it out. But at sil we, we had this problem where so we translate a lot of content right into various languages and we're working on technology that will help us estimate the quality of those translations. The problem is like if we're trying to work on that, we don't have a ton of data with like really bad translations. Right. Because everything we've published have been quality checked, good translations of whatever material. And so we, we use GPT3 to like help us generate like bad contradicting translations. So like we said, hey, here's like the source language and here's like what would be like a contradicting statement to this, to this or what would like follow this pattern of like removing like clauses or certain types of information or something. So that was actually very useful for us in kind of creating that labeled data set. Yeah, I don't know what's this sort of after you've seen a lot of use cases, what are the kinds of the things that people want to do most with GPT3? Is it like creating like movie scripts or is it like what's the thing that people want to do?

Most variations of marketing, so writing content or adjusting content to different audiences. Copy AI I think was one of the very early companies to have raised money that are built very much on top of GPT3 and many tried to reproduce what they did.

Yeah, not surprised by that.

Yeah, you also mentioned Codex. So we talked a little bit about GPT3 and we have mentioned that before on the show, but we haven't talked as much about Codex. Could you give us just like a brief sketch of what Codex is and what the intention is that someone might do with it?

Definitely. Codex is the engine that drives GitHub's copilot. This is one of OpenAI's engines and it is designed to not just perform general language tasks or natural language tasks, but it's specifically trained to translate language to code. And it's trained on some languages, so mostly 10 or 15 languages that it's really good at, but it performs great even in other languages that it was not meant to be trained for. So Python, it's the language that it performs best at. But as you mentioned, I'm a big fan of Go, and it's also one of the first languages on the list that it's supporting some unexpected languages that it supports. For example, is Shell.

Yeah, so like bash scripts, all the Bash magic.

Yeah, yeah, exactly. The data scientists jumped. Yes. Finally, all the O commands, all the step commands. Somebody's going to do that for me.

Yeah, I mean, it's probably better than my endless stream of copying commands from Stack Overflow, which sometimes do strange things on my local system, but yeah. So you mentioned Copilot. How do people use codecs in practice? So you kind of explained what it does a bit. How are people using it, or how is it intended to like impact people's workflow or development?

So probably the most used way of Codex is through Copilot, which is available as a VS code plugin. So anytime you use Copilot, you use Codex, whether you're aware or not. And if you have applied to the Codex waitlist and you got your access, then you see the exact same interface that you see when you use any GPT3 engine and you get to just kind of syntax highlighting, which is nice, and then kind of makes everything familiar for you. But you basically kind of give the same type of commands, write this for me or complete that for me, and you know that this will perform particularly good in code. And some fun things that I like showing when I'm saying what can it do is just mention casually kind of a name of a library, so no direct path or anything like that, and say add a unit, test or write a function, and here's the signature of it. And if we're talking to developers and I'm saying, hey, Daniel, can you take this client Go Client for Aerospike and kind of like do some example of crowd operations, you're like, okay, let me Google aerospike Go client, Let me look at the documentation, let me copy paste some examples. Let me change one thing. Oh, it broke. Wait, let me try again. Copilot, like three seconds okay, here's everything for you. Kind of mind blowing. It's so much faster than us and it does not make mistakes in the sense of using the library, but also in the syntax of the language. It's performing like it knows to do those two things in a few seconds with a little context that you're not even by the time you finish Googling it, already finished doing what you ask it to do.

Wow. So aside from speeding that process up, does it change your workflow in any other ways or is it just the time compression of getting to something productive?

It's changing, absolutely. So some people like reading the documentation and then going and trying things. Some people like just kind of finding some quick guide or even just copy pasting from Stack overflow and seeing how it goes, or maybe taking an example and playing with that. So sometimes the examples are not covering everything you need. So you can say, generate this example for me and then you can start playing with that. That's one thing it does. Some of the nice things that you can say is add a unit test, and then maybe it will do something that you did not think of. It can propose a different solution for the problem that you have. And then usually you make a pull request and then you start discussing. This is one way of doing that. But your colleague tells you you can also do it this way. And then you have this conversation. So this is becoming a lot faster because you're having this conversation with the AI. Or give me some proposals, something else, another way to implement this. Or here's this function signature and tell me, how would you implement that? And so it's sort of like pair programming with a computer.

Okay.

Write some unit tests. Whether if it's the boring part of just automate, like for all the different types, do that.

I'm sure there's a lot of data scientists out there who are like, oh, you mean I don't have to write all my unit tests? I've had a lot of interactions with data scientists who really want to write that code but are pretty hesitant to write tests.

Yeah. You can also say, refactor this for me.

Oh, yeah.

And I was going to ask. I mean, and it really goes with what you're kind of saying there, Daniel, is there's a point here where no code, you know, it's already kind of coming to realization in various places. Where does this go down the road? Do you think that are we going to be writing our own go pretty soon, or do you think we're just going to be giving kind of use cases and getting to that, or Python or pick your language, whatever it is.

I think that in the short term we will be using this in the IDE and getting all the help and different proposals and so on. But I do think that no code will go even one step further. So not just to your ide, because for having an IDE you need to have it set up, you need to, you know, whatever language binding set up and so on. I do see that the world of no code is developing even further to the place that with just an interface you can already play that. So kind of somebody will put a GUI on top of that and then it will be a few clicks and then it translates to that call to the API of codecs that then generates that code for you.

Gotcha.

So I'm curious, I mean, you mentioned the different languages that are supported, I'm assuming, and it would be interesting to dive into all of these details, which would take a whole nother episode. But I'm assuming that like a lot of code from GitHub was used to train this model. I've always been curious, like you mentioned, how it sort of doesn't make mistakes in terms of the syntax of the language and following those prompts. Is that because there's sort of like the prediction of like generated code plus an analysis of like, is this like valid syntax or not? Or like a rule based analysis of the syntax, like behind that? Because I know, like with generating natural text you can certainly generate things that are like, not grammatically correct, right? And I assume it's similar on the code side, generating things that are not syntactically valid or something like that. Any insights there in terms of how that happens?

Yes, this is a hot topic, especially around the time that the Copilot was released. First, there were lots of questions on what type of license had the content that it was trained on. So obviously it was only trained on the open code, right? Not anything that is private on GitHub and only on a specific set of licensed code. But some code is not licensed and even for some of the license types there was also a discussion whether it's okay or not and the code is generated correct, like whatever grammatically equivalent is for code. But what's interesting is that if you tell it something like generate an SSH key for me, it will generate a key for you. It will have the right syntax, so it will be the right length. It will not use forbidden characters, but it will not be a valid one. So this is also an interesting point, how it automates development, but not just yet. DevOps infrastructure in this world, because all the world of configurations, it will not do correct for you. You still have to put all the keys, you still have to set up all those values because it can generate a value in the right range. But does that value make sense? That's still to come.

This episode is brought to you by Imerit and their upcoming ML Data Ops Summit in partnership with TechCrunch. It's a virtual event happening December 2, 2021. Check out the speakers and register@imerit.net DataOps the event is gathering more than 700 attendees from top AI and ML companies and feature major speakers including Facebook, AI Cruise, Zoox, ge, Healthcare and more. And I'm here with Ivan Lee, the founder and CEO of datasor, who's also speaking at the event. Ivan, I know you'll be speaking at the conference on this subject, but can you share a teaser of what's happening right now in the NLP space?

If we look at the advances in NLP over the last few years, there have been some really exciting developments, Perhaps most notably OpenAI's GPT3 and their ability to just really start mimicking humans in generating snippets of English language. What we've noticed is that perhaps of all the branches of AI, NLP is one of the most mature. And there were some obvious use cases when we were starting out. There's things like the ability to handle customer support, improve upon chatbots. These were very clear verticals that we wanted to go after. But as we learned more, it turns out there's applications in the legal industry, in healthcare, in financial. There were a number of nonprofit organizations using us to label COVID 19 research and be able to just make sense of all the abundance of research that was coming out. We were kind of astounded by the creativity and the ways in which NLP could be produced.

All right, learn more and register to attend for this free virtual event@imerit.net DataOps Again, you'll hear from top AI and ML speakers who successfully deployed machine learning data operations in their organizations. Again, this event is free and it's virtual. Learn more enricher@imerit.net DataOps.

Okay, so I did get access to the GitHub, copilot, the trial or whatever they're calling it, and I've tried out a few things for a while. I didn't try it out because I'm one of those annoying people that use vim and so I was like, I don't really want to install VS code, But I did because I wanted to try it. And I think actually I could be wrong about this. But when I looked at the documentation last on Copilot, there was a little bullet that said neovim. So maybe I need to look a little bit deeper into that and play around with it. And I don't know if you have any info there, but I did try just like a whole bunch of things. And what I found interesting was there's sort of like tab complete kind of operations like you might find in Gmail, and then there's the like, prompt type of thing. So it does seem like there's. Am I correct on that, Natalie? That there's sort of like you can start typing something that you're about to do, like a loop or a function or something, and it will kind of tab complete a lot of things for you. Or you could like in natural text or a comment, tell it to do something for you. Do I have that right?

Yeah, those both are two ways of using it. Yeah.

Okay.

I saw a tweet the other day, a funny one, that says my next startup is going to be auto generated from scratch by codecs. I'm just gonna press tab until I have software and then let's see how it goes.

I did think like three years ago, and I probably should have done it, that I. I should have just created a script that bought. So took like real words and converted them into something AI and just like bought up a bunch of domains and then like sold them. But alas, I. I didn't.

You missed that opportunity.

Oh, boy. Yeah, I know, right? But yeah, like some of the things I did just to like, give people a sense. And this is like, I'm sure it's not as complicated as the things that you just mentioned, but as a simple example, I like started like a python list. Like data equals, you know, bracket one, comma two. And then it just like filled in the rest of the numbers for me up to a certain point. Right. And then it was cool because then I was like, well, I want to create a data frame now. Right? And that's going to be one of the columns. And I said, like labels equal bracket A, B. And then it filled in the same number of things but with the AB pattern. And then, you know, data frame, create data frame. It did that for me. And then I just said, you know, comment, you know, save data frame to CSV. And it did the thing. So that's just a very simple example, but it was pretty cool to see, like, For a non versus code user who was also learning how to use VS code at the time. I wrote things like very, very quickly, which maybe is blasphemous from. From a VEM user, but it was very exciting. I want to get back maybe to one thing you mentioned, Natalie, around the open source code and how it was trained and such. I wonder if you have any thoughts. One of the things that I've thought about this whole time with the OpenAI codec stuff is that open source code is really like a lot of it's really bad and there's a lot of closed source code that's really good. Was there like. And if you don't know, it's fine. But outside of like the licensing issue in terms of code quality, like what code might be there and also there's all sorts of stylistic opinions that people have. So is that part of that, like providing ways to have people have alternates or something like that?

So the wonderful thing about GO is that there's no different styles. There's gofmt, which is a formatting function and then we all use that. So not in my universe. I think you probably can see different styles. I think if you use Copilot, it will stick to the style that you started if you use a different language. And I do think that if you use the prompt, so kind of a clean way of interacting with it, you will see sometimes one style and sometimes another style.

Gotcha.

And training on good versus bad code. That's a wonderful question. It's a model that's trained on hundreds of millions of parameters. Certainly there's good and bad code. I don't know if it represents the ratio of good bad code in open and closed source. I don't know if such a number exists.

Yeah, I'm just thinking that there's code out there that is in the open that I've written that I wouldn't want anything emulating. So maybe I should deal with that on my own.

I'll take a stab at that.

At my bad code or.

No, no, no, no, just the general because I mean this has come up before. I think open source tends to be better than closed source because open source people are going to see if it's out there on GitHub or any other place people will see it and people are embarrassed to publish code that's just not very good. But in closed source they do it all the time.

I have no shame, I guess.

Yeah, there's open source, there's closed source and there's Daniel's Code.

Yeah, yeah, it's a whole nother category.

That adds up to ocd.

Yeah, right, yeah, that works out, which is also a part of my life. So we've mentioned GO quite a bit. There's probably a good portion of our audience that might not even be aware of what GO is. Could you just like maybe give a couple of minutes of like, if I don't know what GO is, what is it and how is it sort of like used in things that I might be familiar with?

It's a statically typed language that just celebrated its 12th birthday. It came from Google, but it's used everywhere. So not private to Google in any way. And there's lots of community contributions, obviously more as time goes. So the closest language to it is Pascal, or Pascal as I heard the American pronunciation for it. Right.

I like yours better.

It's pretty close to C, but it has all sorts of benefits like built in concurrency and parallelism. It has safety and it's used in all sorts of tools that you know. So it obviously in the beginning it was used mostly for web development, so lots of websites and it kind of bubbled into the world of DevOps and infrastructure. So Docker is written in go, Kubernetes is written in Go. If you do monitoring, you might have heard of Prometheus or Jaeger. Both are also written in Go. SpaceX is unofficially shared. They're using Go, so it will be on Mars soon.

Exciting. Yeah, I know also that Go is used at cern. I have a friend there that's using GO for high energy physics. It's a whole, whole range of things.

Yeah, yeah, yeah. It's mostly backend. It's not exactly great for front end. But surely you can do something also you probably can do something with mobile if you really want to. I personally see it not just a great fit for web and for tooling, but also for things like machine learning. And I think we've both been preaching the idea of using GO in the infrastructure of systems that do machine learning, so serve AI models because it's wonderful with parallelism and concurrency and it's super fast and it has this really nice feature that it's very easily cross compilable. So one CLI command, add the flag and you're good. So that's also why teams that do tooling internally really love that because you have five people or five types of operating systems and whatnot and architectures, you just add all flags done. Your binaries run everywhere.

Yeah. And I definitely am really excited that this messaging is getting out on this channel, because I definitely believe in what you're saying on our team. And it's sort of a mix, right? I think it's still a mix, because maybe you can comment on your workflow with this, Natalie, but there's so much tooling in the sort of experimentation phase of AI around training and testing models. That's really great in Python, but our team has found that as you transition that out, you've done your experimentation. You know, this model architecture and this sort of data is like what we want to do and it's useful in these ways. This is like the access pattern and how we want to run inference, then like transferring to running that behind an API that's written in Go, or a streaming server that's written in Go, or some type of like batch processing infrastructure that's written in Go that sort of integrates with that model is what we've found to be a really useful pattern in. In my own work. I don't know if you have any comment about that, Natalie, if I'm off or if you have other thoughts.

No, I definitely share this view that this is a great choice, although it's not a trivial one. And I do think that as AI kind of bubbles into any field like legal tech or agritech or whatnot, this is all becoming things of how do you serve your AI model? One thing is kind of have it trained and running, but then comes everything else. And there is a wonderful paper by a group of Googlers from 2015 about the technical debt of AI systems. And it's kind of what happens when you patch up a system that does ML and quickly upload it to production. And it lists over 12 or so pages of everything that can go bad and all the considerations you should have. And it's things that in the past, you may have not thought of them in the context of systems that serve AI, but you just thought of them as kind of general system. So any website, but monitoring security, all the additional stuff that, like making sure that things are working, all these systems, it's the wonderful ecosystem of infrastructure that already has the perfect ecosystem inside Go. Everything you need is kind of already there. So plugging those two together is even a better reason for using Go, because GO is really fast for serving your model and also really useful for monitoring everything.

There's a thing, and I know we've brought it up before, and that is that these models, for them to be any good, for them to be productive, they've got to end up in software. And there's a reason that so much of the modern Internet infrastructure has been written in Go. It gives you all those things that you just talked about. It gives you two other things that we alluded to earlier. I just wanted to bring back up was it's a fairly small language. And part of that is as going back to what you were saying is, there's kind of one way of doing everything, which is a struggle for people when they move into it. But after you accept that, it's just wonderful. So you can remember everything fairly easily. And that means you're more productive and you're less likely to create errors. And so I know, as I've watched over the last few years, the modeling get out and be productive in all these different use cases. I think Go is a really good language for doing that in terms of being able to get to productivity quickly with your model.

And one other benefit for this characteristic of Go is that if you have the AI generate a huge chunk of Go, it will look exactly like the code that you wrote, because there's only one way of doing that. So you know that uncanny valley of robots, you're not going to see the uncanny value of code.

If it looks too human, it's too creepy.

But once you cannot tell whether if it's a. Whether it's a robot or a human, you're happy with it again. And because there's only one way of writing Go code visually, you will not be able to know who generated that. So you're not falling into that uncanny valley, unlike with many other languages that have multiple formats.

True.

So that's why it's a great language for AI.

So, like, sort of bringing this back to the Codex world. So if we're generating code and there's like a lot of variability in style or how you might do something or even like, things like there's a lot of Python 2 code out there and Python 3 code out there. Right. You know, Go sort of is more consistent like that. So would you say that, like, it's maybe a bit easier to get bigger chunks of code generated in GO than like, just kind of the small helps that I was alluding to earlier in Python, where, like, I was doing smallish things.

Yeah. And you will feel easier reading it and integrating that into your code base or creating that to be your code base and you integrate into that.

We are going to save three, two, one.

I'm Kahar Lazu, host of Shipit, a show with weekly episodes about getting your best ideas into the world and seeing what happens. We Talk about code ops infrastructure and the people that make it happen. Like charity majors from Honeycomb.

We act like great engineers make great teams. It's exactly the opposite, in fact. It is great teams that make great engineers.

And they farley when the founders of Continuous Delivery start off assuming that we're.

Wrong rather than assuming that we're right, test our ideas, try and falsify our ideas. Those are better ways of doing work.

And it doesn't really matter what work.

It is that you're doing.

That stuff just works better. We even experiment on our own open source podcasting platform so that you can see how we implement specific tools and services within changelog.com. what works and what fails.

It's like there's a brand new hammer and we grab hold of it and everyone gathers around, we put our hand out and we. We strike it right on our thumb. And then everybody knows that hammer really hurts when you strike it on your thumb. I'm glad those guys did it. I've learned something instead.

Yeah, I think that's a very interesting perspective, but I don't see that way. Okay, it's an amazing analogy, but I'm not sure that applies here.

Listen to an episode that seems interesting or helpful, and if you like it, subscribe today. We'd love to have you with us.

So we were talking just before we started recording about this whole world of ML Ops or AI Ops and how that is like, so, so much of the conversation in the AI world is centered around this. We've got sort of various takes on this over time on the podcast, and I'm curious, like, when you're thinking of mlops or like when you're thinking of a project that is coming up in your pipeline and involves machine learning or AI in some way. Like, what is it that you have in mind in terms of like the mlops things that you need to be thinking about?

So kind of what is a Checklist for your MLOps project?

Like, what are the first things that are like, yeah, the necessities of ML Ops that are just crucial to making things work in production.

It's a great question. And I think it's getting this bare minimum, it's getting more complex or like the longer. Every year this list gets a bit longer. So you definitely need to have some sort of data processing. Right, data governance variation, you'll call that. You need something for serving the model. You need something for the feedback loop of retraining it online or offline. So a growing trend that I noticed over the last year or two is about feature extraction, feature engineering, feature stores and so on. So you almost cannot ignore this anymore in the context of MLOps, I guess because it's an AI podcast, we don't need to talk what is a feature which is fun. We get to talk instead about what is go. But the reason that I think that Go is a good choice for that, for things about features is again, it's that it's really fast in all the different benchmarks, partly because the good concurrency and it's also easy to utilize this feature there.

Yeah, we were also talking with for the show about how both of us have been trying to promote this within the Go community. And I'm really excited because you are giving a talk at the upcoming Gopher Con. So this will be December of 2021 for those listening in. So if you can find it on the Internet after that, what are you hoping that sort of your audience takes away from that talk at GopherCon, who may be an audience that isn't as familiar with AI, but is into all of these infrastructure and monitoring things? What are some of the takeaways that you hope they'll have?

So for the good practices of mlops, there's some short checklist of things that you should have in mind, like be aware of all the things that MLOPs mean and why GO is a great choice for that and the more general cause that I have, and I hope that everybody who comes to the talk eventually will have is kind of a heads up of this is how AI is likely to integrate into your developer flow, whatever it is you're doing with Go, or even in another language really. And you know, you can be cynical about this. You can say, nah, I'll stick to what I know. But you can also utilize all the different benefits that we said. Like you can automate boring parts. So, you know, we all love Kubernetes for doing that for us. Not just because it's boring, but also it actually prevents us from making mistakes. You get inspired for all the auto completions or the alternatives that it offers for you. And a huge thing that we didn't give enough focus that it can do is that documentation, but like both ways documentation. Right. It can help you document your own code and it can help you read somebody else's code if the documentation is bad, nonexistent, or just a language that you don't know.

Can Codex add comments? Like I can just say add comments to this text or comments to this code. Will it do that yet?

Yeah, explain this code.

Awesome. That's awesome.

It can be something like, help me understand this code base that I wrote last year because I forgot what I did there.

That hits home. It does.

I was just thinking that. Exactly. I always look back on my old code and go, oh, who did that?

Who hacked into my computer and changed everything? And then also changed the history of commits and the timestamp. How dare they?

Exactly.

So sometimes you have to understand what somebody else did. Like for example, I'm really not good in front end technologies. I am generalizing. I've barely experienced working with any of these. But sometimes you have to understand what's happening. So I can go and try to understand it. I can go and find a developer to explain that to me, or I can just highlight this and say, hey, AI, please explain this for me.

So I have a question for you. I actually want to take the same question Daniel asked you about kind of, you know, bringing the Go folks kind of into AI. And for some of the folks that are listening to this podcast right now and they've been hearing us talking about go, they may not have been exposed to it very much in the past, maybe not at all, and. But they're now kind of curious, having heard the three of us chit chatting about it for a few minutes. How would they incorporate that or start to. What would be a reasonable way of them doing that to get that into their flow right now? Maybe alongside their Python, What's a good first step for them?

If you have access to Copilot or Codex, just take any code in Python, highlight it and says, rewrite that into go, run that, see what happens.

That's fantastic.

That's one thing I would do right away because I first like to play with that and then I'm going to go and read the docs and kind of go through the tutorial. So once you've played with that a little bit and got excited, Google for the tour of go. This is a fun little sandbox that you can like. It's a guided step by step of all the things that you need to know. It's not specific for AIOps, it's not specific for ops in general, but it does cover most of the interesting features of GO, and kind of helps you understand how it's built and what's happening under the surface and how can you utilize the fun features that it has. It's been around for a while. You can definitely find some code examples if you want to see. Daniel, is there a workshop that you're giving about this topic about infrastructure in Go for ML? Stuff. Is it available anywhere?

Yeah. So I'm giving an updated workshop at the upcoming GopherCon, so thanks for bringing up. There will be the Gopher Con event in early December and there are workshops also. The main event is free for everyone. That's my understanding this year. So the sort of main talks you'll be able to join. But then, yeah, I'm going to post an updated version of my workshop this, you know, around the time of the workshop. So if you're listening to this and it's early December, you can check out my GitHub and see some updated things there. But yeah, I think it's a great idea, Natalie, to like rewrite some Python stuff and go to see how it might look. It's fun to see the codecs can be like a productivity thing, but maybe it can also be a learning thing. Chris, I don't know if you remember, one of the early shows that we had was there was an app that helped African farmers identify disease spots on cassava plants. I do remember the model was completely capable of saying this is diseased or not, but the intentionality behind the app was that it wanted to sort of help infuse that knowledge in the community. Right. So it's, it pointed out things and sort of explained why they might be indicative of what you know. And by doing that it sort of freed the community from dependence on the app and that knowledge was sort of infused. So it's cool to see that like, you know, these tools can also, you know, automate things for us, but also help us kind of gain knowledge in new areas a lot quicker.

So, yeah, kind of cool when AI brings humanity into focus there.

Yeah, yeah. Natalie, I know you do a lot of community related things, whether it's the OpenAI stuff or it's related to Google Developers or with GopherCon Europe or GopherCon. When you're sort of talking about AI and machine learning, I'm just curious how you've seen those conversations shift over time because I think early on I heard people talking about Terminator and Sentient things. I've seen some of those conversations shift over time to other, maybe more useful subjects. But as you're interacting with those communities, have you noticed any trends in terms of people's interest in AI or their fear around AI or their desire to do this or that or any thoughts on that?

Yeah, I think in 2017 I talked and shared some code that I wrote on how to use go with TensorFlow, which seemed as unrelated as using Go with Mobile. Go with Mobile has Never really picked up. It's still under the experimental path of the Go project. But the TensorFlow API actually is available in Go. And I guess it came not just from the side of the software of like here's how you can use that and use that API and so on, but also from the side of the infrastructure. Here is how the entire monitoring and DevOps ecosystem that is already in go mostly just fitting itself nicely with ML As ML&AI bubble into the average tech stack. So now you have front end, you have backend and you have AI. Everything is getting automated and we obviously have to support that as DevOps people, as infrastructure people, as backend people, as a tech team.

That's a great point. I love that point. I'm going to steal your point going forward is that we find ourselves commonly talking about how AI, you know, is in software, it's a part of software now and stuff. But the way that you just put it in terms of a front end and back end, now there's AI and there's a reason for it's not just for data scientists, it's for developers. And there's so many tools like what you're working on that are making it accessible to people. How do you think that will change the software development world going forward in terms of how non specialists in AI are engaging now that these new tools like Copilot and Codecs are becoming part of the workflow?

I think it will make things faster and efficient in the sense of how in the past you developed code by writing everything and then IDEs came and got all those fun plugins and useful things like show me the signature, help me find quickly where the function is defined and so on and it became a part of your workflow. Although depends how back you go for the developer's history, this would be considered a cheat. And like I don't need that, I just need needs the clear notepad. So I see this as a next step of something that fits the world of developer productivity. It also helps boost the world of no code, which kind of introduces into the community of people who create tech people who don't know code just because they will have the tools that will translate their English commands into tech or into code. Right. So we as developers, we kind of in our mind we do this translation from our instructions In English, the GitHub issue from the product manager, whatever, you translate that into code and then the machine goes and translates that into compiled binaries for you. So in addition to this flow being more efficient, it's going one level up of abstraction that I will just write in English what I need. I will play with the GUI and the AI will tell the computer to compile the code that it generated for us. So I see that as we go forward there'll be like these two branches of developer productivity, but I also see that things like infrastructure and monitoring not necessarily going to be as affected by that because you cannot have it. Like you cannot say to the AI, create a config file for me and you can just go ahead and use that because the numbers will be funny and the keys will be funny as we talked in the beginning. So this is something that people will still have to manually do for a while.

Yeah, I hope that maybe that comes someday. But I think even those other things that you mentioned are just like an amazing new kind of development and how we write code and how we think about the things that we automate and the code that we generate. So I'm super happy that you joined us on the other podcast in changelog and we will include a number of links that are relevant to this discussion, including the wait list for the codec system, along with the sign up for Copilot. I will also include links to GopherCon and all the cool go stuff that we mentioned. So if you're interested in either of those things, definitely check out those links and make sure and listen to Natalie's upcoming talk at GopherCon. I know I will be so thanks so much Natalie. Appreciate you taking time to join us.

Thanks Daniel. Thanks Chris.

That's our show. Thanks for listening. For more like this, check out our Master feed. It is all changelog podcasts in one easy to consume place. Let your podcast app snag everything we produce and then pick and choose which ones to listen to. Subscribe today@changelog.com master or just search for changelog master in your podcast app of choice. You'll find it. Special thanks to Breakmaster Cylinder for providing our music and to our longtime sponsors Fastly, LaunchDarkly and Linode. That's all for this week. We'll talk to you again next time.

Sam.