I talked with Erin Fox about treating every feature like a new product, and about the quiet way AI-generated PRs broke the trust we used to have with teammates.
Erin and I go back to around 2018. She has shipped a React Native MLS soccer app, a lot of React web, and more recently creator-focused email work. What I wanted on the show is how she thinks when a new feature lands on her desk. She freaks out a little, writes a list, and asks why it exists.
A feature is a product with a job
Erin's framing is that each feature is its own product under a company-sized umbrella. The email editor is a product. The API is a product. A two-hour margin fix can be the product if that is what was actually blocking revenue.
That is the difference between implementing a story and doing product engineering. Sometimes the research already said people were not uploading images because the margins were off. Building a whole new flow would have been the expensive wrong answer.
She also said something I keep seeing with agents: they are good at inventing problems. "I'm just curious why we are doing this" is now a senior move, including in the PR template.
The why went missing
Erin used to trust a teammate's PR. Tests passed, they knew the code, they had thought about edge cases. Half the PRs now look like that and are not that. The contract is broken until we put the why back.
Her red flag is an AI-looking change with no explanation of the problem. Large language models are built on language, which is already a lossy way to move an idea from one head to another. If you did not give the agent the why, it cannot keep it.
The same muscle shows up after you ship. Erin spent most of her career adding analytics and never circling back. The engineers who stand out now are the ones who know whether the thing they built mattered, and who use community Slack - including accessibility channels - as a reminder that real people are stuck.
Tell the story, then slow the agent down
Erin has a master's in communications from Hawaii Pacific. You can hear it. She does not lead with "this migration takes a quarter." She asks what the other person is optimizing for, including whether they are scared of getting fired this quarter, and she tells the story in that language.
She also just asks her manager: what are your goals, and how can I make that job easier? That sounds obvious. It is not common.
When we got to agents, her advice was to go slower. "Fix this bug" will change a million things. You have to name the patterns, the data-fetching rules, the fact that you are trying to leave Angular. Otherwise the repo fills with whatever the model felt like that day.
The homework
Erin made it easy so people will actually do it.
On the next PR you open or review, write why this change is needed. If it was written by Claude, say that, and still answer why. If you cannot explain your own PR, that is the bug.
