Jahnavi Molleti@jahnavisrilekha131
jahnavisrilekha131
🤓 Latest Submissions
Pebble: a payments app built by an agent factory
Most multi-agent demos add agents and hope. We measured what actually goes wrong, then redesigned the team around it. THE PROBLEM. In run 1, our five agents built a payments app, but a reviewer rejected a batch while three more batches were stacked on the broken code, and it flagged the same blocker three times. Stale branches blocked merges, a fixed-interval timekeeper sent 49 of 65 wake-ups while nothing was wrong, one room hit Band's 10,000-message cap, and a human had to step in. THE FIX IS COORDINATION, NOT MORE AGENTS. Same five seats, new operating model, written into the mandates: work is a dependency graph; a batch starts only when what it builds on is merged; one branch per batch; one review per batch; the reviewer checks screenshots at phone and desktop width; a close-out roll call gates every stage report; the timekeeper speaks only when the room is quiet. Claude Sonnet plans and reviews; a low-cost model writes code and tests. THE RESULT, FROM THE ROOM LOGS. Four stages built and verified from one dispatch, with zero human messages after it (run 1: 5). Batches stacked on a rejected one: 4 to 0. Needless timekeeper wake-ups: 75% to 2%. Rejections fixed and merged in 7 to 58 minutes (median 15), against 3 h 31 min and still unmergeable in run 1. 35 committed screenshots. Stage 4 acceptance suite: 70 passed, 0 failed, 1 expected skip. THE APP. Pebble: pay, request, split, hold and refund. Payments are retry-safe: 50 concurrent identical requests produce exactly one payment, so money is never spent twice. WHAT DID NOT IMPROVE. Run 2 cost more messages (+28%), time (25.6 h to 29.8 h) and spend (about $10.50 to $25). Claude session limits stalled both runs for about 30% of the clock, and our process did not fix that unless we use api keys without any limits. We went with Claude sessions for now. The mandates name no product, so the factory can be pointed at a new problem.
6 Oct 2026
Bob Delivery Line
Bob Delivery Line takes a single product requirement and turns it into a documented, traced and tested microservice, built by five IBM Bob agents, with humans in the loop only where judgment is needed. The problem: shipping even a small feature is a relay. A requirement passes from product owner to architect, through refinement meetings, to a developer, then to testing and review. That is nine steps and five roles, and each person has to re-read the functional, technical and non-functional requirements to rebuild context. Tests come after the code, and every review finding starts another rework loop. Most of the time goes into meetings and handoffs, not into building. The solution: five specialist agents, each a custom Bob mode backed by its own skill, and each one reading the previous agent's output. The Product Owner agent writes an SRS with requirement IDs and Given/When/Then acceptance criteria. The Technical Architect agent produces the SDD, architecture decision records and Liquibase migrations. The Delivery agent builds the backlog, story points and sprint plan. The Testing Engineer agent derives test cases, BDD features and a requirements traceability matrix. The Coding agent implements the service sub-task by sub-task, with a review on every file. When an agent is missing context, it doesn't guess: it sends a structured question to a human in Mattermost through MCP. Seven custom skills, about 1,450 lines of instructions, encode real engineering standards: ISO/IEC/IEEE 29148 for requirements, IEEE 1016 and arc42 with C4 and ADRs for architecture, INVEST stories with Fibonacci points, and boundary value analysis, equivalence partitioning and state transitions for testing. A merge gate checks the full test suite, coverage and leftover TODOs, and a global hook keeps every conversation under 80,000 tokens so output quality stays high. The proof: from one idea, a payment service for a Venmo-like app, the pipeline produced 45 requirements, 3 ADRs, 10 user stories over 2 sprints, 59 test cases and 45 BDD scenarios traced back to requirements, plus a 47-file Java 21 / Spring Boot service with 37 unit and integration tests. It includes a double-entry ledger, idempotency keys, deadlock-safe locking and exact money handling. Zero lines of code were written by hand, and the main build session cost about 22 Bobcoins. The demo shows a live change request typed in plain words: "an admin should be able to see all transactions." In about 2.5 minutes Bob updated the SRS with new requirement IDs, added a new epic and user story to the backlog, and fitted the story into the sprint plan, with the developer approving each step. The developer then asked Bob to explain the technical design and the business scenario, answered directly from the SDD. After "implement US-011", Bob switched to Coding Agent mode, built the first sub-tasks, found and fixed a failing unit test on its own, and had 7 unit tests passing about 13 minutes after the request. The impact: fewer meetings and handoffs, faster onboarding, and a product developers can understand. Every task carries its business purpose and technical design, so developers can question it from either side. Testing is planned from the requirements instead of added at the end, and every artifact stays traceable. Teams can run the pipeline step by step with a developer, or fully automated. Next: run the merge gate in CI with automatic pull requests, add a DevOps agent to carry code to a deployed environment, and reuse the same modes and skills on new services.
27 Sep 2026
