TrueVectors

The AI Discipline Framework ​

By Radhakrishnan Poomari · 2026

The Problem This Solves ​

Uber burned through its annual AI compute budget in four months. Microsoft pulled Claude Code licenses after costs spiraled. Andrej Karpathy — one of the architects of modern deep learning — called AI-generated code "gross" and described debugging it as harder than writing from scratch. A Stack Overflow survey found that 96% of developers do not fully trust AI-generated code. One in six AI-assisted commits introduces a new defect.

And yet, the default behavior across the industry remains: prompt first, think later.

Every AI interaction has a cost, produces noise, and adds complexity. Yet almost no one accounts for these before prompting. The result: runaway budgets, unreliable outputs, accumulating technical debt, and decisions made on outputs nobody verified.

This framework enforces discipline. Before you ask an AI to do anything, you define what you're willing to spend, what you expect back, how you'll know it worked, and what happens when it doesn't.

The Three Pillars ​

1. COST — What Are You Willing to Spend? ​

People and companies are bleeding money on AI tools with no visibility into what they're actually getting for it. Nobody has an instrument that tells you "this agent cost you $X and produced $Y of actual value."

Cost is not just tokens. It is time, compute, human review effort, downstream integration effort, and the opportunity cost of doing this instead of something else.

Before prompting, define:

  • Token / Usage Budget: Maximum input + output tokens for this task (for developers), or total API calls, seat license hours, or compute cost (for teams and organizations). If you don't know, estimate. A 500-line code generation is ~2,000–4,000 tokens output. A strategic analysis is ~1,500–3,000. Set a ceiling.
  • Time Budget: How long should this take end-to-end, including your review? If the AI saves you 30 minutes of writing but costs you 45 minutes of debugging, you lost time.
  • Iteration Budget: Maximum number of follow-up prompts to reach acceptable output. One-shot is ideal. Three is acceptable. More than five means the task is poorly defined or beyond the model's reliable capability.
  • Review Budget: How much human effort is required to verify the output? If verification takes longer than doing it yourself, the task is not suitable for AI delegation.
  • Downstream Budget: What does it cost to integrate this output into your system, codebase, document, or workflow? AI-generated code that takes 2 hours to refactor costs more than it saved.

The Rule: If you cannot estimate the total cost before prompting, you are not ready to prompt. Define the budget first. Prompt second.

2. NOISE — How Will You Separate Signal from Slop? ​

Karpathy's own word for AI-generated output was "gross." 96% of developers don't trust AI-generated code. One in six AI commits introduces a new defect. But the output looks correct on the surface. The problem isn't that AI fails — it's that you can't tell when it's failing versus when it's working.

AI outputs are probabilistic. They contain filler, hedging, hallucination, and structural bloat by default. Noise is not a bug — it is the baseline behavior of language models. Your job is to specify what signal looks like so you can measure deviation from it.

Before prompting, define:

  • Output Specification: What exactly should the output contain? Be precise. "Write a function that validates email addresses and returns a boolean" is a specification. "Help me with email validation" is an invitation for noise.
  • Exclusion List: What should the output NOT contain? Specify explicitly. No comments unless requested. No alternative approaches unless requested. No explanations of what the code does unless requested. No caveats, disclaimers, or hedging unless the task involves genuine uncertainty.
  • Format Contract: Define the exact structure. File type, section headers, variable naming conventions, line count range, language, framework version. The tighter the format contract, the less noise in the output.
  • Verification Criteria: How will you know the output is correct? Unit tests, manual inspection, diff against expected output, compilation without errors, factual cross-reference. Define this before prompting, not after.
  • Noise Tolerance: What percentage of the output do you expect to be usable without modification? If your tolerance is below 70%, the task is either too vague or too complex for a single prompt.

The Rule: If you cannot describe what a correct output looks like before prompting, you will not recognize one after. Define the signal first. Prompt second.

3. COMPLEXITY — Is This Task Within the Model's Reliable Capability? ​

Models change every 3 months. Capabilities appear and disappear based on whatever the labs put into the training mix. Karpathy said it himself: "we are slightly at the mercy of whatever the labs are doing." A tool that worked with GPT-4 breaks with GPT-5. A workflow tuned for Claude Opus behaves differently on Sonnet. No one is tracking how agent behavior evolves across model versions, tool updates, and prompt changes over time.

Language models have what researchers call "jagged intelligence" — they can refactor 100,000 lines of code but fail at deciding whether to walk or drive 50 meters. Capability is not uniform. It depends on what was in the training data, what was reinforced, and what the model has never seen. Your job is to assess whether this specific task falls within the model's reliable operating envelope.

Before prompting, define:

  • Task Decomposition: Can this task be completed in a single, self-contained prompt? If it requires the model to maintain state across multiple turns, remember earlier context, or coordinate between systems, it is a complex task that requires human orchestration, not delegation.
  • Domain Specificity: Is this task within a well-represented domain in training data (common programming languages, standard business writing, widely-known frameworks)? Or is it niche, proprietary, or recent enough that the model is likely extrapolating rather than recalling?
  • Architectural Decisions: Does the task require making design choices that have long-term consequences? If yes, the model should propose options, not decide. Karpathy's MenuGen experiment — where the AI used email strings instead of persistent user IDs for a restaurant app — illustrates what happens when architectural decisions are delegated to a statistical predictor. The system worked on the surface but was fundamentally broken underneath.
  • Failure Consequence: What happens if the output is wrong and you don't catch it? If the answer is "a production outage," "a security vulnerability," "a financial error," or "a legal liability," then the task requires human-primary execution with AI assistance, not AI-primary execution with human review.
  • Generalization Requirement: Does the output need to work across edge cases the model hasn't seen? AI outputs tend to handle the happy path well and fail on boundary conditions. If generalization matters, specify edge cases explicitly in the prompt and test against them.

