I've been having a lot of coffees recently. With peers, friends, and ex-colleagues.
One thing keeps coming up: people are drained.
Not everyone. I've talked to folks who are genuinely energized right now. But I've talked to a lot more — engineers especially — whose orgs are racing to become "AI first" and who are running on fumes. Burnout isn't quite the word. Disillusionment is closer.
A few senior engineers have told me, flat out, that they're not sure they'd enter this field if they were starting today.
The pattern is always the same. A constant stream of AI-generated PRs, thrown over the wall by people who haven't read the code, don't fully understand it, and in a lot of cases haven't tested it end to end. And now the burden is on you to review and approve it. Or worse, encouraged to just... care less, without org-wide alignment on how quality standards should be adjusted.
Here's my tension as a PM.
I want everyone to be a builder. It's one of the real unlocks this technology has handed us. But without a good 'software factory' infra and culture of rapid improvement, it also leads to an uneven burden, where those who have the expertise to tell good from bad are increasingly just gatekeepers of sloopy outputs.
I have 100% been that person who submits a PR that I don't fully understand. Not because I want to submit bad code, but because my primary concern is "does it solve the problem" and "does it work". For a lot of programming languages, I don't know how to determine if Claude has written really messy code.
For a lot of experimental features, that approach makes sense. For high scale production features, not so much.
So you put people in a rough spot. The one who raises their hand and says "hey, maybe we slow down and get this right" becomes the skunk at the garden party. The person who cares too much.
The interesting question: how do you let both of those be true at once? How do you ship more without crushing the people who have to hold the line on quality?
A few companies seem, from the outside at least, to have cracked a version of this. I've recently spoken to friends at Ramp, Sierra, and Shopify. They've put the democratization of building on rails — genuinely functional AI-driven software factories that compresses the time it takes to build almost anything. It's remarkable. But they got there by thinking deeply about the system of building the software itself, not just the output.
That's the part I think most orgs are missing. Not the ambition. The infrastructure underneath it, and the shared cultural understanding. The culture where "everyone's a builder" comes with an agreed definition of what that means, and an agreed list of the risks. So when someone flags X, it isn't "you're the only one who cares about X." It's "no, we all care about X, it's already on the list, here's how we hold it while we move fast."
Faster is the goal. But we need to be able to move faster in a way that is explicit about quality standards (when do we care vs. not, how do we make that call, etc)
Nobody should feel they are being the skunk for doing their job.