Let AI ship to your codebase.
Prove every change.

A code factory with a human in the loop

Astutely runs every AI-written change through the same workflow on the coding tool you already use: product spec, technical spec, implementation, review, QA and merge. Every check that ran is recorded, and you approve each phase.

A human gate at every phase, fewer as trust builds

Merges only with proof that the checks ran

One-minute summary at every step

Join early access See how a loop runs

Works with Claude Code, Codex, Cursor, Copilot and OpenCode. Runs on your GitHub repos.

Loop: Send a receipt email after each payment

One-minute summary

Changed · must stay · proved

Waiting for your approval

Changed: receipt email on payment success

Must stay: webhook retries and invoice PDFs

Proved: acceptance criteria before any code

Approve PRD

Why not a rules file?

Guardrails for AI coding agents that check the work

A rules file tells your agent what to do. Astutely checks that it did.

Checks that actually ran

Every change shows which tests and checks ran and what they found, so you are not taking the agent's word for it.

A human at each phase

Approve, or send back with feedback, with a one-minute summary.

Retries with a reason

Attempts are capped. Every retry or timeout shows why.

Same process on any tool

Switch Claude Code, Codex, Cursor, Copilot or OpenCode. Keep the same phases.

The Loop

One workflow for every AI change, from PRD to merge

Each phase leaves a one-minute summary and waits for you. Nothing merges until the checks ran on the exact commit.

01 Product Planning PRD Done
02 Technical Planning RFC Done
03 Implementation Done
04 Review Done
05 Test QA Done
06 Merge Done

AI Human summary Merge · Attempt 1 · 1 min read

Customers get a receipt email right after each successful payment.

In scope: Receipt on payment success, with amount, currency and receipt link
Out of scope: Refund and failed-payment emails, invoice PDF changes
Acceptance checks: 3: one email per payment, currency shown, no duplicate on webhook retry

Assumption Every paying account has a billing email on file.

Send from handlePaymentSuccess, right after recordPayment.

Touches: billing/payments.ts (1 call), new function in emails/send-receipt.ts
Locked decision: Payment handler, not the webhook background job
Named tests: sendReceiptEmail once per payment, formatCurrency
Blast radius: Low. One call site; retries and invoice PDFs untouched

Assumption formatCurrency already supports every billing currency.

sendReceiptEmail is wired into handlePaymentSuccess.

Changed: new sendReceiptEmail in emails/send-receipt.ts, 1 call in billing/payments.ts
Must stay unchanged: webhook retry semantics, invoice PDF generation
Proved: 2 named tests written and passing locally

Open question Answer

Should receipts go to the billing email or the account owner?

Billing email.

You answered: Billing email.

Matches the approved RFC. 1 low comment, nothing blocking.

Invariants: 2 of 2 held, each proved by an existing test
Named tests: 2 of 2 present and passing
Your note: invoice number added to the subject
Comment: subject line can exceed 78 chars (low, style)

Full test suite failed on 09ea1dc: a webhook retry sent a second receipt.

Failing test: webhooks/retry.test.ts:41 retried payment sends one receipt
Passed: lint + typecheck, both named tests
Next: Sent back to Implementation automatically, with the failing test

Requested: fix the failed test.

Failure: webhook retry sent a second receipt on 09ea1dc
Fix: pass paymentId as the mail idempotencyKey
Also: cap the subject at 78 chars (the low review comment)

The fix matches the RFC. Earlier low comment resolved, nothing blocking.

Changed: idempotencyKey on the send, subject capped at 78 chars
Invariants: 2 of 2 still held
Named tests: 2 of 2 present and passing

All 3 acceptance checks pass in a browser run on b21c7e0.

Local runs: 3 of 3 green on b21c7e0
QA scenarios: one email per payment, currency shown, no duplicate on webhook retry
Attempt 1: Full test suite failed on 09ea1dc, fixed in attempt 2

Ready to merge b21c7e0 with CI and QA proof attached.

Approved: PRD, RFC, Review (both attempts), by you
Attempts: Implementation 2 · Review 2 · Test 2 · others 1
Proof: 6 local runs, 3 QA scenarios, CI on b21c7e0

Merged b21c7e0 into main. The intent record is pinned.

