
The Problem A bug report is not a bug fix. Between "a customer complained" and "a reviewed pull request" sits slow, serial, manual work: decide whether the report is new or a duplicate, find the request in the logs, follow the stack trace, find the policy document that defines correct behaviour, write a reproducing test, fix, verify, and write a PR for the right reviewer. We estimate about 2.7 hours per bug, mostly spent gathering context rather than on engineering judgement. It also produces errors. Duplicate reports get fixed twice. Wrong-result bugs leave no stack trace to follow. Under pressure the reproducing test is skipped, so the bug returns. Fixes that contradict an unread policy cause rework in review. The solution: BugFlow BugFlow gives each kind of work to the right actor. 1. Deterministic steps go to a toolkit: A stdlib-only Python CLI does the following: - Links each report to its log evidence and fingerprints the failure. - Merges duplicates, ranks by severity and routes to CODEOWNERS. - For bugs with no stack trace, finds the faulty line through the governing policy section. - Writes a one-page debug brief per bug. - Enforces a gate: the suite must pass and every bug needs a named regression test. - Drafts PRs and times every stage. 2. Judgement steps go to IBM Bob agents. `/bugflow` starts a custom **BugFlow Lead** mode. It runs the toolkit, reads the issues and policy documents, and spawns **one fixer subagent per unique bug, in parallel. Each fixer writes a failing regression test first, confirms the failure, applies the smallest policy-compliant fix and passes the gate. The Lead reviews each fix against the cited policy, drafts PRs and reports the impact. Demonstrated impact (live run on a sample checkout service) - 4 reports became 3 unique bugs. A duplicate, worded differently by VIP support, was detected automatically and closed through the canonical fix. - 3 fixer subagents ran concurrently and fixed a float-rounding cent mismatch, a strict comparison that blocked buying the last unit, and a case-sensitive lookup that caused HTTP 500 errors. - 3 regression tests were added, each failing before its fix. The gate passed, and 3 PRs were drafted for the right teams. - It took 4.0 minutes of measured wall-clock time against an estimated **500-minute** manual baseline (about 124× faster). The baseline estimates are itemised in PROBLEM.md. Errors are prevented by construction. Fixes need a failing-first test. Duplicates close through one fix. Every root cause cites the rule it broke, and every PR reaches its owner. BugFlow works on any repository with bug reports, logs and policy docs. Engineers review fixes instead of hunting for context.
27 Sep 2026

We trained LangACT — stock ACT (a 52M-parameter bimanual manipulation policy) with a language instruction written into an internal slot the architecture already has but never uses. This costs 0.2% more parameters and 0ms of inference time, since the instruction is a known string embedded once and cached. Trained from 15,000 to 200,000 steps across 5 chained Kaggle T4 sessions, it reaches 70% closed-loop success on the standard AlohaTransferCube-v0 bimanual benchmark (MuJoCo, 20 fixed seeds) — tying the no-language ACT baseline exactly. Then we ran the test that actually matters: the instruction-swap test. Feed the model the wrong instruction while running the same task. If language steers behavior, success should collapse. We ran this at three checkpoints (125k, 150k, 200k steps). At 150k and 200k, the swapped-instruction run produced the exact same per-seed outcomes as the correct instruction — every time. We diagnosed why: every training episode pairs one task with one instruction 1:1, so the visual scene alone fully determines behavior, and nothing ever rewards reading the sentence. Rather than hide this, we built the voice interface around it. Speechmatics STT transcribes the spoken command, keyword matching resolves it to a known task, and that task actually runs — Speechmatics TTS confirms the true outcome. If asked for a task the system can't do (peg insertion, measured 0/20), it declines honestly instead of failing silently. Exported to OpenVINO INT8 (NNCF, 3.9x smaller), verified with official benchmark_app numbers: 239ms (fp32 CPU) to 71ms (INT8, Intel iGPU) — a real 3.4x speedup, on our own Core i3 laptop, no NPU, disclosed plainly. Fully reproducible: public checkpoint, verified end-to-end from a fresh clone.
16 Sep 2026

Every AI wellness app works the same way: your tasks, sleep, spending, and health data get shipped to someone else's servers before you get an answer. LifePilot removes that trade-off — every model runs on the device itself. LifePilot is a calm, offline-first wellness app with four features, each backed by its own on-device model: • Overwhelm Manager — describe what's overwhelming you; an on-device Llama 3.2 1B model breaks it into a concrete 5–8 step plan, personalized from on-device memory that never syncs anywhere. • Energy Planner — a trained time-series model predicts your energy curve for the day from recent sleep and activity. • Hydration Tracker — a trained regression model sets a personalized daily water target and explains why. • Expense Scanner — point the camera at a receipt; on-device OCR plus trained models extract the merchant, total, currency, and category. No photo or text ever uploaded. Every model is exported to ExecuTorch and runs directly on the phone's own chip. There is no server-side inference path — put the phone in airplane mode and everything still works identically. That's not a fallback; it's the only mode. Where AMD fits: the four trained models (energy, hydration, and two expense models) are trained and exported on AMD Instinct MI300X GPUs via ROCm, on AMD's ROCm cloud notebooks — real GPU compute producing the exact .pte files that ship in the app. All four features are built and running on a real Android device today, including the on-device Llama agent generating multi-step task breakdowns in airplane mode. Privacy isn't a marketing line here — it's the architecture.
13 Jul 2026