A year back at a serverless conference session, I mentioned: “I am yet to see a vibe-coded application using Kubernetes.” That's still mostly true. AI is moving fast at the top service level, but it hasn't crossed into the layer where Kubernetes lives. Honestly, most use cases don't even need Kubernetes at start, and the one that needs it usually comes with human expertise & experience already attached, where AI is assisting and not disrupting.
Two trends are running in parallel right now, and most takes on AI in 2026 only see one of them.
The first is loud and visible: AI is rapidly reshaping how software gets written. Production-ready frontends, ready with auth, payments and other features, ready in just few hours. Using the most popular services for hosting, auth, database, and code, etc. That's the first layer — the easiest one, repeated over and over.
The second trend is quieter and bigger over a long term. The hyperscalers are shipping new infrastructure at rapid pace. Not just application services, not even AI tooling. The deeper layers: storage, specialized databases, data warehouses, HPC, custom silicon, niche compute.Things that don't show up in “AI is eating software” headlines, but that the AI itself runs on.
These two trends are aiming at different layers.
The software layers
Software runs on layers. The closer to the surface/client, the more replaceable the layer is by AI right now. The deeper you go, the more specialized the purpose and the harder to disrupt.
At the top: UI, glue code, basic API handlers, scripts. This is where AI is genuinely eating the floor. You may never write another <button> from scratch unless you want to.
Below that: application architecture, service decomposition, state management, data shape. The model can produce a confident-looking first draft, but knowing why it's wrong is still the job.
And below that: storage, specialized databases, data warehouses, specialized compute. This is where the cloud providers have been quietly building, and where AI doesn't replace anything — it consumes the output. This layer needs expertise and years of experience to build or consume.
What AWS shipped recently
A small sample of what's actually moved in the deeper layers recently:
- EC2 UltraServers with Trainium2 chips and instances with NVIDIA Blackwell GPUs (May 2026). Trainium3 announced — AWS's first chip on a 3nm process node, 2× the compute of Trainium2, 40% more efficient.
- S3 Vectors: vector storage built directly into S3 — a new storage primitive aimed at AI workloads, but the primitive itself is storage, not AI.
- Redshift zero-ETL integrations with Aurora MySQL, Aurora PostgreSQL, and RDS MySQL, including automatic incremental refresh of materialized views against operational data.
- Graviton5 custom ARM CPUs — two large AWS customers reportedly asked to reserve all of 2026's Graviton capacity before public availability.
These are highly specific. Most teams will never touch most of them. Each is solving a real customer problem at scale.
What Google Cloud shipped at Next '26
Google's announcement count from Cloud Next '26 was 260 separate items. A handful that hit the same deeper-layer thesis:
- Managed remote MCP servers for AlloyDB, Bigtable, Cloud SQL, Firestore, and Spanner. The databases are getting first-class agent connectivity — they aren't being replaced; they're being made more usable from inside agentic workflows.
- BigQuery external datasets for Spanner — federated query across operational and analytical stores without the ETL.
- Spanner columnar engine + zero-ETL Apache Iceberg integration — operational and analytical workloads against the same data.
- Real-time data replication from Spanner, AlloyDB, and Cloud SQL into BigQuery — closing the loop between raw data and operational action.
Same shape. Specialized, deeper-layer, aimed at use cases the AI surface doesn't touch.
The pattern
Notice what these big providers are actually focusing on.
AWS is shipping specialized compute substrates — custom silicon, vector storage, federated database integrations. Google is shipping specialized data architecture — agentic connectivity into the database tier, unified analytical and operational engines, zero-ETL across the operational/analytical divide.
In both cases, the real work is in the deeper layers. The AI tools sit on top of this infrastructure and consume it. They don't replace it. The MCP servers Google launched explicitly make AlloyDB and Spanner more available to AI agents — Spanner doesn't get smaller because an agent can query it; it gets more central.
What this means for engineers
The engineer who only knows the top layer — frontend templates, glue code, basic backend — is the one feeling replaced this year. Reasonable. That layer is moving fast.
The engineer who knows the deeper layer — knows when DynamoDB is wrong and Aurora DSQL is right, knows what Trainium2 is and isn't, knows the cost shape of Snowflake at scale vs. BigQuery, knows when an Iceberg table beats a Spanner column — is more valuable than they were a year ago, not less. Because the AI now writes the connectors, the glue, the queries. But it still has to be pointed at the right primitive. Picking the substrate is judgment. Judgment doesn't compress.
Browse aws.amazon.com/new/ or cloud.google.com/blog for a month. The list of new services and features is long. Most won't apply to most teams. Every one solves a real problem at scale for someone.
The disruption story is real. It's just not uniform across the stack.
The deeper you go, the more your career compounds. The closer to the user, the more your work depends on what model wrote it last sprint. Pick which layer you're operating at on purpose. Don't get talked into thinking the whole stack is changing because the top of the onion is.
Most of it isn't.