Approved: PRD, RFC, Review and Merge, by you
Attempts: Implementation 2 · Review 2 · Test 2 · others 1
Checks that ran: 10, ending green on b21c7e0

Attempt 1 approved 10:31 to 10:33 · Claude Code · claude-sonnet

Iterate

emails/send-receipt.ts:45 Message the agent

Cancel Send back Approve

PRD prd-send-receipt-email.md View full PRD

Goal Customers get a receipt email right after each successful payment.

In scope

Receipt email on payment success
Amount, currency and receipt link

Out of scope

Refund and failed-payment emails
Changes to invoice PDFs

Acceptance checks

AC1 One email per successful payment
AC2 Amount shown in the payment currency
AC3 Webhook retries never send a duplicate

RFC rfc-send-receipt-email.md View full RFC

Approach Call sendReceiptEmail from handlePaymentSuccess right after recordPayment.

Files and functions

billing/payments.ts · handlePaymentSuccess (1 new call)
emails/send-receipt.ts · sendReceiptEmail (new function)

Locked decision Send from the payment handler, not the webhook background job.

Invariants · must stay unchanged

Webhook retry semantics
Invoice PDF generation

Named tests

sendReceiptEmail sends once per payment
formatCurrency formats amount and currency

PR #165 Open in GitHub

feat(notifications): send receipt email after each payment

feat/send-receipt-email → main +11 −1

billing/payments.ts @@ -43,2 +43,2 @@ handlePaymentSuccess

43 43 await recordPayment(event.paymentId);

44 - // receipts were sent by the webhook job

44 + await sendReceiptEmail(event);

emails/send-receipt.ts @@ -40,0 +41,10 @@

41 + export async function sendReceiptEmail(event: Payment) {

42 + await mailer.send({

43 + to: event.billingEmail,

44 + subject: buildReceiptSubject(event),

45 + amount: formatCurrency(event.amount, event.currency),

46 + receiptUrl: event.receiptUrl,

47 + });

48 + }

49 + const buildReceiptSubject = (event: Payment) =>

50 + "Receipt " + event.invoiceNumber + " for your " + event.plan;

PR #165 Open in GitHub

feat(notifications): send receipt email after each payment

feat/send-receipt-email → main +12 −1

billing/payments.ts @@ -43,2 +43,2 @@ handlePaymentSuccess

43 43 await recordPayment(event.paymentId);

44 - // receipts were sent by the webhook job

44 + await sendReceiptEmail(event);

emails/send-receipt.ts @@ -40,0 +41,11 @@

41 + export async function sendReceiptEmail(event: Payment) {

42 + await mailer.send({

43 + to: event.billingEmail,

44 + subject: buildReceiptSubject(event),

45 + idempotencyKey: event.paymentId,

46 + amount: formatCurrency(event.amount, event.currency),

47 + receiptUrl: event.receiptUrl,

48 + });

49 + }

50 + const buildReceiptSubject = (event: Payment) =>

51 + truncate("Receipt " + event.invoiceNumber, 78);

PR #165 Open in GitHub

feat(notifications): send receipt email after each payment

feat/send-receipt-email → main +11 −1

Checked against the approved RFC

Invariants Webhook retries unchanged Invoice PDFs unchanged

Named tests emails/send-receipt.test.ts:9 utils/currency.test.ts:6

billing/payments.ts @@ -43,2 +43,2 @@ handlePaymentSuccess

43 43 await recordPayment(event.paymentId);

44 - // receipts were sent by the webhook job

44 + await sendReceiptEmail(event);

Invariant held

Sent from the payment handler, not the webhook job (locked decision)

webhooks/retry.test.ts:28 passes

emails/send-receipt.ts @@ -40,0 +41,10 @@

41 + export async function sendReceiptEmail(event: Payment) {

42 + await mailer.send({

43 + to: event.billingEmail,

44 + subject: buildReceiptSubject(event),

45 + amount: formatCurrency(event.amount, event.currency),

46 + receiptUrl: event.receiptUrl,

47 + });

48 + }

49 + const buildReceiptSubject = (event: Payment) =>

50 + "Receipt " + event.invoiceNumber + " for your " + event.plan;

LOW Style

Subject exceeds 78 chars

