• 

  https://canva.link/ev0gzbi7dhynbhj

• 

• 

• 

• 

  Flow Diagram

• 

  Architecture Diagram (Ask Deep Architecture: https://deepwiki.com/justinedevs/premortem)

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Most teams only discover their real failure modes in postmortems, after production incidents, missed SLAs, or painful customer-impacting bugs. We wanted a way to run a premortem on the codebase itself, before merge or release, with the discipline of a good staff engineer reviewing the whole system, not just a linter pointing at individual lines.

We were also frustrated by issue trackers full of vague, low-signal tickets. The idea for Premortem came from asking: what if an agent could swarm over a repo, CI, docs, and runtime signals, predict how this system is likely to hurt us in the future, and then turn those predictions into a high-quality, triage-ready backlog?

What it does

Premortem is an agentic web application that runs multi-angle audits on a GitLab project, including code, configuration, CI/CD history, and operational context, to surface future failure modes before they turn into incidents. For each repository, it treats the question "what could go wrong here?" as a structured analysis problem instead of a one-pass static check.

It then synthesizes its findings into deduplicated, structured GitLab issues with a consistent template: problem, expected behavior, suggested fix, success criteria, and why it matters. The maintainer gets a backlog of highly actionable work items instead of a wall of warnings, and can review or approve each issue before Premortem creates it in GitLab.

How we built it

Premortem runs as a hosted system with a Vercel frontend and an Alibaba Cloud ECS backend. The reasoning layer uses Qwen Cloud and Gemini, with OpenRouter as a routing layer for compatible model fallback and provider flexibility. The backend is wired to GitLab MCP plus GitLab REST and GraphQL APIs so it can read repositories, CI pipelines, and existing issues, and then create or update issues when changes are approved.

On top of that, we built a swarm-style orchestration layer: a set of logical sub-agents, each responsible for a different lens, including product gaps, future failure modes, security and privacy risks, onboarding and developer-experience problems, rollout and rollback paths, generated artifacts, integration boundaries, and cross-service drift. The orchestrator plans which lenses to run, scopes their view of the repo, aggregates findings into a canonical internal format, and then performs clustering and deduplication before passing everything into the issue synthesis step.

The frontend is a containerized TypeScript web app built with Next.js and React. It talks to the backend through a thin API layer, handles GitLab OAuth, project selection, audit configuration, Slack notifications, billing, and an interactive review UI where maintainers can inspect, edit, merge or split, and approve suggested issues before they are created.

Challenges we ran into

The first challenge was designing the swarm orchestration so that multiple lenses could run in parallel without stepping on each other, while still sharing enough context to avoid duplicated work. Getting the right level of granularity, specifically what each sub-agent sees and is responsible for, took several iterations.

Another hard problem was deduplication and issue shaping. Many risk signals overlap. The same misconfigured rollout path might show up as reliability risk, unsafe automation, and missing rollback criteria. We had to design a clustering pass that could merge these into one parent issue with clear child links, instead of spamming maintainers with near duplicates.

Finally, integrating GitLab, Slack, Qwen, and the observability stack required careful handling of authentication, scopes, rate limits, and event delivery. We had to ensure that the agent could be powerful enough to read everything it needed and create issues, while only holding the minimum required permissions for each project and integration.

Accomplishments that we are proud of

We are proud that Premortem does not just summarize code. It produces backlog items that a senior engineer would actually accept into a sprint. Each issue includes context, expected behavior, a concrete suggested fix, and explicit success criteria.

We are also proud of the transparency of the system. For every suggested issue, the UI lets you drill down into the reasoning, including which files, pipeline runs, runtime traces, or existing issues contributed to the finding, and which lens surfaced it. This makes the agent feel like a collaborator you can audit, not a black box that dumps tickets into your tracker.

What we learned

We learned that multi-agent, multi-lens design is a strong fit for system-level risk analysis compared to a single monolithic prompt. Assigning each lens a clear responsibility and bounded scope makes the overall behavior easier to reason about and tune.

We also learned a lot about making AI output operationally useful. The difference between AI analysis and a ticket that will actually be worked on is in the structure. Expected behavior, suggested fix, and success criteria turned out to be critical fields, and we had to iterate on prompts and schemas to get those reliably. On the infrastructure side, working with Alibaba Cloud ECS, Vercel, Qwen Cloud, Gemini, OpenRouter, GitLab MCP, Slack, and the observability tools taught us how to design tools and actions that are robust to partial failures, such as network glitches and rate limits, while still giving the agent enough flexibility to explore a large codebase.

What is next for Premortem

Next, we want to extend Premortem beyond a single GitLab project into cross-repo and cross-service analysis, so it can surface risks at the boundary between services, including schema mismatches, contract drift, rollout misalignment, and integration failures between teams. We also plan to add richer lenses such as performance and capacity planning, runbook coverage, SLO alignment, Slack-driven workflows, and policy-aware checks so Premortem can enforce organization-specific standards instead of only generic best practices. Longer term, we would like to ship a CLI, more deployment automation, and tighter GitLab pipeline integration so teams can run a premortem automatically on key branches or tags and gate releases on high-severity findings.

Built With

• alibaba-cloud
• arize-phoenix
• containerized-frontend
• docker
• gemini-3
• gitlab-graphql-api
• gitlab-mcp-integration
• gitlab-rest-api
• google-cloud-agent-builder
• https-reverse-proxy
• langfuse
• next.js
• oauth-2.0
• qwen
• react
• slack
• supabase
• typescript