Make yourself redundant: How two Amazon developers think about a dev career in the AI era
Career Advice from a senior developer and a junior developer at Amazon around what it takes to get hired and grow in the software developer career path in the age of AI
If you're trying to break into tech, or stay in it while AI rewrites the job description every six months, this one is for you. I sat down to interview two developers from Amazon on the opposite ends of the experience curve: Miles, a junior developer about nine months into his first role, and Chirag, a senior developer with eight years behind him on the same team. They disagreed on certifications. They agreed hard on networking. And between them they landed on a piece of advice that sounds like a great way to get fired: make yourself redundant.
You can find the video of this interview here . This blog will summarize the key takeaways from this podcast style interview.
They meant the opposite of what it sounds like. Below is that idea and the rest of what stuck, sorted into getting in, staying in, and surviving the fact that the tools change faster than you can finish a tutorial about them.
The workflow change is real, and a little uncomfortable
Chirag described the before-and-after of AI in two words: night and day.
The old loop went like this. You hit a problem, you looked up what you needed to understand, then you went hunting through framework docs, Google results, and Stack Overflow. The answer you needed was rarely the top result. Sometimes it was the tenth answer. Sometimes it was a comment buried under the tenth answer, posted by someone with a username like
dev_guy_1987. He spent his IoT years in obscure hardware forums, because the niche product he was wiring up had documentation written by three people, two of whom had moved on.He called the whole thing an exercise in patience and perseverance. Copy this, paste this, edit this, compile, run, compile, run, edit. Now the agentic tools run that same loop, except fast. Same number of steps. Less waiting. You still have to check the output, because a confident wrong answer is still wrong, but you stop losing afternoons to forum archaeology.
Miles added the part I felt in my own teeth: bad documentation. Some API docs are confusing, some have mistakes, all of them were written by humans on a deadline. Being able to point a tool at the docs and get back the three lines you actually need saves real time when you're onboarding to a system you didn't build.
The discomfort, and Chirag admitted this openly, is that he liked the slow grind. The deliberate research had its own satisfaction. That feeling is gone, traded for speed. Worth it, but not free.
Where AI stops and you start
Chirag uses these tools for almost everything in software engineering: ideation, turning a rough idea into a problem statement and a solution proposal, proofs of concept, the actual code, unit tests, integration tests, and troubleshooting the pipeline when it breaks at 5pm on a Friday.
Then he draws a line. He used to call it a hard line, now he calls it a line in the sand, because he's honest that the technology keeps moving it. The line is human interaction. Convincing your manager that a project matters. Having a real conversation with your peers about how the work is going. Telling a customer no.
His example came from consulting and AWS premium support, where he worked with customers on their worst days. You know the feeling of calling support and hitting a bot that won't give you your answer. Compare that to reaching a person who understands how frustrated you are and gets you to a decent outcome anyway. You can ask AI to write the script for the hard conversation. It just won't be you saying it. At least not yet.
The takeaway worth keeping: the better you understand the human on the other side, the better your prompts get when you do reach for the tools.
The skills that survive every rewrite
I asked the question every developer quietly worries about: which of my skills are disposable?
Chirag's answer was blunt about his own resume. The specific languages, the hardware tricks, the framework knowledge, those are fungible. Python is the hot language today. Tomorrow it might be Rust. The exact syntax you memorize has a shelf life.
What does not expire is knowing why the tools exist. Anyone can look up how to write a function in Python. The lasting skill is understanding why you reach for a function or a class in the first place, and the philosophy underneath it. Same with how systems stay reliable: uptime, SLIs, SLOs, how much of a system you can recover and how fast when it falls over. He apologized for throwing jargon around, which I appreciated, but the point holds. Understand the philosophy and you become a better programmer, or at the very least a better prompter.
He has a name for the role you grow into. Not the director of a movie. The conductor of an orchestra. You're not playing every instrument. You're making sure the whole thing sounds like music.
The XY problem, starring DMX
The single most useful idea in this section was the XY problem, and it has nothing to do with code.
Picture someone trying to solve problem X. They've decided the solution is Y, so when they ask you for help, they ask about Y. You spend an hour solving Y. Then you discover Y was never going to fix X. Everyone's tired and X is still sitting there.
Chirag sees this constantly in support: a customer asks how to do the specific thing they think they need, instead of describing what they're actually trying to accomplish. The fix is to keep asking until you find the real X. The host could not resist pointing out that X, in fact, gon' give it to ya. I'm contractually obligated to tell you the panel laughed.
Getting in when AI is screening the resume AI wrote
Here is the loop nobody enjoys. AI writes your cover letter. AI writes your resume. AI on the other side screens your resume and generates your take-home. Two robots negotiating your career while you refresh your email.
Miles's way out of the loop is the least technical thing in this entire post: talk to people. He pushed back on the tech-world belief that networking doesn't matter. Out of hundreds of applications, he got maybe five to ten real interviews. Close to half of those came from people he had chatted with first, who pulled him into their interview cycle. A few messages to an alumni network or anyone he knew in the industry did more than another hundred applications ever did.
Chirag tied it back to people skills, the same thread running through everything he said. Socialize. Find mentors. Build something that resembles a reputation. And remember you have AI too, so you're as equipped as the system on the other side of the table.
The blog flywheel, and why teaching beats knowing
The host shared the advice he gave his old coding bootcamp students, and it's the cheapest high-return habit in the post: keep a blog, and every week pick one technical thing you're curious about, build with it, and explain it.
The reason is the Feynman principle. If you can't explain something clearly to another person, you don't understand it as well as you think. Writing it down exposes the gaps. You reinforce what you learned, you build communication skills, and you leave a public trail that quietly becomes your brand.
There's a hidden payoff Miles and the host both landed on. Interviews are mostly you explaining things out loud under mild pressure. The more you practice explaining, the more an interview feels like a Tuesday. The flywheel turns: learn, explain, get better at both, get noticed.
Miles added the part that reframes the whole job. The most respected developer is not the one who knows the most. It's the one who can hand that knowledge to someone else. The person you go to with a hard question, because they'll get you unstuck and you'll understand why afterward. That's the reputation worth building.
"Will AI take the junior jobs?"
This is the fear, so I asked it directly. Does a junior developer still add value, or is that work getting automated away?
Miles was steady about it. AI is good at the contained task: read this codebase and find the issue, scan these logs and surface the important line, look at this config and tell me what's misconfigured. What it can't do yet is hold all of it at once. The developer is the one who reads the log, suspects the package, connects it to the part of the infrastructure that was taking too many requests, and figures out why the thing actually went down. Stacking those layers together is where the machine is still years behind.
Chirag zoomed out to transportation. We went from horses to horse-drawn carriages to combustion engines. Transportation never disappeared. It changed shape. He expects software jobs to do the same.
Then he gave the advice that sounds unhinged until you sit with it: make yourself redundant. Get so good at your current layer that you automate yourself out of it, then move up to the next layer and do it again. AI is the thing that finishes the low-level work for you, which frees you to spend your hours on ideas and business value instead of plumbing. He's not worried about jobs being eaten. He thinks they'll just look different.
Six months, a laptop, and no degree
The host posed a clean hypothetical: no CS degree, no network, a laptop, an internet connection, and six months. Where do you start?
Miles would build projects, and let the change in learning do the heavy lifting. It used to take hours of documentation to pick up a new framework. Now you can have a tool walk you through integrating it into a real project. His one condition: don't let the tool write all the code while you watch. Understand what each piece does and how it fits, or you've built a thing you can't maintain and learned nothing.
Chirag added open source. Contribute to popular projects on GitHub, the ones with thousands of stars. The first step is the hard one. Once the ball is rolling you keep going. He also credited plain old courses on platforms like Udemy, which is how he picked up cloud concepts while building his first blogging site.
The host's contribution was the most practical: rebuild an app you already pay for. You're the customer, so you already know how it should feel, what it's missing, and where it annoys you. That insight is hard to fake and it makes a strong portfolio piece.
Chirag's contribution was the most fun: build something silly. A goose trying to move a table, in his example, which I have not stopped thinking about. You'll have a good time, and a good time is underrated fuel for actually finishing things.
Certifications: the diplomatic answer and the real one
The panel started diplomatic. Certifications are worth it if you're doing them to learn, less worth it if you're stapling a badge to a resume. Miles never did any himself, and said most of what they teach you'd pick up from projects and open source anyway.
The host wasn't letting them off that easy and asked for one name. So, on the record:
- AWS Cloud Practitioner if you're starting from zero and want the lay of the land.
- AWS Solutions Architect Associate once you understand the cloud and want to go deeper.
- AWS Developer Associate, Chirag's pick, which taught him the fundamentals like DynamoDB and Lambda. He studied for it before his first AWS interview, which tells you how much he rated it.
One bonus from Chirag: cloud skills transfer. He'd certified on another major cloud before AWS, and found the core services mapped one to one. Learn one cloud well and you're most of the way to being useful on the others.
How to ask for help without annoying everyone
There are bad questions. Miles said it plainly, then softened it into something useful: take time to look into a question before you ask it. Senior developers are in meetings most of the day and don't have the bandwidth to answer something you could have found in an internal doc or by asking the AI first.
Chirag wants questions in a specific shape. Tell me what you're trying to do. Tell me why. Tell me what you tried and what failed. Tell me where you're stuck. This works on a senior engineer or a peer, and not only because it's polite. You've eliminated a pile of dead ends, so the person helping can skip straight to the part you both haven't ruled out.
The host packaged this as the 20-minute rule he used with bootcamp students. Stuck? Spend twenty minutes trying things and writing down what worked and what didn't before you ask anyone. Even on an urgent project, twenty minutes of self-discovery is twenty minutes well spent, and the question you bring afterward lands far better. Chirag liked it for a second reason: it timeboxes the spinning. Sometimes stuck is just stuck, and a timer saves you from grinding your wheels for two hours.
Miles closed it with the line a professor once gave him. The struggling is where the learning happens. If your reflex every time you hit a wall is to ask someone smarter, it gets very hard to ever become the someone smarter. Push until you're genuinely certain you can't move another inch on your own. Then ask.
The one-line version
If you skipped to the bottom, fair. Here's the panel in a few lines.
Go-to tool: an agentic coding assistant (theirs is Kiro). Worst advice they ever took that sounded fine at the time: "stretch indefinitely" (you should stretch, not always) and "networking doesn't matter in software" (it does, a lot).
And the message each of them would send to every developer at once:
Chirag: breathe in, breathe out, enjoy the process, be patient.
Miles: hold yourself to your own standard, don't compare yourself to your peers, aim higher.
Two things to try this week
- Start the blog flywheel. Pick one tool you're curious about, build the smallest real thing with it, and write a post explaining how it works to someone who's never seen it. You'll learn it, you'll practice the exact skill interviews test, and you'll have a public trail by Friday.
- Run the 20-minute rule on your next blocker. Set a timer, try things, write down what worked and what didn't. When it goes off, either you've solved it or you have a question so well-formed that any senior developer would be glad to answer it.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article