AI on Alfero Chingono

How I Run SonarQube in My Own CI Pipeline (And Let AI Fix What It Finds)

Thu, 05 Mar 2026 09:00:00 +0000

I wrote in 2024 about automating OWASP scan reports in Azure DevOps because I wanted security scanning to become part of the delivery flow instead of an afterthought.

This post is the next step in that same direction.

The thing I wanted from SonarQube was not another dashboard full of guilt. I wanted a loop that could actually create work, route it, fix it, and come back cleaner on the next scan.

That changed the design completely.

The real goal was not “run SonarQube”

Running SonarQube is easy.

Turning findings into a useful engineering loop is the hard part.

The pattern I have found most practical looks like this:

run the scan on a schedule
translate findings into issues with enough structure to act on
let AI or agents handle the obvious remediation work
keep human review as the merge gate
rescan and repeat

That is what I have been doing across FireFly and CueMarshal.

The FireFly version: temporary SonarQube, durable issues

In FireFly, the workflow is intentionally self-contained.

The scheduled GitHub Action spins up a SonarQube Community service container, sets the admin password, creates the project, generates an analysis token, runs the scanner in Docker, and then uses the SonarQube API to fetch open issues.

From there, the workflow does something I think is more useful than just failing the pipeline: it turns findings into GitHub issues with meaningful labels.

The labels encode both issue type and severity:

sonar
sonar: bug
sonar: vulnerability
sonar: security hotspot
sonar: blocker
sonar: critical
sonar: major

That small step matters a lot. Once the findings live as first-class issues in the repo, they stop being hidden inside a scan report and start participating in the normal engineering workflow.

The FireFly workflow also keeps the body format clean: key, severity, type, rule, file, line, and the actual message. That makes the issue understandable without forcing someone to click back into SonarQube every time.

The CueMarshal version: findings re-enter the agent loop

CueMarshal takes the pattern further.

There, SonarQube is not just a quality gate. It is a signal source for the self-improvement system.

The scan runs on a schedule, the quality gate is checked, and when issues remain, they are picked up by the self-improvement workflow. That workflow runs deterministic scanners, produces a findings JSON file, and lets AI select the high-value, automation-friendly items to turn into actual repository work.

At that point the flow becomes very CueMarshal-like:

finding becomes issue
issue gets labels such as self-improvement and source:sonar
developer agent works the task
reviewer agent reviews it
human still controls the merge

That is the part I care about most. Static analysis becomes part of an operational loop instead of a reporting loop.

What AI actually fixed

This pattern became more convincing to me once I could see it in the commit history instead of just in a diagram.

In FireFly, the SonarQube-driven fixes moved through recognizable stages:

critical auth and data exposure issues
medium-severity issues in the LLM, tracer, and execution paths
blocker and critical tracer problems
remaining major issues in non-UI files

In CueMarshal, the same loop showed up in a different form:

bug-class findings resolved
cognitive-complexity hotspots refactored
scan-flow issues fixed so the SonarQube pipeline itself became more reliable

That is the detail that made the whole approach feel real to me. The AI was not “doing security” in some theatrical sense. It was participating in a bounded remediation loop with concrete input, reviewable output, and a cleaner next scan.

What I still keep human

I do not think static analysis findings should all be auto-fixed blindly.

Some changes affect security-sensitive behavior. Some touch core orchestration logic. Some need architectural judgment more than mechanical cleanup.

That is why I still care so much about review gates, protected areas, and explicit pull requests. AI can do triage. AI can do a surprising amount of repair work. But the system becomes trustworthy only when people retain approval authority over the consequential parts.

This is the same design instinct behind CueMarshal more broadly: automate aggressively, but make the control points obvious.

Why I like this pattern

The more repositories I maintain, the less patience I have for passive quality tooling.

If a scan only tells me what is wrong, it is useful. If a scan creates the next actionable task, it is much more useful. If that task can be routed through an AI-assisted workflow and still land in a human-reviewed PR, then the tool has become part of delivery rather than commentary on delivery.

That is the threshold I care about now.

I still think DAST and pipeline security automation matter deeply; that earlier OWASP post still reflects that. But SonarQube plus an AI remediation loop feels like the next generation of the same idea: make quality signals operational, not ornamental.

If you want the broader architecture around this, Designing Multi-Agent Systems: Lessons from Building an 8-Agent Engineering Orchestra covers the orchestration side, and Why I Started Building My Own DevOps Platform covers the bigger motivation.

References:

MCP in Practice: What Anthropic's Model Context Protocol Actually Means for Developers

Thu, 20 Mar 2025 09:00:00 +0000

