Notifications
Clear all
Topic starter
15/05/2026 7:41 pm
TL;DR: Vibe coding now spans no-review prompting, guided editing, and structured AI-assisted engineering, with AI already writing 20-30% of Microsoft code and 85% of developers regularly using AI tools, according to Backslash Security and the JetBrains 2025 Developer Ecosystem Survey. The governance issue is no longer whether AI can write code, but when human review, access control, and lifecycle discipline must return.
NHIMG editorial — based on content published by Backslash Security: The Vibe Coding Spectrum: From AI-Assisted Engineering to AI-Native Agentic Development
By the numbers:
- Satya Nadella has noted that AI is already writing 20-30% of Microsoft's code.
- The JetBrains 2025 Developer Ecosystem Survey, covering over 24,000 developers across 194 countries, found that 85% regularly use AI tools.
- 62% rely on at least one AI coding assistant.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do AI coding agents create new identity and access management risk?
A: AI coding agents create IAM risk because they often act through persistent tokens, service accounts, and tool connections that outlive a single prompt.
Q: What is the difference between guided vibe coding and structured vibe coding?
A: Guided vibe coding relies on light review and conversational edits, while structured vibe coding keeps human ownership over architecture, interfaces, and verification.
Practitioner guidance
- Classify AI development modes by risk Define which projects permit full vibe, guided vibe, or structured vibe coding based on data sensitivity, lifespan, and deployment scope.
- Scope every agent identity explicitly Inventory the non-human identities used by coding assistants, agentic IDEs, CI jobs, and deployment automations.
- Block secrets from prompt and log pathways Prevent API keys, tokens, and certificates from entering prompts, local transcripts, and model logs.
Practitioners should expect the development lifecycle to absorb identity controls that previously lived only in infrastructure and runtime layers?
👉 Read Backslash Security's analysis of vibe coding and AI-native development risk →
Explore further
15/05/2026 7:42 pm
AI-assisted development is becoming an NHI governance problem, not just a developer productivity trend. Once agents can generate code, run tests, and touch deployment paths, the identity question shifts from who wrote the code to what non-human principal was allowed to act. That change expands the scope of access review, logging, and revocation. Practitioners should treat agentic development as part of identity governance, not a separate tooling conversation.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the same research.
A question worth separating out:
Q: When does vibe coding become too risky for sensitive workloads?
A: It becomes too risky when the code will persist, process sensitive data, or touch financial or operational controls. At that point, no-review prompting and loose editing create unacceptable governance gaps because the cost of a hidden defect or leaked secret is longer-lived than the convenience benefit.
👉 Read our full editorial: Vibe coding raises NHI governance risk as AI-native development scales
