Don’t Spend Any Token Before It’s Time

Don’t Spend Any Token Before It’s Time

A Practical Principle for Intent-Driven Engineering

AI has made it incredibly easy to generate software.

That does not mean we should generate it immediately.

One of the biggest mistakes organizations make with AI-assisted development is assuming that more context, more prompts, more agents, and more generated code automatically produce a better result.

They do not.

Every token should have a purpose. Every retrieval should answer a question. Every agent should have a defined responsibility. Every line of code should move the system toward a measurable outcome.

That leads to a simple principle:

Don’t spend any token before it’s time.

This is more than a cost-saving technique.

It is an engineering discipline.

It is the practice of giving an AI system only the context, tools, instructions, and work required for the current stage of delivery—and nothing more.

Within Intent-Driven Engineering, tokens are not spent because they are available. They are spent because the next decision requires them.

Start With the Outcome

Intent-Driven Engineering does not begin with a prompt.

It begins with an outcome.

The first question is not:

“What should the AI generate?”

The first question is:

“What must be true when this work is complete?”

That outcome might be:

• A customer can update a billing address.

• A failed payment is retried safely.

• A TMF request reaches Salesforce and the billing platform.

• A developer can submit a governed, tested pull request.

• A production incident can be diagnosed and resolved faster.

• A business process can be completed with less cost, risk, or delay.

The outcome defines the work.

The AI does not need the entire enterprise architecture, every Jira issue, all repository documentation, or every policy document at the beginning.

It only needs enough information to understand the intended result and determine the next responsible action.

This is where token discipline starts.

The Intent-Driven Engineering Flow

A disciplined workflow looks like this:

Business Outcome

↓

Structured Intent Artifact

↓

Targeted Context Retrieval

↓

Repository Exploration

↓

Implementation Plan

↓

Specialized Execution

↓

Validation and Testing

↓

Pull Request and Deployment

↓

Outcome Verification and Observability

Each stage earns the right to spend the tokens required for the next stage.

The system does not load everything at once.

It progressively discovers, reasons, acts, and verifies.

Step 1: Capture the Intent Before Generating Code

The first artifact should be a clear statement of intent.

This may be stored in a file such as:

Feature.md

A strong intent file should describe:

• The business outcome

• The user or system affected

• The current problem

• The expected behavior

• Acceptance criteria

• Constraints

• Known dependencies

• Security or compliance requirements

• How success will be measured

For example:

# Intent: Add Asynchronous Billing Submission

## Business Outcome

Allow Salesforce to submit validated billing requests without waiting

for the downstream billing platform to complete processing.

## Expected Behavior

1. Accept the billing request through the existing API gateway.

2. Validate the request against the approved schema.

3. Return an acknowledgment with a correlation ID.

4. Publish the validated request to the approved Kafka topic.

5. Process the request through the billing adapter.

6. Publish success or failure events.

7. Allow the originating system to retrieve processing status.

## Acceptance Criteria

- Invalid requests are rejected before publication.

- Duplicate requests do not create duplicate billing transactions.

- Every transaction can be traced using a correlation ID.

- Failures are observable and retryable.

- Automated tests cover validation, publication, and error handling.

This artifact gives the AI a destination without prematurely telling it how to build everything.

That distinction matters.

Intent describes the required outcome.

The implementation plan determines the most appropriate path after the repository and environment have been examined.

Step 2: Retrieve Context Only When It Becomes Relevant

A common anti-pattern is copying every potentially relevant document into the initial prompt.

This wastes tokens and often reduces accuracy.

Large context windows can contain more information, but more information is not automatically better information.

Irrelevant context creates noise. It can distract the model, introduce contradictions, bury important constraints, and make the reasoning process harder to control.

Intent-Driven Engineering uses targeted retrieval instead.

An MCP server or another approved integration can retrieve information from systems such as:

• Jira

• Confluence

• Figma

• GitHub

• GitLab

• API catalogs

• Schema registries

• Databases

• Observability platforms

• Enterprise policy repositories

The system should retrieve information because a specific question needs to be answered.

For example:

• Retrieve the Jira issue to understand the requested behavior.

• Retrieve the API specification when evaluating an endpoint.

• Retrieve the Figma design when implementing a user interface.

