A ticket sits in the queue for three days because nobody noticed the description doesn’t say whether the endpoint needs admin-role authorization. A developer starts implementing it, makes the wrong assumption, the PO rejects the PR two days later, security flags a concern a week after merge.

This isn’t a hypothetical — it’s the default mode of operation on any team where clarifying requirements depends on someone happening to notice the gap on first read, rather than on a systematic process.

We want to build something concrete against this and similar problems: an AI agent platform named Handrail (it steadies you, but doesn’t walk for you) that meaningfully lightens a development team’s work — clarifying ambiguous tickets before anyone starts coding, analyzing production incidents before someone gets paged at 3 a.m., learning from its own past solutions instead of asking from scratch every time.

We don’t start with a framework, or with npm install. We start the way any non-trivial system should start in practice: with the question of exactly what we want to automate, and why a human has to stay in the loop.

The guiding principle: an agent never acts without a human’s approval

Every application in this series — whether it’s drafting clarifying questions for a ticket, proposing a fix for a production incident, or expanding a knowledge base — stops at the same place: right before an irreversible action. The agent proposes, the human approves. Never the other way around.

Trade-off: this slows down every single interaction — nothing happens „instantly,” there’s always a wait-for-a-human step. We pay that price deliberately, because the alternative (an agent merging its own code to production, or sending its own reply to a customer unchecked) is unacceptable given how mature these tools actually are today — and the numbers below show why.

This isn’t excessive caution — it’s a decision backed by data worth citing directly, not just summarizing:

  • Trust in AI tool output has dropped to 29% in the Stack Overflow Developer Survey 2025, down from over 70% in 2023.
  • According to the Lightrun State of AI-Powered Engineering 2026 report (cited, among others, in Lightrun’s overview of AI in the SDLC), 43% of AI-generated code still needs manual debugging in production despite passing QA — and developers now spend more hours per week reviewing AI-generated code (11.4 h) than writing new code (9.8 h), a reversal of the pattern from two years ago.
  • Only 35% of companies say they’re ready to govern autonomous agents — the biggest blockers are security concerns (27%) and regulatory/compliance requirements (22%), per surveys cited in this report on AI adoption across the SDLC.

The strict human-in-the-loop we adopt here by default is aligned with where the market is maturing toward — not a step backward from fully autonomous tools, but a response to exactly what these numbers already show.

How we’ll design this platform

Instead of jumping straight at the first idea and writing code, we’ll walk the same path a team designing a non-trivial system would walk in practice:

  1. Ideas, confronted with the market — exactly what we want to build, and whether someone has already done it better.
  2. The big architectural question — separate, small applications, or one shared platform? What risk does each choice carry?
  3. Designing the platform core — the components and contract that every future application will build on, the knowledge base, the technology choices.
  4. The first application to build — a deliberate choice of where to start coding, and why without the rest of the platform for now.

Only then do we open the editor.

Who this is for

Developers curious what designing an agentic system looks like in practice — not a one-prompt demo, but decisions you’ll actually have to live with: where an agent’s autonomy ends, how to split responsibility across applications, what it takes so that adding a fifth application in six months doesn’t force a rewrite of the previous four.

What’s next

The next post gets concrete: what ideas are on the table, and what the market is already doing about the exact same problem — so we don’t design in a vacuum.

Bibliography

Categorized in:

AISDLC