DEV Community: K Manoj Kumar

AI Made Developers 10x Faster. DevOps Didn't Catch Up.

K Manoj Kumar — Tue, 20 Jan 2026 13:16:36 +0000

Developers ship features in 15 minutes now. They used to take a day. Then they wait 30 minutes for CI/CD.

That's the pattern I keep seeing.

AI coding tools made the easy part faster. The hard part stayed slow.

When coding took a day and builds took 30 minutes, nobody complained. The build happened in the background. Developers moved to the next task.

Now that same 30-min build is the longest part of shipping code.

The bottleneck shifted. And most teams haven't noticed yet.

The velocity paradox nobody's talking about

Harness AI surveyed thousands of engineering teams in 2025. They found something surprising.

63% of organizations ship code faster since adopting AI.
But 45% of deployments with AI-generated code lead to problems.
And 72% of organizations suffered at least one production incident from AI code.

DORA's 2025 research confirms it. Individual developer productivity is up.

Task completion improved 21%. Pull request volume jumped 98%.

Delivery metrics stayed flat.

Deployment frequency didn't improve. Lead time for changes didn't drop. Change failure rates increased for most teams.

Here's what's happening:

AI makes individuals faster. Organizations stay slow.

77% of organizations deploy once per day or less. Some deploy monthly. That cadence worked when coding was the constraint. It doesn't work when features get written in minutes.

AWS describes it like this: "When AI increases code output, manual processes can't keep pace. Work accumulates at handoff points faster than teams can clear it."

You're NOT shipping faster. You're queuing faster.

The velocity gains you got at the code level become technical debt at the infrastructure level.

AI made code generation 10x faster. Code delivery stayed the same speed. The gap between them is your new bottleneck.

Why your 30-minute build just became unacceptable

Let me walk through the math:

Feature takes 1 day to code. CI/CD takes 30 minutes. That's 3% overhead. Acceptable.

Same feature now takes 15 minutes to code with AI. CI/CD still takes 30 minutes. That's 200% overhead. Not acceptable.

The pipeline didn't get slower. The context changed.

Developers sit there waiting. The build is now the longest step. Every deployment magnifies the pain.

If you're deploying 10x more frequently because coding is 10x faster, and your CI/CD time stayed constant, you just made DevOps your critical path.

15% of teams need more than a week to recover from failed deployments. When you're shipping AI-generated code at high velocity into an unprepared pipeline, failures multiply.

The tooling you built for manual coding at human speed can't handle AI coding at machine speed.

Platform engineering: The foundation AI velocity actually requires

DORA 2025 found 90% of organizations now have platform engineering capabilities. That's up from 45% in 2022.

Why the explosion?

Because AI amplification requires platform maturity.

Organizations struggling with basic CI/CD reliability see AI gains absorbed by infrastructure friction. The ones thriving built Internal Developer Platforms first.

Here's what IDPs actually provide:

Self-service infrastructure. Developers provision resources through portals instead of filing tickets.
Golden paths. Pre-defined workflows with embedded best practices. You don't teach every developer CI/CD setup. The platform enforces it.
Standardized environments. "Works on my machine" problems disappear.
Automated provisioning. Infrastructure as code means instant deployment.

The results are measurable:

40-50% reduction in cognitive load for developers.
Environment provisioning goes from days to hours.
70% reduction in deployment errors with multi-cluster GitOps.

GitOps forms the backbone.

It gives you version control for infrastructure. Every change tracked. Rollbacks automatic. Audit trail for compliance.

93% of organizations plan to continue or increase GitOps use in 2025.

When AI writes code that breaks production, GitOps lets you revert in seconds instead of hours.

