Judgment

The bar for building has collapsed. Anyone with an AI assistant can produce a prototype, a draft, a working script. That is not the challenge anymore. The challenge is identifying people who can tell whether what was built is right, catch what is wrong, and make the call on what to do about it. That is a different hire than the one most managers have been trained to make. And the stakes are higher now, because your hiring decision is no longer a baseline. It is a multiplier. ...

Your team closed 47 tickets last sprint. Deployment frequency is up. Lead time is down. The sprint review looked clean. And you have no idea whether your team is getting better at what matters. Every metric on that dashboard measures motion. None of them measures whether the team made the right decision. In an era where AI generates the first draft of almost everything, code, architecture proposals, incident summaries, and product specs, that gap is no longer academic. It is the difference between a team that compounds in judgment and a team that accelerates toward the wrong destination. ...

For decades, the path was obvious. A junior engineer joined a team, got handed a bug nobody else wanted, fixed it, broke something else, fixed that too, and over a few years accumulated the scar tissue that turned into judgment. Senior engineers were not trained; they were grown, slowly, by the system itself. That system has stopped working at both ends. At the entry point, juniors aren’t being hired. AI makes a senior dramatically more productive and a junior only marginally so, which makes the rational move, for any single team, in any single quarter, to skip the junior hire and let an experienced engineer with AI do the work two juniors used to do. Industry-wide, the pipeline is being shut off before it starts. ...

The Lesson That Used to Be Unavoidable Every senior engineer I respect has a similar war story. They wrote a Python script that was too slow, and someone told them to learn what a list comprehension actually does under the hood. They built a React app that re-rendered itself into a coma, and they had to crawl back into the DOM to figure out why. They shipped a service that fell over the first time real traffic hit it, and they spent a weekend learning what a connection pool is. ...

Working with AI to generate code is extremely satisfying. In a matter of minutes, you get something that looks great and, in most cases, does what you wanted it to do and even more. But many times, what looks ready for production is far from being production-safe. A large-scale study conducted by two researchers at FernUniversität in Hagen analyzed 7,703 files from public GitHub repositories explicitly attributed to AI tools. Using CodeQL, the researchers identified 4,241 CWE instances across 77 different vulnerability types. While 87.9% of the analyzed AI-generated code contained no identifiable CWE-mapped vulnerabilities, the risk came from code that appeared to work fine. It compiled, it solved the visible task, but it still carried hidden assumptions, unsafe patterns, and security debt. ...

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

In the previous posts, I argued that execution is no longer scarce and that judgment, not effort, has become the limiting factor. I also argued that judgment without memory slowly degrades into improvisation. But even if you solve memory, even if context is accessible and history is visible, something can still go wrong. You can have full information, experienced people, and AI assisting at every step, and still end up making decisions that gradually weaken the system. ...

Memory Is the Missing Layer in AI-Assisted Development In the previous posts, I argued that execution is no longer the bottleneck and that judgment isn’t intuition, it’s accountability. Those two shifts already change how we should think about building software. But there is a third layer that matters just as much and is far less visible. Memory. Not model memory. Not guardrails. Not rule engines. Institutional memory. The living history of why things exist. ...

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