JDD

Gartner published a prediction this week: by 2027, 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps that are only identified after production incidents. The root cause they name at Level 3 of their autonomy framework is approval fatigue. Agents execute actions, writing data, sending communications, and modifying configurations, but only after explicit human approval. Under time pressure, that approval becomes reflexive. The control degrades, and the risk compounds in silence. ...

I recently argued on the JFrog blog that trusted AI requires more than model quality. It requires visibility, provenance, governance, and a real system of control around the things models consume, build, and ship. That is the foundation. This post is about what you build on top of it. Because visibility is necessary. Without it, you cannot govern anything. If you cannot see which models are running, where they came from, how they behave, and what they touch, you do not have a governance posture. You have hope dressed up as architecture. ...

A developer recently gave Claude Code write access to a live Meta Ads account. The agent’s read-only analysis was genuinely valuable; it correctly identified the cheapest campaign as having the worst ROI. The insight was good. The judgment about what to do next was absent. The agent executed autonomously, triggered API rate limits through automated publishing, and resulted in the account being permanently banned. The read was right, the write destroyed the business relationship. ...

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? ...

The Stages of Judgment-Driven Development Most of the pain I’ve seen in software wasn’t caused by bad code. It was caused by bad decisions that were never treated explicitly as such. In the last two posts, I argued that execution is no longer the bottleneck. AI made building cheap. Judgment is now the scarce resource. If that’s true, the way we develop software must change, not in terminology or ceremonies, but in where and how we place judgment. ...