Pick Backstage (Spotify's open-source platform) if you have platform engineers to customize it. Pick Port if you want to deploy in days. Use ArgoCD or Flux to automate GitOps underneath.

Platform engineering isn't about tools. It's about creating guardrails that let developers ship fast without breaking things.

CI/CD optimization: the tactics that cut build times 30-90%

Docker layer caching in builds alone can deliver up to 30-90% reduction in build times.

The technique is simple. Structure your Dockerfiles so dependencies cache separately from code.

❌ Bad approach:

Every code change rebuilds everything, including dependencies that didn't change.

COPY . .
RUN npm install

✅ Good approach:

Dependencies get cached. Only code changes trigger rebuilds.

COPY package*.json ./
RUN npm ci
COPY . .

Harness CI achieved 8X faster builds compared to GitHub Actions using Docker Layer Caching. CircleCI reports builds going from minutes to seconds.

BuildKit adds advanced caching. Cache mounts. Inline cache. Registry cache for CI runners.

For GitHub Actions:

Remote caching shares cached layers across your GitHub runners. First build is slow. Every build after reuses layers.

-name: Build with cache
uses: docker/build-push-action@v6
with:
cache-from: type=gha
cache-to: type=gha,mode=max

Dependency caching is even simpler. npm, Maven, pip dependencies rarely change. Proper caching reduces build times by 50-90% depending on the project.

Most CI platforms support this. CircleCI uses restore_cache and save_cache. GitHub Actions has a cache action. GitLab has cache configuration built in.

Downloading dependencies on every run is an unnecessary drain on time and money.

Multi-stage builds separate build dependencies from runtime dependencies:

FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

The final image only includes what's needed to run. Build tools stay in the builder stage. Smaller images deploy faster. Caching works more effectively.

Parallel testing cuts execution time. Run multiple test suites simultaneously in isolated Docker containers.

AI can determine which tests actually need to run based on what changed. You skip irrelevant tests without sacrificing coverage.

Cost optimization matters too. Auto-delete artifacts after 7-30 days. Cache persistence based on branch activity. Microservices isolation so you only test affected components.

These aren't exotic optimizations. They're standard practice that most teams haven't implemented yet.

Staging bottleneck? Use Ephemeral environments

Shared staging environments create queues. Ephemeral environments eliminate them.

Ephemeral environments are temporary, isolated deployments created automatically for each pull request. Full-stack environments with micro-services and databases. Production-like configuration.

They spin up on PR creation. They tear down on merge.

Everyone works in parallel instead of sequentially.

Developers don't wait for staging.
QA tests in isolation.
Product managers preview features before merge.

Cost control makes this viable.

Environment TTLs auto-delete after 7 days. Working hours scheduling shuts down environments nights and weekends. Spot instances deliver up to 90% cost reduction compared to on-demand.

Smaller instance sizes for preview environments. Per-resource billing tracks costs. Auto-teardown when PR closes or merges prevents orphaned environments.

Northflank provides Kubernetes-based ephemeral environments with automatic PR triggers. Signadot uses request-based isolation without infrastructure duplication.

Pick one that fits your stack. They all solve the same problem: staging bottlenecks.

Rework Rate: The new DORA metric for AI-generated tech debt

DORA added Rework Rate in 2025.

Why?

The original four metrics had a blind spot. Teams could hit strong numbers on deployment frequency, lead time, change failure rate, and recovery time while spending too much time cleaning up AI-generated code.

Rework Rate measures unplanned deployments. Emergency patches. Quick corrections. The "we just shipped this yesterday and now we need to fix it" deployments.

AI impacts every metric differently.

Deployment Frequency: You might deploy more often. But if change failure rate increases, faster deployment is meaningless. Track them together. Fast plus stable equals healthy. Fast plus failing equals danger zone.
Lead Time for Changes: Break it into stages. Code, review, test, deploy. If AI only speeds up coding, you haven't improved lead time. You've identified your bottleneck. Teams seeing real improvement speed up the full pipeline, not just the first step.
Change Failure Rate: AI code often looks fine. Passes tests. Matches conventions. Gets approved. But it can hide edge cases and subtle bugs. Segment CFR by AI-assisted versus non-AI-assisted changes. Track repeat incidents from similar AI code patterns.
Failed Deployment Recovery Time: Measure alongside repeat incident rates. Fast recovery plus fewer repeats equals healthy. Fast recovery plus same fires monthly equals cleanup mastery, not resolution.
Rework Rate: Catches what the others miss. If you're constantly patching AI-generated code after deployment, this metric reveals it.

DORA identified multiple team archetypes in 2025. Three matter most for AI adoption:

Legacy Bottleneck teams have deployment pipeline fragility. AI coding assistants won't help. They need DevOps investment first.
Pragmatic Performers have constraints shifting from code generation to integration. They need better code review capacity and automated testing.
Constrained by Testing teams have high code output but insufficient test automation. AI accelerates their problem.

Your archetype determines what AI benefits you'll see and what risks you'll face.

The cloud cost reality nobody wants to discuss

AI budgets average $85,521 per month in 2025. That's a 36% increase from 2024.

30-50% of AI-related cloud spend evaporates into idle resources, over-provisioned infrastructure, and poorly optimized workloads.

Only 51% of organizations can confidently evaluate whether their AI investments deliver returns.

Right-sizing matters.

Not every model needs A100s or H100s. Running small workloads on high-end GPUs is overkill. Match compute resources to actual requirements. Use smaller model variants for development. Separate dev, staging, and prod clearly.

Auto-scaling based on actual usage helps. Companies using predictive analytics see 28% less downtime and 31% better recovery.

FinOps integration surfaces cost visibility in developer workflows. Real-time cost information in IDEs. In developer portals. In GitOps pipelines. Team and service-level cost attribution.

CloudZero converts raw billing into engineer-usable insights. Cast AI handles autonomous Kubernetes optimization. Datadog correlates cost with application performance.

The best teams embed cost awareness into every deployment decision.

The controversial data you need to see

METR ran a randomized controlled trial in 2025. 16 experienced developers working on their own large open-source repositories. 22K+ stars. Over 1M lines of code.

When using AI tools like Cursor Pro with Claude, developers took 19% longer than without AI.

Tasks averaged 2 hours each.

This was experienced developers in familiar codebases. AI likely helps less experienced developers or in unfamiliar territory. But the study reveals something important.

AI amplifies strengths and dysfunctions.

If your DevOps is broken, AI makes the brokenness worse. If your platform engineering is solid, AI accelerates everything.

GitClear analyzed 153 million changed lines of code. AI code assistants excel at adding code quickly. But they also cause "AI-induced tech debt". Hastily added code is caustic to teams expected to maintain it.

DORA 2025 found roughly 30% of developers still don't trust AI-generated output.

Trust is earned through reliability.

Platform engineering provides the guardrails that build trust. Automated testing catches AI mistakes before production. Observability reveals where AI code performs poorly.

Here's the paradox Harness AI uncovered:

74% believe companies that fail to integrate AI safely across their SDLC in the next year will "go the way of the dinosaurs".
But 73% warn that unmanaged AI assistants could widen the blast radius of failed releases.

You must adopt AI to stay competitive. But unmanaged adoption creates existential risk.

The winning move is clear: Invest in platform engineering, automated testing, and observability before you scale AI adoption.

Where to actually start

You don't fix everything at once.

Start with your biggest bottleneck.

If CI/CD is slow:

Implement Docker layer caching this week. Structure Dockerfiles for optimal caching. Set up dependency caching in your CI platform. You can cut build times by 30-50% in days, not months.

If staging is a bottleneck:

Evaluate ephemeral environment platforms. Start with one team. Prove the velocity gain. Scale from there.

If you lack platform foundations:

Pick an IDP framework. Backstage if you have strong engineering skills. Port if you want faster setup. Define golden paths for your most common workflows. Enforce them through automation.

If cloud costs are climbing:

Audit your data pipelines. Map what models actually consume. Auto-shut down idle resources. Implement ephemeral environment cost controls. TTLs, working hours scheduling, spot instances.

Measure properly:

Start tracking all five DORA metrics, not just four. Segment by AI-assisted versus non-AI-assisted changes. Identify your team archetype. Invest in the constraints that actually matter for your archetype.

The truth about AI and DevOps

AI didn't make DevOps obsolete.

AI made DevOps essential.

The velocity gains from AI coding assistants are real. 55% faster task completion is real. 98% more pull requests is real.

But those gains don't matter if your delivery infrastructure can't handle the throughput.

The platform engineering market hitting $40B+ by 2032 isn't hype. It's infrastructure catching up to AI velocity.

Optimize the pipeline. Build the platform. Measure what matters.

The AI coding revolution already happened. The DevOps evolution is happening now!

References

– MK

Cloudflare Hyperdrive: Here's What You Need to Know

K Manoj Kumar — Thu, 27 Nov 2025 13:34:11 +0000

I've been tinkering with Cloudflare products for a while now. Workers, Pages, D1, KV - they all have their place in the stack. But Hyperdrive? This one's different. It's the piece I've been waiting for because it actually solves a real problem that most developers don't talk about until it bites them.

Here's the thing - you've got a database somewhere. Maybe it's AWS RDS, Neon, Supabase, or PlanetScale. Maybe it's an old Postgres instance running on AWS us-east-1. And you want to build a fast, global application using Cloudflare Workers. But every query to your database is taking forever because it's on the other side of the world.

I spent the last few days building with Hyperdrive, and I'm gonna walk you through what it actually does, how it works, why it matters, and where it fits in your architecture.

What Hyperdrive Actually Is

Hyperdrive isn't a database. It's not a replacement for your database. It's a connection pool that sits between your Workers and your existing database, distributed globally across Cloudflare's network.

Think of it like this: instead of your Worker in London trying to connect to a database in New York every single time, Hyperdrive keeps a pool of connections already open in data centers close to your database. When your Worker needs to query data, it borrows a connection from the nearest pool, runs the query, and gives it back.

That's it. Simple concept. But the performance difference is massive.

The Pain This Solves

Before I explain how Hyperdrive works technically, let me explain why you'd want it.

When your Worker connects directly to a remote database, it has to do this:

TCP handshake (1 round-trip)
TLS negotiation (3 round-trips)
Database authentication (3 round-trips)

That's 7 round-trips before you even send a query. With each round-trip taking 100-200ms depending on geography, you're looking at 700-1400ms just to set up a connection. Then add another 100-200ms for the actual query. Your response time is already in the red zone and the user hasn't even seen anything yet.

With Hyperdrive? All those round-trips happen once when the pool is initialized, and then connections are reused. Your Worker talks to Hyperdrive on the same Cloudflare server it's running on, sends the query, and gets a response.

The benchmark they ran internally showed a direct database query taking 1200ms, but through Hyperdrive it's 500ms - a 60% reduction just from connection pooling. With query caching enabled, that drops to 320ms. That's 75% faster. I ran my own quick test and got similar numbers. The difference is night and day.

How Hyperdrive Actually Works

Here's where it gets interesting. Hyperdrive has 3 core components working together.

1. Connection Pooling at Scale

Hyperdrive maintains a pool of database connections that are placed in data centers as close to your origin database as possible. This is intentional - they actually measure which Cloudflare locations have the fastest connection times to your database and place the connection pool there.

When you create a Hyperdrive configuration, you set a max_size parameter which tells Hyperdrive how many connections it's allowed to maintain. For free tier it's around 20 connections, for paid it's around 100. This is a soft limit - Hyperdrive will temporarily exceed it during traffic spikes to ensure high availability.

The pooler operates in transaction mode. When your Worker sends a query, it gets assigned a connection. That connection stays with your Worker for the duration of the transaction, then gets returned to the pool when the transaction finishes. The next query might get a different connection from the pool, which is fine - the pool ensures all connections are in a consistent, idle state.

2. Smart Query Caching

This is where Hyperdrive gets clever. It understands SQL at the protocol level. It can differentiate between a SELECT query (read-only, safe to cache) and an INSERT, UPDATE, or DELETE (mutating, should never be cached).

By default, Hyperdrive caches all read queries for 60 seconds. You can configure this up to 1 hour. It also supports stale_while_revalidate which means it can continue serving cached results for an additional 15 seconds while it's fetching fresh data in the background.

But here's the kicker - this caching happens across all Cloudflare locations. If a query was cached in Frankfurt, and someone in Tokyo runs the same query, they get the cached result from the nearest edge location. This was a recent improvement and it cuts latency by up to 90% for cache hits.

About 70-80% of queries in a typical web application are reads that can be cached. That means most of your queries are served from cache without ever touching your origin database.

3. Latency Reduction Through Placement

This is the unsexy but super important part. Hyperdrive collects latency data from all its edge locations to your database. It then deterministically selects the best data centers - the ones that can connect to your database fastest - and only runs the connection pool in those locations.

Recently, they improved this further. They moved connection pool placement even closer to origin databases. The result? Uncached query latency dropped by up to 90%. That means even when you can't use cache, you're still getting a massive speedup.

Combined with Workers' Smart Placement (which runs your code closest to where it's needed), the whole system starts to feel like your database is global even though it's in one region.

