Mahima Koul

Posted on Nov 7

We turned discord into a Coding Harness.

#ai #discord #agents

Built for Flip the Switch by WeMakeDevs
When Trivy reported a clean scan, we discovered a flaw in the scanner's output contract: malformed native output could be interpreted as a false clean result. We wanted to do more than ask an AI to explain the bug or suggest a fix. We wanted to see whether a team of AI specialists could take a Discord report, investigate the underlying code, implement a fix, verify it against the exact revision, and return the evidence for human review.

That experiment became SwitchCrew, a Discord-first AI engineering team. Switch coordinates addressed handoffs between specialists, each operating through its own defined workflow, while humans retain control over sensitive decisions. In our Phase 1 demo, the workflow took the scanner fix all the way to a merged pull request on a disposable branch.

The idea behind SwitchCrew is straightforward: your team communicates through Discord, while a bounded, auditable system coordinates the engineering work behind the conversation.

The short version

A human reported a false-clean Trivy result in Discord.
The PM coordinated two addressed handoffs over Switch. Security reproduced the issue; Company Brain helped ground the code and test investigation.
After a human approved the Engineering work, managed Codex made the change.
QA, an independent policy-based Reviewer, the configured Security gate, and GitHub checks evaluated the resulting commit.

The problem: chat is where the work starts, not where it finishes

Developer teams already discuss bugs, feature ideas, and decisions in chat. The trouble starts after someone reports an issue. A person has to reproduce it, find the relevant code, choose tests, implement a change, check it, get approval, and tell the original thread what happened.

That chain crosses tools and people. Context gets lost. A green check can be misunderstood. And a generated patch is not the same as a verified change.

We wanted Discord to be the place where someone could ask for work and follow its progress, without making the Discord bot itself an unrestricted shell. That meant treating collaboration, task state, code execution, evidence, and approval as separate parts of the system.

What SwitchCrew does

SwitchCrew is an AI workforce for software teams. A person makes a request in Discord. A PM plans and routes it. Specialist workers take addressed assignments through Switch and return their results. LangGraph handles the workflow inside each role; FastAPI and SQLite hold application task state and its audit history.

The distinction matters: Switch is not just a notification layer around one giant agent. Workers have separate identities and responsibilities, and they can hand off work through a shared transport. A message being delivered does not, by itself, authorize code execution or publication.

The project’s architecture also includes Company Brain for source-backed repository context, optional Waggle memory, isolated checks, and GitHub integration. Those components have different readiness levels. The scanner-fix run is the evidence for the particular path described here.

The Green Check That Lied

Our Phase 1 story starts with a native Trivy output that could be malformed and still look clean. The team blueprint calls the issue an output-contract bug. The goal was to reproduce that behavior, patch the parser path, and make sure a regression test would catch it next time.

Here is the verified path, in order:

A human asked about the false-clean result in Discord.
The PM sent two Switch handoffs.
Security reproduced the issue with an isolated failing assertion.
Company Brain connected the affected scanner code to relevant symbols and tests. Its graph evidence influenced which tests Engineering included in its proposal.
A human approved the Engineering task in Discord.
Managed Codex changed the code and committed the fix.
QA, Reviewer, Security, and GitHub checks evaluated the resulting revision.
After publication approval, PR was merged. The PR’s CI and commit statuses passed. The evidence was real and revision-specific, but the labels matter: the Trivy gate proof in this run covered secret scanning, and the Reviewer ran independently executed policy checks. It was not a broad vulnerability-database scan or an open-ended semantic AI review.

Repository context before the patch

The scanner change was small, but choosing the right checks still required understanding where the code connected. Company Brain is SwitchCrew’s repository-knowledge layer: a revision-pinned graph of source files and relationships, with provenance back to the code.

The Phase 1 checkpoint recorded 224 files, 1,677 symbols, 2,449 calls, and 606 resolved imports in the graph. The blueprint says that evidence influenced the tests proposed for Engineering. It also notes that 12,009 unresolved calls were not treated as known edges. Unknown stayed unknown.

That is the useful role for repository context: help specialists find likely impact and relevant tests, while keeping the actual code, test output, and commit as the evidence for the change.

Every check points to the same commit

One design decision shaped the whole coding flow: evidence must describe the exact revision under consideration. QA, Reviewer, and Security results are useful only if they refer to the same resulting commit that Release is being asked to publish.

Engineering and Release are separate approval points. A human decision authorizes implementation; checks then evaluates the code. Another human decision authorizes publication. If the revision changes, previous evidence cannot simply be carried over. If an approval is missing, stale, or ambiguous, the workflow should stop rather than guess.

This is also why “looks good” in a conversation is not enough to authorize a privileged transition. The system needs an authenticated person, a specific task and approval stage, and a decision that applies to the current version of the workflow.

Why Switch is central

We could have made one bot call every specialist function privately and post a summary at the end. That would make the demo simpler, but it would hide the collaboration the product is meant to support.

In SwitchCrew, Switch carries addressed handoffs between independent workers. LangGraph manages each role’s internal state and steps. The task store records the durable application workflow. Discord gives the human a place to make the request, follow progress, and approve consequential actions.

That gives us several things to inspect when a job goes wrong: which identity received it, whether delivery was acknowledged, what task state was persisted, what revision was checked, and which human decision allowed the next step.

What we learned

Make the handoff visible. If Switch is central, show its real addressed handoffs and worker identities. A Discord screenshot alone can make the transport disappear from the story.

Pin checks to a revision. “Tests passed” leaves out the most important detail: which commit was tested? QA, Reviewer, and Security receipts should identify the exact SHA.

Separate the proposal from permission. An agent can investigate and prepare a change. A human decides whether privileged work proceeds and whether the result is published.

Show the artifact. The PR, branch, checks, fixed SHA, and merge SHA tell a stronger story than a narration that says “the AI shipped it.”

Be precise about what passed. We can say the fix merged to a disposable demo branch and that the recorded checks passed. We should also say that the Security proof covered secret scanning and the Reviewer used policy checks.

What it still gets wrong (or has not proven)

The repository has implementations for 17 roles. That does not mean all 17 are deployed or proven live in Discord. The Phase 1 blueprint identifies a smaller set as live or partially live and explicitly says to demonstrate one reliable team, not claim an autonomous 17-agent organization.

Some capabilities are future work or still need live acceptance:

A continuous interactive terminal or PTY inside Discord is not built. Isolated reproductions and recorded check logs exist; unrestricted shell access is not the intended design.
Live Discord voice capture and a complete consented voice-to-task flow were not proven in Phase 1.
A real approved Waggle lesson changing the result of a second live Switch task has not been demonstrated.
Full phone-first control was not shown in the Phase 1 recording.

These boundaries help us decide what to build next, and they help a reader understand exactly what the demo proves.

Where SwitchCrew goes next

The immediate work is to make the proven path easier for a teammate or judge to reproduce and inspect: document one clean setup path, show authentic Switch handoffs, make the Discord evidence readable, and give the final PR and its checks a clear place in the demo.

After that come narrower slices: phone-based task inspection and approval, bounded command-and-receipt controls, a confirmed voice-note-to-task workflow, and a live second-task memory experiment. Each should become part of the product claim only after its own acceptance evidence exists.

We started with a chat message and ended with a verified code change that a human approved. That is what we mean by turning Discord into a coding harness: not a shell in a chat window, but a team workflow with specialist handoffs, revision-pinned checks, and human control.

DEV Community