If you run engineering for a communications platform, you live inside a contradiction. The business wants more features, faster, on a network it cannot afford to break. Your SLAs are not marketing copy; for emergency-call paths they are a legal and human obligation. And the tooling that promises to make you faster is, on the current evidence, just as likely to make you less reliable.
The job is no longer choosing between speed and stability. It is engineering a delivery system where the two stop trading against each other. This piece walks through four pressures that define that system for telecom and large-scale service platforms, each grounded in 2025 data, and what a disciplined response looks like.
Key takeaways
- AI amplifies whatever delivery system it lands in, so on tightly coupled telecom stacks it raises change-failure rate unless automated testing, enforced review and progressive delivery come first.
- The 2025 Optus emergency-calling outage was an SDLC failure: a routine change with no blast-radius containment, no canary, monitoring that missed the most critical path and, by implication, no tested rollback.
- Running legacy and cloud-native in parallel roughly doubles the operational surface, and unmanaged toil becomes a burnout risk that drives change-failure rate up.
- NIS2 brings 24-hour, 72-hour and one-month reporting clocks and makes management personally accountable, so resilience evidence has to come out of the pipeline.
- The teams that cope rely on a small set of disciplines rather than a toolchain: progressive delivery, verified observability, shifted-down guardrails and audit-ready evidence.
AI is an amplifier, not a fix, and your foundations decide which way it amplifies
The 2025 DORA research on AI-assisted software development is blunt about the mechanism. AI adoption is now near-universal: 95% of developers use AI tools and over 80% report productivity gains, yet the same data shows an "Acceleration Whiplash" in which more code arrives with less scrutiny. The same analysis records:
441%
increase in median time in pull-request review
31%
more PRs merging with no review at all
242.7%
more incidents per PR
Bugs per developer are up 54%. More code, arriving faster, scrutinized less.
The decisive variable is not the model; it is what the model is poured into. AI amplifies whatever delivery system already exists. Teams with strong testing, review discipline, and loosely-coupled architecture convert AI output into throughput. Teams with weak foundations convert it into technical debt and process chaos at higher velocity. Telecom organizations running mission-critical, tightly-coupled legacy stacks sit squarely in that second profile.
A naive "use AI, ship faster" mandate pushed onto an OSS/BSS estate that was never designed for rapid, independent change does not accelerate delivery. It raises change-failure rate against exactly the reliability your SLAs depend on. The leadership move is to treat AI as a forcing function for the foundations: invest in automated testing, enforced review, and progressive delivery first, so that the amplifier has something worth amplifying.
In a tightly-coupled network, a routine change is a blast radius
The reason reliability dominates this domain is that the failure modes are not abstract. The 2025 Optus emergency-calling outage is the canonical recent case, and it is worth studying as a pure SDLC failure rather than as a telecom curiosity. An 18 September 2025 firewall upgrade caused roughly 600 failed Triple Zero emergency calls over about 13 hours across four Australian states, with four deaths reported during the outage, and Optus stated its monitoring system excluded Triple Zero calls so "there were no alarms".
Decompose that and every element is a familiar engineering control that was absent or weak:
None of these are exotic. They are the standard disciplines of change management and observability, applied to a tightly-coupled system where the cost of skipping them is measured in lives and government inquiries rather than dashboards. For a communications engineering leader the lesson is uncomfortable but actionable: the controls that feel like overhead on a routine firewall change are precisely the controls that exist for routine changes, because in this domain the routine ones are what kill you.
Operating two worlds at once is taxing your SRE capacity to the bone
The structural reason these controls are hard to apply consistently is that telecom is not migrating off legacy; it is running legacy and cloud-native in parallel, indefinitely. Monolithic OSS/BSS and circuit-era network functions are moving onto cloud-native 5G stacks built on microservices, Kubernetes, and multi-access edge. Teams operate both at once, which roughly doubles the operational surface. Traditional monitoring is part of the problem: tooling built for circuit-switched networks and monolithic OSS cannot handle 5G standalone, distributed edge, and microservices-based BSS, which is exactly the kind of gap that lets a critical path go unmonitored.
The human cost shows up in toil. On the network side the work is dominated by manual ticketing and "swivel-chair" provisioning, multivendor tool fragmentation, and non-standardized "snowflake" infrastructure that is hard to automate. Unmanaged toil is therefore not only a throughput tax; it is a retention and burnout risk, and burned-out engineers operating snowflake systems under time pressure are how change-failure rate climbs. The correction is to shift guardrails down into a self-service golden path rather than dumping operational load onto individual developers.
The platform engineering response is real but immature
In one 2025 survey 29.6% of platform teams do not measure success at all, and 55.9% of companies now operate more than one platform. Building a platform is not the same as building one that demonstrably reduces toil.
NIS2 turns reliability evidence into a board-level, personally-enforced constraint
The final pressure removes any option to treat this as best-effort. Under the EU NIS2 Directive, telecom and digital infrastructure are in scope regardless of size, with a 24-hour early warning, 72-hour assessment and one-month final incident report mandated, fines up to EUR 10 million or 2% of global annual turnover, and management bodies "personally accountable for compliance," against a transposition deadline of 17 October 2024. For Benelux and wider European operators this is now binding law, not guidance.
Read those clocks as engineering requirements:
- 24-hour early warning
- Impossible without observability good enough to detect and characterize an incident quickly, which is exactly the gap the Optus outage exposed.
- One-month final report
- Impossible without audit-ready change records, supply-chain traceability, and tested incident-response runbooks already wired into the pipeline rather than reconstructed afterward.
- Personal accountability for management
- The resilience evidence has to be a byproduct of how you deliver, not a document assembled under deadline pressure.
NIS2 is what fuses the other three pressures into a single mandate: move fast, stay reliable, and prove it, simultaneously, with names attached.
What good looks like
The teams that hold all four constraints at once tend to share a small set of disciplines rather than a particular toolchain:
- Progressive delivery by default for network and service changes, so the unit of risk is a canary slice, not the whole estate, with automated, tested rollback wired to the same signals.
- Critical-path observability that is verified, not assumed, including synthetic monitoring of emergency and high-value call paths, so a silenced alarm is itself an alertable condition.
- Guardrails shifted down into a golden path, so review, security checks, and compliance evidence are produced by the platform automatically rather than depending on individual engineers under load.
- Measured platform outcomes, tracking toil, cognitive load, rework rate, and change-failure rate, because a platform nobody measures is a cost center, not a control.
- Compliance evidence as a pipeline artifact, with change records and incident runbooks generated as you ship, ready to satisfy a 24/72-hour clock without a scramble.
Where speed and stability stop fighting
None of this is exotic, and that is the point. The pressures on a communications platform in 2025 are AI amplifying instability, tightly-coupled change blowing up in production, toil draining the people who keep the network alive, and regulation making the whole thing personally accountable. What connects them is that each is a delivery-discipline problem dressed as a technology problem. A platform that encodes progressive delivery, verified observability, shifted-down guardrails, and audit-ready evidence is not a reliability tax you pay reluctantly. It is the only configuration in which speed and stability stop fighting, which in this domain is the difference between shipping and dropping the call.
Sources
- DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics (2025 DORA State of AI-Assisted Software Development Report) - Faros.ai, July 2025
- Announcing the State of Platform Engineering Report Vol 4 - PlatformEngineering.org, December 2025
- Observability Evolution in Telecommunications: 8 Trends Reshaping 5G Networks and BSS/OSS Operations in 2025 - Vamsi Talks Tech, 2025
- Applying Platform Engineering Principles to Networking - Futuriom Research via Itential, 2025
- 2025 Optus emergency calling outage - Wikipedia, September 2025
- EU NIS 2 Directive: Expanded Cybersecurity Obligations for Key Sectors - Greenberg Traurig LLP, August 2025
