Building a Multi-Agent QA Platform as a Student: What Broke and What I Learned
I'm a student and QA & CDN development intern who built BugMind AI, a full-stack platform that uses LangGraph agents to turn requirements into test cases. Here is the architecture, the bugs that cost me the most time, and how my media-pipeline work is shaping the redesign.
Why I built it
I'm a CDN development intern, working on how uploaded media is processed and delivered. Alongside that, I also do manual testing, and I kept noticing the same repetitive step: turning a feature description into modules, checklists, and test cases. I wanted to see if an agent pipeline could produce a good first draft so a human only has to review it. That became BugMind AI, a personal project I'm building solo.
The architecture
- Frontend: React, Vite, and Tailwind
- Backend: FastAPI, SQLAlchemy, and PostgreSQL
- Agents: LangGraph runs three agents in sequence: a module agent, a checklist agent, and a test case agent, each calling the Gemini API
- LLM access: LiteLLM with a fallback chain. It uses the user's own key first, then a developer key, then a free proxy, so the app keeps working when a quota runs out
I chose a sequential pipeline because each step depends on the output of the one before it. A module list feeds the checklist, and the checklist feeds the test cases.
One design decision I'm proud of
AI output can look more certain than it is. So the UI shows confirmed items as solid chips and assumed items as dashed-outline chips. A tester can see at a glance which test cases came from the requirements and which the model guessed.
What broke
1. Silent failures. A failure at the checklist level made the test case step render an empty result with no error. The page looked fine but showed nothing. I fixed it so failures surface instead of showing a blank state.
2. Retry logic that bypassed logging. My self-healing JSON retry called the model directly, so those calls skipped logging and quota handling. Routing it through one shared
call_llm() function fixed both.3. Two API folders. I had a stale
fetch() client sitting beside the axios client, and it skipped the auth interceptor. Requests from some screens went out without auth while others worked fine, which made it hard to spot. The lesson was to keep one API layer and delete the old one instead of leaving it around.4. A bcrypt crash. Passwords over 72 bytes caused a crash because bcrypt truncates input.
Where it runs today, and how it maps to AWS
BugMind currently runs on Azure, with the frontend deployed on Azure Static Web Apps. For the backend and database, I mapped the FastAPI service to Azure App Service and PostgreSQL to Azure Database for PostgreSQL Flexible Server. I looked at Azure because of the Azure for Students offer, which made it a low-cost place to host a student project.
I'm also familiar with AWS from my coursework and internship, so I mapped each piece across to understand both clouds:
- Static frontend (Static Web Apps) to S3 with CloudFront
- API (App Service) to Elastic Beanstalk or App Runner
- PostgreSQL Flexible Server to RDS for PostgreSQL
- Queued agent jobs to SQS
I haven't deployed BugMind on AWS yet, so these are equivalents I've reasoned through, not something I've tested. If I did the queue-driven redesign, I'd want to compare how each cloud handles worker autoscaling.
What I'd redesign
Right now the agent chain runs inside the request flow. My CDN work taught me a better pattern: long, expensive jobs belong on a queue, processed by workers that scale with demand, with the job record and the message committed together (a transactional outbox) and processing that is safe to retry (idempotent). I'm considering moving BugMind's agent chain to that model so long generations don't block the API and can be retried independently. I expect it to make failures easier to recover from, but I'm unsure whether the extra moving parts (a queue, workers, an outbox) are worth it for a project of this size.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article