Coduck logo Coduck
In development

One standard.
Every repository.

Coduck in CI sees what a laptop structurally cannot.

api web payments mobile auth infra

On a laptop

One repo. One diff.

api webpayments mobileauth infrabilling search

In CI

Every repo. Every PR.

apiweb paymentsmobile authinfra billingsearch

What a laptop cannot see

Four things that need the whole org in view.

Architectural guardrails

Declared once. Checked on every repo, every PR.

Cross-repo security

Find the pattern once. Enforce it everywhere.

Blast radius

Know what a contract change breaks downstream.

Duplicate code

Catch the copy living in another repository.


Blast radius

A small diff here. Eleven services there.

The repository making the change cannot see who depends on it. CI can.


PR comments

It asks when it isn’t sure.

A confident wrong comment teaches people to ignore the bot. A question costs ten seconds and sometimes catches the real bug.

src/components/dashboard/progress-widget.tsx
@@ -14,8 +14,8 @@ export function ProgressWidget({ userId }: Props) {
14 const { t } = useTranslation()
15- const { data, isLoading } = useUserProgress(userId)
15+ const data = SAMPLE_TASKS
16+ const isLoading = false
17 if (isLoading) return <Skeleton />
coduck product Question

SAMPLE_TASKS renders for every user here, and isLoading is pinned false so the skeleton never shows. ENG‑482 asks for the signed‑in user’s own progress. Is the endpoint not landed yet?

M
maya commented

/v2/progress ships Thursday, placeholder until then. Follow‑up is ENG‑491.

coduck marked this resolved

Proof, not opinion

It proves the bug before it reports it.

The pipeline already runs your suite. So when coduck is sure, it writes a test that fails on the branch and re‑runs it against the fix. Nothing is reported as a bug unless it can be shown.

progress-widget.test.tsx written by coduck
✗ FAIL on this branch

› renders the signed‑in user’s own progress

expectedtasks for user_8123

receivedSAMPLE_TASKS

✓ PASS after the fix

same test, re‑run once useUserProgress was restored


Domain map

It learns what your system actually does.

Every review reads real code against a real ticket. Run that on every pull request and coduck accumulates something no repository holds in one place: the domains your system is made of, what each one guarantees, and which ones depend on each other.

The rules that live in one senior engineer's head become a thing the next review, the next hire, and the next agent can all read.


$ coduck domain booking
 
BOOKING 31 files · 14 rules
 
what this domain guarantees
• a booking is never created without an availability check
• cancelling releases the slot in the same transaction
• the timezone is stored on the booking, never derived
• a paid booking is only confirmed after the charge settles
 
depends on availability payments notifications
depended on by teams webhooks
 
learned from #10967 #11059 #14740 and 22 more

In your terminal

Ask it before you write the code.

The map is not a wiki nobody updates. It is a command, next to the code, answering from what the reviews actually found.

Every rule says which pull requests taught it, so you can go and read the change it came from rather than take coduck's word for it.


Why it matters

Reviews stop being about the diff alone.

The review knows the rules

A change that breaks an invariant is caught because the invariant is written down, not because a reviewer happened to remember it.

New engineers get the map

The thing that takes six months to learn is a command on day one.

Your agent gets it too

Point Claude or Codex at the same map and it writes against your rules instead of guessing them.

It stays current

Rebuilt from the pull requests as they merge, so it cannot drift the way a wiki does.


For larger teams

Before it goes near your pipeline.

Single sign-on
Audit logs
Compliance reporting
Dedicated support

Built for the org, not the laptop.

The CLI is free and works today. This is what comes next.