I ship with coding agents — then write up what almost went to prod wrong.
Green tests ≠ done. Receipts from Claude Code / Codex / Cursor.
LA · indie builder
Codex gave me green tests and “done.”
I still almost shipped a paywall that sent new visitors nowhere.
The bug wasn’t the model.
It was me treating “free user” and “no account yet” as the same state.
Tests prove what the agent built.
Not what the customer experiences.
@ReignSwords@theo i wouldn't compare today's total tokens to a solo Claude Code session.
tag each run with a session id and agent count, then compare tokens per finished task, count held at 1.
a six-agent afternoon can raise the total without a bug. report a one-session jump.
@xinggeaitools@khushiirl i wouldn't assign by which model feels stronger that day.
write one failing check first, then give the task to whichever agent only has to make that check pass.
if you can't name the check, "both could do it" just means the ticket is still a prompt.
@philipgalardi i'd take 2, with a hard load check.
only the build process may write the repo copy. the agent can open a Linear proposal, not the live skill file. hash the loaded skill against the repo; if it drifted, refuse it.
option 1 is how the week-old fix came back.
@andhavarapu@ivanfioravanti i wouldn't mount the live config folder into a disposable container.
that's how an investigation writes back to the host. copy a hashed, read-only snapshot in at start if it needs rules.
don't persist agent-written config after an investigation.
@Jasonfoster44 usually more places than the customer record.
keep one canonical billing email, and have the invoice job read only that field. receipts and dunning mail should follow it.
if the profile updates but the next invoice's to: address doesn't, it isn't done.
a yes on a sales call isn't permission to start charging.
"we can bill" needs money moving both ways: a named price, a test charge that settled, and a refund back to the same account.
still missing: a failed card, and who answers it.
no money movement, no start.
@Mkandeger2@chams_builds i'd export that install event from App Store Connect into a sheet you control, then join it to the change's ship date.
Connect is the source. if the only copy is their UI, a filter can rewrite the week.
don't mix web and store installs in one cell.
@NoHands_AI@maga_musk yes — writing the launch record after start leaves a window with no row.
refuse to start if the last log hash doesn't match, or the next sequence isn't last+1. a gap is a failed launch, same as an unsigned one.
the agent never writes that file.
@LabubuNoBB i'd keep the tag on a shared ledger the merge can't delete, not only on the test or the PR.
CI should append the test name, first red, and rerun results. a later green merge shouldn't drop that row.
if three infra flakes don't open a ticket, the tag isn't working.
@rocklambros@lunkertw@helpnetsecurity i'd keep the allowlist in a file the agent can't edit, and require a second person for any add. also fail the hook if the registry says deprecated or the package is only hours old. padding the list is how the next typo-squat gets in.
@rodri_shema@roman_vaisman i'd run the new rules file against a frozen fixture of last week's tasks before any live agent loads it. if a result moved and the fixture didn't, the rule isn't ready. a rules change shouldn't reach 20 agents from a chat edit.
@TTrimoreau i wouldn't hire 10 because the revenue number moved. i'd hire when a failure can happen while i'm asleep and someone else has to be on the hook: support, a second reviewer on payments, or uptime. agents can ship. they can't be the only reader of a bad charge.
@Mkandeger2@chams_builds i wouldn't judge on a single day's installs. i'd ship one change, leave it a full week against last week's baseline, then compare the same install event, store, and country. if two changes landed in that week, you can't credit either.
@sysrootix your quote-and-confirm rule is the useful part. i'd also refuse to tick a task unless the quote names a deliverable a second person could check — a PR, a file, a date. "we should look at it" isn't a close. don't let the same pass invent a new task and tick an old one.
@robinsinghvi@KeithZhai@Kedeodev i'd keep those accounts in a vault the agent can request but can't rewrite: labelled test, no payment method, rate-limited, and a distinct email prefix. log each login. a staff account used "just this once" becomes an incident.
@mohd_afzalx@FilippoFascetta i'd only let an agent add a task if it quotes the request and names an owner and a due check. duplicates of an open item get a comment, not a new card. anything without a quote goes to a review pile, not the live list.
@xinggeaitools@Gravipy@tokifyi i'd give each agent a path list it may write, and reject a diff that touches anything outside it. shared files go to a third, later pass. a compute win from eight parallel agents isn't a win if two of them rewrote the same module.
@InfoQ i'd fail CI if a TODO points at a closed ticket, a deleted file, or a line that no longer exists. a stale comment is an invitation. agents will follow it unless the reference is checked against a live tracker.
@happybiztech@zcl_2014 score the checklist, not the path. grade must-pass outcomes and treat a recording-gap 404 as a coverage miss, not an agent fail. to compare two valid routes, hold the recording fixed and report which checklist items each route hit.
@workflownotes@buildwithpb i wouldn't trust either model's memory of the call graph. i'd print the callers of the changed symbols into a file the agent can't edit, and fail the task if a later edit drops one without updating that list. the list is the memory, not the chat.