Disclaimer: Views are my own, not Amazon’s.
Everyone says AI is changing the world. Ask how, and the room goes quiet.
William Gibson had the more honest version: the future is already here — it’s just not very evenly distributed. I have been watching that future from inside Amazon.
Engineers here can reach for nearly every frontier model.
You stop rationing tokens.
You start rationing attention.
When the cost of generating code collapses, the software engineer does not vanish. The job relocates.
The old edge is gone
For a long time, a good SDE had a private advantage. You knew the domain. You knew which service owned the truth. You knew the failure modes nobody wrote down.
That edge is being flattened. AI is unusually good at understanding as well as writing code, and we have been using it to write almost all of it. Not as a parlor trick. As the default. The gap that used to be “I know this system and you don’t” can now close in an afternoon.
Nobody is better than a well-directed model at producing the first version of the code. What the model does not have is the thing Fred Brooks named in 1986:
The hardest single part of building a software system is deciding precisely what to build.
We treated that sentence as a warning. AI turned it into a job description.
The tools caught up
Two tools make this concrete.
Amazon’s Kiro is a spec-driven environment: requirements, then design, then tasks, then code. If an agent can write the implementation, the scarce skill is writing the spec it cannot misunderstand.
Kiro Crew is the next layer — an open-source, multi-agent workspace that keeps working across sessions. One engineer, several agents, overnight, while you are in a customer meeting.
The tools get better every release. When the instrument improves weekly, the job cannot stay annual.
A week that used to take a quarter
Here is the pattern, collapsed into one week.
An operations team asked for something that sounded too small to staff. When a workflow stalled, they did not want another dashboard. They wanted one sentence on the page they already had open: why this stopped, who owns the next action, and what to do in the next five minutes.
Two years ago, that request would have entered the old machine: a one-pager, a design review, weeks of implementation, a launch checklist. Six weeks if you were lucky.
This time the conversation started Tuesday morning, with the people who actually click the page. They did not want “more visibility.” They wanted to stop guessing. By lunch, Kiro had a spec. By evening, there was a working slice in a branch. The feature was real before the second sunset.
When AI makes you fast at building, the cost of building the “wrong” thing goes up, not down.
The cycle flipped
The old sequence was: customer, requirements, design, alignment, implementation, test, release. The expensive middle was everything after “we should build this.” Because building was slow, we treated requirements as sacred and kept engineers away from customers.
That logic only holds if building is hard. It is not, in the same way, anymore. Give a clear requirement to an agentic workflow and, depending on the feature, you can have something real the same day.
So the sequence flipped. Implementation can be delegated. The conversation that decides whether the feature deserves to exist cannot. That conversation is landing on the SDE.
The majority of time-to-release is no longer writing code. It is customer alignment and team alignment — often by the engineer who used to be protected from both. You sit with the customer, hear the actual problem, turn it into a spec, keep the team pointed at the same target, and ship again before the last launch has cooled.
The new job, same title
Nobody sent a memo. The work just moved.
The service still has to stay alive. The code still has to be correct. That part got faster, which makes it easier to get sloppy. The engineer who cannot review an agent’s output, or refuse a bad requirement, is not more productive. They are a high-speed liability.
The center of gravity is different. The job is now: talk to the customer without a translator, write a spec an agent can execute, align other humans, and ship so often that the calendar itself becomes the hard problem.
That last one is the part I did not expect. You can spin up five agents. You cannot spin up five versions of yourself to sit in five rooms and mean it.
The title still says Software Development Engineer. The week says something closer to product engineer and conductor of a small orchestra of models.
If you are still optimizing for “I can write this service from memory,” you are training for a race that already finished. Syntax is no longer a moat. Taste is. So is sitting with a customer long enough to hear the requirement they did not know how to say.
AI did not make software engineering smaller. It made coding smaller. The rest of the job — the human part, the “what should exist” part — got louder.
The title has not caught up. The expectations already have.
I send out Master Mentee 🎓 articles with curiosity and a passion for growth. If you’re enjoying it, I’d be grateful if you shared it with a friend who’d appreciate it too.
Not subscribed yet? Join the growing mentee squad of curious minds.
✨ Get the next issue in your inbox:
💚 If this resonated, tap the 💚—it’s free for you, but it supports my work and helps Master Mentee reach more amazing people like you.