AI Engineer World's Fair 2026
SonarQube + OpenAI: Agentic Development — Killian Carlsen-Phelan, Sonar
Read the talk
SonarQube + OpenAI: Agentic Development
Killian Carlsen-Phelan wires SonarQube into Codex, traces a SQL injection from command-line input to database execution, and repairs it under an automatic verification hook. The workshop shows where guidance, secret detection and independent analysis enter the coding process—and where their guarantees stop.
From a talk by Killian Carlsen-Phelan
At a glance
Ideas worth remembering
A reviewable change needs independent evidence: an agent-generated test can repeat the same misunderstanding as the implementation.
The SQL injection connects sys.argv input to an interpolated SQL string and database execution. The repair uses a parameterized query, and reanalysis stops reporting S8702 while retaining a pre-existing issue.
Secret interception protects the prompt and tool paths covered by its hooks. The workshop explicitly acknowledges that a bypassed hook may not run.
Context augmentation supplies guidance before generation; agentic analysis checks edits afterward. Both require organizational entitlements beyond the free tier.
“Fixed” needs evidence
An agent can produce a plausible fix and a plausible test that share the same mistake. That is the opening problem in the OpenAI/Codex introduction to Killian Carlsen-Phelan’s workshop. Missing context can lead to a local repair that breaks a project-wide requirement; a test generated from that same understanding can then approve the repair. Self-critique helps, but it does not supply an independent check.
“Done” therefore means a reviewable change supported by evidence. The task needs an intended outcome, a defined scope, acceptance criteria and invariants—the properties that must remain true while the implementation changes. Compiler results, tests and analysis should challenge the agent’s claim of completion. Human review remains part of deciding whether the result meets the intent.
Two kinds of control answer different questions:
- Execution controls: Which tools can the agent use, where can it act, and which actions need approval? A sandbox limits what execution can affect.
- Artifact checks: Is the resulting code acceptable? Tests, analysis and policy checks examine what the agent produced.
A sandbox can contain a file write without establishing that the SQL query written into that file is safe. These controls need to work together, with people retaining responsibility for intent, exceptions and the decision to ship.
The integration points are concrete. Skills describe procedures; MCP supplies structured tools and context; hooks run checks at particular lifecycle events. Together they can intercept a secret before model input, supply a vulnerability’s location and data path, and recheck a repair. CI and human review still matter, but useful feedback should also arrive while the agent can act on it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Move verification closer to generation
Killian Carlsen-Phelan, a developer content engineer at Sonar, turns that framing into a workflow for Codex. Sonar’s survey of over a thousand developers supplies the motivation: he reports that 42% of committed code was AI-generated or AI-assisted, 96% of developers did not fully trust it, and fewer than half said they fully verified it before pushing and merging. These are reported survey findings, rather than a measurement of the workshop’s tools. Their practical tension is clear: generation can grow faster than people’s capacity to check it.
Sonar calls its response the agent-centric development cycle. The coding agent handles generation; Sonar supplies three surrounding capabilities:
- Guide: Give the agent project guidelines, rules and relevant architecture before it writes code. The workshop calls this context augmentation.
- Verify: Analyze generated changes for security, code quality and maintainability issues. Agentic analysis supplies the automatic check demonstrated later.
- Solve: Feed detected issues back into the agent’s work so it can repair them and obtain another check.
The timing matters. In the familiar outer loop, a developer writes code, pushes it, waits for CI, discovers a failed test or scan, returns to the IDE and pushes again. The proposed inner loop performs verification in the development environment immediately after generation. That lets the agent respond before a push, reducing the repeated trip through the pipeline. It also addresses the frustration Carlsen-Phelan jokes can add to engineers’ therapy bills.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with a small project containing known failures
The hands-on example uses a tiny Python project: about four files and fewer than 200 lines, with four deliberately planted issues. Three are security issues; the fourth is a code smell. A small, known set makes it possible to follow one finding from its initial detection through repair without confusing that repair with a claim that the whole application is clean.
Provisioning starts with Apply Sonar, Carlsen-Phelan’s personal helper script, which he explicitly distinguishes from an official Sonar product. It requires a Bash terminal, creates a SonarQube Cloud project, runs the initial scan and installs supporting tools, including the CLI. The setup authenticates through a browser and asks for the organization associated with the account. Docker is also a workshop prerequisite for the MCP server used later.
The live setup stalls. Wi-Fi is slow, but Carlsen-Phelan also notices that he may have forgotten to export the Sonar token into his shell. He stops sharing his screen while handling the credential, then resumes provisioning. That correction is a useful setup detail: browser authentication and a token available to the shell are separate pieces of the demonstrated process.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Follow command-line input into SQL execution
The first highlighted failure is an OpenAI API key stored directly in source code. The scan identifies the plaintext credential rather than relying on a reviewer to notice it. Carlsen-Phelan contrasts that with supplying a value through an environment file or variable; the concern is that a credential embedded in code can travel into a published repository.
The SQL injection has a different mechanism. In database.py, a search function inserts its query argument directly into an f-string and passes the resulting SQL text to a cursor for execution. The argument originates in sys.argv, so someone supplying command-line input can influence text that becomes part of the SQL command. Input crosses from being a search value into helping define the query itself.
SonarQube uses symbolic execution and taint analysis to trace that path through the application. The useful distinction is between the source, where user-controlled input enters, and the sink, where the database executes the constructed query. Following the intermediate functions and files connects the dangerous operation to the input that makes it exploitable; inspecting only the final execution line would lose that explanation.
Where does the input travel before it reaches the database? The dashboard’s SQL injection view is the place to inspect that relationship: Carlsen-Phelan follows the source across files and functions to the sink. The completed initial scan reports four issues, including three security issues, and a security rating of E. The data path supplies the actionable detail behind that aggregate rating.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Install the plugin and separate guidance from analysis
The Codex integration begins by adding the SonarQube plugin marketplace. Inside Codex, /plugins opens the plugin selector; searching for SonarQube allows installation. Carlsen-Phelan then exits Codex so it can reload, authenticates the Sonar CLI with sonar auth login, and runs sonar integrate codex to wire the project into the integration.
The wiring adds a secrets detection hook, an agent Markdown directive to use the SonarQube skills, additional skills and MCP configuration. The token causes another interruption: the exported value appears to be getting lost. Once the setup completes, the integration has both instructions telling Codex how to use SonarQube and configured tools through which it can do so.
Two capabilities sit on opposite sides of an edit:
- Context augmentation, before work: Fetch relevant project guidelines and architecture and supply them to Codex as it begins a task.
- Agentic analysis, after an edit: A hook runs when the agent writes or modifies a file and submits the newly written code for server-side analysis.
The first improves the information available for generation. The second checks the resulting change. Carlsen-Phelan’s organization has access to both; free-account participants may not see them.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Block a fake secret—and examine the hook’s limits
What happens when a prompt itself contains a credential? Carlsen-Phelan starts Codex, accepts the configured hooks and submits a request to push a commit using a fake token supplied for the exercise. The request is immediately blocked. The intended interception point is before the secret reaches model context, rather than after the model has already received it.
The distinction becomes sharper in the audience question: could Codex write a script that reads the secret-bearing file instead? Carlsen-Phelan acknowledges that this is possible. The described hook runs at particular prompt or tool-use events; a path that bypasses the relevant event may avoid invoking it. The blocked prompt demonstrates protection on that path, not universal prevention of secret access through arbitrary agent execution.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bring dashboard findings into the coding session
The next step gives Codex the project’s existing findings. The SonarQube MCP server lets the session fetch information from SonarQube Cloud, including the issues previously inspected in the dashboard. Carlsen-Phelan restarts the session and server after connectivity trouble, then asks, “List the issues in my project.” That request gives the agent a specific analysis result to work from.
An audience question separates the local pieces. The CLI provisions and configures the integration; the MCP server runs in Docker. Carlsen-Phelan further clarifies that task execution may use an MCP skill or a CLI command. The plugin sits on top of these facilities, so the setup should not be read as every operation passing through one mandatory CLI-to-MCP chain.
The session finds the issue-listing and context-augmentation skills. Secret scanning also runs while it reads files, including its own skill files. Eventually, the same findings shown in the dashboard become available in the terminal. The workshop’s long waits make connectivity a visible dependency; Carlsen-Phelan’s expectation of much faster operation on normal Wi-Fi is personal experience, not a latency benchmark established by this run.
Access also affects which workflow a participant can reproduce. Carlsen-Phelan describes the integration as available across SonarQube Cloud, Server, enterprise and free-tier use. Context augmentation and agentic analysis require the corresponding organizational entitlements and are unavailable on the free tier. Retrieving findings and automatically analyzing every edit are therefore separate capabilities.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Replace interpolation with a parameterized query
The selected finding is S8702, which Carlsen-Phelan describes as a rule written for AI agentic workflows. In this project it identifies the previously traced sys.argv path into SQL execution. The instruction to Codex is short: fix S8702. Its specificity comes from the issue already retrieved into the session, connecting the request to the vulnerable operation.
Codex replaces the vulnerable construction with a parameterized query. The important change is the separation of SQL structure from the supplied value: the search argument is bound as data instead of being interpolated into executable SQL text. After the edit, the post-tool-use hook sends the change for server-side analysis. This addresses the “hydra” problem Carlsen-Phelan describes—fixing one issue only to introduce several more.
What changed in the query, and what does the recheck actually clear? The reported result is that S8702 disappears and the edited code passes the inline analysis. Another planted issue remains in the file and is identified as pre-existing. That distinction keeps the repair scoped: resolving the selected injection does not require silently fixing every unrelated issue, and a successful recheck does not declare the entire file free of problems.
Without agentic analysis, the code can still be scanned during a subsequent CI push, provided that scan is configured. What the hook changes is when the result becomes available: the agent gets analysis feedback immediately after its edit and can respond in the same session. Consistent with the opening, this is evidence from a particular checker; it complements behavioral tests and human review.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use the same checks when adding new behavior
The final demonstration moves from repairing a known vulnerability to generating a new operation: delete a task by ID in database.py. Context augmentation fetches relevant project rules and architecture for Codex before implementation. The feature completes quickly in the session, and agentic analysis checks the generated change.
The feedback now applies to new work as well as old findings. If analysis flags an issue, the intended behavior is for Codex to continue repairing it and receive another check. The recording describes that conditional path; it does not show a newly detected failure during this final operation. The demonstrated progression is guidance into generation, followed by analysis of the resulting code, all within the terminal.
The remaining planted issues provide further exercises, and participants whose organizations have the entitlements can explore context augmentation and agentic analysis. Carlsen-Phelan closes by directing people who get stuck to the Sonar community, where product engineers answer questions. The useful stopping point is concrete: a blocked fake credential, a retrieved and repaired SQL injection, and a new database operation checked during development—with the hook’s bypass limits and the organization’s feature access still part of the design.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Beating RL With Reflection: GEPA and Optimize Anything
Explores how execution traces, errors and evaluator feedback can improve prompts, agent programs and repository skills—a complementary use of feedback beyond checking individual edits.
Read the transcript and explore slides
Loading transcript and slides…