SafeBreach’s Evolution into an AI-First Development Team: Part II

Last week we kicked off a blog series designed to document SafeBreach’s journey to becoming an AI-First development team. In my first post, I explained how we came to define what AI-First actually means at SafeBreach, why intentional leadership was essential to navigate this “do-or-die” shift, and what high-level best practices we implemented to ensure our use of AI supports the high quality and safety standards our enterprise customer base has come to expect of us.

In this post, I want to make things tangible. The evolution we have undergone as a development organization is not theoretical. Instead, we have quite literally changed the operational flow a SafeBreach developer follows, down to the way in which they implement a new Jira work item in a sprint.

As platforms improve and we refine our thinking, we will continue to adjust our process. And other organizations on this journey may choose different tools or sequences. But the goal of this post is simply to describe the system we’ve intentionally designed—and continue to improve upon—to make AI-First development practical and measurable for our team.

The AI-First Flow: From Jira Ticket to Merged PR

At SafeBreach, our workflow is built on a deliberate stack: Jira for ticket management, BitBucket for source control, and Claude Code as our exclusive coding agent. Reaching that level of consolidation was not accidental—we evaluated multiple agents before standardizing on one. The reasoning behind that decision deserves its own discussion, and we’ll cover it in a future post. What matters here is that AI-First development requires intentional tooling choices, not fragmented experimentation.

Now, let’s walk through the flow when a developer is assigned a Jira ticket. 

Step 1 — Create the Branch

Before writing a single line of code—human or AI—the developer creates a dedicated feature branch in BitBucket. The branch must include the Jira key; in this example, we will use SAF-12345: feature/saf-12345

This is more than a naming convention. It anchors everything that follows—PRDs, commits, reviews, and automation—to a single traceable unit of work. By embedding the Jira key in the branch name, we create an explicit linkage between Jira and source control. That linkage allows automation and reporting to associate code changes, PRDs, and ticket states across systems, transforming a simple naming pattern into the structural backbone of our AI-First methodology.

AI-First development is not ad-hoc prompting. It is structured, versioned engineering.

A Note on Our Internal Claude Skills and Infrastructure

Before continuing, an important clarification is needed. Within Claude, “skills” are reusable AI workflows that contain specific instructions, scripts, or context created by a user to train the agent to apply knowledge across different conversations or actions. 

All the skills mentioned in this post—/preparing-ticket, /planning-dev-task, /tdd-implementing-prd, /developing-loop, /reviewing-code, and /analyzing-risks—were developed internally by the SafeBreach engineering team. They are not out-of-the-box Claude features.

Each skill was designed around our problem domain, architecture patterns, quality standards, and security requirements. Over time, we refined them to encode SafeBreach-specific engineering knowledge directly into the AI workflow.

These skills, along with custom agents and internal MCP servers, are distributed across the organization through a private SafeBreach plugin marketplace. This ensures that every developer operates with consistent capabilities and guardrails, while benefiting from accumulated organizational learning.

For us, AI-First development is not just about prompting a powerful model. It is about building structured layers on top of it that reflect our engineering standards and evolve with them.

Step 2 — Enrich the Ticket with /preparing-ticket Skill

The developer opens a Claude Code terminal and runs the following skill: /preparing-ticket SAF-12345

The objective is not to begin coding. The objective is to eliminate ambiguity.

This skill expands the ticket through a back-and-forth interaction with the developer that is guided by pre-defined context, questions, etc. that have been incorporated into the skill. This includes:

• Clarifying functional requirements
• Identifying user flows and edge cases
• Defining acceptance criteria
• Establishing scope boundaries
• Surfacing constraints and dependencies

It generates two persistent artifacts:

• /prds/saf-12345/context.md
• /prds/saf-12345/summary.md

These files are committed to the feature branch. Persisting them ensures continuity. If work pauses or sessions reset, the context remains intact for both the engineer and the agent.

This step fundamentally shifts behavior: thinking precedes implementation.

Step 3 — Generate the PRD with /planning-dev-task Skill

