There is no doubt that this post was at least 80% written by AI but I’m not even super mad about it because that is just the way of the world now, and the summary it generated from how Uber works is actually legit interesting:

A prototype without a PRD can drift away from the problem the team intends to solve. A PRD without a prototype can remain abstract, leaving room for inconsistent interpretations. […] If going from idea to prototype is now fast and cheap, the PRD can no longer be the primary place where ideas are defined. Its value increasingly lies in capturing intent, tradeoffs, success metrics, and decisions.

The PRD as an artifact is in the spotlight right now in a way that I think is really healthy. Should it remain but change its JTBD? Should it be an eval instead? Who knows. Let’s figure it out together…

This post on org design really resonated.

Most companies today are using AI the way you’d use a faster horse — to make the existing structure run a little better. The companies that pull ahead will be the ones willing to ask a harder question: what would we build if we were designing this organization from scratch, today, knowing what AI can do?

We have to seriously rethink the SDLC, design it from scratch in the context of how our own organizations work. It’s not about a global “right” process any more. The question now becomes “How can the humans in our team, at our company, at this point in time, work best together to serve our customers?”

Oh, this is very good. On the classic take that the core characteristic of outstanding engineers is “laziness”:

The problem is that LLMs inherently lack the virtue of laziness. Work costs nothing to an LLM. LLMs do not feel a need to optimize for their own (or anyone’s) future time, and will happily dump more and more onto a layercake of garbage. Left unchecked, LLMs will make systems larger, not better — appealing to perverse vanity metrics, perhaps, but at the cost of everything that matters. As such, LLMs highlight how essential our human laziness is: our finite time forces us to develop crisp abstractions in part because we don’t want to waste our (human!) time on the consequences of clunky ones.

The best engineering is always borne of constraints, and the constraint of our time places limits on the cognitive load of the system that we’re willing to accept. This is what drives us to make the system simpler, despite its essential complexity.

This is exactly why I practice Fear-Driven Development, and why everything I do in code includes multiple versions of asking Claude Code “do we need this?” and “is this adding bloat?”