An Amazon Engineer's Take: How to Honestly Document When AI Doesn't Help—and Find a Way Forward

Title

An Amazon Engineer's Take: How to Honestly Document When AI Doesn't Help—and Find a Way Forward

Meta Description

Amazon engineering leadership's Terk Terkowitz proposes: when AI can't help, document why, share with peers, and report to your manager. This article unpacks what that statement means for engineer judgment in the AI era, and how teams can turn "AI isn't applicable" into organizational knowledge.

Article Content

Amazon engineering leadership recently published an update on the role of developers in the AI era, and a passage from Terk Terkowitz has drawn attention in the tech community. The core of the passage isn't complicated: if your work isn't benefiting from current AI tools, that's a finding, not a failure.

An Overlooked Form of Engineering Judgment

Here's what Terk Terkowitz said:

If your work does not benefit from current AI tooling, that is a finding, not a failing. Document why, share it with your community of peers, bring it to your manager, and work to find solutions. An engineer who can explain where AI does not yet help their work is demonstrating the judgement we are asking for.

The value of this statement lies in how it reframes "AI doesn't work here" from an embarrassment to be concealed into an engineering conclusion worth documenting and sharing.

Why "Documenting What Doesn't Work" Is Harder Than "Forcing It to Work"

With AI tools being widely promoted, engineers face an implicit pressure: not using AI seems backward, and saying AI is useless seems like resisting change. Terkowitz's statement directly dissolves that pressure. He points out that judging where AI doesn't apply is itself a professional skill—it requires engineers to truly understand their own workflows, understand the capability boundaries of AI tools, and have the courage to reach an honest conclusion.

This kind of judgment isn't inferior to "being proficient with AI." On the contrary, it's harder, because it requires resisting herd mentality and expressing conclusions in a verifiable way.

From Individual Observation to Organizational Knowledge

The action path Terkowitz lays out is very concrete: document it, share it with peers, bring it to your manager, and work together to find solutions. This path turns an individual's "AI isn't applicable" observation into knowledge that the organization can accumulate.

Documentation Is a Responsible Practice

Simply saying "AI is useless to me" doesn't mean much, but if you clearly explain "at which step, for what reason, what methods were tried, and what the results were," that becomes a valuable engineering record. Accumulated over time, such records can help teams identify the real applicability boundaries of AI tools and provide direction for tool improvement.

For managers, receiving this kind of feedback is equally valuable. It's closer to reality than "everyone is using it," and more constructive than "it just won't work."

Community Sharing Amplifies Individual Experience

Sharing conclusions with the peer community is an easily overlooked part of this path. A single engineer's observation may be an exception, but when engineers across multiple teams and domains all document similar "AI isn't applicable" scenarios, these scattered findings can piece together a more complete map of boundaries.

This is also what open-source communities and engineering blogs have been doing for a long time: turning individual experience into public knowledge. Terkowitz explicitly wrote this practice into his expectations for engineers.

Organizational Knowledge Management refers to the practice of systematically capturing, structuring, and circulating individual members' experiences, insights, and judgments within an organization. In engineering organizations, this kind of knowledge is often preserved in the form of design documents, postmortems, and internal tech blogs. The core challenge lies in externalizing tacit knowledge—an engineer's intuition about "when not to use a certain tool" is hard to reuse by others if it isn't put into writing. The "document—share—feedback—solve" path proposed by Terkowitz is essentially a lightweight organizational knowledge management chain: it turns one-off individual observations into searchable, discussable, and iterable organizational assets, preventing the same trial-and-error from repeating across teams.

The Engineer's Role in the AI Era: User or Judge?

This passage comes from Amazon engineering leadership's update on "the role of developers in the AI era," and the stance behind it is worth noting: an engineer's value lies not only in whether they can use AI tools, but in whether they can make accurate judgments about those tools.

The Other Side of Tool Literacy

Current discussions about AI coding tools mostly focus on efficiency gains, code generation quality, and workflow integration. Terkowitz offers a complementary perspective: tool literacy includes not only "how to use it well" but also "when not to use it" and "why it doesn't work well."

People who can articulate the latter often have a deeper understanding of systems and are more likely to make the right choices as tools iterate rapidly.

Tool literacy in the software engineering context typically refers to a systematic understanding of a tool's capabilities, limitations, and applicable scenarios, rather than merely operational proficiency. Compared with "knowing how to use it," it emphasizes awareness of the tool's internal mechanisms—for example, AI code generation tools perform well on general tasks with sufficient training data coverage, but may introduce subtle errors in domain-specific logic, legacy system coupling, or scenarios with strong compliance constraints. Engineers with tool literacy can anticipate a tool's failure modes and make more robust trade-offs during selection and review. This is why "explaining why AI isn't applicable" is regarded as an advanced skill: it requires clear awareness of both one's own workflow and the tool's boundaries.

Practical Suggestions for Teams

To put this passage into team practice, you can start with a few small moves: leave room for an "AI applicability note" in technical documents; dedicate time in retrospectives to discuss where AI tools fail; treat "explaining why AI isn't applicable" as a positive contribution rather than a complaint. These practices cost little but give honest judgment room to breathe within the team.

The reason Terkowitz's passage has been widely quoted is precisely that it speaks for many engineers the thing that's hard to say out loud: AI is great, but it isn't omnipotent—and pointing that out is itself doing what engineers are supposed to do.

One-line Summary

Amazon engineering leadership points out that work not benefiting from AI tools is a finding, not a failure—being able to explain AI's boundaries is itself a demonstration of engineer judgment.

Paragraph Summary

The article centers on a statement from Terk Terkowitz in an Amazon engineering leadership update: if your work isn't benefiting from current AI tools, that's a finding, not a failure—document why, share it with peers, report it to your manager, and work together to find solutions. The author argues that this statement dissolves the implicit pressure on engineers that "not using AI means falling behind," reframing "AI doesn't work" from an embarrassment into a valuable engineering conclusion. The article further notes that this action path turns individual observations into organizational knowledge about AI's applicability boundaries, and amplifies individual experience through community sharing. It ultimately lands on a repositioning of the engineer's role in the AI era: engineers are not just tool users but people who can make accurate judgments about tools—and "clearly explaining why AI isn't applicable" is itself what engineers should do.