The Problem
Software teams spend a disproportionate amount of time orchestrating repetitive engineering tasks—creating PRs, running tests, handling reviews—especially when scaling across many repositories. Manual coordination introduces latency and error‑prone hand‑offs that slow delivery of even routine changes.
What This Does
SWE‑AF bundles a full autonomous engineering crew (planner, architect, coder, reviewer, tester) behind a single HTTP call. The implementation lives in the examples folder, where each sub‑directory (claude-code-haiku, claude-code-sonnet, codex, swe-af-haiku) contains a minimal Node.js agent that can be run inside the Docker‑based runtime.
The Dockerfile at the repository root builds the execution environment, installing the Node runtime and copying the examples/ payload. docker-compose.yml and docker-compose.local.yml define a service exposing port 8080, matching the API endpoint shown in the README. The entry point for each agent is a CLI script (examples/agent-comparison//src/cli.js or examples/agent-comparison//cli.js). These scripts parse the JSON payload, spawn the appropriate role agents, and write results back to the caller.
The repository also ships a comprehensive test suite (42 test files under examples/agent-comparison//test and examples/agent-comparison/swe-af-haiku/tests/) that validates the CLI behavior and the end‑to‑end flow.
How To Use It
Setup – Build and start the container. The presence of a Makefile suggests a make wrapper, but the concrete target can be inferred from the Docker files:
Build the image
docker build -t swe-af:latest .
Start the service (exposes port 8080)
docker compose -f docker-compose.yml up -d
The repository provides an .env.example; copy it to .env and fill any required values (e.g., API keys for the underlying LLM provider). Configuration – No additional config files are required for the core runtime. Model selection and runtime mode are passed in the request payload, as documented in the README. Running it – Issue a POST request to the local API. The README’s example is directly usable once the container is running:
curl -X POST http://localhost:8080/api/v1/execute/async/swe-planner.build \ -H "Content-Type: application/json" \ -d @- <<'JSON' { "input": { "goal": "Add JWT auth", "repourl": "https://github.com/user/my-project", "config": { "runtime": "claudecode", "models": { "default": "sonnet" } } } } JSON
The request triggers the CLI in examples/agent-comparison/claude-code-haiku/src/cli.js (or the appropriate runtime folder) via the container’s entrypoint.
Real‑World Use
A micro‑service team could point SWE‑AF at their monorepo, request a feature such as “expose a new health‑check endpoint,” and receive a merged PR after automated design, coding, review, and test generation. The workflow would be:
Trigger from CI pipeline
curl -X POST http://swe-af.internal/api/v1/execute/async/swe-planner.build \ -H "Content-Type: application/json" \ -d '{"input":{"goal":"Expose health endpoint","repo_url":"git@github.com:org/monorepo.git"}}'
The service returns a PR URL once the autonomous pipeline completes, allowing the team to merge with confidence.
Code Health & Issues
Low – Missing npm lockfile – examples/agent-comparison/claude-code-haiku/package.json (and similar) lack a package-lock.json or pnpm-lock.yaml; reproducible builds rely on the lockfile. Low – Limited test coverage of failure paths – Tests focus on happy‑path CLI execution; error handling for network failures or malformed payloads is not exercised. Low – No explicit license file – The root contains LICENSE but its content is not verified; ensure it matches the Apache‑2.0 badge. Low – Secrets not audited – .env.example hints at required credentials; repository does not contain a secret‑scanning workflow. Low – CI only runs make check – The GitHub Actions workflow (.github/workflows/ci.yml) invokes make check; without seeing the Makefile target we cannot confirm it runs the full test matrix. Low – Dockerfile does not pin base image digest – Potential drift in the underlying OS/library versions across builds.
Overall the codebase is modular, with clear separation between agent runtimes and a well‑instrumented test suite. The missing lockfiles and limited failure‑path testing are the primary gaps.
The Bottom Line
SWE‑AF delivers a functional proof‑of‑concept for an autonomous engineering fleet, packaged in a reproducible Docker environment and backed by a solid test suite. It is ready for evaluation in controlled settings, but production adoption should first address lockfile hygiene, broaden error‑scenario testing, and tighten CI security checks. Suitable for teams experimenting with AI‑driven code generation and multi‑repo orchestration.