Most metrics for AI-assisted development measure the wrong thing. Lines of code generated. Documentation-to-code ratio. Tokens consumed.
Here’s a better question: How much consistent behavior do you get per line of specification?
Intent Density = (consistent_behaviors_generated) / (spec_lines_required)
This isn’t about writing less. It’s about writing things that compound.
Low intent density looks like this:
The player health bar should be red.
The player health bar should be 200 pixels wide.
The player health bar should be 20 pixels tall.
The player health bar should be positioned at x=10, y=10.
The player health bar should decrease from right to left.
The player health bar should have a black border.
Six lines. One health bar. The LLM will generate exactly what you asked for—nothing more. If you want an enemy health bar, you write six more lines.
This is the LLM as transcriptionist.
High intent density looks like this:
Health bars visualize current/max ratios.
UI elements use the damage palette (red/orange) for threats,
restoration palette (green/blue) for healing.
Player UI anchors top-left. Enemy UI tracks world position.
Three lines. But now the LLM can infer:
You didn’t specify any of this. The LLM derived it from constraints and relationships.
This is the LLM as reasoning engine.
Three things:
Low density: “The sword does 10 damage.” High density: “Weapons never one-shot players from full health.”
The constraint applies to every weapon. It shapes design decisions the LLM makes when generating new weapons. It prevents edge cases you’d otherwise have to patch.
Low density: “Goblins have 30 HP. Orcs have 60 HP. Trolls have 120 HP.” High density: “Enemy HP doubles with each tier. Goblins are tier 1.”
Now the LLM can generate tier 4 enemies without asking. It knows the pattern.
Low density: “Fire beats ice. Ice beats lightning. Lightning beats fire.” High density: “Elements form a rock-paper-scissors cycle: fire → ice → lightning → fire.”
The rule is generative. Add a fourth element and the LLM knows to extend the cycle, not break it.
You can’t measure it precisely, but you can estimate it:
Test 1: The extension test Add a new entity (enemy, item, UI element) using only your existing spec. If the LLM generates something consistent without new instructions, your intent density is high.
Test 2: The contradiction test Ask the LLM to generate something that violates your spec. If it refuses or asks for clarification, your constraints are working.
Test 3: The new session test Start a fresh LLM session with only your spec. Does it produce the same results as your previous session? High intent density means high reproducibility.
Intent density compounds over time.
Early in a project, you’re defining vocabulary: “A room is a discrete playable area. Rooms connect through doors. Encounters spawn in rooms.”
Later, you can write: “Boss rooms have one entrance, no exits until the encounter resolves.”
The LLM knows what rooms, doors, and encounters are. It infers that boss rooms need locked doors, that the encounter must have a resolution state, that the room needs to track whether it’s been cleared.
One line. Dozens of correct implementation decisions.
High intent density isn’t always the goal.
The goal isn’t maximum abstraction. It’s appropriate abstraction—enough structure to enable inference, not so much that you’re fighting your own rules.
Traditional programming skill: turning requirements into working code.
LLM-assisted skill: expressing requirements so that working code is inevitable.
Intent density measures how well you’ve done the second part. It’s not about prompting tricks or magic words. It’s about understanding your domain deeply enough to describe its rules, not just its instances.
The question isn’t “how do I get the AI to write good code?”
The question is “how do I express intent so clearly that good code is the only possibility?”