• Retrieve the schema when validating a Kafka message.

• Retrieve security policy when the change touches authentication.

• Retrieve deployment documentation when preparing the release.

Do not retrieve ten documents because one of them might eventually be useful.

Retrieve the one document required to resolve the current uncertainty.

Context should be pulled by need, not pushed by habit.

Step 3: Explore the Repository Before Making Assumptions

The repository already contains valuable context.

It contains architecture, naming conventions, tests, interfaces, dependencies, build scripts, deployment configurations, and examples of how the organization solves similar problems.

The AI should inspect this existing evidence before inventing a solution.

A disciplined exploration phase may examine:

CLAUDE.md

README.md

package.json

pom.xml

*.csproj

src/

tests/

.github/workflows/

docker/

helm/

docs/

The AI may also search for:

• Similar endpoints

• Existing adapters

• Validation patterns

• Error-handling conventions

• Authentication mechanisms

• Logging and tracing utilities

• Test fixtures

• Event schemas

• Retry implementations

• Idempotency patterns

This is another example of spending tokens only when they are justified.

The system does not read the entire repository.

It builds a map, identifies the likely change surface, and then examines the most relevant files in greater detail.

The pattern is:

Explore broadly enough to orient. Read deeply enough to decide.

Step 4: Plan Before Implementing

Once the outcome, intent, and repository context are understood, the system creates an implementation plan.

The plan should answer:

• What files are likely to change?

• What existing patterns should be reused?

• What assumptions are being made?

• What dependencies are involved?

• What tests must be added or updated?

• What security or compliance controls apply?

• What could fail?

• How will completion be verified?

• How does the implementation support the stated business outcome?

A plan might look like this:

# Implementation Plan

1. Extend the existing billing request contract.

2. Reuse the repository's current validation middleware.

3. Add a billing submission service.

4. Publish validated requests through the existing Kafka producer.

5. Add correlation and idempotency identifiers.

6. Create success and failure event handlers.

7. Add status retrieval through the existing transaction endpoint.

8. Add unit and integration tests.

9. Run formatting, linting, build, and test validation.

10. Verify that the acceptance criteria in Feature.md are satisfied.

Planning prevents the AI from spending large numbers of tokens implementing the wrong design.

A few hundred tokens spent validating a plan can prevent thousands of tokens, hours of rework, and an incorrect pull request.

The cheapest code to fix is the code that was never generated incorrectly.

Step 5: Use Specialists Only When Specialization Adds Value

Multi-agent systems can be powerful.

They can also become expensive, noisy, and unnecessarily complicated.

An agent should not be created simply because the platform supports agents.

A specialist agent should be used when the work genuinely benefits from isolated expertise or context.

Examples include:

• A security agent reviewing authentication changes

• A testing agent designing edge cases

• A database agent evaluating migration safety

• An API agent checking contract compatibility

• A frontend agent validating the implementation against Figma

• A reliability agent reviewing retries and idempotency

• A documentation agent updating operational guidance

The orchestrator should pass each specialist only the information required for that responsibility.

For example:

Planning Agent

    ↓

API Specialist

    ↓

Implementation Agent

    ↓

Testing Specialist

    ↓

Security Reviewer

    ↓

Validation Agent

The testing specialist does not need every architecture document.

The security reviewer does not need unrelated user-interface assets.

The documentation agent does not need the complete internal reasoning history.

Each agent receives:

• Its objective

• The relevant intent

• The required context

• The expected output

• The constraints it must follow

This keeps the workflow focused and reduces duplication.

Do not pay five agents to rediscover the same facts.

Step 6: Put Reusable Knowledge in the Right Place

Not every instruction belongs in every prompt.

Intent-Driven Engineering separates different types of knowledge into the appropriate control layer.

CLAUDE.md

Use CLAUDE.md for persistent repository guidance such as:

• Architecture conventions

• Required commands

• Coding standards

• Important directories

• Testing expectations

• Security rules

• Pull request conventions

• Known repository constraints

Keep it useful and focused.

A massive CLAUDE.md containing every organizational policy becomes expensive to load, difficult to maintain, and easy to ignore.

Skills

Use reusable skills for repeatable procedures such as:

• Creating an implementation plan

• Reviewing API compatibility

