Let's tag it as "provisional" then. As in, once you have my provisional trust, accrued over time, I'll probably stop auditing every single line. I'll still look tho.

But the long and short of it is this - XZ utils backdoor actually makes case for trusting clankers more than human collaborators. Clankers are incompetent... they usually aren't Machiavellian.

I've heard it said that an LLM is like a Labrador retriever when it comes to coding. Overly excited, pulls ahead, does some really goofy shit and sometimes chews up your couch (hello Qwen 27B)...but it is trainable.

Human devs are like cats...which is oddly on brand for this project :)

I'd sooner trust a clanker I had prompted with my house style ticket and narrowly sandboxed than a rando online. Of course, the difference is, a rando may eventually earn trust...a clanker doesn't - but it doesn't need to if narrowly scoped.

EDIT: here's a template I use / created for Qwen / Codex. It's...opinionated and bears scars of prior over eager Labradors. This is usually step 1 I fill out. My fingers are going to shit with O/A , so am trying to minimise scut work.

TICKET-Px-SHORT-DESCRIPTIVE-NAME

Status: PROPOSED Timestamp: DD-MM-YY-HH-MM Priority: P0 | P1 | P2 | P3

Purpose

One paragraph:

• what changes
• what does not
• whether this is proposal / proof / implementation

Why this exists

Describe:

• concrete failure mode
• why current behaviour is wrong
• why this is architectural not cosmetic
• why local patches are rejected

Include: We do not want ... We do want ...

Proof requirements before implementation

Hard gate.

Before implementation exists, prove:

• seam exists
• ownership is correct
• contract can be enforced
• no god-object expansion
• no hidden coupling

If proof fails: stop and escalate. Do not patch.

Gates

• Step 0 GO/NO GO
• Step 1 GO/NO GO
• Step 2 GO/NO GO
• Step N GO/NO GO

Each gate:

• exact thing being proven
• explicit stop condition

Test Plan

Mix of:

• unit fixtures
• regression replay
• smoke coverage
• edge cases
• negative cases

Prefer: prove behaviour changed, not just coverage increased.

Definition of Success / PASS

Minimum acceptable state.

Must describe:

• observable outcome
• old failure closed
• contract enforced
• ownership preserved

Definition of Success / EXCELLENT

Stretch target.

Usually:

• generalises across adjacent lanes
• demonstrates reuse
• proves contract not logging theatre

Assumptions

State assumptions explicitly.

Examples:

• baseline already proven
• implementation surface bounded
• no broad whitelist/regex fix

Proposed shape

Describe:

• modules
• packets/cards/contracts
• ownership boundaries
• interfaces

Prefer: small typed objects.

Thin leaf intent

If adding logic:

prefer:

• thin leaf
• compact return object
• narrow ownership

Avoid:

• diagnostic fluff
• local maxima

Policy versus signal

Policy: config

Signal: code

Config controls behaviour. Signal detects reality.

Scope

Explicitly include:

• what this ticket covers

Non-goals

Explicitly exclude:

• unrelated cleanup
• opportunistic refactors
• god-object growth
• broad routing changes

Acceptance criteria

Numbered list.

Must be testable.

Definition of done

Agreement on:

• ownership
• interfaces
• config surface
• enforcement point

Only then may implementation tickets follow.