Amazon's new engineering bar puts problem-solving ahead of AI use

Last month, Amazon released a memo revising its software-engineering guidelines to emphasize long-term customer and business impact rather than maximizing AI use. The company called the approach the “era of the Renaissance Developer,” a shift that directly affects hiring, promotion, performance goals and job descriptions.

For HR, the immediate question is whether assessment systems reward judgment and outcomes, or simply visible tool use and code volume. AWS chief AI and technology officer Matt Wood argues for the former: “You want them to have less love for their specific solution and more love for the specific problem.”

What does Amazon's revised guidance change?

Wood made the comments in a Business Insider interview by reporter Ana Altchek. He leads technology in Amazon's division, which provides cloud and AI services to millions of organizations.

Wood described the exceptional engineer as someone who falls in love with the problem rather than a solution. That is more than a slogan about AI coding tools; it sets a behavioral standard for how engineers frame work, test alternatives and respond when evidence changes.

Wood said AI has enabled developers to explore multiple solutions at once. He added that engineers use the technology not only to write code, but also to understand a problem more deeply and pursue multiple paths to solve it.

Software development used to cost more, which made alignment around one solution worthwhile, Wood said. AI now allows developers to go deeper on the problem and explore multiple ways to solve it at the same time.

The practical change is not that engineers need more AI in every task. Their employer needs to assess how they choose problems, compare solutions and apply judgment to generated work.

Takeaway: Amazon's revised guidance makes customer and business impact the performance anchor, rather than AI usage itself.

How is AI changing the engineering job?

AI has automated code and reshaped the engineer role, though the work never consisted only of writing code. It centered on solving problems, a distinction that becomes more important when machines can produce code quickly.

Engineers once spent days waiting for code reviews, manual testing and design revisions. With AI able to generate code, people can redirect that time toward more complex reviews, according to Wood.

He said engineers who avoid becoming attached to one solution remain more responsive and move faster. “They're much happier and have a lot more momentum in their career,” he said.

That is a leadership claim, not a measured finding in the interview. Wood's interview provides no productivity figures, error rates, retention data or engineer survey results showing that problem-first working produces faster delivery or better morale.

Wood's remit has scale because he leads technology for an Amazon division serving millions of organizations. The interview does not quantify how many teams follow this approach or what they achieve.

Takeaway: AI can change review capacity and career momentum, but the interview does not establish a measurable business result.

Which skills should hiring and promotion tests measure?

Many technical leaders have said taste and judgment matter most as AI shifts engineers toward managing agents and making more decisions. Wood's problem-first account fits that view: the stronger signal is the quality of choices made under uncertainty, not attachment to a preferred solution.

AWS principal engineer David Yanacek offered a sharper formulation. He described the strongest developers as “paranoid and lazy,” meaning eager to automate repetitive work but cautious enough to set guardrails so agents can operate safely without constant oversight.

For hiring and promotion, that suggests testing behaviors rather than counting prompts or completed tickets. Useful evidence would include:

• How a candidate defines the problem before selecting a solution.
• Which alternatives the candidate considered, and why the candidate rejected them.
• How the candidate verifies AI-generated work and sets review guardrails.
• How the candidate changes course when evidence weakens the preferred approach.

This process remains open to subjectivity. “Falling in love with a problem” is not an observable competency unless managers define it through decision quality, customer impact and the reasons behind changes of direction.

Takeaway: Hiring and promotion should test judgment, alternatives and safe agent oversight, not merely demonstrated enthusiasm for AI.

Can employers measure the new performance model?

HR teams should resist translating Wood's philosophy into another tool-usage quota. Amazon's guidance warns against maximizing AI usage, while a new performance cycle could reward code generation, ticket closure or agent activity without proving better customer outcomes.

A credible measurement plan would ask whether engineers explore meaningful alternatives, reduce time lost to routine review work and improve business outcomes. It would also ask what happens when generated code fails, who owns that risk and how managers evaluate the resulting work.

This requires more than adding AI to a job description. Employers need to revise role expectations, interview rubrics, promotion criteria and review standards together, or engineers may optimize for the easiest visible measure.

Wood's interview does not describe such a measurement plan at Amazon. It also does not show that every engineer can pursue multiple solutions or explain how company constraints affect that freedom.

The forward test is therefore straightforward: employers will need to show whether AI expands better decisions and customer impact without turning AI use, speed or solution exploration into another proxy for performance.