Attention sits on the model. The investment and the durable work sit underneath it. Two questions tell you which layer to build on.
Most people choosing a tech career right now are looking at the wrong end of technology.
They see ChatGPT. They see Claude. They see agents and a thousand new apps launching every week. So the natural assumption is that the best career must be the one sitting closest to those products: AI engineer, agent engineer, machine learning engineer, prompt engineer. Then someone says cybersecurity is safer. Someone else says software engineering is dying. Another person says data is the new oil. Before long you have compared six careers, opened fifteen tabs, and become less certain than when you started.
I know the loop. I did it myself, more than once. The problem is not the research. The problem is that these all look like separate careers when they are different parts of one stack. And until you see the stack, every list makes the decision harder.
So forget the job lists for a minute. There is a stronger move: test the stack, not the titles.
The two-question test
Walk any technology down to its layers and ask one question: if this layer disappeared tomorrow, what above it would stop working?
Then ask the second question: how far down can an ordinary engineer go while still learning and operating the work through software, from a laptop, basically remote?
When both answers meet, the strongest career foundation for the AI era stops being a guessing game.
Run the test on a real product
Imagine an online retailer launches an AI customer support assistant. A customer opens the site and types, "Where is my order?" and "Can you change the delivery address?"
This looks like one product. Several completely different pieces have to work together before the customer gets a useful answer.
The front end is what the customer sees and touches: the website, the app, the chat box, the buttons. It collects the request and shows the result. It does not know where the order is, and it cannot change an address.
That work happens behind the screen, in the back end. The back end checks who the customer is, looks up the order, applies the company rules, talks to the delivery company, and updates the data. This is where the business logic lives. Before changing an address, the company must authenticate the customer, limit access to the correct order, check whether it has shipped, record the change, and handle failure safely. AI does not remove those requirements.
Above the back end you can add an agent. An agent is software that takes a goal, calls a model, uses approved tools, checks the results, and repeats. It sits inside or beside the back end. Before it runs, the back end authenticates the customer and limits the request to authorized data. The agent interprets the request, retrieves the approved order, checks its status, calls a policy service, and only then invokes the courier API. The model does not automatically know the order. It cannot safely act without data, without tools, without rules and permissions around it.
Most companies do not train a frontier model. They rent it through an API or a managed service. Providers change. The surrounding application still needs data, networking, permissions, security, monitoring, operations, and compute.
And every layer above needs somewhere to run. Compute runs the code. Networking connects the pieces. Storage holds the information. Identity controls access. Monitoring shows what is happening. Automation makes the environment repeatable. Backups and recovery help when something breaks. That is the infrastructure layer: the environment keeping the product running for real users.
Now remove things
Remove the front end. The company swaps in a mobile app, another website, an internal screen, or an API. The customer experience changes. The system underneath remains.
Remove the agent. The company uses a fixed workflow, or sends the harder request to a person. The AI experience becomes less capable. The order system still exists.
Replace the model. The answers behave differently, and the prompts and tests need to change. Companies already use more than one model provider. The identity, the order data, the network monitoring, and most of the application stay exactly the same.
Remove the infrastructure. No compute means the code has nowhere to run. No network means the pieces cannot talk to each other. No storage means no durable information. No identity controls means the demo technically runs, but no serious company lets customers use it. No monitoring means nobody knows the product is broken until the customers complain.
The upper layers serve one experience each. The infrastructure below serves many applications, many agents, many models, many databases, many business systems. The lower layers do not make the upper layers unimportant. They make the upper layers dependent. Models, applications, and providers will keep changing. Networking, identity, security, storage, automation, monitoring, and reliability keep returning.
The second half of the test
Physical data centers are even deeper. If the chips or the electricity disappear, everything stops. So why not tell everyone to become a semiconductor engineer or a data center technician?
Because of the second question: how deeply can you realistically enter a layer while operating through software, remote? Physical infrastructure demands specialist hardware knowledge, a lot of capital, and being near a facility, physically handling equipment. Some people deliberately go deeper: chip design, kernel engineering, database engine development. For most IT professionals and career switchers, the deepest broadly accessible production layer you can practice from a laptop is programmable infrastructure used by real businesses.
Most companies reach that layer through cloud platforms. Cloud platforms turn physical capacity into compute, network, storage, identity, and security controls that you operate through code and APIs. That does not guarantee a remote job. It means you can learn and practice the work without owning a facility.
So when both tests meet, when you ask how many systems reuse the layer and how deeply you can work through software, the answer becomes clear. That layer is cloud infrastructure.
Follow the money
Public attention goes to the model, the application, the agent at the very top. The investment pours through the layers underneath.
Reported figures from the International Energy Agency say five large technology companies spent more than $400 billion in capital expenditure in 2025, projected to rise another 75 percent in 2026. The Stargate project bundles cloud infrastructure, data centers, chips, energy, and construction. Anthropic has said it will spend more than $100 billion with AWS over the next decade on capacity for training and running Claude.
The product is AI. The buildout is compute, networks, storage, chips, power, cooling, security, and cloud capacity. Agentic workflows add multiple model calls, tool calls, permissions, data movements, and failure points. Larger models need more compute and more memory bandwidth. Connecting more company data adds storage, governance, backups, and security requirements.
This does not mean every billion spent creates a matching number of jobs. These companies will automate heavily. It shows which part of technology they believe they will need more of.
Demos are not production
You can build an impressive agent over a weekend. You are still not ready for a production role.
The company asks the questions production always asks. Who is the customer? Which data can they access? What happens when the courier fails? How much does every request cost? Employers need evidence that you understand everything underneath the demo. That is the whole gap between the weekend project and the job.
What this means from where you already stand
If you already work in support or operations, this matters most. AI is not making what you know irrelevant. It is creating more systems that must be connected, secured, monitored, and recovered. Your next move is learning to design and automate those systems instead of reacting after they fail.
An IT analyst in a hospital already sees identities, integrations, networks, backups, devices, and security controls. Years in L2 support teach you how users experience failure, where handovers go wrong, and what happens when nobody can diagnose a system. I spent years on that side: tickets, incidents, DNS, permissions, the moment a system fails inside a real business. The move is not a restart. It is moving from handling the ticket after the failure to helping design, automate, secure, and recover the system around it. That is exactly what I am learning now, through the AWS re/Start program and the labs I build and break. If you are switching from sales, teaching, healthcare, or operations, keep your communication and business experience. It cannot replace hands-on competence. It helps you understand the business around the system while you build the missing technical layer.
One trap: do not now decide the answer is to become an AI infrastructure engineer. That repeats the same mistake with newer titles. For most companies, the infrastructure around an AI application is familiar cloud infrastructure with AI-specific architectures and services. If they call a managed model API, the provider handles much of that infrastructure; the company still owns its application, its data access, its identity, its networking, its monitoring, and its cost. If they train or host models themselves, they need specialist chips, high-speed connections, distributed workloads, model serving, and specialized monitoring. Those needs sit on top of the same foundations: compute, networking, storage, identity, security, automation, reliability, cost control. AI infrastructure is a workload specialization. Cloud infrastructure is the reusable foundation. Build the foundation first, then add the specialization if your role needs it.
AI will automate parts. It will not take the responsibility.
Yes, AI will automate parts of cloud work. It can already generate Terraform configurations, draft a deployment pipeline, and suggest network configuration. I use it too. But generating a configuration file and taking responsibility for a production system are not the same job.
Imagine the AI generates infrastructure for a company. The code works, but one permission is too broad. A support process can now read every customer's order instead of only the one it needs. The syntax is valid. The business outcome is a security incident. Someone still has to decide how much access is required, test the change, review what could be affected, monitor the deployment, recover safely, and explain the risk to stakeholders.
If your only value is clicking through a console or copying commands, more and more of that work will be automated. If you understand requirements, design systems, review output, secure it, control cost, troubleshoot it, and explain trade-offs, AI makes you faster. No career is completely AI-proof. where AI is creating more infrastructure to build, more complexity to manage, and more production outcomes that somebody must still own. Cloud is not AI-proof. It is AI-relevant. The code is becoming faster to produce. The production consequences are not disappearing with it.
What cloud engineering actually is
It is not memorizing services. It is not collecting certifications and hoping an employer imagines your practical ability. It is answering a small set of important questions, over and over:
Where should this application run? How does traffic reach it? Which part is public and which is private? Who or what is allowed to access the data? What happens when traffic increases? What happens when one component fails? How will we know there is a problem? How do we rebuild the environment consistently? How do we recover it? How do we stop the bill and the complexity getting out of control?
AWS gives you services for solving those problems. The service name is not the skill. The skill is knowing which problem you are solving, why the service fits, what could fail, and what you rejected. Two people can finish the same course and leave with completely different career value. One remembers the steps. The other understands how the parts connect, changes the design when the requirement changes, catches a dangerous permission, and can explain the decision in an interview. Same information. Different level of ownership.
A practical test for your own decision
This week, run the test on something you actually use. Pick an app you open every day. Draw its layers. Ask what stops working if each one disappears. Then ask how deep you could go from a laptop.
Then, for your own next step, do a bounded 30-day build. A sandbox account with MFA and a budget alert. Synthetic data only, never real customer data. Build one small real system from requirements, not from service names. Break it. Explain it in ninety seconds to someone who knows the job. Use AI if you want, but inspect every permission it writes and make it explain its assumptions. If the AI did the work and you cannot explain it, the proof belongs to the tool, not to you.
The layer under the hype
Here is the conclusion I keep landing on. Stop asking which AI job will be the hottest next year. Look under every AI application and ask what it cannot operate without. Then go as deep as you can while still building from a laptop.
In the AI era, that points to cloud infrastructure. AI does not replace that foundation. It increases what is built on top of it. I am building there right now, and it is the first direction where the years I spent in support stop looking like a detour and start looking like the base of the stack.