🤓 Latest Submissions
.png&w=828&q=75)
DocuSwarm: Parallel Due-Diligence on AMD GPUs
DocuSwarm is a parallel document due-diligence agent swarm running on AMD Instinct GPUs in the cloud. Reviewing contracts, NDAs, and reports for risky clauses is slow, manual work done one document at a time. DocuSwarm turns it into a single upload: drop in up to 20 documents and a swarm of async agents analyzes them concurrently against the same LLM endpoint, surfacing risk level, red flags, key dates, and parties per document, with a consolidated Excel/JSON report. This isn't a chatbot demo — it's built to make AMD GPU throughput visible. Every document gets its own async task bounded by a semaphore; all of them hit the same vLLM server, which is exactly the continuous-batching workload AMD Instinct GPUs + ROCm + vLLM are built for. A live dashboard streams completed/total, tokens/sec, elapsed time, and active concurrency in real time. Tested end-to-end on an AMD Instinct MI300X (AMD Developer Cloud) serving Qwen3-8B via vLLM: 6 documents processed concurrently in 1.5 seconds at 1,653.9 tokens/sec — real GPU throughput, not a simulation. Each result reflects genuine LLM judgment (e.g., a contract flagged MEDIUM risk with specific red flags like termination penalties and liquidated damages), not keyword matching. The backend is provider-agnostic by design: it talks to any OpenAI-compatible endpoint, so moving from a laptop to an AMD GPU instance is a one-line config change. Tech stack: FastAPI + asyncio backend, React/Vite dashboard streaming over Server-Sent Events, vLLM serving on AMD Instinct GPUs (ROCm), openpyxl for Excel export. Repo: https://github.com/yanerox69/docuswarm
1 Dec 2026
DocuSwarm: Parallel Due-Diligence on AMD GPUs
DocuSwarm is a parallel document due-diligence agent swarm built for the AMD Developer Hackathon: ACT III — "AI agents and high-performance AI applications on AMD GPUs in the cloud." Reviewing contracts, NDAs, and reports for risky clauses is slow, manual work done one document at a time. DocuSwarm turns it into a single upload: drop in up to 20 documents and a swarm of async agents analyzes them concurrently against the same LLM endpoint, surfacing risk level, red flags, key dates, and parties per document, with a consolidated Excel/JSON report. This isn't a chatbot demo — it's built to make AMD GPU throughput visible. Every document gets its own async task bounded by a semaphore; all of them hit the same vLLM server, which is exactly the continuous-batching workload AMD Instinct GPUs + ROCm + vLLM are built for. A live dashboard streams completed/total, tokens/sec, elapsed time, and active concurrency in real time. Tested end-to-end on an AMD Instinct MI300X (AMD Developer Cloud) serving Qwen3-8B via vLLM: 6 documents processed concurrently in 1.5 seconds at 1,653.9 tokens/sec — real GPU throughput, not a simulation. Each result reflects genuine LLM judgment (e.g., a contract flagged MEDIUM risk with specific red flags like termination penalties and liquidated damages), not keyword matching. The backend is provider-agnostic by design: it talks to any OpenAI-compatible endpoint, so moving from a laptop to an AMD GPU instance is a one-line config change. Tech stack: FastAPI + asyncio backend, React/Vite dashboard streaming over Server-Sent Events, vLLM serving on AMD Instinct GPUs (ROCm), openpyxl for Excel export. Repo: https://github.com/yanerox69/docuswarm
18 Oct 2026
Dark Factory — the band that refuses its own work
Dark Factory is a software factory built in BAND Desktop: three coding-agent seats in one room, coordinating through @mention routing, building a wallet and payments service against a written specification. THE DESIGN DECISION Grading here is literal and automated: exact field names, exact status codes. One mistyped attribute scores nothing. So the advantage is not implementing faster; it is refusing to hand off anything that does not conform. Two of the three seats are forbidden from writing production code: a coordinator who plans and holds the gate, an implementer, and a reviewer who checks conformance against the spec text, never against the implementer's report. All three run the same harness and model — OpenCode on Featherless, GLM-5.2 — so nothing comes from giving a role a better model. The only difference is the mandate file, loaded as that seat's system prompt. WHAT IT CAUGHT Before any code existed, the reviewer turned the specification into a 158-item checklist, derived from the spec text only, never from the shipped tests, which are a sample that would encode its own blind spots as the requirement. Then one seat corrected another: the coordinator ruled that an empty request body means an empty object; the reviewer confirmed it and rejected it as incomplete, because the stored body must be that empty object too, or a legitimate retry reads as a key reuse — a money bug, caught before a line was written. WHAT IT MISSED We stopped the reviewer partway to conserve budget. Two defects shipped past the seats, one of them making login impossible after an import. The owner caught both at the gate. MEASURED 3h49m, 451 messages, 11,743,469 tokens, $11.70 of a $25 credit, 147 of 147 shipped checks. Input outweighed output 54 to 1: a seat re-reads the whole room every turn, so a factory costs what its own history costs. THE DELETE TEST Take BAND out and this factory does not degrade. It disappears — the rejection has no channel.
6 Oct 2026
Issue → PR: Bug reports to tested PRs with IBM Bob
**The broken workflow.** Going from a bug report to a merged fix is mostly glue work: reading a vague report, writing a reproduction, hunting through the codebase, patching, re-running the suite and writing the PR description. It is slow, and it is where AI assistants usually cut corners: "fixing" a bug by weakening the test, or patching the symptom instead of the cause. **What we built.** Five IBM Bob 2.0 custom modes (`.bob/custom_modes.yaml`) that turn one command, `/Issue → PR Fix @issues/ISSUE-004.md`, into a branch with a regression test, a root-cause fix and a PR write-up: 1. **🎯 Issue → PR (orchestrator):** creates the branch and runs each stage as a visible Bob subtask, gating every step on the previous one's result. It never edits code itself. 2. **🧪 Reproducer:** writes the smallest pytest test that fails for the reported reason. 3. **🔍 Diagnoser:** read-only root-cause analysis with symbol navigation and a cheaper `explore` subagent. Reports file:line and every other place with the same mistake. 4. **🔧 Fixer:** minimal fix, iterating until the full suite is green. 5. **📝 PR Writer:** commits and writes the PR description (root cause, fix, verification, risk). **Guardrails enforced by Bob, not by prompts.** Each mode's edit access is restricted with `fileRegex`: the Reproducer can only touch `tests/`, the Fixer can only touch `shopcart/` and **cannot modify tests**, and the Diagnoser cannot edit at all. So the agent physically cannot "pass" by editing the test. **Honest measurement.** We seeded 10 realistic bugs (rounding, off-by-one dates, shared mutable state, overselling inventory, CSV quoting, BOM encoding, ID reuse…) into a Python order-management library, written up as user-style bug reports. Every fix is scored by **hidden acceptance tests stored outside the repo** (Bob never sees them), and only counts if the full existing suite still passes. **Results.** **9/10 bugs fixed** as judged by the hidden tests, for **~18 Bobcoins total (~2 per fixed bug)**, in three batched Bob tasks. Every fix landed on its own branch with a regression test, a conventional commit and a PR description, and no existing test assertion was changed on any branch. **The one miss is the most useful result.** ISSUE-005 (a reorder cart that mutates a past order) is a shared-mutable-state bug with two call sites. Bob fixed the one described in the report (`reorder()`) and all visible tests went green, but it missed the same aliasing in `place()`. The hidden tests caught the incomplete fix, and a second independent run made the same choice. That is exactly the failure mode that slips through code review, and why the pipeline is graded on tests the agent cannot see. **Bob 2.0 features used.** Custom modes, Agent mode, subtasks (`start_subtask`), `explore` subagents, todo lists, per-mode tool groups and `fileRegex` edit restrictions, symbol navigation, terminal execution.
27 Sep 2026
RevenueFlow: WhatsApp voice receptionist
In Latin America, WhatsApp is not a channel — it is the channel. Customers message small businesses there, usually with a voice note. But the person who would answer is the person doing the work: a dentist with their hands in someone's mouth is not replying to WhatsApp. Messages pile up, and the customer books somewhere else. RevenueFlow answers instead. It transcribes the voice note with AssemblyAI Universal-3.5 Pro, extracts intent through the AssemblyAI LLM Gateway, resolves "el jueves en la tarde" into a real timestamp in the business's timezone, checks actual availability, books the appointment, and replies — in about seven seconds. Language is detected, not assumed. Detection runs with expected_languages, a country fallback and code_switching for mixed voice notes, and on_low_language_confidence set to fallback, so a noisy note degrades to the country's language instead of failing outright. It answers in Spanish, Portuguese or English — and still books for someone writing in Russian or Mandarin. One rule shapes everything: the model decides what the customer wants; the system decides what is allowed. The model cannot invent a service (catalog IDs only), a date (it returns a weekday symbol and the system computes the date), or availability. Replies are hand-written templates, because they carry exact dates and times, and a hallucination there is a lost appointment in real life. It holds the conversation too. Four words — "mejor para el viernes" — reschedule the right appointment to Friday at the same hour, without repeating the service or the date. Complaints, money and medical questions stop and go to a human. Running on a real WhatsApp number, in two countries, with row-level tenant isolation and money stored as integer minor units with its FX rate. 177 tests. Source public under MIT.
30 Sep 2026
