The game plan for engineers to thrive. 2026 to 2030

I joined a Swift team at Amazon with 0 experience in Swift.

My last role was Prime Video, on the team that owned playback. Before that I had never shipped a line of Swift. I wasn't even an Apple fan. I was team Android all the way.

ChatGPT was new then. And we weren't allowed to use it. The AI wars were starting and the rules were strict.

So I learned the hard way. Here is what was on the list:

• SwiftUI and UIKit — the 2 UI frameworks every Apple app is built on, and Apple's own tutorial track if you want to start today

• HLS, Apple's HTTP Live Streaming protocol, plus Low-Latency HLS for live events. The authoring spec is the rulebook real streaming apps have to follow

• Encoding and manifests — the .m3u8 playlists that tell a player what to fetch and when

• Sye, the low-latency streaming tech Amazon bought in 2020 and now runs across its CDN. Amazon IVS is the managed version you can build on yourself

• Internal services for live playback, and Prime Video's own tools for tracking playback health

That's 6 domains in one role. Most of them do not have a tutorial.

Here is the part I keep coming back to. Even if we had every model available today, that system was too tangled for an LLM to reason through alone. Too much internal context. Too many edge cases that only showed up during a live event.

Our jobs were secure. Not because AI was weak. Because the problem was bigger than the code.

That is the whole lesson, and it still holds.

The fear is not losing your job. It's the list.

Every week an engineer messages me asking for the list.

Not students. Not new grads. Engineers with strong jobs and strong salaries. They want me to send them everything they are supposed to learn now. Agents. MCP. RAG. Evals. Vector databases. The 3 frameworks that shipped last month.

They are not scared of being replaced. They are scared of falling behind a list that grows every single week.

I get it. The list does grow every week. And nobody finishes it.

But chasing all of it is the actual mistake.

AI is the world's smartest junior engineer

That is the honest framing. Smart, fast, endlessly available, and 4 years old.

It has the internet. It follows instructions. It writes clean code faster than any of us.

But it does not know that the payments team deprecates that endpoint next quarter. It does not know your on-call history. It does not know which VP will kill the design in review.

It struggles at the exact thing a senior engineer is paid for. Making the best decision with all the information and the situation in front of you.

Software is not just writing code that runs. It is writing code that holds up when the edge cases hit. Code that survives review. And code that survives 3 years of changes from people who were never on the original team.

That gap is your job.

Know exactly what AI is good at

This is not a fight. Half of being an expert now is knowing where the model beats you.

Use it for:

• Boilerplate, scaffolding, and config you have written 50 times

• First drafts of tests, docs, and migration scripts

• Explaining an unfamiliar codebase or framework fast

• Rubber-ducking a design before you take it to a real reviewer

  
  

Every one of those used to eat your afternoon. Give them away.

Then spend the time you got back on the work AI cannot touch.

Know exactly what AI is bad at

This is the more important list. Own these and you are hard to replace.

• Architecture decisions with real tradeoffs and real constraints

• Requirements. A person still decides what gets built and why

• Cross-team context, politics, and the history of why the system is shaped like that

• Debugging production when the logs lie

• Deciding what not to build

  
  

Look at the company writing the most AI-generated code in the world.

75% of all new code at Google is now AI-generated. But every line of it is approved by human engineers who architect, review, and decide.

If an AI generated the code, a person wrote the requirements. A person approved the design. A person owns the outage.

Be that person.

Build like AI does not exist. Then use it anyway.

Here is the rule I hold myself to.

I want to understand how to build everything I build without AI. Then I use AI to make the build faster.

That order matters. Learn the thing, then automate the thing. Never automate a thing you never learned.

The reason. If pricing changes, if access changes, if there is an outage or a policy shift at your company, the engineers who can still build without it will shine.

Skill is the hedge.

My goal is to know more about architecture than the model

That might sound outrageous. I do not think it is.

An LLM lacks the years. It was not in the room when the design got torn apart. It did not sit through the postmortem. It did not spend 3 weeks in review, taking hard feedback from 4 teams, and rewrite its whole approach twice before anyone approved it.

I have that. You have that. It compounds and it does not transfer.

Pick your niche and go deeper than the model can. I promise it does not take as long as you think.

The plan for the next 5 years

Short version, so you can act on it today.

1. Pick a domain area or 2 and get deeper in it than any general-purpose model

2. Use AI daily to remove the boring 40% of your work

3. Never ship code you cannot explain, defend, and debug

4. Learn to build AI-powered solutions, not just consume them

5. Stay the expert who checks the work

   
   

We are confusing AI-generated code with not having to be experts anymore. Those are not the same thing.

You are the brain behind the decision. The model is the hands.

You can become a senior engineer. AI is not.