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

Like most tech companies today, SafeBreach wants to ride the AI wave—or, more accurately, avoid being run over by it. There is enormous excitement around what AI can do for software development, and for good reason. At the same time, there is real anxiety. It feels a bit like a roller coaster: moments of genuine exhilaration followed quickly by moments of doubt, concern, and recalibration. We feel all of it, often in the same day. But there is a growing consensus—at SafeBreach and across the industry—that this is a do-or-die moment for technology companies.

For many months now, this transformation has been the topic of conversation across our development organization. Our development team, which is structured in a traditional disciplinary way, has specialized units that are dedicated to maintaining and improving every layer of the SafeBreach platform. Our challenge, naturally, is to maintain and evolve high-velocity, enterprise-grade products, while keeping the engineering debt under control. It’s a complex task for a team that is responsible for multiple product lines that are used by hundreds of global enterprise customers.

We knew AI would enable us to tackle this challenge head-on; we also knew that it would force us into largely uncharted territory. As the pioneers in the Breach and Attack Simulation (BAS) space over 12 years ago, we are accustomed to blazing new trails when it comes to technological advances—it’s in our DNA. So, the choice was not whether to engage with this transformation, but rather how to do so intentionally to both maximize the impact and set the gold standard in this new frontier. 

This post is the first in a series designed to document our journey—including the challenges and the successes—on the road to becoming an AI-First development team. It is not a playbook, and it is certainly not a victory lap. It is an exposition: how we came to think about what “AI-First” actually means, why we underestimated the scope of the change, and what made us realize this transformation could not be left to happen organically.  

Defining What “AI-First” Actually Means

One of the earliest lessons we learned is that the meaning of “AI-First” evolves as you progress. At the very beginning of our journey, being AI-First meant something fairly narrow: “We want our developers to use AI when they code.” We believed that would translate into things like smarter autocomplete, generating unit tests, or speeding up implementation work.

As our team gained experience, the definition expanded: “We want our developers to use AI for their day-to-day work, not just coding.” This included debugging production issues, assisting with deployments, and supporting operational tasks.

As we continued to advance, a deeper realization emerged—one that was both powerful and uncomfortable: being an AI-First development team requires redefining the role of the software engineer. In this new paradigm, engineers gradually shift from being the primary authors of code to being the reviewers, validators, and approvers of code written by AI agents. The responsibility for correctness, quality, and design did not disappear—if anything, it increased—but the nature of the work fundamentally changed.

Accepting that AI-First is not a fixed state but a continuously progressing definition turned out to be the whole point.

A Bigger Transformation Than We Expected

We initially underestimated how deep this change would go. This was not simply about adopting new tools. It was about changing habits, workflows, and—most challenging of all—professional identity.

Early on, we encountered real pushback. Many developers were emotionally attached to what we know as “vibe coding”: rapid, improvisational iterations with minimal upfront planning. There is something genuinely enjoyable about that flow, and it is reinforced by immediate feedback loops.

Introducing a strong emphasis on upfront planning, detailed product requirements documents (PRDs), and explicit design phases was not universally welcomed. In fact, as VP of Development, I had to be very explicit: this was not a democratic decision. We made authoring detailed PRDs a prerequisite for development tasks involving AI.

That decision was not popular at first and, anticipating this, we took significant steps to support our team during this seismic shift. This included engaging with external consultants who provided a series of hands-on training sessions with each of the engineering disciplines (front end, back-end, threat research, automation, and QA). We made sure the new methodologies were well documented and easily accessible through internal resource pages. We also raised the topic in full-team forums several times, providing ample opportunity for individual team members to safely raise concerns, identify potential inhibitors, and openly discuss mitigation strategies.

Over time, even the most resistant developers adopted the methodology and began to experience its advantages firsthand. One of the most striking shifts was how our time allocation flipped:

• In the old model, roughly 20% of our effort went into planning and design, and 80% into human coding.
• In the new model, roughly 80% of our effort goes into producing a detailed PRD—combining functional requirements, high-level architecture, low-level design, and quality gates—while only 20% is spent iterating with the AI coding agent.

The PRD became the primary leverage point. Writing it well turned out to be more important than writing code well. We’ll dive into how we enabled the team in this area in a future post, so be sure to check soon for more details.

Why This Could Not Be Left to Organic Adoption

One of our strongest convictions today is that our transformation to an AI-First organization could not have happened organically. If we had waited for it to emerge on its own, several things would almost certainly have occurred:

• Developers would have continued using a wide variety of AI tools and agents, preventing us from investing in shared infrastructure, accumulated practices, and internal capabilities.
• AI would have remained a voluntary assistant for relatively small, low-risk tasks, rather than being trusted with the complex work that dominates sprint capacity.
• The organization would have drifted toward scaled-up vibe coding, rather than toward a more professional, repeatable, and auditable development methodology. From a business perspective, it was critical that we did not allow this to happen—we had to ensure our use of AI within our development processes supported the high quality and safety standards our enterprise customer base had come to expect from SafeBreach.

By intentionally standardizing on a single coding agent and formalizing how it is used, we enabled shared learning, internal tooling, and compounding benefits that simply do not emerge from fragmented experimentation.

In short, organic adoption optimizes for comfort. Managed change optimizes for outcomes. We needed to ensure the latter.

The Role Shift No One Warns You About

As we became more comfortable with the new realities this type of transformational shift required, an unexpected insight emerged as our velocity improved.

It came as AI agents generated more code and pull requests began to pile up, waiting for human attention. We also noticed that while the code was often syntactically correct, it did not always meet our standards for design completeness, edge-case handling, or long-term maintainability.

This forced another realization: AI does not reduce responsibility—it redistributes it.

• Engineers became responsible for:
• Ensuring the agent does not drift from the intended design
• Catching missing edge cases and incomplete assumptions
• Validating test coverage and occasionally performing manual testing
• Thinking deeply about security, scale, and future compatibility

Interestingly, this shift promoted even junior developers into roles that previously required senior-level judgment. In many ways, our engineers became more aware of system-level concerns, not less.

But accepting this shift—from builder to inspector, from implementer to approver—is not easy for everyone. It requires letting go of familiar markers of value and embracing a new definition of craftsmanship.

Leadership in Uncertainty

Excitement and concern go hand in hand throughout this journey. We talk about it openly, often daily. The emotional swings are real.

What is also real is the growing industry-wide recognition that this transformation does not happen by accident. The rise of Chief AI Officer roles across many companies is, in my view, an acknowledgment that waiting for AI adoption to “just happen” is not a viable strategy. Deep organizational change requires intentional leadership.

We do not have all the answers. But we are convinced that pretending this is a minor tooling shift is far riskier than admitting how profound the change really is.

An Ongoing Journey

This post is not a conclusion — it is an invitation. Every organization will find its own path to becoming AI-First. But ignoring the need for deliberate leadership, shared practices, and cultural adaptation is a gamble few tech companies can afford.

In future posts, we’ll go deeper into the practical aspects of this journey: PRDs as leverage, quality gates, infrastructure, and what we’ve learned along the way.

We’re still on the ride — and we’re sharing the road, not just the destination. Join us for Part II, as I explore how an AI-First methodology impacts the team’s day-to-day process and how adoption is being measured.