• Generating tests

• Checking repository conformance

• Preparing a pull request

• Performing a security review

• Converting Jira requirements into an intent artifact

A skill packages specialized instructions so they do not have to be rewritten in every conversation.

MCP Servers

Use MCP servers for current or external information such as:

• Jira tickets

• Confluence pages

• Figma designs

• Database metadata

• API contracts

• Deployment status

• Observability data

MCP makes information available without forcing all of it into the initial context.

Hooks

Use hooks for deterministic enforcement such as:

• Formatting

• Linting

• Unit tests

• Build validation

• Secret detection

• Policy checks

• File protection

• Required metadata

• Prohibited command detection

Hooks should handle requirements that must not depend on the AI remembering to comply.

CI/CD

Use CI/CD as the final independent enforcement layer.

The AI may run tests locally, but the pipeline should verify the work again in a controlled environment.

The guiding rule is:

Instructions guide. Skills standardize. MCP retrieves. Hooks enforce. CI/CD verifies.

Step 7: Separate Generation From Verification

An AI system should never be trusted merely because it produced a convincing answer or generated clean-looking code.

The work must be verified.

Verification should match the type of change.

For backend work:

• Compile or build the project

• Run unit tests

• Run integration tests

• Validate API contracts

• Check database migrations

• Exercise failure paths

For frontend work:

• Build the application

• Run component and end-to-end tests

• Inspect the rendered result

• Compare against the design

• Capture screenshots when useful

• Test responsive behavior

For infrastructure work:

• Validate templates

• Run policy checks

• Review deployment plans

• Test in a safe environment

• Confirm rollback behavior

For event-driven systems:

• Validate schemas

• Test publication and consumption

• Confirm idempotency

• Simulate retries

• Verify dead-letter handling

• Trace correlation IDs across services

Tokens spent on verification are not waste.

They are spent protecting the outcome.

However, verification should also be targeted. There is no reason to rerun every enterprise test suite after changing one isolated documentation file.

The scope of verification should correspond to the scope and risk of the change.

Spend the verification tokens that the risk requires.

Step 8: Use Delta-Based Execution

Once the AI understands the repository and creates a plan, subsequent work should focus on the delta.

The system should not repeatedly restate or reprocess the complete project.

Instead, it should ask:

• What changed?

• What remains incomplete?

• Which tests are failing?

• Which acceptance criteria are not yet satisfied?

• What new information invalidated the original plan?

• What is the smallest responsible next action?

This creates a tighter loop:

Intent

  ↓

Plan

  ↓

Implement Small Delta

  ↓

Validate

  ↓

Observe Result

  ↓

Implement Next Delta

Delta-based execution reduces context growth and makes failure recovery easier.

When a test fails, the AI does not need to reconsider the entire system. It needs the failure output, the relevant implementation, and the corresponding requirement.

This is Intent-Driven Engineering at its most practical:

Carry the intent forward. Carry only the necessary context with it.

Step 9: Measure the Outcome, Not the Volume of Generation

An organization should not judge AI-assisted engineering by:

• Number of prompts

• Number of tokens consumed

• Number of agents deployed

• Lines of code generated

• Number of pull requests opened

• Percentage of code written by AI

Those are activity metrics.

They do not prove that the organization is delivering more value.

Better measures include:

• Lead time from approved intent to production

• First-pass test success rate

• Pull request rework

• Defect escape rate

• Deployment frequency

• Change failure rate

• Mean time to recovery

• Cost per completed feature

• Percentage of acceptance criteria satisfied

• Business outcome achieved

• Customer or operational impact

The goal is not to minimize token usage at any cost.

The goal is to maximize useful outcomes per unit of cost, time, and risk.

Sometimes the responsible decision is to spend more tokens on planning, testing, or security review.

Sometimes the responsible decision is to stop generating because the intended outcome has already been achieved.

The best token is not always the token you save. It is the token that prevents wasted work.

The Token Maturity Model

Organizations tend to progress through several stages.

Stage 1: Prompt Everything

Developers paste large amounts of information into a chat and ask the AI to generate a complete solution.

The process is fast but inconsistent.

Stage 2: Add More Context

The organization assumes poor results are caused by insufficient context, so it loads more documents, larger prompts, and broader repository content.

