SWE AF - Moses Yebei

The Problem

Coordinating multiple AI agents to ship production-grade code is usually ad-hoc: prompts scattered across scripts, no shared state, no defined roles, and no way to scale from a single PR to a multi-repo effort. SWE-AF replaces that with a single API call that spins up a structured engineering team—product manager, architect, coders, QA—that plans, implements, and verifies changes end to end.

What This Does

SWE-AF is a Python 3.12+ runtime that orchestrates autonomous software engineering fleets. The core logic lives in swe_af/ (45 files): app.py and fast/app.py expose the HTTP API, execution/dag_executor.py runs the workflow as a DAG, and reasoners/execution_agents.py dispatches work to model-backed agents. prompts/ holds role-specific prompt templates for architect, coder, QA, and merger agents.

The examples/agent-comparison/ directory contains four complete runs—Claude Code Haiku, Claude Code Sonnet, Codex, and SWE-AF itself—each producing a working CLI todo app with tests and coverage reports. examples/diagrams/ contains a full trace of a diagram-generator project built by the fleet, including per-agent JSONL logs in .artifacts/logs/.

How It Is Wired

Execution starts at the HTTP layer: swe_af/app.py receives a POST to /api/v1/execute/async/swe-planner.build, which routes through swe_af/fast/executor.py into the DAG executor. The module graph shows swe_af/execution/schemas.py as the central hub—43 modules import it, making it the highest-blast-radius file. swe_af/app.py (18 importers) and swe_af/prompts/_utils.py (19 importers) are secondary hubs.

The main entry point is run in examples/agent-comparison/codex/src/cli.js, which reaches 11 functions. The shortest path to a filesystem effect is run → addTodo → loadTodos, which calls fs.readFileSync—three hops from entry to disk I/O. The call graph shows createSVG and addTitle each called from 14 places, making them the most change-sensitive functions in the example code.

How To Use It

git clone https://github.com/moses-y/SWE-AF
cd SWE-AF
make install   # or: pip install -e .
make check     # run tests
docker compose up --build   # start the API on :8080

Configuration lives in .env.example—copy to .env and set your model provider keys. The API accepts a JSON payload with goal, repo_url or repo_path, and a config block specifying runtime and per-role models. The README documents both single-repo and multi-repo modes via the config.repos array.

Real-World Use

A team maintaining a monorepo with a shared auth library can submit one goal: "Add JWT auth across API and shared-lib." SWE-AF spawns separate agents for each repository, coordinates the dependency order, runs tests in its own CI, and opens a PR with the merged result—no human orchestrating prompts or merging branches.

Code Health & Issues

Static analysis found 89 issues (20 high, 68 medium, 1 low) across 7 kinds. The main concerns:

High – Oversized files: swe_af/execution/schemas.py, swe_af/app.py, swe_af/execution/dag_executor.py exceed 676 lines each, making changes ripple widely.
High – Deep nesting: max indentation depth of 9 in swe_af/app.py and swe_af/fast/app.py; control flow is hard to follow.
High – Hub modules: swe_af/execution/schemas.py has 43 dependents; churn there is high-blast-radius.
High – Duplicated code: 994 repeated 6-line blocks across 141 test files in examples/agent-comparison/swe-af-haiku/tests/.
Medium – Broad exception handling in swe_af/app.py and dag_executor.py swallows errors indiscriminately.
Medium – File handle leak: open(...) without context manager in swe_af/prompts/merger.py.

The audit also flags missing lockfile for pyproject.toml, no least-privilege GITHUB_TOKEN in CI, mutable Docker base image, and no dependency vulnerability scan. Tests and CI are present and passing.

The Bottom Line

SWE-AF is a serious attempt at autonomous multi-agent engineering, with a clean API surface and real evidence of working end-to-end runs. The core orchestration code needs refactoring—the hub modules and deep nesting will hurt maintainability as the fleet scales. Use it if you need a programmable engineering team, not if you want a polished library.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,427 files

Markdown272
Rust132
Python95
JSON41
JavaScript41
Shell30

ReactFlaskExpressDocker

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["swe_af<br/>45 modules"] g1["tests<br/>45 modules"] g2["examples<br/>34 modules"] g1 -->|145| g0

Module dependencies

The 10 most depended-upon modules of 124, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_swe_af_execution_schemas["schemas"] n1_swe_af_prompts__utils["_utils"] n2_swe_af_app["app"] n3_swe_af_fast___init__["__init__"] n4_swe_af_fast_app["app"] n5_swe_af_fast_schemas["schemas"] n6_swe_af_fast_executor["executor"] n7_swe_af_reasoners_schemas["schemas"] n8_swe_af_fast_planner["planner"] n9_swe_af_fast_verifier["verifier"] n2_swe_af_app --> n7_swe_af_reasoners_schemas n2_swe_af_app --> n0_swe_af_execution_schemas n4_swe_af_fast_app --> n3_swe_af_fast___init__ n4_swe_af_fast_app --> n5_swe_af_fast_schemas n6_swe_af_fast_executor --> n3_swe_af_fast___init__ n6_swe_af_fast_executor --> n5_swe_af_fast_schemas n6_swe_af_fast_executor --> n4_swe_af_fast_app n8_swe_af_fast_planner --> n3_swe_af_fast___init__ n8_swe_af_fast_planner --> n5_swe_af_fast_schemas n9_swe_af_fast_verifier --> n3_swe_af_fast___init__ n9_swe_af_fast_verifier --> n5_swe_af_fast_schemas n9_swe_af_fast_verifier --> n4_swe_af_fast_app n1_swe_af_prompts__utils --> n0_swe_af_execution_schemas

Dependencies

1 declared dependencies, none a major version behind. Resolved 1 of 1 against the registry.

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium6

low1

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/ci.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

python:3.12-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow

.github/workflows/ci.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.