Inspiration
Every developer knows the drill: an app crashes, you dig through a wall of log text, Google the error message, hunt down the exact file and line, and finally write a fix. It's slow, repetitive, and pulls attention away from real work — especially for well-understood failure classes like a bad connection string or a missing environment variable.
We wanted to see how much of that loop could be handed off to an agent — not just an alert bot that tells you something broke, but one that goes a step further: reads the real code, proposes an actual fix, and opens it as a pull request for review.
What it does
CIEARA watches for new error entries in Google Cloud Logging, fetches the actual source file responsible for the crash from GitHub, and sends both the error and the real surrounding code to an LLM (Groq) for diagnosis. The agent explains the root cause, proposes a corrected version of the file, and shows the diff in a Streamlit dashboard. Nothing is written to the repository until a human clicks approve — at which point the agent creates a branch, commits the fix, and opens a real pull request with the diagnosis included in the description
How we built it
Detection: a Python script pushes structured error logs (message + stack trace) to CIEARA using the google-cloud-logging client library. Code retrieval: PyGithub fetches the exact buggy file from the target repository. Diagnosis: the error and code are combined into a single structured prompt sent to Groq, asking for a root cause, a corrected file, and an explanation, in a fixed format we can parse programmatically. Extraction: Python's re module pulls the fixed code, root cause, and explanation out of the LLM's response, stripping markdown artifacts along the way. Remediation: on approval, PyGithub creates a timestamped branch, commits the fix, and opens a pull request — GitHub renders the diff automatically, so we never had to build that ourselves. UI: a Streamlit dashboard ties the whole flow together — detect, diagnose, review a sidebar diff, approve, and see a persistent history of past fixes (stored locally in SQLite). Deployment: hosted on Streamlit Community Cloud, with credentials passed through Streamlit's secrets manager rather than committed to the repo.
Challenges we ran into
Credential handling across environments was trickier than expected — a setup that worked locally with a service account JSON file completely breaks on a hosted platform where that file doesn't exist. We ended up writing a small credential loader that tries Streamlit secrets first and falls back to the local file, so the same codebase works in both places. Getting a clean fix out of the LLM's response took a few iterations — the model would sometimes wrap code in markdown fences, add stray formatting characters, or place them inconsistently, so the parsing logic had to be made more robust over a few passes. Deciding where "location-finding" logic belongs: we initially over-engineered a system to have the buggy app compute its own file path relative to its repo, before realizing that a much simpler, more honest design is to keep the target app's code untouched and let the agent fetch a known file directly — closer to how real error-monitoring tools are actually configured. Avoiding stale state in the UI — the dashboard would keep showing a diagnosis from a previous error after checking for a new one, which could have led to approving a fix for the wrong bug. Clearing session state on each new detection fixed this.
What we learned
How CIEARA , GitHub's API, and an LLM can be composed into a single coherent agent loop without needing heavyweight orchestration frameworks. Why real monitoring tools (Sentry, Datadog, etc.) always require you to explicitly link a repository rather than trying to auto-detect it — a stack trace alone is genuinely ambiguous about where the code lives. The value of a human-approval gate: it's not a limitation bolted on for safety theater, it's what makes an autonomous coding agent trustworthy enough to actually use.
What's next for CIEARA
- Continuous monitoring: right now CIEARA checks for errors on demand; the next step is a background polling loop so it truly watches logs in real time without a manual click.
- Multi-repo support: currently CIEARA is configured to watch a single GCP project and GitHub repository; extending this to a mapping of multiple services to their respective repos would make it usable across a real team's infrastructure.
- Post-merge verification: after a fix is merged, CIEARA could automatically recheck Cloud Logging to confirm the original error has actually stopped occurring, closing the loop completely.
- Broader bug coverage: we've tested CIEARA against connection failures and missing configuration values; expanding to more error categories (data validation, timeout handling, malformed input) would strengthen its general-purpose claim.
- Packaging as an installable SDK: instead of requiring a target app to log errors in a specific way, a small pip-installable library could handle error capture automatically for any Python (and eventually other language) codebase.
Log in or sign up for Devpost to join the conversation.