The Rule: If the task requires judgment, architectural reasoning, or handling of unseen edge cases, the model is an assistant, not an executor. Define the complexity boundary first. Prompt second.

The Pre-Prompt Checklist ​

Complete this before every non-trivial AI interaction. Trivial means: a single factual question, a quick rephrasing, a format conversion. Everything else is non-trivial.

TASK: [One sentence. What exactly do you need?]

--- COST ---
Token / usage budget: [max tokens or estimated cost]
Time budget:          [total time including review]
Iteration budget:     [max follow-up prompts: 1 / 3 / 5]
Review budget:        [estimated review time]
Downstream budget:    [integration effort: none / minor / significant]

--- NOISE ---
Output spec:          [exactly what the output must contain]
Exclusions:           [what the output must NOT contain]
Format contract:      [file type, structure, naming, length]
Verification:         [how you will confirm correctness]
Noise tolerance:      [% of output expected usable as-is]

--- COMPLEXITY ---
Single-prompt task:   [yes / no — if no, decompose first]
Domain coverage:      [well-known / niche / proprietary]
Architectural:        [does this involve design decisions? yes / no]
Failure consequence:  [trivial / recoverable / severe]
Edge cases:           [list known edge cases to test against]

--- DECISION ---
Proceed:              [yes / no / decompose further]
Mode:                 [AI-primary / human-primary-AI-assisted / human-only]

Prompt Construction Rules ​

Once the checklist is complete and the decision is "proceed," construct the prompt using these principles:

Rule 1: Lead with the constraint, not the goal. Instead of "Write a REST API for user authentication," write "Within 120 lines of Python using FastAPI, no external auth libraries, write a REST API for user authentication that handles these 4 endpoints: [list]. Return only the code file. No comments. No explanations."

Rule 2: Specify the negative space. Models fill silence with noise. If you don't say "no comments," you get comments. If you don't say "no alternative approaches," you get three versions. If you don't say "no caveats," you get a paragraph about why this might not work. Explicitly exclude what you don't want.

Rule 3: Include the verification contract in the prompt. "The output is correct if: (a) all 4 endpoints return 200 on valid input, (b) invalid tokens return 401, (c) missing fields return 422 with field names in the error body." When the model knows how you'll verify, it optimizes for your criteria instead of its own priors.

Rule 4: Set the iteration expectation. "This is a one-shot task. Do not ask clarifying questions. Make reasonable assumptions and state them at the end in a single line." This prevents the model from deferring decisions back to you as a way to avoid committing to an output.

Rule 5: Bound the output. "Response must be under 200 lines." "Summary must be under 300 words." "Return exactly 5 items, not more." Unbounded outputs are where bloat lives.

Post-Output Evaluation ​

After receiving the output, score it before using it:

ACTUAL TOKEN USAGE:    [tokens consumed vs budget]
ACTUAL TIME:           [time spent vs budget, including review]
ITERATIONS USED:       [follow-ups needed vs budget]
NOISE RATIO:           [% of output you deleted or rewrote]
CORRECTNESS:           [passed verification criteria? yes / partial / no]
INTEGRATION EFFORT:    [actual downstream effort vs estimate]

VERDICT:               [accept / revise / reject / redo manually]
LESSON:                [one sentence — what would you change next time?]

Track these over time. After 20 tasks, you will have a personal model of where AI delivers value and where it costs more than it saves. This is your behavioral baseline — the foundation of informed decision-making about AI.

When NOT to Use AI ​

This framework assumes AI is a tool, not a default. Some tasks should not be delegated:

  • When you don't understand the domain well enough to verify the output. If you can't tell whether the answer is right, you can't use the answer safely. Learn first, delegate later.
  • When the task is faster to do yourself. A 10-line function that you know how to write takes less time to type than to prompt, review, and test. Do it.
  • When the cost of being wrong exceeds the value of being fast. Speed is not value. Correctness is value. If the failure cost is high, slow down.
  • When you're prompting because of FOMO, not because of need. Using AI to feel productive is not the same as being productive. If the task doesn't benefit from AI, don't force it.

The Principle ​

AI should earn its seat at the table the same way any hire does — by delivering measurable value within a defined budget, with work you can verify, at a complexity level matched to its actual capability. Anything less is not automation. It is abdication.

This framework is not anti-AI. It is anti-waste, anti-noise, and anti-complexity. It exists because the current default — prompt first, think later — is producing runaway costs, unreliable systems, and a generation of builders who cannot distinguish between output and outcome.

Cost. Noise. Complexity. Measure all three. Trust nothing you haven't verified. Budget everything you delegate.

Where this thesis is implemented ​

The discipline above is what every AI engineer should be doing before prompting. The work that comes after — verifying that the agent actually did what it said, not merely produced something plausible — is implemented in the TrueVectors Auditor: the Agent Behavioral Reliability engine, where every finding carries an evidence tag so reviewers know which verdicts are proved and which are judgment. Public software distribution is closed; the public audit record remains reproducible without the product.

By Radhakrishnan Poomari · 2026