LoomCode — Every Function Has an Origin Story

Act I · August 2025

The requirement is born

☎ MeetingAug 4, 10:15 AM

Compliance flags a gap: payment amounts aren't being validated against customer credit limits before charging. Turns out it's also a legal requirement for any app handling payments — something the team only found out about now.

"We need this fixed before the October audit. If we fail, we lose our payment processing license."

📋 JiraAug 5, 2:30 PM

JIRA-2847 is created: "Validate payment amounts against customer credit limits." Acceptance criteria include audit logging, clear error messages, and a 72-hour implementation timeline. The ticket references the compliance meeting notes and links to the legal doc that triggered it.

Act II · August 2025

The code is generated

💬 AI PromptAug 6, 9:45 AM

Developer opens Cursor and types a prompt referencing the Jira ticket:

// Prompt to Cursor:
"Add a validation step before process_payment() that
checks amount against customer.credit_limit.
Raise PaymentExceedsLimitError if exceeded.
Include audit logging per JIRA-2847."

⌨ GeneratedAug 6, 9:46 AM

Cursor generates the function. The developer reviews it, tweaks the logging format, and commits:

def validate_payment_amount(amount, customer):
  # Validate against credit limit
  if amount > customer.credit_limit:
    audit_log("PAYMENT_LIMIT_EXCEEDED", ...)
    raise PaymentExceedsLimitError(...)
  if amount <= 0:
    raise InvalidAmountError(...)
  return True

✓ MergedAug 7, 11:00 AM

PR #412 is reviewed and merged. The commit message says feat: add payment validation. The Jira ticket is closed. The audit passes. Everyone moves on.

Act III · February 2026

Nobody remembers why

📋 JiraFeb 10, 3:20 PM

A new feature request comes in: "Enterprise customers should be able to make payments exceeding their credit limit with manager approval." A new developer is assigned.

⚠ ProblemFeb 11, 10:00 AM

The new developer looks at validate_payment_amount(). Questions pile up:

"Why is there a hard block on exceeding the credit limit? Is this a business rule or a regulatory requirement? Can I add an override parameter, or will that break compliance? Who wrote this? The commit message just says 'add payment validation.' The original developer left the company in November."

Git blame shows a name. The commit message is useless. The Jira ticket is buried. The Cursor prompt is gone forever. The compliance meeting notes were never linked.

💸 CostFeb 11–18

One week is lost. The team spends days reverse-engineering the business logic. They schedule calls with compliance. They dig through Confluence. They eventually track down the original compliance requirement — but only after nearly shipping a version that would have violated it.

"We almost broke our own compliance because nobody could explain eight lines of code."

Act IV · The Rewind

What if you had LoomCode?

🔶 LoomCode30 seconds

The new developer hovers over validate_payment_amount() and sees the full origin story instantly:

📋JIRA-2847 — Legal requirement. Payment apps are required to validate amounts against credit limits before charging. This isn't a product decision — it's the law.

☎️Compliance meeting, Aug 4 — Team flagged this as audit-critical. Failure to comply risks loss of payment processing license.

💬Cursor prompt, Session #412 — Developer explicitly requested hard block (not soft warning) and audit logging. The hard limit was intentional.

⚠️⚠ Cannot add override without compliance review. This is a regulatory constraint, not a business preference.

🔶 Result30 seconds vs. 1 week

The developer immediately understands: this is a regulatory hard block, not a business preference. They propose a new approval flow that maintains the validation but adds a compliance-approved override path. No reverse-engineering. No wasted week. No compliance risk.

What LoomCode Does

Four ways to never lose
the why again.

Whether you're starting a new project or inheriting a vibe-coded codebase, LoomCode keeps the reasoning chain intact.

🔍

Core

Intent Trace

Hover over any function and see the full origin story: which business requirement created it, which prompt generated it, and why specific decisions were made. Works in your IDE, CLI, browser, or via MCP — so any AI agent can query intent directly.

$ loomcode trace validate_payment_amount

🔮

New

Retroactive Spec Generation

Already have a vibe-coded codebase with no specs? LoomCode reverse-engineers intent from your code, prompt history, git log, and business docs — reconstructing the specs that should have existed.

📥

Spec Ingestion

Connect Jira, Confluence, Linear, Notion, or formal spec files from tools like Kiro and SpecKit. LoomCode indexes them as source-of-truth layers — not to author specs, but to link them to your code.

📊

Intent Coverage Map

See which parts of your codebase are traceable back to business requirements — and which are "dark code" with no known justification. Like test coverage, but for why things exist.

62% traced

38% dark

This function was born six months ago.
Nobody remembers why.

The requirement is born

The code is generated

Nobody remembers why

What if you had LoomCode?

Four ways to never lose
the why again.

Intent Trace

Retroactive Spec Generation

Spec Ingestion

Intent Coverage Map

Plugs into the tools
your team already uses.

Code tells you what.
LoomCode tells you why.

Stop losing the thread.

This function was born six months ago.Nobody remembers why.

The requirement is born

The code is generated

Nobody remembers why

What if you had LoomCode?

Four ways to never losethe why again.

Intent Trace

Retroactive Spec Generation

Spec Ingestion

Intent Coverage Map

Plugs into the toolsyour team already uses.

Code tells you what.LoomCode tells you why.

Stop losing the thread.

This function was born six months ago.
Nobody remembers why.

Four ways to never lose
the why again.

Plugs into the tools
your team already uses.

Code tells you what.
LoomCode tells you why.