← All Insights

Building repo.spot: How We Used Qwen Cloud and Alibaba Function Compute to Create an Autonomous DevSecOps Agent

· Updated 8 July 2026
Share X in f Reddit Email

This post documents the journey of building repo.spot for the Global AI Hackathon Series with Qwen Cloud — an autonomous DevSecOps review agent powered by Qwen on Alibaba Cloud.

The Problem

Security vulnerabilities in open-source repositories are found, triaged, and fixed by humans — a slow, expensive, and error-prone process. As a developer who maintains multiple open-source projects and actively tracks the AI/ML ecosystem, I wanted to explore whether a disciplined multi-agent system could replace that manual review loop with something faster, more consistent, and fully auditable.

The hackathon’s Agent Society track made this the perfect frame: not one “smart” model, but a structured team of agents with distinct roles, hard stopping rules, and verifiable outputs.

What We Built

repo.spot is an open-source DevSecOps CLI that combines three layers into one lean pipeline:

  • Local risk scoring — every file in your repo is scored instantly, offline, using a weighted formula combining code complexity, sensitive-pattern detection (environment variables, auth tokens, eval calls), and git churn. No network calls, no cost, instant results.
  • Serverless Alibaba Cloud backend — only files above the risk threshold are sent anywhere. They go via an authenticated HTTPS request to a Function Compute relay running in the UK London region. The Qwen API key lives exclusively in FC environment variables — it never touches the client.
  • Qwen reasoning — the FC relay assembles a structured prompt from the file path, code, and instruction, then calls Qwen via the OpenAI-compatible DashScope API and returns concise, actionable review output to the terminal.

The Architecture

The system has five clear layers:

  1. Local CLI (repospot.py) — the developer-facing entry point with four commands: --ping, --score, single-file review, and --repo full scan.
  2. Risk scorer (swarm/risk.py) — deterministic, offline scoring using the formula: 0.5 × Complexity + 0.3 × Sensitivity + 0.2 × Churn. Files below score 65 are skipped entirely.
  3. Relay client (relay/client.py) — a stdlib-only Python HTTP client that sends POST JSON to the FC endpoint with Basic auth, typed error classes, and a forward-compatible payload shape.
  4. Alibaba Cloud Function Compute (app.py) — a custom-runtime Python web function deployed in eu-west-1 (UK London). Reads QWEN_API_KEY from FC environment variables. Builds a structured prompt from all three envelope fields and calls Qwen.
  5. Qwen via DashScope — the model layer, called via the OpenAI-compatible API endpoint at dashscope-intl.aliyuncs.com/compatible-mode/v1.

The Build Journey

Stage 1: Proving the Alibaba Cloud deployment

The first challenge was getting a real, working Function Compute deployment rather than a mock. This meant navigating the FC console, understanding the difference between built-in Python runtimes and custom-runtime web functions, and getting the HTTP trigger configured correctly.

The key insight: Alibaba’s custom runtime web function model expects a running HTTP server process started by a startup command — not a plain function handler. Once we understood that, the deployment clicked. The function was deployed as a Python HTTP server listening on port 9000, with the QWEN_API_KEY stored in FC environment variables and never in source code.

The first successful test returned:

{"ok": true, "source": "alibaba-function-compute", "message": "FC_ACK"}

That was the moment the infrastructure was real.

Stage 2: Building the relay client

With the backend proven, the next step was a clean Python relay client that could call the FC endpoint from any local tool. The design goals were strict:

  • stdlib only — no extra dependencies
  • typed error hierarchy (RelayNetworkError, RelayAuthError, RelayHTTPError, RelayBackendError)
  • forward-compatible payload shape so the API could be extended without breaking the client
  • Basic auth credentials read from local env only, never hardcoded

Four sanity checks were run against the live FC endpoint before the client was considered done: POST-only transport, no QWEN_API_KEY anywhere client-side, clean 401 error handling, and strict response shape validation.

Stage 3: The backend contract fix

An early version of the FC backend had a subtle bug: the prompt-building logic used a Python or short-circuit that silently discarded the code_envelope field whenever prompt was non-empty. This meant only one of the three envelope fields ever reached the model.

The fix was to replace the short-circuit with explicit structured prompt assembly:

Instruction:
Review this file for correctness...

---

File Path:
src/auth.py

---

Code:
def verify_token(token):
    parts = token.split(".")
    return parts[1]

All three fields now reach Qwen together, giving the model proper context for every review.

Stage 4: The self-review moment

The moment that best demonstrated the system working: repo.spot was pointed at its own relay configuration file, relay/config.py. Qwen reviewed it and caught a real robustness bug — a missing error handler around RELAY_TIMEOUT that would crash the program on startup if the environment variable was set to a non-numeric string like abc.

The fix was applied immediately. The system reviewed itself, found a real issue, and improved itself. That is the Agent Society track working exactly as intended — bounded agents with specific roles producing verifiable, actionable output.

What We Learned

  • Bounded agents outperform free agents. Giving each layer a single, narrow job and a hard exit condition produces more reliable results than giving an agent broad autonomy and hoping it converges.
  • Prove the infrastructure first, then build product logic. Getting a real Alibaba Cloud deployment working before writing any application logic saved significant debugging time later.
  • The deterministic layer earns its keep. The offline risk scorer means the LLM is only invoked when it is genuinely needed, keeping latency low and costs predictable.
  • Qwen’s OpenAI-compatible API makes integration fast. Switching from a local test script to a live Alibaba Cloud serverless relay required minimal code changes because the interface is identical.
  • Security needs to be designed in from the start. Keeping the API key server-side and adding Basic auth to the HTTP trigger before making the repo public are choices that are much harder to retrofit later.

The Stack

  • Model: Qwen (via Alibaba Cloud Model Studio, OpenAI-compatible DashScope API)
  • Backend: Alibaba Cloud Function Compute, custom runtime, UK London region (eu-west-1)
  • Client: Python 3, stdlib only
  • Auth: HTTP Basic Authentication on the FC HTTP trigger
  • Risk scoring: Deterministic Python, offline, no external dependencies
  • AI tools used during build: Qwen Cloud, Perplexity Comet, Google Gemini, OpenCode CLI agent

Try It

The full source code, architecture diagram, and documentation are available on GitHub. The project is open source with a working Alibaba Cloud deployment and a live demo flow documented in docs/PRODUCT.md.

# Health-check the relay
python repospot.py --ping

# Risk-score a single file (no LLM call)
python repospot.py --score src/auth.py

# Full review of a single file
python repospot.py src/auth.py

# Scan an entire repository
python repospot.py --repo ./my-project

Built for the Global AI Hackathon Series with Qwen Cloud — Track 3: Agent Society.