AI Development is Cheap Until the Code Ships

When IT leaders talk about AI-powered development, the focus is almost entirely on productivity. I've been in rooms with engineering leaders around the world over the past few months, and a pattern is emerging: AI is helping teams create software faster than many organizations can absorb the operational impact.

Every application AI helps create still needs infrastructure to operate, identities to manage, dependencies to track, telemetry to process, and vulnerabilities to secure. Those responsibilities don't disappear because the code was cheaper or faster to produce.

AI has fundamentally changed the economics of software. Building applications is becoming cheaper every month. Operating them isn't.

AI developer productivity has a downstream cost

AI-powered coding assistants have the ability to instrument the applications they create, automatically adding telemetry for errors, saturation, throughput, and latency.

More instrumented applications can mean better visibility. But as organizations produce more software, they also produce more telemetry. Someone still has to collect, store, analyze, and act on it.

Organizations may save time during development only to add cost downstream through infrastructure, observability, security, and operations. On consumption-based platforms, growing data volumes can also translate directly into growing spend.

The question is whether that additional data produces enough signal to justify the cost. Telemetry that helps teams detect a threat, diagnose a failure, or understand application performance has clear value. Collecting data simply because an application can generate it does not.

Three challenges executives need to confront now

1. More software means more data to manage

As application development accelerates, data pipelines can struggle to keep pace with the growing volume of telemetry from new applications and services.

AI-built applications generate instrumentation that often follows generic open-source patterns, with exporters and collectors configured by default rather than by design. That can leave organizations paying to collect and process large volumes of telemetry without knowing what actually contributes to security or operational outcomes.

The fix is knowing which data earns its storage cost and which is just noise with a timestamp. Organizations can retain lower-value telemetry economically while prioritizing the data that helps teams detect, investigate incidents, and understand application performance.

2. Security and observability need their own AI multiplier

Here’s the asymmetry that should concern every CTO and CISO: AI-powered tools are increasing developer productivity, while security analysts and SREs responsible for everything developers ship still need the capacity to keep pace.

AI can help close that gap. Emerging tools can identify vulnerabilities earlier, reinforce observability practices during development, and help analysts investigate operational data without relying on complex manual queries.

The organizations I see moving fastest treat AI as a force multiplier across the software life cycle, from the developer writing code to the SRE keeping it running and the analyst keeping it secure.

Accelerating development without accelerating operations simply moves the bottleneck.

3. AI governance has to include what AI creates

I remain bullish about the pace of AI innovation and believe organizations should keep pushing. That makes it even more important to address the operational and security challenges that emerge as AI scales.

Ownership of AI security and governance is still taking shape. And governance needs to extend beyond the AI tool or model.

Organizations also have to account for the applications AI helps build, the data those applications generate, the dependencies they introduce, and the interactions between AI agents and other services. Each new application becomes something the business has to operate, secure, and govern for as long as it remains in production.

That changes the AI governance conversation. Leaders need visibility not only into where teams use AI, but also into what that usage creates and what the organization will be responsible for after it ships.

Measure AI success beyond code output

At the core, the question hasn't changed: Are the applications and services my company depends on secure, available, and performing as they should?

AI makes answering that question more complicated. Teams can produce more software, services, and data without a corresponding increase in the people responsible for operating them.

That means developer productivity alone is an incomplete measure of AI success.

Technology leaders also need to understand what happens downstream: how much new infrastructure they're operating, how telemetry volumes and costs are changing, whether vulnerability and incident workloads are growing, and whether security and operations teams can keep pace.

The organizations that thrive in this next phase won't simply build the most applications the fastest. They'll figure out how to observe, secure, and govern what they build without allowing operational costs and complexity to erase the productivity gains AI created in the first place.

So here's the question I'd put to every CTO, CISO, and VP of Engineering:

Turn AI productivity into lasting business value. Subscribe to the Perspectives by Splunk monthly newsletter for executive insights on AI, security and technology leadership.