Code is the Best Prompt

If you have spent any time building with Large Language Models (LLMs), you have likely written a prompt that looks like this:

"Please analyze the following text. Return your response as a JSON object. The object should have a field called 'summary' and a field called 'sentiment'. The sentiment must be one of 'positive', 'negative', or 'neutral'. Do not include any markdown formatting. Do not include any preamble. I really mean it, please just give me raw JSON."

You hit run. The model returns: "Here is your JSON: { ... }"

You sigh. You go back to the prompt. You add:

"Do NOT say 'Here is your JSON'. Just output the JSON."

You are Prompt Engineering. You are using English prose to try and enforce a technical contract. You are begging a probabilistic poet to act like a deterministic compiler. It is exhausting, it is fragile, and it is the wrong way to build software.

The "Vibe" vs. The Contract

English is a language of vibes. It is ambiguous, nuanced, and open to interpretation. "Be concise" means different things to different people (and different models).

Code is a language of contracts. It is rigid, binary, and absolute.

When you write a prompt, you are suggesting a vibe. When you write code, you are enforcing a law.

The Shift: Schemas over Prompts

At Dwizi, we have found that the most effective way to control an LLM is not to prompt it, but to give it a Tool Definition.

Modern LLMs (like GPT-4 and Claude 3) have been trained to respect "Function Calling" signatures. They understand that if a function requires an integer, they must provide an integer.

This means we can replace our pleading paragraphs of English with clean, strict TypeScript.

Instead of the prompt above, we define a Dwizi tool:

type Sentiment = "positive" | "negative" | "neutral";

type Input = {
  summary: string;
  sentiment: Sentiment;
  confidenceScore: number;
};

export default async function analyzeText(args: Input) {
  // ...
}

When Dwizi sees this code, it automatically generates a JSON Schema. It tells the LLM:

• "I need a summary (string)."
• "I need a sentiment (enum)."
• "I need a confidenceScore (number)."

The Power of the Enum

Look closely at the Sentiment type.

type Sentiment = "positive" | "negative" | "neutral";

This is a Union Type (or Enum). It is one of the most powerful tools in AI engineering.

By defining this type, you have physically constrained the universe of possible outputs. The LLM cannot output "mixed". It cannot output "kinda happy". It cannot output "angry".

It is forced, by the underlying geometry of the API call, to collapse its messy, high-dimensional understanding of the text into one of your three pre-defined buckets.

You didn't have to beg. You didn't have to provide "few-shot examples." You just defined the type.

Type-Driven Development for AI

This shift—from Prompt Engineering to Type-Driven Development—is how we move AI from a toy to a tool.

Imagine you are building an agent to triage GitHub issues.

• The Old Way: You ask the agent, "Is this a bug or a feature?" The agent replies, "It looks like a bug, but maybe it's a feature request because..." Parsing this text is a nightmare.
• The Dwizi Way: You define a tool triage_issue that takes an argument type: "bug" | "feature". The agent must call the tool. It must make a choice.

Suddenly, your AI application becomes deterministic. You can write unit tests for it. You can build logic on top of it.

The "Code First" Philosophy

We believe that code is the highest-bandwidth communication channel between a human and a machine.

English is too lossy. If I tell you to "build a house," you might build a cottage or a mansion. If I give you a blueprint (code), you build exactly what I designed.

LLMs are smart enough to read blueprints now. They don't need us to dumb it down into conversational English. They crave structure. They perform better when they have boundaries.

So stop writing prompts. Stop negotiating with the machine. Start writing types.

Code is the best prompt.