Buglensa

• 

  Proposed fix

Inspiration

Bug reports often arrive as vague descriptions, screen recordings, voice context, or logs. The difficult part is not only understanding what the user saw, but turning that evidence into repository context, reproducing the failure, finding the relevant code, and preparing a fix that another engineer can review.

Buglensa turns that manual investigation chain into one autonomous workflow.

What it does

Buglensa follows this flow:

Report Bug → Analyze → Investigate → Reproduce → Proposed Fix → optional Validate Fix → Create PR

A user submits bug evidence. Gemini structures the report, then a Google ADK-based agent investigates the connected GitHub repository, searches for likely duplicate issues, and prepares a constrained Playwright reproduction plan. Buglensa executes the plan, returns repository findings and reproduction evidence, and produces a deterministic Proposed Fix from trusted repository content.

When the user explicitly selects Create PR, Buglensa verifies the persisted original contents against the exact current default-branch SHA, creates an investigation-scoped buglensa/fix-* branch, commits the persisted fix, and opens a reviewable pull request. It never writes directly to the repository default branch.

Fix Validation is optional and informational; a blocked or not-yet-run validation does not prevent a user from creating a PR for human review.

How we built it

• Gemini through Vertex AI for multimodal bug analysis and repository investigation
• Google Agent Development Kit (ADK) for the autonomous investigation agent
• FastAPI / Python for orchestration and API services
• Next.js / React for the web application
• Playwright for constrained browser reproduction
• GitHub App / GitHub API for installation-scoped repository access, issue search, branch creation, and pull requests
• Cloud Run for the Next.js and FastAPI services
• Cloud SQL PostgreSQL for durable investigation and workflow state
• Google Cloud Storage for production evidence storage

Safety and engineering discipline

Buglensa uses short-lived GitHub App installation tokens. The model does not receive arbitrary shell execution. Browser actions are constrained to a bounded DSL. Pull-request publication is explicit, stale-safe, idempotent, branch-only, and never force-updates an existing deterministic branch.

Challenges we ran into

The hardest part was making autonomous investigation useful without allowing model output to directly mutate a repository. We separated model reasoning from trusted publication state, made Proposed Fix baselines deterministic, added bounded browser execution, persisted operation state for recovery, and made GitHub publication explicit and idempotent.

Browser reproduction and runtime validation also exposed an important distinction: an environment can block a check without proving that a proposed fix is wrong. Buglensa records these states separately rather than hiding them behind a generic success/failure result.

Accomplishments that we're proud of

Buglensa now completes a real end-to-end workflow from bug evidence to a GitHub pull request. In the demo target, it identified a checkout navigation bug, proposed changing router.prefetch("/checkout") to router.push("/checkout"), and created a one-file, one-commit PR on an isolated Buglensa branch.

What we learned

Reliable agents need more than a strong model. State persistence, deterministic boundaries, safe tool interfaces, failure classification, idempotency, and explicit human approval are what turn an AI workflow into something engineers can trust.

What's next for Buglensa

Next steps include improving reproduction-plan determinism, moving runtime fix validation into stronger isolated execution, and expanding evidence and integration support while keeping the same explicit publication boundaries.

Built With

• cloud-run
• cloud-sql
• fastapi
• gemini
• github-app
• google-adk
• google-cloud
• next.js
• playwright
• postgresql
• vertex-ai