Repro: INV-000123 builds an 84-char subject

PR #165 Open in GitHub

feat(notifications): send receipt email after each payment

feat/send-receipt-email → main +12 −1

Checked against the approved RFC

Invariants Webhook retries unchanged Invoice PDFs unchanged

Named tests emails/send-receipt.test.ts:9 utils/currency.test.ts:6

billing/payments.ts @@ -43,2 +43,2 @@ handlePaymentSuccess

43 43 await recordPayment(event.paymentId);

44 - // receipts were sent by the webhook job

44 + await sendReceiptEmail(event);

Invariant held

Sent from the payment handler, not the webhook job (locked decision)

webhooks/retry.test.ts:28 passes

emails/send-receipt.ts @@ -40,0 +41,11 @@

41 + export async function sendReceiptEmail(event: Payment) {

42 + await mailer.send({

43 + to: event.billingEmail,

44 + subject: buildReceiptSubject(event),

45 + idempotencyKey: event.paymentId,

Comment on this line

You

Keep this key when webhooks retry.

46 + amount: formatCurrency(event.amount, event.currency),

47 + receiptUrl: event.receiptUrl,

48 + });

49 + }

50 + const buildReceiptSubject = (event: Payment) =>

51 + truncate("Receipt " + event.invoiceNumber, 78);

LOW Style

Subject exceeds 78 chars

✓ Resolved in attempt 2

Local run · Run 1 on b21c7e0

Lint + typecheck passed
Named tests passed
Full test suite passed

QA proof · browser scenarios

Your receipt INV-000123

Receipt email

Payment successful Receipt sent

Payment flow

AC1 One email per payment queued ✓ pass
AC2 Currency shown queued ✓ pass
AC3 No duplicate on webhook retry queued ✓ pass

Merge

Waiting for CI on b21c7e0 CI passed on b21c7e0

QA: 3 of 3 scenarios passed View QA proof

Merge method Squash and merge

Approve

Merged with proof · b21c7e0

Intent record

Why: Customers get a receipt email right after each successful payment.
Approved by: Product Planning: You · Technical Planning: You · Review: You · Merge: You
Attempts: Implementation 2 · Review 2 · Test 2 · others 1
Checks that ran: 10 (6 local runs over 2 attempts, 3 QA scenarios, 1 CI run on b21c7e0)

PRD RFC prd-send-receipt-email.md rfc-send-receipt-email.md Download Close

Send a receipt email after each payment

Goal Customers get a receipt email right after each successful payment.

In scope

Receipt email on payment success
Amount, currency and receipt link

Out of scope

Refund and failed-payment emails
Changes to invoice PDFs

Acceptance checks

AC1 One email per successful payment
AC2 Amount shown in the payment currency
AC3 Webhook retries never send a duplicate

Background

Customers ask support for receipts. Today they only get an invoice PDF at month end.

Assumption

Every paying account has a billing email on file.

Send a receipt email after each payment

Approach Call sendReceiptEmail from handlePaymentSuccess right after recordPayment.

Files and functions

billing/payments.ts · handlePaymentSuccess (1 new call)
emails/send-receipt.ts · sendReceiptEmail (new function)

Locked decision Send from the payment handler, not the webhook background job.

Invariants · must stay unchanged

Webhook retry semantics
Invoice PDF generation

Named tests

sendReceiptEmail sends once per payment
formatCurrency formats amount and currency

Rollback

Revert the PR. No data migration and no new config.

Assumption

formatCurrency already supports every billing currency.

09 / 09 Merges only with proof. The why stays attached.

Join early access

Illustrative example. Early access, details may change.

AI made verification the bottleneck

+156.6%

longer wait for a first PR review as teams move to high AI adoption (Faros AI, 2026)

Source

AI increased the capacity to produce change. The next constraint became our ability to verify it.

Spotify Engineering

Across 535K bot and AI diffs at Meta, about 60% were auto-approved, with roughly a third of the revert rate of human diffs.

Meta (RADAR)

PRs up 4x, incidents down 42%, with about 10% of PRs skipping human review.

Imprint (Will Larson)

The teams getting this right earned their way to less review, change by change. Astutely is built to do that on your codebase.

Figures from each source. None of these teams use Astutely.

