Deterministic vs. Non-Deterministic Work: A Framework for AI-Assisted Development

One of the most common mistakes teams make with AI coding tools is treating all development work the same. They prompt the AI for everything — from generating boilerplate CRUD endpoints to designing a distributed event system — and then wonder why the results are inconsistent.

The results are inconsistent because the work is fundamentally different. Some development tasks have clear inputs, known patterns, and verifiable outputs. Others require judgment, trade-off evaluation, and contextual reasoning that no current AI tool can reliably provide.

IFD addresses this with an explicit categorization: deterministic work and non-deterministic work.

Deterministic Work

Deterministic work follows known patterns and produces predictable outputs. Given the same inputs and rules, the output should be the same regardless of who (or what) produces it.

Examples:

• Generating CRUD endpoints from a data model schema
• Creating test harnesses that follow an established testing pattern
• Scaffolding React components from a defined component template
• Transforming configuration files between formats
• Generating TypeScript types from an API specification
• Writing migration scripts from a schema diff

These tasks share a common trait: the what and the how are both well-defined. There is no ambiguity about what the output should look like. An experienced developer would produce essentially the same code as any other experienced developer given the same inputs and conventions.

AI tools excel at deterministic work. When the patterns are clear and the constraints are explicit (encoded as Skills in IFD), AI generates this code reliably and quickly. The output is verifiable against known expectations.

Non-Deterministic Work

Non-deterministic work requires creative judgment. The inputs are ambiguous, the constraints are in tension, and reasonable people would produce different solutions.

Examples:

• Choosing between a microservices and monolithic architecture
• Designing the domain model for a new business capability
• Deciding where to draw service boundaries
• Evaluating build-vs-buy for a notification system
• Determining the right consistency model for a distributed data store
• Designing an API that balances usability, performance, and extensibility

These tasks have no single correct answer. The right choice depends on organizational context, risk tolerance, team capabilities, timeline constraints, and strategic priorities that extend well beyond the technical domain.

AI tools can assist with non-deterministic work — surfacing options, identifying trade-offs, challenging assumptions, presenting patterns from similar systems. But the decision authority must remain with the human architect or team. An AI tool does not know that your organization is risk-averse about eventual consistency, or that your team has deep expertise in event sourcing but none in CQRS, or that the CEO wants the product shipped by Q3 regardless of technical elegance.

Why the Distinction Matters

Without this categorization, teams fall into two failure modes:

Under-delegation: Teams that do not trust AI tools refuse to delegate even deterministic work, missing the productivity gains that AI legitimately provides. They review every generated line of boilerplate as if it were a novel architectural decision.

Over-delegation: Teams that over-trust AI tools delegate non-deterministic work without sufficient oversight, accepting architectural decisions made by a tool that lacks organizational context, strategic awareness, and accountability.

The deterministic/non-deterministic distinction provides a clear decision framework:

• Deterministic work: Delegate to AI with confidence, guided by Skills that encode conventions. Review output against known patterns. Verification is mechanical.
• Non-deterministic work: Use AI as a collaborative partner. Let it surface options and trade-offs. Make the decision yourself. Record it in a DDD. Verification requires judgment.

The Gray Area

Some work falls between the categories. Implementing a caching strategy is partially deterministic (the cache implementation follows known patterns) and partially non-deterministic (which data to cache, for how long, and what invalidation strategy to use are judgment calls).

IFD handles this by separating the decision from the implementation. The non-deterministic part — cache scope, TTL strategy, invalidation approach — is resolved in a design session and recorded in a DDD. The deterministic part — implementing the chosen strategy — is delegated to AI with the decision as context.

This separation is the core operational pattern of IFD: human judgment for decisions, AI execution for implementation, with Skills and documentation bridging the two.

Applying This in Practice

Start by auditing your current AI usage:

1. List the last ten tasks you delegated to an AI coding tool
2. For each, ask: "Given the same inputs and conventions, would any competent developer produce essentially the same output?"
3. If yes, it is deterministic — make sure the conventions are encoded as Skills so the AI has clear guidance
4. If no, it is non-deterministic — the design decision should have been made and captured before AI was asked to implement

This categorization is not a one-time exercise. As your Skills mature and your documentation corpus grows, work that was previously non-deterministic can become deterministic. Once you have decided on an event-driven architecture and encoded the patterns as Skills, creating a new event consumer is deterministic work — the decisions have already been made and documented.

The goal is not to eliminate non-deterministic work. The goal is to make the boundary visible so your team delegates with intention rather than habit.