Intelligence Is a Utility. Judgment Is the Product.

4 min read

Translating clinical notes into ICD-10 codes: intelligence. Recommending the treatment: judgment. The difference determines what compounds and what gets absorbed by the next model release.

There are roughly 70,000 standardised medical billing codes. Translating a clinical note into the correct ICD-10 code requires reading the note, understanding the diagnosis, matching it to the right category, and applying a set of rules that are complex but ultimately deterministic.

AI handles this now. Not as an experiment. In production, at scale, with accuracy rates that match or exceed human coders.

But deciding which treatment to recommend to the patient who generated that clinical note? That’s a different kind of work entirely. It requires weighing risks that aren’t in the manual. Reading a situation that involves the patient’s history, preferences, tolerance for uncertainty, and the clinician’s experience with similar cases.

The first task is intelligence. The second is judgment. The difference between these two determines what compounds and what gets absorbed by the next model update.

The distinction that determines your architecture

Sequoia framed it precisely: writing code is mostly intelligence. Knowing what to build next is judgment.

Intelligence work follows patterns. It translates rules, processes documents, classifies inputs, generates outputs according to templates. It requires knowledge, but the knowledge is codifiable. AI does this now, and does it better every quarter.

Judgment work requires experience. Not the kind of experience you can encode in a training set, but the kind that comes from years of watching what works, what doesn’t, and why. Deciding which feature to prioritise. Knowing when a technical architecture won’t hold at scale. Sensing that a customer’s stated problem isn’t their real problem.

The practical consequence for founders: if your product automates intelligence work, you’re building something valuable but commoditisable. The model will get better. Your advantage will shrink. If your product augments judgment, you’re building something that the model can’t replicate because the judgment itself is what makes the product different.

Iron Man suit, not Iron Man robot

Andrej Karpathy offered the most useful metaphor: build Iron Man suits, not Iron Man robots.

The robot is the flashy demo. Fully autonomous. No human in the loop. Impressive for a presentation. Fragile in production. It fails when it encounters an edge case that wasn’t in the training data, and nobody is there to catch it.

The suit is partial autonomy. The AI handles the intelligence work at machine speed. The human handles the judgment calls. The system gets faster and more capable over time, but the human remains in the critical path for decisions that require experience, taste, or accountability.

Karpathy’s practical advice: work in small, incremental chunks where verification is easy. Don’t accept a 10,000-line code dump and hope it’s correct. Keep the AI on a leash. Review its output. Catch errors before they compound. The suit makes you faster. The robot makes you reckless.

The most effective builders in this model are the ones who focus on the logic and architecture of systems rather than the language of code. A non-technical background becomes an advantage, not a limitation, because it forces you to direct the AI toward the right problems instead of getting lost in implementation details. The AI is the translator. The judgment about what to translate is yours.

Where intelligence is already a utility

The shift is further along than most people realise.

Testing and debugging: AI agents now handle unit testing, integration testing, and bug detection at a level that exceeds most junior engineers. The intelligence work of “find what’s broken and fix it” is becoming a utility.

Document review: Legal document analysis, contract comparison, regulatory compliance checking. The pattern-matching work that associates at law firms and compliance officers performed is being absorbed by models that process documents faster and miss fewer details.

Financial analysis: Earnings report summaries, market comparisons, risk assessments. The intelligence work of “read these documents and extract the relevant numbers” is automated.

Customer support: Routine inquiries, troubleshooting guides, ticket classification. The intelligence work of “understand the problem and route it to the right answer” is handled by agents.

In each case, the intelligence work became a utility. What remained valuable was the judgment: deciding what to do with the analysis, which legal strategy to pursue, which customer to prioritise, how to handle the case that doesn’t fit the pattern.

What this means for pricing

If your product handles intelligence work, your pricing is under pressure. The work gets cheaper every quarter as models improve. Per-seat pricing collapses because you need fewer humans. Your margins depend on whether the model provider charges you more or less than the value you deliver.

If your product augments judgment, your pricing is defensible. The value scales with the quality of the decisions being made, not with the volume of intelligence work being processed. Outcome-based pricing works because the outcome depends on judgment that the customer can’t get elsewhere.

The founders charging per resolution, per completed transaction, or per verified outcome are in a structurally different position from the ones charging per seat or per API call. The first group is selling judgment. The second is selling intelligence. One scales with value. The other races against cost.

Intelligence is becoming what electricity became a century ago: essential, ubiquitous, and not a basis for competitive advantage. Nobody builds a company around having access to electricity. In five years, nobody will build a company around having access to intelligence.

Judgment is the product. Everything else is infrastructure.