Database Support and Drivers

Hyperdrive supports PostgreSQL and MySQL, which covers most use cases. But more importantly, it works with almost any database provider you can think of.

AWS Aurora (both Postgres and MySQL)
Neon (Postgres)
Supabase (Postgres)
PlanetScale (MySQL)

It also supports Postgres-compatible databases like CockroachDB and Timescale. The versions it supports are pretty broad - PostgreSQL 9.0 to 17.x, and MySQL 5.7 to 8.x.

MongoDB and SQL Server are currently not supported.

For drivers, you've got solid options:

node-postgres (pg) - Recommended. Solid, well-maintained, works great with Hyperdrive.
Postgres.js - Modern, minimalist, handles connection pooling well.
mysql2 - For MySQL. Fast, supports promises.
Prisma, Drizzle, Sequelize - All the major ORMs work because they use these base drivers under the hood.

The important part is that you don't need to rewrite your code. You just change your connection string to use Hyperdrive and you're done. Your existing ORM or driver just works.

Setting Up Hyperdrive

Setting up is straightforward. Create Hyperdrive configuration via the Cloudflare dashboard:

wrangler hyperdrive create my-database --connection-string postgresql://user:password@host:5432/dbname

Then bind it to Worker in wrangler.toml:

[[hyperdrive]]
binding = "DB"
id = "xxxxx"

