Self-Evolving Code with AI: Enhancing Quality and Security in CI

Talk transcript

1. 0:00

   [on-hold music] My name is Gunjan Patel.

2. 0:15

   Um, I'm a director of engineering at Palo Alto Networks. Uh, like many of you in the last year and a half or two years, I've pivoted to working on generative AI.

3. 0:26

   Um, the talk today is about self-evolving code. I'm not here to sell you anything. None of this is a product from our company. Uh, this is, um, a side project that I've been exploring.

4. 0:40

   Before we get started with this talk, um, I would like to dedicate this talk to my close friend, Nikhil, who passed away two weeks ago. Um, it was unexpected, uh, but, um, he was very excited for me to come and do this talk.

5. 0:57

   Uh, and he was very enthusiastic about this conference itself. Um, so I wanna dedicate this talk to him.

6. 1:06

   Okay. Let's start with the coding flow. Uh, if you read the book called The Flow, um, it talks about this zone where, uh, your skills on one axis, your, your skills and how challenging the problem is on the next, on x-axis.

7. 1:25

   As you're starting to work on a project, you should be somewhere within that green zone to stay in the flow state.

8. 1:34

   In reality, what happens is, in the beginning, you have an idea, you start writing some code, initially crank out some code.

9. 1:42

   Then you have a little bit of a difficult problem, so it cranks up the, uh, direction a little bit to the anxiety, may even go a little bit into anxiety.

10. 1:53

    And then you have to write unit tests, and then it goes straight to the boredom part, uh, because it's, uh, your skill levels are quite higher, but nobody likes writing unit tests, uh, or code documentation.

11. 2:10

    So what's the problem there? As a developer, you're... When you're writing code, uh, when you're developing software, writing code is a small portion of that entire flow, right? Uh, you have to work with a lot of stuff like, you know, uh, building Kubernetes, uh, like manifest, building Docker file, et cetera, deploying stuff, writing unit

12. 2:35

    tests. So then there is this copilot duct tape. Yes, uh, having something like a copilot that would help you get through a lot of technical hurdles on, uh, coding side.

13. 2:48

    Whenever you see something challenging, you can overcome that.

14. 2:52

    Um, but we are trying to outsource more and more of that to do offline, right? So you have, you as a developer, have more time to write code. So the key part in this talk is about outsourcing a boring task, uh, to CI.

15. 3:11

    Uh, [chuckles] uh, had to insert this meme here, um, that like on both ends of the spectrum, people use ChatGPT. In the middle, the mid, uh, such as myself, is like juggling all these different tools, trying to figure out how to write the code.

16. 3:29

    Okay, let's get into this. Uh, so what's the difference between copilot and, uh, I just coined this term ghostpilot. Uh, copilots are made for quick just-in-time dec-- uh, decisions, right?

17. 3:41

    Uh, copilot examples are, uh, Sourcegraph Cody, like Quinn just talked about earlier, uh, and GitHub Copilot.

18. 3:50

    They work with developer lives. Developers are impatient. You need response in seconds. Uh, uh, how good of a tool it is, partly measured by how quick the responses are, right?

19. 4:04

    Um, code review-- A code reviewer is made to have a deliberate thinking, right? When you write code and then a code reviewer is reviewing your code, it's deliberate thinking.

20. 4:17

    It's not just guess the next word, uh, at this point. Uh, you need to ref-reflect on the answers that, uh,

21. 4:25

    that you're providing or, uh, like human code reviewer, uh, being aware of the full context and, uh, to update the answer, right? So some of those things require... They need time, they require iteration.

22. 4:41

    Uh, so one, one example is, uh, this book called Thinking, Fast and Slow. Uh, so if you think about copilots as thinking fast, uh, the slow system is this, uh, ghostpilot system.

23. 4:57

    So this is the high-level architecture, uh, I'm talking about here. Developer writes, um, code using, uh, a copilot or IDE assistant, uh, tool.

24. 5:11

    They check in the code in, in CI, in the-- during the pull request process. Uh, the first step is, uh, improving code vari-- uh, code comments and variable names.

25. 5:24

    Second step is adding and running, running unit tests in a loop. Uh, and I'll go into each of these steps in more detail. Uh, adding unit tests here early on...

26. 5:35

    Uh, sorry. Let me talk about the first step. Doing the first step properly means adding unit tests makes more sense, right? Like you need AI to understand what is the intent of this piece of code.

27. 5:49

    Uh, adding unit tests early on sets a baseline behavior for the code that this is-- if this is the input, this is the expected output. So it's set- it's setting the baseline.

28. 5:59

    Then third step is based on the environmental context, identify security issues, security best practices that are not followed. Um-

29. 6:08

    And fourth step is fixing them. And after fix-- proposing a fix, not fixing them, proposing a fix for a human to review, uh,

30. 6:18

    run the unit test again. So let's go into each of these steps. So first one, why improve variable names, uh, and code comments?

31. 6:29

    Uh, yesterday there was a session here from Manuel, uh, that he, he wrote this line: "LLMs are cultural technology," right? LLMs are built based on all the knowledge in the world, not just coding knowledge.

32. 6:43

    Like most of us here, we know a lot more about coding than art or how humans behave, uh, psychology, et cetera. But LLMs have all that knowledge stuffed into them.

33. 6:56

    We should figure out how to utilize that completely, right? So an example is if you're working at a finance company, for example, and use a variable name rev, it makes sense to you, like revenue, in that con- small context of your code.

34. 7:15

    Uh, but improving it to annual revenue, and then in the subsequent steps, if, uh, LLM is run, uh, using different, um, different LLM providers,

35. 7:27

    it will pull in its existing knowledge from all the finance world.

36. 7:32

    So there may be some corner cases that may not have been discovered if you just use the variable name rev versus annual revenue.

37. 7:41

    Um, the second part is, uh, improving good, uh, improving code comments, right? Uh, code com-comments can get out of date quickly. If someone is in a hurry, makes change to a piece of code without improving the code comment, uh, then it's out of date, right?

38. 7:58

    Like, it doesn't state the developer's intent. So improving that, um, to make sure that LLMs understand what is intended behavior of this code, even though-- even if the code may not reflect it, and that's why we have bugs, right?

39. 8:14

    There's the intent. Nobody intends to have a bug. Uh, so making that intention of the code block clear, that's why we improve the code comments.

40. 8:25

    So this is a small example of that. Um, you can see, uh, in CI, it's adding high-level flow of what is expected from this code, uh, code block. Um, here, like, it's a server, so I just put port, and it improved the port number because it could be port name or port number.

41. 8:48

    Uh, I don't think about those things, but, uh, when it comes to adding unit tests, AI-generated unit tests, it ma- it becomes important.

42. 8:59

    Second one is adding unit tests. So adding unit tests, as I said earlier, it's to set the baseline behavior. Um, uh, then

43. 9:09

    o-once we have the baseline behavior, we can add second layer of unit tests co- uh, for covering corner cases. Third one is to get context from historical bugs. Uh, what, uh, looking at Jira fetching for this project, we have seen these kind of bugs in the, in the past.

44. 9:25

    So adding additional precautions to make sure those cases are covered.

45. 9:31

    So what are the steps like? It's not asking an LLM to say, "Generate unit test for this code." It doesn't do a very good job. Uh, and this is where having iterations comes into play, right?

46. 9:45

    So first one we do is, um, because we have all the time in the world, people are not rushing for CI jobs to complete. I mean, yeah, a lot of people are impatient, uh, but it's not like when you're writing code, uh, with an IDE-based assistant, you need response quickly.

47. 10:02

    So what we do in, in this one is set the baseline. So, uh, LLM outputs the expected behavior of this code. N-not the person who wrote it. LLM will read it and say, "Okay, this is the expected behavior."

48. 10:15

    Uh, it will take things into consideration like, uh, code comments, README file, and maybe a PRD document. It may not go into function-level details, but overall intent is there.

49. 10:29

    Uh, then in the next step, uh, we added adversarial mindset. Uh, you can use the same model or a different model and say, uh, system prompt is, uh, you assume adversarial mindset and what are the edge cases.

50. 10:44

    A- think about weird characters, min, max, all the boundary conditions, and add, list out the unit test cases. Don't write the unit test yet, just list it out. Then, uh, personalize the code.

51. 10:56

    Personalizing happens from team priorities that, uh, are written in context.yaml file, which I'll cover in a second. Um, and historic bugs again. So personalizing which unit tests to add based on that.

52. 11:11

    So we'll add few more unit tests at the end that are specifically applicable to this code and this application.

53. 11:18

    And then the last step is, here's the unit test cases we need to cover, generate unit tests. And then it will do a much better job, and then it can go in a loop until they pass, right?

54. 11:31

    Uh, because again, it's cheap labor, free labor.

55. 11:36

    Uh, this is what the context looks like. Uh, context is used in the n- uh, step three, but things like what is the cloud provider? What is the service?

56. 11:45

    Where is it deployed? Is it a company internal tool or a customer-facing tool? Is there PII data in it? Um, is it a front-end or back-end, uh, application?

57. 11:56

    Networking, PRD. Where, where is the Jira project to pull all the bug reports and, uh, more information on this project? Slack channel. Now, this is important. I haven't implemented this part yet, but where it could go and ask follow-up questions to the user saying, "Hey, I'm not sure about this context.