Control

Approve each phase, then loosen control as trust builds

Gates are on by default and per phase. Approve to move on, or send back with feedback.

Read

A short summary of what the AI did and why. Full detail and attempt history one click away.

Refine

Leave a note on the PRD, RFC, or a line of code, and the AI redoes that phase.

Decide

Approve to move on, or send back with your reason.

What we're building next

Retros that improve your workflow over time
Contract checks that catch drift before merge
Token cost per change, with budgets and alerts
Earned auto-merge and risk-based routing
Incident revert or fix-forward
Per-user keys

Who it's for

Built for engineering teams adopting AI coding

You already use AI to write code, and review cannot keep up. Astutely is for teams of 3 to 50 engineers who want the same process, human gates, and proof on every change.

Accountability

A human stays accountable for every merge

Every change has named approvers per phase, an intent record, and checks that ran on the exact commit.

Know why every change exists

Each change starts from an approved PRD and RFC, and its intent record stays attached after it merges.

See who approved what

Roles decide who can approve each phase, and every decision goes into an audit trail.

Astutely FAQ

Which AI coding tools does it work with?

Claude Code, Codex, Cursor, Copilot and OpenCode. Astutely talks to them through an open interface, so more can plug in.

Do I need a subscription to an AI coding tool?

Yes. Astutely runs on your team's own AI coding tool account and your own GitHub repos. You keep your tool, your model and your provider's terms.

How much does it cost?

Pricing isn't set yet. We're working it out with our first teams. Join early access and you'll hear about it before anyone else.

Will the AI change my code without me knowing?

No. By default every phase waits for a human to approve it before the next one starts. You can send a phase back with feedback. Automatic loosening as trust builds is on the Coming next list.

Where does my code go?

Connects to your GitHub. You choose which repos it can see. Astutely only reads your code while a change runs and never stores it, apart from short excerpts quoted in each change's intent document. Your AI tool's own data terms still apply.

Do I need tests or CI to get started?

No. Without CI, QA relies on the checks your agent can run and a human approves the merge. With CI, Astutely also waits for green CI on the exact commit.

Does Astutely merge on its own?

Only after QA is done and CI is green on the exact commit, and by default a human approves the merge phase.

Is it for solo developers?

You can use it alone, but it's built for teams of 3 to 50 engineers adopting AI coding.

Why not just build my own harness?

You can, and working alone, a few scripts and a rules file may be enough. Astutely covers the process layer that is tedious to maintain: phase gates, proof that checks ran, an intent record with attempt history, and the same workflow across tools. It works with the AI coding tool you already use, so nothing needs rewiring when models change.

Why not just use my AI tool's built-in code review?

Keep using it. Built-in review is good at catching bugs in a diff, and it works fine alongside Astutely. Astutely adds what comes before and after: phase gates from PRD through QA, proof that checks ran, and an audit trail. A human approves each phase. It works across Claude Code, Codex, Cursor, Copilot and OpenCode, so your process stays the same when the tool changes. Astutely does not replace code review.

How is this different from Cursor Projects or Spec Kit?

Those run or scaffold work inside one tool. Astutely adds phase gates, proof that checks ran, and an audit trail across tools.

Does it replace Cursor or Claude Code?

No. You keep the AI coding tool you already use and pay for. Astutely runs on top of it and takes each change through PRD, RFC, implementation, review and QA, with you approving along the way.

What about the PRs already open in my repo?

Astutely works on new changes, from the PRD onward. Your open PRs stay in GitHub as they are. Once your team starts changes in Astutely, each one arrives with its PRD and a one-minute summary.

Join early access

We're shaping Astutely with a few early teams. Join early access and your feedback decides what comes first.

Let AI ship to your codebase. Prove every change.

Guardrails for AI coding agents that check the work

Checks that actually ran

A human at each phase

Retries with a reason

Same process on any tool

One workflow for every AI change, from PRD to merge

AI made verification the bottleneck

Approve each phase, then loosen control as trust builds

Read

Refine

Decide

What we're building next

Built for engineering teams adopting AI coding

A human stays accountable for every merge

Know why every change exists

See who approved what

Astutely FAQ

Join early access

Let AI ship to your codebase.
Prove every change.