When Anthropic announced the Model Context Protocol, the most interesting part to me was not “LLMs can call tools.” We already knew that. The interesting part was that someone was finally trying to standardize the connection.

That may sound like a small distinction, but it is the difference between a clever demo and an architecture you can actually build on.

For developers, MCP matters because it turns tool access into something more portable, more inspectable, and less bespoke. Instead of wiring every model to every internal system in a slightly different way, you get a shared protocol for secure, two-way connections between AI clients and the systems where work actually lives.

In other words: fewer one-off connectors, fewer weird wrappers, and less glue code pretending to be strategy.

The real problem MCP solves

Without a protocol, most AI integrations end up with the same shape:

custom JSON formats
hand-rolled function schemas
transport logic mixed into business logic
a different adapter for every new client

You can absolutely ship systems that way. Many people already have. But you pay for it later in duplication, debugging, and lock-in.

Anthropic’s framing resonated with me because it describes a problem I had already been running into while building CueMarshal. I did not need agents that could merely “use tools.” I needed a stable way for different parts of the system to use the same tools in different contexts.

That is where MCP becomes practical.

What it changed in my own thinking

In CueMarshal, I ended up with three MCP servers:

a Gitea MCP server for issues, pull requests, repositories, workflows, and search
a Conductor MCP server for task coordination and agent state
a System MCP server for costs, runners, and health

That split was not arbitrary. It reflected a design choice: organize tool access around bounded responsibilities instead of dumping everything into one giant catch-all toolbox.

Even more important, the same MCP server code supports two transports:

stdio for agent runners
HTTP/SSE for the long-running chat/orchestration layer

This is the part I think many developers will underestimate. The value is not just that the model can invoke a tool. The value is that your tool layer stops being trapped inside one execution model.

The CueMarshal runners can spawn MCP servers directly as child processes. The Conductor can hold long-lived connections to those same tool surfaces over the network. Same capability, different runtime, no duplicated tool logic.

That is not just elegant. It is operationally useful.

MCP is really about interface discipline

One thing building AI systems teaches very quickly is that “prompting” gets too much credit for problems that are really interface problems.

If the tool schema is vague, the model will behave vaguely.

If the permissions are broad, the behavior will feel risky.

If the transport is brittle, the whole system looks flaky even when the reasoning is fine.

What I like about MCP is that it nudges teams toward better engineering habits:

Typed tools instead of implied behavior
Separation between protocol and implementation
Reusable tool layers across multiple clients
Clearer permission boundaries

That discipline matters even if you never use Anthropic’s stack directly.

What developers should actually do with it

My advice is to treat MCP less like a product feature and more like a systems design decision.

If you are building AI-assisted software delivery, internal automation, or even just richer developer tools, start by asking:

What are the real systems my assistant needs to access?
Which of those interactions deserve typed, validated interfaces?
Which capabilities should be shared across chat, automation, and background agents?
Where do I want auditability and permission scoping to live?

That line of thinking will produce a better architecture whether you adopt MCP tomorrow or not.

In my own work, it pushed me away from raw curl-driven integration and toward a universal tool layer. Once I made that shift, a lot of downstream problems became easier: orchestration, reuse, security boundaries, and even explanation. It is easier to trust a system when you can say, very plainly, “here are the tools it has, here is what they do, and here is how they are invoked.”

What MCP does not solve

MCP does not magically make an agent reliable.

It does not fix poor workflow design.

It does not remove the need for human review.

And it definitely does not turn vague prompts into good engineering.

What it does is give you a cleaner control plane for connecting models to real systems. That is already a meaningful improvement.

For me, that is why MCP feels important. Not because it adds more AI theater, but because it reduces architectural friction in a place where friction compounds very fast.

If you are curious how that idea plays out in a larger system, I wrote more about the broader coordination problem in Why I Started Building My Own DevOps Platform and the orchestration lessons in Designing Multi-Agent Systems: Lessons from Building an 8-Agent Engineering Orchestra.

References:

Why I Started Building My Own DevOps Platform (And What I Learned)

Sat, 15 Feb 2025 09:00:00 +0000

For a while, I had the same reaction to most AI-for-software-delivery demos: impressive in a narrow way, but not something I would trust with real work. One tool could write code. Another could summarize a diff. Another could review a pull request. But the hard part of software delivery is rarely one isolated step. It is the handoff between steps.

That was the itch that eventually pushed me to start building CueMarshal.

I did not start with the ambition to build “an AI company” or some abstract autonomous future. I started because I wanted a more coherent delivery system: one place where a task could move from idea to issue to branch to pull request to review without losing context every time responsibility changed hands.

