AI Engineer World's Fair 2024
Self-Evolving Code with AI: Enhancing Quality and Security in CI
Read the talk
Self-Evolving Code: Moving Deliberate AI Review into CI
A CI-based assistant can clarify code, build a behavioral test baseline, and debate security fixes before handing a reasoned proposal to a human reviewer.
From a talk by Gunjan Patel
Before you start: Familiarity with pull requests, CI, and unit tests will help you follow the workflow; no prior experience building AI agents is required.
Keeping routine work out of the coding flow
How much of developing software is actually writing application code, and what happens to your concentration when the work shifts to tests, documentation, and deployment? Gunjan Patel explores that problem through an independent side project, not a Palo Alto Networks product. At the time of the talk, he was a director of engineering there and had spent the preceding year and a half to two years moving into generative AI. He dedicates the talk to his close friend Nikhil, who had been enthusiastic about the conference and died unexpectedly two weeks earlier.
Patel starts with the relationship between skill and challenge described in the book he calls The Flow. A green flow zone sits between anxiety and boredom. A developer begins with an idea and writes code; a difficult problem raises the challenge and can push the developer toward anxiety. Then unit tests and documentation arrive. In Patel’s framing, those tasks can pull the same developer toward boredom because the work no longer matches their skill level.
The surrounding work is substantial: Kubernetes manifests, Dockerfiles, deployment, and tests all compete with application development. A copilot helps overcome immediate technical hurdles, but the developer still has to steer each interaction. Patel’s proposed change is to move routine work into CI, where it can proceed without continuously interrupting the person writing the code.
A ChatGPT meme supplies the joke behind that ambition: people at both ends of the spectrum simply use ChatGPT, while the person in the middle—Patel includes himself—juggles tools to get the work done. Moving tasks offline is also an attempt to reduce that juggling.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A ghostpilot has time to reconsider
Patel calls the offline assistant a ghostpilot. Sourcegraph Cody and GitHub Copilot illustrate the live alternative: they work beside a developer who expects a response in seconds. Code review has a different interaction pattern. A reviewer needs context, time to reflect, and opportunities to revise an answer.
| Dimension | Copilot | Ghostpilot |
|---|---|---|
| Interaction | Live assistance | Offline review |
| Immediate goal | Help with the next decision | Assess a change in context |
| Reasoning pattern | Quick response | Reflection and iteration |
Patel connects this distinction to Daniel Kahneman’s Thinking, Fast and Slow: the copilot fills the fast role, while the ghostpilot provides a slower, more deliberate process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Establish intent and behavior before proposing fixes
The workflow begins with a developer writing code using an IDE assistant, then submitting it through the pull-request process. CI performs an ordered sequence:
- Clarify intent. Improve variable names and comments so subsequent model calls have a better account of what the code is supposed to do.
- Establish behavior. Generate and run unit tests in a loop, creating a baseline of expected outputs for given inputs.
- Identify security issues. Use environmental context to look for missing security practices and relevant vulnerabilities.
- Propose fixes and rerun tests. Prepare changes for human review, then check them against the earlier baseline.
The order matters: clearer intent informs the tests, and the tests provide a behavioral check on later changes. Patel explicitly corrects himself when describing the last stage: the system proposes fixes; a human reviews them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Names and comments supply domain context
Why spend a CI stage on names and comments? Patel recalls a line from a conference session by Manuel: “LLMs are cultural technology.” The point is that a model’s knowledge extends beyond programming into domains such as finance, psychology, and art. Meaningful identifiers can connect the code to that broader knowledge.
In a finance application, rev may mean revenue to its author. Naming it annual_revenue makes both the domain and the time period explicit. Patel suggests that subsequent model calls—even calls to different providers—can then draw on financial knowledge and consider corner cases that an abbreviated name might not evoke. The name becomes context passed between stages.
Comments serve a related purpose, but they can become stale when someone changes code in a hurry. The useful information is the intended behavior, which may differ from what buggy code currently does. Improving comments should make that intention legible to the next model.
In Patel’s CI example, the assistant adds a high-level description of a code block’s expected flow. It also makes a server’s port identifier explicitly refer to a port number, distinguishing it from a port name. That small clarification becomes useful when the next stage decides which inputs and behaviors to test.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
List test cases before writing test code
The test stage builds coverage in layers: ordinary behavior first, corner cases second, and regression precautions drawn from historical bugs third. A project’s Jira history can reveal failures that deserve explicit coverage even when they are not obvious from the current code.
Patel reports that a single request to generate unit tests does a poor job in his workflow. CI offers room to separate the reasoning into multiple steps. People still care about CI completion time, but they are not waiting for each response in the same way they wait for an IDE suggestion.
The sequence is deliberately staged:
- Describe expected behavior. Have the model read the code, comments, README, and possibly a product requirements document, or PRD. It first states what the code should do. Requirements may describe overall intent without reaching function-level detail.
- Enumerate adversarial cases. Give the same model or another model an adversarial mindset. Ask for unusual characters, minimum and maximum values, and boundary conditions. List cases without writing tests yet.
- Personalize the list. Add cases based on team priorities in
context.yamland the project’s historical bugs. - Generate and run tests. Turn the assembled case list into test code, then iterate until the tests pass.
The intermediate case list makes the coverage decision explicit before the model commits to test implementation. Patel describes repeated model work as cheap or free labor, but supplies no cost measurements for this loop.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Combine declared context with inferred priorities
The context file describes the application’s operating environment: cloud provider, service, deployment location, whether the tool is internal or customer-facing, whether it handles personally identifiable information, and whether it is a frontend or backend application. Networking details, the PRD, and the Jira project connect that environment to requirements and bug history.
A Slack channel has a more ambitious proposed role: the assistant could ask a person for missing context. Patel explicitly says this interaction is not implemented. He compares the intended experience to Perplexity Pro asking a clarifying question when a request is unclear. Company security policies and InfoSec guidelines complete the declared context used for review.
A second portion of the context is inferred by AI. The model identifies the language and kind of code—such as infrastructure as code, backend code, or shell code—because each implies different review priorities. Historical bugs and escalations identify focus areas such as SQL injection, timeouts, and concurrent users. Patel also points to Quinn’s OpenCtx as a potential way to bring in additional context, rather than an integration already present in the project.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Debate which security findings warrant a fix
Security review uses that context to look for company security practices that are not being followed and for problems in logical flow. Patel distinguishes this goal from running static application security testing, or SAST. The task includes prioritizing findings, because asking a model to find problems tends to produce a list even when some issues are minor. A useful review must decide which ones warrant action.
To make that decision, Patel simulates three employees. For Python code, the roles receive different context:
| Role | Context supplied |
|---|---|
| Red-team engineer | Security policies and reviewed code |
| Python developer | Code author’s perspective and product requirements |
| Engineering manager | Business context, Zoom transcripts, Slack conversations, and PRD |
The developer represents the intent behind the implementation, while the manager brings in business constraints that a security-only reading could miss.
A prompt has the roles take turns debating each issue: what risk it creates, whether it needs fixing, and how much effort a fix requires. After the debate, a reflection step checks whether the answer still matches the original intent. That check can use a separate model. The output is therefore a considered priority decision, rather than merely the first reviewer’s list of concerns.
Patel then suggests an optional experiment he recalls from a podcast as an “Odyssey Journey”: imagine three possible future paths, then return to advise your past self. This is a proposed prompting exercise, not another established pipeline stage. He mentions research suggesting such approaches can outperform standard LLM use, but does not identify the study or give comparison conditions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A vulnerability in the placement of a condition
The concrete security example is a vulnerability in Kubernetes Go code that Patel describes as critical. He says he selected an issue from after GPT-3.5’s training cutoff. The relevant repair moves an if statement from one place in the control flow to another: the problem lies in when a condition is checked.
Patel reports that his workflow finds the issue and argues that SAST tools would miss it because it is a logical-flow problem. The talk does not identify the vulnerability, exact patch, model snapshot, or detection output, so this remains one reported example rather than a measured detection rate or a verified comparison with SAST.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Hand the reviewer a proposal, rationale, and test result
The final stage produces outcome-oriented suggestions, with the human reviewer deciding which fixes to accept. For each proposal, three bullet points summarize the simulated employees’ discussion and explain the priority. Security-policy citations give the reviewer a concrete basis for the recommendation. Before that handoff, CI reruns the unit tests established earlier to check the proposed change against the behavioral baseline.
Patel closes the technical demonstration with a deliberately simple example: a hard-coded API key. The review comment includes a risk score, an effort score, a recommendation, and a proposed code snippet. A Python recommendation for removing an embedded key can take this form:
python
import os
def load_api_key() -> str:
api_key = os.environ["SERVICE_API_KEY"]
if not api_key.strip():
raise ValueError("SERVICE_API_KEY must not be empty")
return api_key
This proposal moves the credential into runtime configuration and fails when it is missing or empty. The review still needs to explain the relevant policy, the risk being addressed, and the effort of supplying that configuration. The snippet is the proposed change; acceptance remains the human reviewer’s decision.
The closing slide points to Patel’s contact information and a GitHub repository. At the time of the recording, he says the code, GitLab CI files, and GitHub Actions files will be uploaded in the next few days. The implementation handoff is therefore a promised release, following a workflow whose final artifact is a tested, explained proposal for human review.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Experimental standard and source code for bringing external developer-tool context into code views. The repository was archived in May 2026.
Daniel Kahneman's account of intuitive and deliberative thinking supplies Patel's copilot-versus-ghostpilot analogy.
Further reading
Research on improving reasoning and factual answers through repeated debate among language-model instances.
Read the complete timestamped transcript
- 0:00
[on-hold music] My name is Gunjan Patel.
- 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.
- 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.
- 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.
- 0:57
Uh, and he was very enthusiastic about this conference itself. Um, so I wanna dedicate this talk to him.
- 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.
- 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.
- 1:34
In reality, what happens is, in the beginning, you have an idea, you start writing some code, initially crank out some code.
- 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.
- 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.
- 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
- 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.
- 2:48
Whenever you see something challenging, you can overcome that.
- 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.
- 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.
- 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?
- 3:41
Uh, copilot examples are, uh, Sourcegraph Cody, like Quinn just talked about earlier, uh, and GitHub Copilot.
- 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?
- 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.
- 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,
- 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.
- 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.
- 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.
- 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.
- 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...
- 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.
- 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.
- 5:59
Then third step is based on the environmental context, identify security issues, security best practices that are not followed. Um-
- 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,
- 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?
- 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.
- 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.
- 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.
- 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,
- 7:27
it will pull in its existing knowledge from all the finance world.
- 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.
- 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?
- 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?
- 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.
- 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.
- 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.
- 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
- 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.
- 9:25
So adding additional precautions to make sure those cases are covered.
- 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?
- 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.
- 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."
- 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.
- 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.
- 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.
- 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.
- 11:11
So we'll add few more unit tests at the end that are specifically applicable to this code and this application.
- 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?
- 11:31
Uh, because again, it's cheap labor, free labor.
- 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?
- 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?
- 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.
- 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.
- 12:28
Uh, and your company security policies, um, guidelines from your InfoSec team, if you have any.
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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.
- 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.
- 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,
- 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.
- 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."
- 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.
- 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.
- 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.
- 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.
- 16:35
Now, that's something that's when I run it through this, it's, it finds that issue.
- 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.
- 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.
- 17:10
Uh, so human reviewer has the context and security, uh, policy, uh, citation.
- 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.
- 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.
- 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.
- 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.
- 18:06
Uh, but thank you for coming. [upbeat music]