Authored by Taylor Luttrell-Williams, identified as a developer content engineer at Sonar, and published April 27, 2026. The guide connects Gemini Code Assist to SonarQube through MCP and uses project instructions to make generation, analysis, issue retrieval, repair, and re-analysis part of one workflow. A Flask example fails its quality gate because of insufficient test coverage; after adding tests, the agent separately checks for remaining open issues rather than equating a passing gate with zero findings.
Authored by Luttrell-Williams and published May 7, 2026. Explains how generated code can compile and pass tests while introducing dependencies that violate architectural boundaries. Distinguishes the current architecture recovered from source, an intended architecture expressed as permitted dependencies, context supplied to an agent before generation, and subsequent analysis that detects deviations. This establishes his authorship of the explanation, not creation of SonarQube architecture management.
Authored by Luttrell-Williams and published June 14, 2026. Walks through GitHub App installation, repository selection, initial scanning, pull-request summaries and inline feedback, and requesting fixes through review comments. Describes follow-up fixes arriving as new commits rather than force pushes. His documented contribution is the onboarding guide, not authorship or ownership of Gitar.
Authored by Luttrell-Williams and published July 20, 2026. Documents installation, keychain-backed authentication through the SonarQube CLI, and an analyze-before-commit workflow inside Kiro. Explains that analysis uses complete file content for accuracy while a snippet filter limits reported findings to newly generated code; remediation is followed by another analysis.
Authored by Luttrell-Williams and published August 17, 2026. Explains how credentials can enter model requests through deliberately pasted prompts or routine context gathering, including reads of environment files. Advocates dedicated local secrets scanning independent of model judgment, blocking sensitive prompts or file reads before transmission, with additional protection in the IDE and pull-request workflow.
Authored by Luttrell-Williams and published September 21, 2026. Covers a dedicated service account, token scopes, project service hooks, pull-request review, CI failure analysis, and automatic fix commits without modifying pipeline definitions. Its TypeScript example returns a string despite declaring a number return type; review additionally identifies missing validation and maintainability improvements. The guide explicitly sequences repair as a fix commit followed by an Azure Pipelines rerun, with further repair attempts possible if that rerun fails.
Authored by Luttrell-Williams, identified as a developer content engineer, and published October 28, 2026. Documents assigning Hunter Agent findings to Remediation Agent, sandboxed patch generation and quality-gate validation, and human review of resulting pull requests. A privilege-escalation example restricts editable profile fields to username and email and makes promotion administrator-only. The guide highlights silently ignored profile updates, changed client behavior, and missing automated tests despite a passing gate. The agent opens pull requests but never merges them.
sonarsource.com
Bio, Work & Ideas
Taylor Luttrell-Williams
Conference affiliation: Sonar
On this page
Taylor Luttrell-Williams is a developer content engineer at Sonar who writes practical guides and technical essays on code quality, security, and AI-assisted development. His work explains how developers can connect coding agents to independent analysis, act on the findings, and review automated repairs. He pays particular attention to what a successful check leaves unanswered: code can pass tests while violating architectural decisions, and a security fix can pass automated analysis while changing behavior that users depend on.
Bringing analysis into the agent’s workflow
Luttrell-Williams’s April 2026 Gemini Code Assist guide makes verification part of the coding task itself. It connects the agent to SonarQube through the Model Context Protocol (MCP), which lets agents call external tools. Project instructions tell the agent to generate code, run analysis, retrieve findings, make repairs, and scan again before declaring the task complete.
The guide follows a small Flask application through a failed quality gate—a set of acceptance thresholds—and an attempt to improve its test coverage. Luttrell-Williams distinguishes passing that gate from resolving every detected issue: findings below the blocking threshold can remain. His workflow therefore includes a separate check for open issues after the gate passes.
His July 2026 Kiro integration guide applies analysis before commit. It explains why the analyzer needs the complete file even when the developer wants feedback only on newly generated code: full-file context supports the analysis, while filtering the reported findings keeps the review focused on the current change.
Luttrell-Williams also writes about automated review beyond the editor. His Gitar onboarding guide for GitHub walks developers from repository connection to pull-request feedback and fixes requested through comments. His September 2026 Azure DevOps guide separates code-review findings from continuous-integration (CI) failure analysis. In its example, a TypeScript function promises a number but returns a string; the build diagnosis explains that failure, while the review also identifies missing input validation and other improvements. He makes the repair sequence explicit: Gitar pushes a fix commit, Azure Pipelines reruns against it, and another failure may require another attempt.
Architecture, credentials, and the limits of automated repair
Across his essays and guides, Luttrell-Williams develops several practical distinctions:
Architectural guidance needs a follow-up check. His May 2026 architecture essay examines code that compiles and passes tests but imports a module from a layer that should not access it. He explains how an intended architecture—an explicit list of permitted dependencies—can guide an agent before generation. Analysis afterward compares the actual dependencies with that model and flags deviations. Giving the agent context helps it choose; checking its output catches choices that still violate the design.
Credential protection must happen before transmission. In his August 2026 essay on secrets and coding agents, he traces how credentials can enter a model request through ordinary context gathering. An agent reading a project’s environment file can carry sensitive values into a prompt without anyone deliberately pasting them into chat. He advocates a dedicated local scanner, independent of the model, that can block sensitive prompts or file reads before the data leaves the machine.
A passing repair can still require a human decision. His October 2026 code-maintenance guide connects SonarQube Hunter Agent findings to Remediation Agent pull requests. One example closes a privilege-escalation path by restricting which profile fields a user may update and requiring administrator access to a promotion endpoint. The repair also changes behavior: clients attempting to update other profile fields will have those values ignored, and the example lacks automated test coverage for the change. Luttrell-Williams directs reviewers to inspect those consequences even though the quality gate passes. In this workflow, the agent opens the pull request but never merges it; required reviewers and branch protections remain in place.
Killian Carlsen-Phelan and Taylor Luttrell-Williams use Gitar on a sample ticketing API to expose a cancellation bug outside the diff, check an all-in-pricing rule, and automate repair of a failing CI test—with separate controls for applying fixes and merging them.
A green test suite can miss a new interaction with unchanged code. In Box Office, transferring a ticket worked, but canceling its original order afterward still voided the friend's ticket; Gitar located the correction in orders.py.
Project guidance and conditional rules serve different roles. The all-in-pricing requirement defines the expected behavior, while a rule triggered by pricing-file edits asks Gitar to inspect and report on affected customer-facing fields.
Automatic fixes and automatic merging are separate permissions. The third exercise enables both, with a required GitHub test check gating merge; its final merge is not confirmed before the walkthrough moves on.
Verification can compare a change with linked requirements, dependent repositories, and other in-flight PRs. Those checks address different ways a locally valid change can still be incomplete or incompatible.
External context supplies requirements to check; Knowledge retains feedback about Gitar's reviews and preferred fixes. The Q&A distinguishes these capabilities without resolving the exact ingestion path for the audience's requested integration.
▶ Watch ↗