Killian Carlsen-Phelan

Killian Carlsen-Phelan explains how software analysis can catch defects that AI-generated code leaves behind—and how developers can feed those findings back to a coding agent. His 2026 work as a Developer Content Engineer at Sonar includes guides to autonomous code review, cross-file security analysis, and project-specific review instructions. The examples make the missing assumption visible: an S3 upload needs to verify bucket ownership, a database query must keep user input separate from executable SQL, and an automated reviewer needs explicit instructions to enforce a team’s conventions.

Killian moved from software engineering into developer-facing content, combining programming examples with technical explanation. His contribution is explaining how to use and interpret analysis tools; the underlying analyzers and products are collective Sonar work.

Bringing analysis into the coding loop

Killian’s autonomous code-review guide connects Claude Code to SonarQube Cloud through its MCP server. After generating code, the agent runs a scan, retrieves specific findings, makes corrections, and checks the result again. Making the findings available to the agent turns analysis into an input to the next edit.

The guide asks Claude to write a Python script that uploads a CSV file to Amazon S3. Analysis catches missing bucket-ownership verification, prompting a correction that supplies the expected owner. This gives verification inside the agent loop a concrete meaning: a separate tool identifies a particular defect, and the agent uses that finding to revise its work before handing it over.

Killian applies the same approach with Codex in his SonarQube agentic-development workshop. A deliberately vulnerable Python project supplies the test case: SonarQube traces user-controlled input into database execution, Codex replaces string interpolation with a parameterized query, and a verification hook checks the edit. He also adds a new database operation under the same checking loop, extending the workflow from repairing existing code to checking new work.

Explaining what a reviewer needs to see

Across his writing, Killian distinguishes defects that require tracing program behavior from requirements that developers must first make explicit:

• Security across file boundaries: His SQL-injection walkthrough follows an HTTP request parameter through a Spring controller and service into a repository’s database call. Each intermediate method looks ordinary; connecting the path reveals how untrusted input reaches SQL execution. He explains taint analysis through that movement of data, then shows how a parameterized query keeps the input from becoming executable SQL.

• Plausible wrong answers: In writing co-authored with Jean Jimbo, Killian examines Java time calculations that compile successfully while misrepresenting elapsed time. Subtracting timezone-free departure and arrival values can turn a seven-hour transatlantic flight into thirteen hours. The example connects a type choice to errors in billing, scheduling, and service monitoring, where a believable number can be harder to notice than a crash.

• Project-specific conventions: His Gitar configuration blueprint shows why general bug detection cannot enforce an undocumented design decision. A sample order service receives findings about exceptions and missing tests, yet its reviewer initially misses the required API response envelope because the convention exists only in the developers’ heads. Killian makes the requirement explicit in review instructions and organizes supporting documentation so the reviewer can apply it to later changes.

• Credentials exposed during builds: Killian’s Rust security guide examines build.rs, which executes during a build and can inherit access to the host’s environment. He explains why network downloads and credential reads deserve scrutiny, and recommends moving downloads into controlled setup steps while keeping build scripts focused on declared build inputs and generated output.