Costs rise, but reliability may not improve.

Stage 3: Standardize Instructions

The organization introduces repository guidance, templates, and shared prompts.

Consistency improves, but execution may still depend on human memory.

Stage 4: Orchestrate Context

The organization uses intent artifacts, MCP retrieval, repository exploration, skills, and specialist agents.

Context is delivered according to the stage and responsibility.

Stage 5: Govern Outcomes

Hooks, automated tests, CI/CD controls, audit trails, observability, and measurable outcomes form a complete operating model.

At this stage, the organization is no longer experimenting with AI-generated code.

It is operating an engineered AI delivery system.

A Practical Operating Model

A scalable enterprise implementation might follow this pattern:

Business Request

      ↓

Jira / Product Requirement

      ↓

Feature.md Intent Artifact

      ↓

Approved MCP Retrieval

      ↓

Repository Exploration

      ↓

Implementation Plan

      ↓

Plan Review or Approval

      ↓

Specialized Skills and Agents

      ↓

Incremental Implementation

      ↓

Hooks and Local Validation

      ↓

Automated Tests

      ↓

Pull Request

      ↓

CI/CD Governance

      ↓

Deployment

      ↓

Observability

      ↓

Outcome Measurement

At every stage, the system asks:

1. What decision must be made now?

2. What is the minimum trustworthy context required?

3. Which tool, skill, or agent is responsible?

4. What evidence proves the work is correct?

5. Does the result advance the intended outcome?

If the next step cannot answer one of these questions, the system should pause before spending more tokens.

An Example of Token-Aware Execution

Imagine a Jira issue requests a new payment-status endpoint.

A wasteful approach might:

1. Load the entire Jira project.

2. Load all Confluence architecture pages.

3. Read the full repository.

4. Invoke several agents.

5. Generate the endpoint immediately.

6. Run every test suite.

7. Discover that an equivalent endpoint already exists.

A token-aware approach would:

1. Convert the Jira request into a focused intent artifact.

2. Search the repository for payment-status functionality.

3. Inspect the existing controller, service, and tests.

4. Identify that the requirement is mostly satisfied.

5. Create a delta plan for the missing fields and authorization rule.

6. Implement the narrow change.

7. Run the affected tests and required governance checks.

8. Verify the acceptance criteria.

9. Create the pull request.

The second approach uses fewer tokens, produces less code, lowers risk, and reaches the outcome faster.

That is not merely optimization.

That is better engineering.

The Core Principles

“Don’t spend any token before it’s time” can be expressed through a few practical rules:

Begin with the outcome.

Do not ask the AI to build something until the desired result is clear.

Structure the intent.

Create an artifact that can persist across people, agents, sessions, and tools.

Retrieve context on demand.

Bring in information when a specific decision requires it.

Explore before inventing.

Use the repository as evidence.

Plan before implementing.

Validate the direction before producing large amounts of code.

Specialize selectively.

Use agents and skills when they provide real separation of responsibility.

Enforce deterministically.

Use hooks and CI/CD for requirements that must always run.

Verify with evidence.

Tests, builds, screenshots, schemas, logs, and deployment results matter more than confident explanations.

Work in deltas.

Move from the current state to the intended state through controlled increments.

Stop when the outcome is achieved.

Do not generate more merely because generation is easy.

The Future of Enterprise AI Engineering

The future of software development will not be defined by who can generate the most code.

It will be defined by who can translate intent into outcomes with the least waste, the strongest governance, and the highest level of trust.

That requires more than prompts.

It requires an operating model.

Intent-Driven Engineering provides that model by connecting:

• Business outcomes

• Structured intent

• Controlled context

• Repository intelligence

• Specialized execution

• Deterministic validation

• Enterprise governance

• Measurable results

The objective is not to keep the AI busy.

The objective is to deliver the right outcome.

Every prompt, retrieval, agent, test, and generated line should earn its place in that process.

So before spending the next token, ask:

Does the system need this information now?

Does this action reduce uncertainty?

Does it move us toward the intended outcome?

Will we be able to verify the result?

When the answer is yes, spend the token.

When the answer is no, do not.

Don’t spend any token before it’s time.

Because in enterprise AI engineering, discipline will outperform volume—and outcomes will outperform activity.