Most organizations adopting AI development tools are not restructuring around them. They are adding a code assistant to an existing workflow and expecting the gains to follow. According to IBM Technology's recent overview of developer productivity research, that is precisely why most organizations are not seeing the gains that top-performing teams are seeing.
The difference between average AI adoption and top-quartile performance is not the tools — it is how teams are organized around them. Teams that restructure their practices around AI are seeing 100 to 150 percent productivity gains. Teams that simply adopt the tools are not. For healthcare security practitioners overseeing AI DevSecOps programs, the framing matters: the productivity question and the governance question are not separate.
The Six Practices
IBM Technology's video — presented by Martin Keen — walks through six concrete practices that distinguish high-performing AI-integrated engineering teams. They are worth examining individually, because each one has a healthcare security implication that the general productivity framing does not surface.1. Automate the Smart Way
The first practice is the most easily misunderstood. The recommendation is not to automate everything — it is to automate the right things: repetitive, error-prone tasks like CI/CD pipeline management and linters. The reason this matters is not just the time saved, but what happens with the time reclaimed. The video notes that teams that automate effectively often fill the reclaimed time with more meetings rather than higher-value work. The automation gains evaporate.For healthcare security programs, the direct application is to SDL tooling: static analysis, dependency scanning, container image scanning, secrets detection. These are exactly the error-prone and repetitive tasks the practice targets. The governance question is whether the time those tools reclaim is being used for threat modeling and architecture review — or for status updates.
2. Design First, Experiment Later
The second practice addresses a failure mode that AI code generation makes worse: the tendency to start writing code immediately. The video's framing is precise — five minutes of design (flowcharts, schema sketches) prevents hours of refactoring later. AI can assist in brainstorming and critiquing designs, but should not make architectural decisions.That last sentence deserves emphasis for healthcare environments. AI-assisted design critique is a productivity multiplier. AI-driven architectural decision-making in systems that handle PHI is an unreviewed control gap. The distinction is not semantic — it is the difference between AI as a sounding board during design and AI as a decision-maker in a system that determines how protected health information flows. SDL programs need a clear demarcation between those two uses.
3. Foster the Flow
Research cited in the video indicates that developers maintain flow state 73 percent longer with AI assistance than without. Flow state — the condition of deep, focused work — is where the hardest problems get solved. The practice is about protecting it: team leads must respect deep-work time and minimize context-switching interruptions.For security teams, this practice is a prompt to evaluate oncall and incident response interruption patterns. A developer who is context-switched out of a security-critical implementation to join a status call is not just less productive — they are more likely to introduce the kind of errors that security review exists to catch. Protecting flow during security-sensitive development work is not a luxury; it is a defect-reduction strategy.
4. Lessen the Cognitive Load
The video describes context switching as a "silent killer" of engineering productivity. The practice is to use templates, style guides, and documentation agents to handle routine cognitive tasks, freeing mental energy for the complex work that requires it.In healthcare security SDL programs, cognitive load reduction has a direct analog: secure coding templates, pre-approved library lists, and documentation standards for PHI-handling components. These exist in many programs as compliance artifacts. The productivity framing reframes them as tools that make engineers more effective at the hard parts of their work — not overhead imposed on top of it. That reframing matters for adoption.
5. Make Room for Growth
The fifth practice reframes code review. The recommendation is to treat it as a mentorship opportunity rather than a gatekeeping function, and to use AI to handle the tedious parts of review so human reviewers can focus on high-level guidance.Healthcare security programs that have implemented AI-assisted code review should examine whether they have actually restructured the review process around the tool's capability, or simply added the tool to an existing review checklist. If AI is handling syntax and style checks and human reviewers are still doing the same review they did before the tool was added, the practice has not been restructured — the tool has been layered in. The practice calls for the human review to shift to architectural judgment and mentorship in proportion to what the tool absorbs.
6. Sharpen the Tools of the Trade
The final practice is the most straightforward: ensure IDEs, languages, and frameworks reduce friction rather than create it. Choose modern, well-supported tools that stay out of the developer's way.For healthcare security programs, this intersects with the ongoing challenge of legacy system maintenance. Clinical environments often require developers to work across modern and legacy stacks simultaneously. The practice is a useful frame for evaluating where tooling friction is highest and whether it is being addressed in roadmap planning.
Measuring What Matters
The video's treatment of metrics is where it becomes most useful for security program leaders. The core frameworks presented are:- DORA (DevOps Research and Assessment) — quantitative metrics focused on deployment frequency, lead time for changes, change failure rate, and time to restore service
- SPACE — qualitative framework covering Satisfaction, Performance, Activity, Communication, and Efficiency
- DX Core 4 — an evolution of those frameworks organized around Speed, Effectiveness, Quality, and Impact
The video's caution about metrics is important and directly applicable to healthcare security program management: Goodhart's Law. When a metric becomes a goal, it gets gamed. Deployment frequency as a goal produces smaller, less meaningful deployments. Mean time to restore as a goal produces faster incident closure without root cause analysis. The recommendation is to use metrics as diagnostic tools — guides to spot and fix genuine problems — not as performance targets.
For healthcare security DevSecOps programs, this is a concrete warning about how SDL metrics get misused. Vulnerability count as a goal produces triage optimization rather than remediation depth. Code coverage as a goal produces tests that cover lines without covering threat scenarios. The metrics are useful for finding where the process is breaking down. They are counterproductive as scorecards.
What This Means for Healthcare
Healthcare AI development environments have characteristics that make the IBM framework's recommendations both more important and more difficult to implement than in general enterprise contexts.SDL Integration with AI Productivity Tooling
The design-first practice and the cognitive load reduction practice are directly relevant to secure development in healthcare. Organizations deploying AI coding assistants alongside SDL toolchains need to define where AI input is appropriate (brainstorming, critique, documentation) and where it requires human architectural decision-making (PHI data flows, access control design, encryption implementation). The IBM framing provides a productivity rationale for that demarcation that security leaders can use in conversations with engineering leadership.The Measurement Problem for AI-Augmented SDL
Healthcare security programs are adding AI tooling to SDL workflows at the same time that the IBM framework warns against turning metrics into goals. DORA and DX Core 4 are useful baselines for evaluating whether AI tooling is actually improving development outcomes — not just accelerating output. Speed without quality in a healthcare development context is a regulatory and patient safety risk, not just a technical debt problem.Mentorship and Knowledge Transfer in Healthcare IT
The fifth practice — treating code review as mentorship rather than gatekeeping — has a specific urgency in healthcare environments, where clinical system knowledge is often concentrated in long-tenured staff. AI-assisted code review that handles routine checks and frees human reviewers for architectural guidance is also a mechanism for transferring that clinical system knowledge during the review process. Healthcare security programs should evaluate whether their AI-assisted review workflows are actually creating that transfer opportunity.Cognitive Load and Security-Critical Work
The cognitive load practice has a specific healthcare security implication: the implementations most likely to introduce PHI exposure vulnerabilities are also the ones with the highest cognitive load. Complex data routing logic, cross-system authentication flows, and audit logging implementations are not where developers should be at peak mental fatigue. Structuring development work so that security-critical implementations happen during protected deep-work time — not sandwiched between meetings — is a practical application of the flow state and cognitive load practices for healthcare environments.The Bigger Picture
The productivity framing in this video and the security framing in most SDL guidance are usually presented as separate conversations. The IBM framework suggests they are the same conversation, approached from different angles. The practices that make AI-augmented development teams more productive — design discipline, cognitive load management, mentorship-oriented review, thoughtful measurement — are also the practices that make those teams more likely to produce secure software.For healthcare security practitioners who are trying to get SDL requirements adopted in engineering teams that are under pressure to ship faster, the productivity framing may be the more effective entry point. "This is how high-performing teams are already doing it" is a different conversation than "this is what compliance requires."
The metrics caution is the thread worth pulling hardest. Healthcare security programs that are building measurement frameworks for AI-assisted development should read the Goodhart's Law warning carefully. The goal is not to produce metrics that demonstrate SDL compliance. The goal is to produce software that does not harm patients. Those are not the same thing, and the measurement framework needs to reflect the difference.
This is entry #59 in the AI Security Series. For related coverage, see AI Security Series #58: The Agentic Attacker Has Arrived — What the Hugging Face Breach Means for Healthcare AI Security and AI Security Series #57: Agentic Misalignment Summer 2026 — Anthropic Alignment Research and Healthcare Governance.