Engineering-First Mindset for AI-Assisted Software Development

AI-assisted software development is accelerating, but it's also creating new security risks that traditional audit-based approaches can't keep up with. GitLab CISO Chaim Mazal argues that security teams must adopt an engineering-first mindset, operating like developers and embedding automated testing and CI/CD guardrails from the very start of the software factory.

The data behind the shift

According to Stack Overflow's 2025 Developer Survey, 84% of developers now use AI tools. Meanwhile, a Tricentis study found that roughly 60% of enterprises have shipped AI-generated code without testing it. GitLab itself warned that eight in ten organizations are adopting AI faster than they can develop governance policies. These numbers make it clear that the old model of security as a manual gate at the end of development is no longer viable.

Why this matters for builders

For teams building AI-powered products, security can no longer be a bottleneck. Mazal describes an engineering-first approach where security teams contribute code, make iterative adjustments, and build guardrails from inception. They become "first-level contributors" rather than manual auditors. This shift is critical because AI-generated code introduces blind spots that traditional review processes miss, especially when development cycles shrink from weeks to hours.

How to implement it in practice

GitLab is applying this by ramping up agents in a software factory model, with strict guardrails defined by data sensitivity and requirements from day one. Security teams can uniformly implement governance controls across the board and continuously adjust as requirements change. For builders, this means integrating automated security checks directly into CI/CD pipelines from the design phase, not bolting them on after code is written. If you're shipping AI-generated code, define guardrails based on data sensitivity: code that touches PII or financial data should trigger additional automated checks before merge. The goal is to automate as much as possible while keeping humans in the loop only where risk demands it.

The agent governance challenge

As agents become more involved in writing and reviewing code, you need strict governance from inception. Mazal emphasizes that guardrails must be defined based on data sensitivity and requirements, and uniformly implemented. This is especially important for builders deploying AI agents that can modify code autonomously. Without proper governance, agents could introduce vulnerabilities at scale. GitLab's approach uses agents to enforce these rules consistently, but the industry is still figuring out best practices for automated review and agent oversight.

What to watch out for

The evidence here comes from a single ITPro article citing GitLab's CISO and third-party surveys. The exact implementation details of an engineering-first security model will vary by organization. Fully automated pipelines are still evolving, and concepts like "dark testing factories" are being explored. Builders should treat this as a directional shift rather than a prescriptive blueprint. The industry is still figuring out best practices for agent governance and automated review, so expect iteration.

FAQs

It means security teams act as active contributors in the software factory, embedding automated testing and guardrails from inception rather than only performing audits. They become "first-level contributors" who code alongside developers, making iterative adjustments to security controls as development progresses.