58. 12:15

    It's missing this context." Similar to, uh, if you use Perplexity, uh, and use Perplexity Pro, you ask a question, it's not clear, we'll ask you a question back. Uh, so that's what this is designed to do.

59. 12:28

    Uh, and your company security policies, um, guidelines from your InfoSec team, if you have any.

60. 12:36

    Then second part of the context is built, uh, using AI. So AI infers this context. Uh, what language is this? Is this IAC code or is this back-end code, uh, shell code, et cetera?

61. 12:49

    Uh, because you will have different priorities based on that. Uh, what are the focus areas? That comes from historical bugs, uh, SQL injection, timeout errors, concurrent users, uh, whatever issues as, and escalations you've had in the past.

62. 13:05

    Um, here s- uh, Quinn has done a great job on opencontext.org. Uh, that's a potential integration point here, uh, as well for bringing in additional context.

63. 13:20

    Finding security bugs. Now, uh, security issues. So security best pract-- This is not just looking... It's different from running static code analysis and, uh, diff- running SaaS-based tools. It's finding sec- which security best practices are not followed that your company may have policies around.

64. 13:38

    Uh, logical flow based issues. Uh, I'll show you an example in a bit. Uh, and prioritize which ones need fixing, right? Not just identify, because when you ask AI to find issues, it's going to find issues.

65. 13:52

    Uh, it's never gonna say, "No, it's fine. I mean, it's a small issue," but it's gonna say something is wrong.

66. 14:00

    So how do we do that? This is, this is a little bit of a weird slide now, right? Uh, what I'm doing here is simulating three AI employees, right?

67. 14:13

    Um, one is a red team engineer, one is a Python developer, assuming this is Python code, and an engineering manager. Uh, engineering managers are useful for something, uh, other than, uh, talking in meetings.

68. 14:28

    Uh. [laughing] So what context am I providing the red team engineer? Security policies and the code that's written, uh, or the code that's being reviewed. Python developer will assume the identity of the person who wrote this code, uh, and the PRD, uh, product requirements.

69. 14:46

    Engineering manager will have business side of things, uh, business context, so, uh, Zoom meeting transcripts, uh, Slack channel conversations and PRD. Now,

70. 15:00

    there is a prompt to have these three people take turn, multi-turn, and then debate among each other on each of the security issues on identifying what is the risks associated with it and which ones need to be fixed, and what is the effort for it.

71. 15:16

    And at the end, after they're done with the debate, uh, self-reflect on the answer and say, "Okay, this is," you know. And that could be a s-separate model. It could look at the answer and say, "Okay, this is matching the original intent or not."

72. 15:32

    Uh, some fun things you could try. Um, I was listening to a podcast recently, and they talked about Odyssey Journey, which is like you think about like three potential paths you could take, uh, and then time travel back and then talk to your past self.

73. 15:47

    Now, that's not really possible in real life, but in here we can do that. Um, with AI, it's, it's all fun, um, but it, uh, there is some research paper that show that this is actually more effective than just using LLMs, uh, as a standard tool.

74. 16:07

    Uh, this is an example. Uh, this was a Kubernetes bug, uh, in the Go code. It was a critical severity bug. Uh, and I made sure to find this issue from after the training end, so GPT-3.5, uh, training date end.

75. 16:22

    Uh, this was-- This wouldn't have been picked up in any of the SaaS tools because it's a logical thing. This if sta-statement needs to go from here to here, and that caused the, uh, security vulnerability.

76. 16:35

    Now, that's something that's when I run it through this, it's, it finds that issue.

77. 16:43

    Last one is fixing the security issues. So this is outcome based, uh, and it's again, suggestion, uh, of what to fix, and then human reviewer comes in at the end and, uh, decides which ones to actually fix.

78. 16:57

    For each of the fix, explain the reasoning why it's prioritized. Uh, that all the conversation that the, the three virtual employees had ha- have had, uh, it's summarized in three bullet points.

79. 17:10

    Uh, so human reviewer has the context and security, uh, policy, uh, citation.

80. 17:18

    And at the end, make sure before a human comes in, run the unit tests that were establishing the baseline early on, so a human doesn't have to waste their time, uh, with verifying the fix.

81. 17:32

    Um, this is not a great example, but a simple example of what it would look like in a, a code comment, uh, hard-coded API key. I mean, most people wouldn't have that.

82. 17:43

    Uh, what is the risk score? What is the effort score? Uh, what is the recommendation? Which is the code snippet? And then fix it afterwards.

83. 17:52

    Uh, that's it. This, these are, this is my information. This is the GitHub repo. Uh, I will upload the code, uh, the GitLab CI and GitHub Actions, uh, files there in the next few days, uh, so bear with me.

84. 18:06

    Uh, but thank you for coming. [upbeat music]