Notifications
Clear all
Topic starter
02/08/2026 11:58 am
TL;DR: An AI-first development workflow that ties Jira, BitBucket, and Claude Code to structured planning, controlled implementation, and measurable adoption is described by SafeBreach, with approximately 32% of core development tickets qualifying per sprint after rollout. The broader lesson is that AI use in software delivery only becomes governable when the process is versioned, traceable, and human-validated.
NHIMG editorial — based on content published by SafeBreach: Implementing a Practical, Intentional, and Measurable AI-First Development Process
By the numbers:
- In the core development teams, AI-First qualified tickets climbed from single-digit percentages in the early sprints to approximately 32% per sprint.
- Approaching near-total AI-First qualification for sprint work items could take 18 months or more.
Questions worth separating out
Q: How should teams govern AI-assisted development workflows that use coding agents?
A: Treat them as identity-governed execution paths, not just productivity tools.
Q: Why do AI-first engineering models need more than prompt guidance?
A: Prompt guidance alone does not create accountability, reproducibility, or audit evidence.
Q: What breaks when AI-assisted work is not tied to persistent artefacts?
A: Review and audit break first, because teams lose the ability to prove how a change was planned, executed, and approved.
Practitioner guidance
- Implement artifact-based traceability for AI-assisted work Require every AI-assisted task to carry a persistent ticket, branch, and planning artifact so review and audit can reconstruct the full change history.
- Standardise approved AI workflows and tool paths Define the specific agent skills, prompts, and internal tool integrations allowed for planning, implementation, and review.
- Separate adoption measurement from quality measurement Track AI-assisted workflow completion as one metric, then independently track review defects, staging failures, and rollback rates.
What's in the full article
SafeBreach's full post covers the operational detail this analysis intentionally leaves for the source:
- The exact Jira-to-branch-to-PRD workflow used to qualify AI-First tickets and the artifact names the team requires.
- The internal Claude skills that support ticket enrichment, planning, review, and risk analysis across development stages.
- The measurement logic behind AI-First qualification ratios per developer and sprint, including how the team interprets adoption trends.
- The rollout sequence from pilot sprints to broader team expansion, which shows how the methodology was introduced in practice.
👉 Read SafeBreach's AI-first development workflow and adoption measurement post →
AI-first development workflows: what changes for engineering teams?
Explore further
02/08/2026 1:05 pm
AI-first development becomes governable only when the workflow is identity-aware and artifact-driven. The strongest feature in this model is not the model itself but the chain of accountability linking a person, a ticket, a branch, and a reviewable PRD. That is the same governance principle that underpins IAM and NHI control: every action must be attributable and lifecycle-bound. For practitioners, the lesson is that AI-assisted engineering needs identity and traceability controls from the start.
A question worth separating out:
Q: How can organisations tell whether behavioural AI is working in practice?
A: Look for reduced dwell time between suspicious delivery and response, better correlation between email and identity events, and fewer missed cases where legitimate-looking traffic leads to account abuse. If detections are accurate but cannot explain why an event was flagged, the programme may be operationally weak even if it looks effective on paper.
👉 Read our full editorial: AI-first development is becoming measurable through workflow controls