After enriching the ticket, the developer runs: /planning-dev-task

This triggers an interactive planning process with Claude, resulting in a comprehensive PRD saved at:
/prds/saf-12345/prd.md

The PRD includes:

• Functional and non-functional requirements
• Architectural decisions
• Data models and schema design
• API specifications
• Frontend structure (when relevant)
• Flow and sequence diagrams
• Testing strategy
• Error handling and edge cases
• Phased implementation plan with quality gates

The PRD is committed before implementation begins.

In traditional workflows, planning often occupies a minority of effort. In our AI-First model, it frequently becomes the dominant activity. The PRD is the leverage point.

Precision in planning directly impacts the quality of generated code.

Step 4 — Controlled AI Implementation

Only after the PRD is reviewed and committed does implementation begin.

Developers typically use one of two skills:

• /tdd-implementing-prd — test-driven implementation aligned strictly with PRD phases
• /developing-loop — iterative implementation with built-in review cycles

Each implementation phase:

• Is committed separately
• Must satisfy predefined quality gates
• Requires explicit developer sign-off

The agent generates code. The engineer validates and approves it. Accountability remains human.

Step 5 — Structured AI-Assisted Review

Before merging, we may run: /reviewing-code

This produces a structured verdict — APPROVE or REQUEST_CHANGES — with severity scoring and actionable feedback.

For higher-impact changes, we may also run: /analyzing-risks

This evaluates security exposure, performance implications, maintainability, and business risk. AI supports review, but it does not replace judgment.

Step 6 — Human Verification in Staging

Even after all implementation phases are complete, the developer must validate the change in staging environments.

AI can generate tests. AI can reason about logic. System-level validation still requires human oversight. The final responsibility remains with the engineer.

Measuring AI-First Adoption

A process that cannot be measured cannot be managed. From the outset, we decided that AI-First could not remain a cultural aspiration. It had to be observable.

When a Jira ticket transitions to Done, automation is triggered. The system:

1. Pulls the associated BitBucket information
2. Identifies the impacted repository
3. Verifies that a PRD named after the Jira key exists under the appropriate prds/ directory

If a valid PRD is found, the ticket is marked AI-First qualified. If not, it isn’t. We track the ratio of AI-First qualified tickets per developer per sprint. This provides a clear signal of adoption and helps us spot patterns and improve the system over time.

AI-First is not about occasionally using an assistant. It is about following a defined methodology from ticket creation to merge. Adoption is measurable.

Expect Gradual Adoption

We did not introduce this methodology organization-wide overnight. We began with development leads and representatives from each team, running two pilot sprints in our standard two-week cadence. After retrospectives and refinements, we expanded the model across the broader development organization.

Three months into the rollout, the numbers began to tell a meaningful story. In the core development teams, AI-First qualified tickets climbed from single-digit percentages in the early sprints to approximately 32% per sprint. Adoption within DevOps and Test Automation has been lower so far, which is not surprising. In some cases, this reflects the need for additional “soft” enablement and hands-on support. In other cases, it reflects the nature of the backlog itself: certain work items require additional dedicated tooling (such as new MCP servers or specialized skills) before they can fully comply with the AI-First model.

What matters most is the trajectory. Across teams, the trend line is positive. We currently estimate that approaching near-total AI-First qualification for sprint work items could take 18 months or more. But the pace of change in AI platforms is extraordinary. It would not be surprising if reality proves that estimate either overly conservative or completely wrong.

What we do know is that AI-First transformation benefits from iteration — just like software itself.

A Living Methodology

Our system will continue to evolve. Agents improve. Platforms change. Our understanding deepens. As a result, we regularly adjust skill definitions, PRD structure, quality gates, and automation rules. What remains constant is the commitment to treating AI as a first-class engineering paradigm.

Other organizations may implement different flows or choose different tools. What matters is recognizing that AI-driven development requires structure, artifacts, measurement, and deliberate leadership.

In the next post, we’ll focus on one core element of this methodology: the PRD. We’ll discuss how it became the primary leverage point in AI-First development and how we structure it to maximize agent performance.