Then in Worker code, create a client:

import { Client } from 'pg'

export default {
  async fetch(req, env) {
    const client = new Client({
      connectionString: env.DB.connectionString
    })

    const result = await client.query('SELECT * FROM users WHERE id = $1', [123])
    await client.end()

    return new Response(JSON.stringify(result.rows))
  }
}

That's it! Just one line change and you're routing through Hyperdrive.

For local development, you can either connect to your local database directly (set localConnectionString in your config) or connect to your remote database for more accurate testing.

Connecting Private Databases

What if your database isn't publicly accessible? It's in a VPC behind corporate firewalls. Hyperdrive handles this too, using a secure connection from your network to Cloudflare.

You set up a Cloudflare Tunnel in your private network. This creates an outbound connection from your network to Cloudflare. Then you configure Hyperdrive to connect through that tunnel.

Hyperdrive automatically creates the Cloudflare Access application and service tokens needed to secure this. You just specify the tunnel and Hyperdrive handles the rest. It's like someone finally made this pattern easy.

The connection flow is: Worker → Hyperdrive → Cloudflare Access → Cloudflare Tunnel → Your Private Database.

It's secure, isolated, and actually simple to set up.

Pricing and Limits

Hyperdrive is bundled with Workers pricing. It's included in both free and paid plans.