The problem I actually wanted to solve

CI/CD was never the whole problem. In many teams, the pipeline is the most deterministic part of the process. The mess usually lives around it:

the design decision that only exists in a chat thread
the issue that says too little
the reviewer who has to reconstruct intent from commit history
the documentation that is always “we’ll do it after”
the growing pile of tools that all know a little, but none of them own the workflow

What I wanted was not another dashboard. I wanted a delivery surface that respected how engineering work already happens.

That led me to a simple conviction: Git should be the source of truth, not just the storage layer.

If work already becomes legible through issues, branches, pull requests, labels, and reviews, then the orchestration layer should live there too. Not beside it. Not behind it. Inside it.

Why I built it myself

There were three constraints that mattered to me from day one.

First, I wanted the system to be self-hosted. A lot of AI tooling assumes you are comfortable sending your code, your process, and your delivery metadata into someone else’s black box. Many teams are not. I wanted an approach that made data sovereignty a feature, not an apology.

Second, I wanted the system to be role-aware. Real software delivery is not “one super-agent with a clever prompt.” Design, implementation, review, testing, DevOps, and documentation are different jobs. Sometimes one person does multiple jobs, but the jobs are still different. That distinction matters.

Third, I wanted human control to remain the final gate. I am interested in automation, not surrender. If an AI system cannot work inside a reviewable pull-request workflow, I do not think it is mature enough for serious engineering work.

Those constraints eventually turned into the shape CueMarshal has now: a conductor service in TypeScript, specialized agents for architecture, development, review, testing, DevOps, docs, and linting, a Git-native workflow in Gitea, and a tool layer built around MCP so the same system can reason over structured interfaces instead of raw shell scripts and ad-hoc API calls.

The architecture came later. The principles came first.

Long before the implementation solidified, the design principles were already obvious to me.

1. Git is a better coordination layer than most agent UIs

An issue is a task. A branch is a workstream. A pull request is a proposal. A review is a decision record. A merge is a controlled state change.

That sounds almost too obvious to say out loud, but it changed how I thought about the whole problem. Once I stopped treating Git as the place where code merely ends up, and started treating it as the place where engineering decisions become inspectable, the rest of the architecture got much simpler.

2. Specialization beats a “do everything” agent

In CueMarshal, the system is intentionally split into named roles: Marshal for orchestration, Ava for architecture, Dave for implementation, Reese for review, Tess for testing, Devin for DevOps, Dot for docs, and Linton for linting.

That is not branding for its own sake. It is an operational choice.

The moment one agent tries to be planner, coder, reviewer, tester, and documentarian all at once, you lose clarity. You also lose accountability. Specialization makes prompts sharper, tool permissions narrower, and outputs easier to judge.

3. Tool contracts matter more than prompt cleverness

One of the biggest lessons from building CueMarshal is that the quality of an agentic system is heavily constrained by the quality of its interfaces.

If an agent is forced to improvise around loosely structured APIs, fragile shell commands, or browser automation for tasks that should be typed and validated, the system becomes harder to trust. This is one reason MCP clicked for me so quickly later on: it gave a clean shape to something I already knew was essential.

Good tool contracts do not just help the model. They help the human operator understand what the system is even allowed to do.

4. Stateless workers are a feature, not a bug

CueMarshal’s runners are intentionally stateless. They reconstruct context from the repository, the issue, the pull request, and the tool layer every time.

That may sound less magical than the “persistent AI teammate” narrative, but it is much easier to reason about. It scales better. It fails more cleanly. And it produces a better audit trail.

In practice, that has made me more skeptical of systems that depend on hidden memory to feel smart.

5. Human control is product design

The more I worked on this, the more convinced I became that “human in the loop” is not enough as a slogan. It has to be built into the workflow itself.

That is why I prefer issue-driven execution, reviewable pull requests, typed tools, explicit handoffs, and merge control. Those are not bureaucratic constraints. They are the difference between a system that can support real engineering and a system that is only good for demos.

What I learned from building in public

The most useful part of this project has not been proving that agents can write code. We already knew that. The useful part has been learning where coordination breaks, where trust gets earned, and what kinds of structure make AI assistance actually usable.

It also made one thing clearer for me: the next layer of software delivery is not “more CI/CD.” It is better orchestration around the work humans and machines are already doing together.

That is the reason I started building CueMarshal, and it is still the reason I keep working on it.

If you want the more technical follow-up, I wrote about what MCP actually changed for developers and the coordination lessons from building an eight-agent engineering orchestra.

References: