AI tasks that need patience and iteration can move from the developer's editor into CI.
2
A sequence of prompts can clarify code intent, generate unit tests, and use project history to cover relevant edge cases.
3
Security review can combine several AI roles with company context, followed by human approval of proposed fixes.
Summary
Gunjan Patel describes a CI workflow for code that improves its readability, tests, and security after a developer checks it in. He distinguishes fast coding assistants, which need to answer within seconds, from a slower system that can iterate during a pull request. The workflow first improves variable names and comments so the code's intent is clearer. It then establishes expected behavior, asks an adversarial model to list edge cases, adds tests based on team priorities and historical bugs, and runs them in a loop. For security, the system uses project context and simulates a red-team engineer, a developer, and an engineering manager who debate the risks and effort of proposed fixes. The system suggests changes rather than applying them automatically. A human reviews the reasoning, policies, and code changes after baseline tests run. Patel presents this as a side project with a GitHub repository and planned GitHub Actions and GitLab CI files.
CI can take over repetitive work that interrupts coding
Patel begins with the difference between the work developers enjoy and the work required to ship software. Writing code is only a small part of the full flow. Developers also build Kubernetes manifests and Dockerfiles, deploy systems, write unit tests, and maintain documentation. A coding assistant helps with immediate technical hurdles, but Patel wants slower, repeatable work to happen offline in CI. He calls this approach a "ghost pilot". A coding copilot helps with quick, just-in-time decisions, while the CI system has time to reflect, gather context, and iterate during a pull request.
Clear names and comments give AI a better statement of intent
The first CI step improves variable names and comments. Patel gives the example of a finance application where a variable named "rev" may mean revenue to the original developer. Changing it to "annual revenue" gives later models more useful context from finance-related knowledge. Comments also become stale when code changes under deadline pressure. The workflow updates comments to describe the intended behavior of a code block, even when the implementation no longer fully matches that intent. In his example, a vague port value becomes more explicit because it could refer to a port name or a port number.
Unit-test generation works better as a sequence of smaller prompts
Patel does not ask an AI model to generate tests immediately from a function. The workflow first asks the model to describe the expected behavior using the code, comments, README, and possibly a product requirements document. Another prompt takes an adversarial view and lists boundary cases, including unusual characters and minimum and maximum values. Team priorities from a context.yaml file and bugs from the project's history add application-specific cases. Only then does the system generate the tests. It can repeat the process until the tests pass. The baseline behavior is established before the later security review, so a reviewer can check proposed changes against known behavior.
Project context determines which tests and security checks matter
The context file describes the environment around the code. It can include the cloud provider, deployment location, whether the service is internal or customer-facing, whether it handles personal data, whether it is a frontend or backend application, the networking setup, the product requirements document, the issue tracker, and a project Slack channel. AI can add technical context, such as whether the code is infrastructure, backend, shell, or another kind of code. Historical issues and escalations can set focus areas such as SQL injection, timeout errors, or concurrent users. Patel also mentions a possible integration with OpenContext.org and a future option for the system to ask a developer for missing context.
AI security review needs business context and a debate over findings
Patel separates this workflow from static analysis and SAST tools. It looks for security practices and logical-flow problems that automated pattern checks may miss. To reduce the tendency to report every possible concern, he simulates three AI employees: a red-team engineer, a Python developer representing the code author, and an engineering manager. The red-team role receives security policies and code. The developer receives the product requirements, while the manager receives business context from requirements, Slack conversations, and meeting transcripts. They debate each issue, its risk, whether it needs a fix, and the effort involved. A further model can review whether their answer matches the original intent.
The workflow proposes security fixes while leaving the decision to a human
The security stage produces a recommendation instead of changing the code automatically. Each issue includes its reasoning, risk or effort score, a code suggestion, and the conversation among the simulated roles summarized for the reviewer. The system also cites relevant security policies. Before a human reviews the proposed fix, it runs the unit tests that established the baseline behavior. Patel's example shows a hardcoded API key with an explanation of the risk, an effort estimate, a recommendation, and a code snippet. The reviewer decides which findings should actually be fixed.
"It doesn't do a very good job, and this is where having iterations comes into play."09:24
Who should watch
You maintain a CI pipeline and want AI to handle documentation, test generation, or review work after code is checked in.
Your team needs tests based on historical bugs and application context rather than generic examples from a language model.
You are evaluating AI-assisted security review and want proposed changes to remain subject to human approval.
