built for staff engineers, tech leads, platform teams, and AI-heavy codebases

Your codebase can look stable while losing the ability to survive change.

DST finds the hidden patterns that make software slower, riskier, and harder to evolve — before they become incidents, on-call pain, or permanent architecture debt.

Install / scan a repo See the proof Copy the AI prompt

Most tooling answers: “does it work?” DST asks: “does this change increase or decrease survivability?”

Θ

Real remaining capacity

σ

Stress amplifiers that scale damage

κ

Structural burden, masking, and debt

ρ

Healing structure that restores survivability

Most code reviews ask the wrong question

A feature can pass tests, satisfy the ticket, and still make the system weaker. DST is about measuring whether a change improves the system’s ability to absorb stress — not whether it merely passes locally.

what teams usually ask

Did it work? Did the error disappear? Is the dashboard still green?

works on my machine tests passed looks clean incident delayed

what DST asks instead

Did this change increase or decrease the system’s ability to survive load, failure, latency, scale, and future change?

bounded failure visible error surface stable under scale future maintenance cheaper

The model, in engineer language

DST is not about “clean code.” It is about failure physics. These are the four variables that matter when a codebase is still shipping, still passing checks, and already getting weaker.

Remaining capacity

How much change, load, latency, and complexity the system can still absorb before it becomes brittle.

Stress amplifier

Retry storms, fan-out, unbounded loops, hidden coupling, anything that makes damage scale faster than expected.

Structural burden

Complexity the system carries. Sometimes accidental and toxic. Sometimes intentional and necessary. It still has to be measured.

Healing structure

Boundaries, limits, expiry, observability, fallback paths, and explicit contracts that keep failure bounded instead of contagious.

dΘ/dt = ρ − σ_eff

scanner output preview realistic example

src/payments/retry.tsΘ score 34/100

σ: retry loop against remote dependencyamplifier

κ_a: silent catch + hidden fallbackmasking

ρ missing: timeout, breaker, typed errorfixable

Cap retries at 2 and add jittered backoff
Fail visibly after threshold instead of returning fake success
Protect downstream dependency with breaker + timeout
Raise Θ by reducing repeated damage under partial outage

Who this is for

The page should filter the right people in seconds. DST is not aimed at beginner syntax cleanup. It is for teams shipping real systems under real load.

Staff engineers

Need a sharper way to explain why a “working” change still makes the architecture weaker.

Tech leads

Need a review language that goes beyond style, tests, and surface correctness.

Platform teams

Need a way to rank structural risk, not just collect incident postmortems after the fact.

AI-assisted teams

Need a governor that pushes generated code toward explicit ρ instead of plausible σ.

Same feature. Different physics.

The “before” versions are not bad because they are ugly. They are bad because they quietly reduce Θ. The “after” versions are good because they change failure behavior.

Error handling — silent failure

κ_a accumulated

Without DSTΘ 31/100

async function processPayment(userId, amount) {
  try {
    return await chargeAPI(userId, amount);
  } catch (err) {
    console.error(err);           // κ_a
    return { ok: false };    // fake recovery
  }
}

With DSTΘ 89/100

async function processPayment(userId, amount) {
  const result = await chargeAPI(userId, amount);
  if (!result.ok) {
    logger.error('payment_failed', {
      userId, amount, code: result.errorCode
    });
    throw new PaymentError(result.errorCode);
  }
  return result.data;
}

DST read: the first version delays truth and spreads hidden fragility. The second turns failure into an explicit contract every caller can reason about.

Data fetching — N+1 amplifier

σ amplifier

Without DSTΘ 12/100

async function loadProfiles(ids) {
  const out = [];
  for (const id of ids) {
    out.push(await fetch(`/api/users/${id}`));
  } // scales damage with data size
  return out;
}

With DSTΘ 94/100

async function loadProfiles(ids) {
  if (ids.length === 0) return [];
  const res = await fetch('/api/users/batch', {
    method: 'POST',
    body: JSON.stringify({ ids })
  });
  if (!res.ok) throw new UserFetchError();
  return res.json();
}

DST read: same feature, different scaling law. One version works until traffic makes it catastrophic. The other removes the amplifier entirely.

Caching — optimization that eats the future

σ + κ_a

Without DSTΘ 8/100

const userCache = {};

async function getUser(id) {
  if (userCache[id]) {
    return userCache[id];   // stale forever
  }
  const user = await fetchUser(id);
  userCache[id] = user;      // grows forever
  return user;
}

With DSTΘ 91/100

import LRU from 'lru-cache';

const userCache = new LRU({
  max: 500,
  ttl: 5 * 60_000,
});

async function getUser(id) {
  const cached = userCache.get(id);
  if (cached) return cached;
  const user = await fetchUser(id);
  userCache.set(id, user);
  return user;
}

DST read: this is why green dashboards lie. Response time can stay fast while available memory is being consumed by the architecture itself.

AI default vs AI with a governor

σ → ρ

AI without DSTΘ 11/100

async function callService(data) {
  let retries = 0;
  while (retries < 10) {
    try {
      return await service.call(data);
    } catch {
      retries++;
      await sleep(1000);
    }
  }
}

AI with DST promptΘ 86/100

async function callService(data) {
  if (!circuit.isHealthy()) {
    return { status: 503, retryAfter: circuit.resetIn() };
  }
  try {
    return await circuit.call(() => service.call(data), {
      timeout: 2000
    });
  } catch (err) {
    circuit.recordFailure();
    throw new ServiceError(err);
  }
}

DST read: AI is brilliant at generating plausible completion. That is not the same thing as preserving host capacity, bounding failure, or protecting downstream systems.

How it fits into a real engineering workflow

DST becomes valuable when it stops being an interesting theory and starts acting like a decision layer inside reviews, refactors, and AI-assisted coding.

Scan changes

Flag amplifiers, masking, and hidden structural debt before they are normalized by shipping pressure.

Classify risk

Separate accidental κ from intentional κ. Not all complexity is bad. Some is the price of bounded failure.

Prioritize refactors

Rank work by Θ impact instead of aesthetics. Fix the places where future damage compounds fastest.

Govern AI output

Force generated code to account for bounded failure, visible contracts, and scaling behavior before merge.

Give your AI one job it normally does not have

By default, coding models optimize for completion. DST turns them into governors by forcing classification before implementation.

Use this to push AI away from “make the error disappear” and toward “make the system more survivable.”

Before writing code, classify the change in DST terms. 1. What increases or decreases Θ? 2. Does this add any σ amplifier under load, scale, retries, fan-out, or concurrency? 3. Does it create accidental κ_a through silent failure, hidden mutation, stale caching, or fake recovery? 4. If complexity is added, is it intentional κ_i with an explicit purpose, boundary, and expiry? 5. What ρ exists: timeout, breaker, limit, contract, observability, cleanup, invalidation, fallback? 6. Prefer bounded failure over invisible success. 7. Prefer explicit contracts over hidden behavior. 8. Prefer scaling laws that remain stable as input size grows. Reject changes that merely hide the problem while reducing survivability.

AI can scale good architecture — or scale hidden damage. DST is the difference between a code generator and a system stabilizer.

core claim · use in PR review, architecture review, and AI-assisted coding

If your system is getting weaker while still passing checks, DST is built for that.

Use it to spot structural risk earlier, explain it more clearly, and push both humans and AI toward code that remains survivable under load, failure, and change.

Install the framework Read the theory Read the paper

Measure the system you actually have — not the one your dashboard implies.