Before we design the architecture, we need a short list: exactly what do we want to automate, and has someone already done it — because if so, better to know that now than after a month of writing code. Below are four ideas and, for each, a concrete product already doing something very close — with a link, not just a name.
Four AI SDLC ideas:
Handrail Clarify — ticket refinement.
An agent reads a newly created ticket and, before anyone starts implementing it, generates clarifying questions from four independent perspectives: architecture, development, security, and product owner. They land as a comment (or separate per-role fields) on the ticket, which moves to a „Needs Clarification” column. A human answers and moves the ticket forward, only then does the agent attempt an implementation and open a PR.
Handrail Patch — autonomous production log analysis.
When a critical error occurs in production, an agent locates the faulty code based on the stack trace, diagnoses the root cause, and proposes a fix on Slack/Teams as an interactive message with „Open PR” and „Dismiss” buttons — it never modifies code without a human’s click.
Handrail Learn — self-learning knowledge base.
Customer tickets are answered automatically if the knowledge base (RAG, semantic search over embeddings) already has a confident answer above a threshold. If not, the agent designs a new solution and writes a new article at the same time as the customer reply, but the base only learns organically after a human approves that article. This is the only one of the four ideas that reaches beyond the SDLC proper (customer support, not development) — we keep it in the set because it shares the entire mechanics *and* the knowledge base that feeds the other workflows.
Handrail Triage — flaky-test and CI-failure triage.
An agent classifies a build failure based on the history of the last N runs of the same test — real bug / flaky test / environmental noise — and proposes, respectively: a code fix, a test quarantine with a linked issue, or nothing.
What the market already does — with links, not just names
None of these ideas is a novelty — and that’s good news, not bad. It means the pattern is validated in production, not just in theory:
- Clarify → GitHub Copilot coding agent for Jira does exactly this: you assign a ticket, the agent analyzes it, and if it’s missing information, it asks clarifying questions right in Jira’s comments before it starts coding.
- Patch → Sentry Seer (Autofix) — a three-step flow: root cause analysis → solution identification → patch generation. The Slack alert has a „Fix with Seer” button; Sentry states outright in its docs: „nothing gets merged without your approval.”
- Learn → Intercom Fin „Suggestions” — when Fin can’t resolve a conversation, it maps it to missing content and proposes a new help-center article, which an admin approves with one click. Intercom explicitly notes: Fin does not learn automatically from individual conversations without human review.
- Triage → Datadog’s Bits AI Dev Agent (Test Optimization) pre-generates fixes for flaky tests before a developer even looks at them, delivering a ready PR. Kong publicly wrote about using agentic AI to fix the flakiest tests in its own API gateway.
In one table — what we have, what the market has, and where the gap is:
| Our idea | Closest off-the-shelf product | What that product lacks vs. our vision |
| Clarify (ticket refinement) | GitHub Copilot coding agent for Jira | Questions come as one block, no split into 4 roles with separate status; closed prompts and logic |
| Patch (log analysis / autofix) | Sentry Seer (Autofix) | Tied to the Sentry stack; limited control over escalation rules and proposal format |
| Learn (self-learning knowledge base) | Intercom Fin (Suggestions) | Closed SaaS — no own vector store, article metadata, or control over the confidence threshold |
| Triage (CI / flaky tests) | Datadog Bits AI Dev Agent | Tied to Datadog; knowledge about bug patterns feeds nothing beyond the tool itself |
The last column adds up to one common theme: each of these tools is an island. Our gap isn’t „do the same thing cheaper” — it’s connecting these four areas with one knowledge base and one approval policy.
Trade-off: if these tools already exist and do 70-80% of what we’re planning, why not buy four subscriptions instead of building our own platform? Because none of them gives us full control over prompts and business logic, or — more importantly — the ability to connect knowledge across all four areas at once (e.g., a bug pattern found by the CI agent feeding the same knowledge base the production-incident agent draws on). That’s a real price: we’re building more than we’d strictly need, to gain an integration no single SaaS offers. We come back to this calculation honestly, not just as a stated conclusion, later in this series.
What’s next
So we have four ideas, each confirmed to solve a real, known problem. The natural question: do we build this as four separate applications, or as one platform with four pluggable workflows? The next post tackles exactly that question — along with the risks that need naming before we design the core.
Bibliography
– GitHub Copilot coding agent for Jira — public preview (GitHub Changelog)
– Sentry Seer Autofix (Sentry docs)
– Intercom Fin AI Agent explained — the Suggestions section (Intercom Help)
– Datadog: Automate flaky test fixes with the Bits AI Dev Agent
– Kong: How We Used Agentic AI to Fix Kong Gateway’s Flakiest Tests