Judgment Driven Development

Anyone Can Prompt. Not Everyone Can Engineer. What the AI coding revolution actually changes, and what it doesn’t. The Translation Layer Is Gone I recently watched an IBM video that made a point I’ve been thinking about ever since. The speaker walked through the entire history of programming languages, from machine code and assembler, through COBOL and FORTRAN, to object-oriented, web, and scripting languages, and made a simple observation: every generation moved a little closer to the way humans actually think and speak. ...

A recent Sequoia piece made an argument that immediately felt familiar to me. Not because it repeated the phrase “Judgment Driven Development” word for word. But because it pointed at the same shift from a different direction. The article is here: Services: The New Software. Its claim is simple: the next generation of great companies may not look like software vendors at all. They may look like software and AI powered service providers. Instead of selling tools to people who do the work, they will sell the work itself. Instead of selling accounting software, they will close the books. Instead of selling legal tooling, they will draft the NDA. Instead of helping a team perform a process faster, they will increasingly perform the process directly. ...

There is a version of Product Management work that AI can probably do. It can certainly summarize interviews, cluster feedback, draft PRDs and epics, answer questions about product data, and produce mockups. Do enough of that well enough, and the role starts to look like an information processing layer with some communication on top. But that is not what Product Management is all about. The center of the role was never the paperwork. It was always judgment: deciding what problem matters, interpreting incomplete and conflicting signals, making tradeoffs under uncertainty and pressure, defining success, and taking responsibility for the call. ...

In the previous post, I argued that defining decision boundaries is necessary if we want judgment to survive in an AI-accelerated development environment. When execution becomes cheap, the number of decisions explodes. Without clarity around who decides what, speed simply amplifies risk. But defining boundaries alone is not enough. The next question is more practical: how does work actually flow through those boundaries? How does an idea move from a conversation with a customer to something running in production, while AI accelerates the process without collapsing responsibility across roles? ...