Free Plan:

100,000 database queries per day
Max 10 configured databases per account
~20 max connections per configuration

Paid Plan:

Unlimited queries
25 configured databases per account
~100 max connections per configuration

Both plans get connection pooling and query caching - no additional charges.

The free plan is generous, and you can build a real product on it. The paid plan is where you scale.

A few important limits to know:

Maximum query duration: 60 seconds (both plans)
Maximum cached response size: 50 MB
Idle connection timeout: 10 minutes
Initial connection timeout: 15 seconds

These are reasonable. I've never hit them in normal use. If your query takes more than 60 seconds, that's probably a problem with your query anyway.

When Hyperdrive Makes Sense (And When It Doesn't)

I've been thinking about where Hyperdrive actually fits in different architectures.

Hyperdrive is great for:

Building global apps on Workers that need to query a centralized database
APIs that do a lot of read queries (where caching helps)
Applications where latency to the database is a bottleneck
Teams that want serverless compute without sacrificing database connectivity
Situations where you're currently using slow database proxies or connection pools

Hyperdrive is less useful for:

Applications that are write-heavy and can't use caching
Databases that need to be in multiple regions (use database replication instead)
Applications that need sub-ms latency (still global, might not be enough)
Long-running transactions that keep connections open

The Real-World Performance Impact

Let me be concrete about what this means for your application.

A typical web request that queries a remote database:

Without Hyperdrive: 1200-1500ms (mostly connection overhead)
With Hyperdrive (no cache): 500ms (connection pooling saves 60%)
With Hyperdrive (cached): 320ms (you save 75%)

If your application makes 3 database queries per request (common for web apps), that's:

Without Hyperdrive: 3600-4500ms
With Hyperdrive (mixed cache): 1200ms

That's 3x faster. Your LCP improves. Your Core Web Vitals improve. User experience improves.

Plus, by reducing load on your origin database through connection pooling and caching, you might not need to scale your database as aggressively. That's a real cost saving.

My Takes

What I like:

It actually works. The latency improvements are real and measurable.
Setup is simple. No refactoring required.
It works with existing drivers and ORMs. You don't need to learn new abstractions.
The caching is smart - it understands SQL at the protocol level.
Private database support via Tunnel is clean and secure.
It solves a real problem that wasn't solved before.

What I'd like to see:

Better observability out of the box. I want to see cache hit rates, connection pool utilization, and query latencies without third-party tools.
More granular cache control per-query. Sometimes I want certain queries to never cache, and setting this at the Hyperdrive level will be useful.
Connection pool metrics in the dashboard. Tell me how many connections are open, how many are idle, and when we're hitting the soft limits.
Automatic retry logic for transient failures would be nice.

Hyperdrive is a solid, production-ready service. If you're building on Workers and need to talk to a SQL database, you must try Hyperdrive.

Real Use Cases

Cloudflare itself uses Hyperdrive internally - their billing system, D1 control plane, and Workers KV all use it to connect to Postgres clusters. If it's good enough for Cloudflare's own infrastructure, it's probably good enough for yours.

I've seen it used for:

Content management systems serving global sites
E-commerce platforms reading product catalogs
Analytics dashboards querying historical data
Admin interfaces for SaaS products
Real-time APIs with read-heavy workloads

What's Next

Hyperdrive fits perfectly into the modern serverless stack. You've got:

Workers for compute (global, stateless, instant scale)
Hyperdrive for database access (global connection pooling)
D1 for local/edge data (SQLite at the edge)
Durable Objects for coordination (if you need it)

This stack lets you build genuinely global applications without the complexity of managing databases across regions or dealing with replication lag.

The bottleneck in serverless has always been "how do I efficiently access my database from everywhere?" - Hyperdrive finally makes it practical!

Follow Cloudflare docs to get started!