Notifications
Clear all
Topic starter
06/09/2026 6:20 pm
TL;DR: Enterprise adoption of coding copilots is widespread, but the article argues they rarely move the needle on business outcomes because planning, testing, security, and delivery remain the dominant constraints, according to Arxan Technologies. The real gain comes from improving the end-to-end software lifecycle, not just accelerating code generation.
NHIMG editorial — based on content published by Arxan Technologies: For the Enterprise, Coding Co-pilots Are Simply Not Enough
By the numbers:
- 90% of enterprise R&D organisations have either fully, fully adopted or piloted copilots in the last two years.
- Only 50% of people in an enterprise development organisation are developers, according to the article.
- The article says developers spend only 25% of their time writing code.
Questions worth separating out
Q: How should security teams evaluate AI copilots in enterprise software delivery?
A: Evaluate them against end-to-end delivery metrics, not just coding speed.
Q: Why do coding copilots often fail to improve enterprise outcomes?
A: Because they optimise one narrow task while the real bottlenecks sit upstream and downstream.
Q: What breaks when software delivery governance is not aligned with AI-assisted coding?
A: The system produces more change than the surrounding controls can safely absorb.
Practitioner guidance
- Map the full software delivery bottleneck chain Document where work waits in planning, code review, testing, security scanning, release approval, and production promotion.
- Review pipeline identities and privileges Inventory the service accounts, tokens, and human approvals that can trigger builds, approve releases, and access production systems.
- Strengthen provenance and release governance Require traceable ownership for code changes, build outputs, and deployment actions so faster generation does not weaken accountability.
What's in the full article
Arxan Technologies' full blog covers the operational detail this post intentionally leaves for the source:
- The article's quantitative breakdown of planning time versus coding time across enterprise R&D teams.
- The vendor's explanation of agentic planning, agentic testing, agentic security, and agentic delivery as separate workflow layers.
- The broader argument it uses to position copilots inside the software development lifecycle rather than as a standalone productivity fix.
- The article's own framing of how enterprises should think about the 4th Wave of software development and delivery.
Coding copilots are useful, but what actually improves software flow?
Explore further
06/09/2026 6:21 pm
Coding copilots are a local productivity feature, not an enterprise operating model. The article is right to separate code generation from software delivery. Enterprises do not fail because code is hard to write; they fail when planning, assurance, and release governance are fragmented. For identity teams, the intersection is clear: as AI increases change volume, the identity controls around repositories, pipelines, and production access become more consequential, not less. The practitioner conclusion is to govern the delivery system, not the autocomplete feature.
A question worth separating out:
Q: Should organisations invest in copilots or in delivery workflow automation first?
A: They should start with the stage that limits flow the most. If planning is the bottleneck, improve intake and prioritisation. If security, testing, or release approval slows delivery, automate and harden those controls first. Copilots are useful, but they should not be funded as a substitute for lifecycle orchestration.
👉 Read our full editorial: Coding copilots miss the real enterprise bottlenecks in software delivery
