Four weeks, 1,506 turns, 75 pull requests: what actually sped up

Over about four and a half calendar weeks, one owner and a set of coding agents took a WeChat customer-intake system from nothing to production. The record counts 1,506 conversation turns, 75 pull requests, and at least 61 occasions where the owner corrected the machine. Five versions shipped, then 397 real customer journeys ran through the thing.

By the owner's estimate, the same scope by hand would have taken 14 to 20 engineer-weeks against the 4.7 calendar weeks actually spent: three to four and a half times the throughput. The second number is smaller and more important. His own effective capacity improved by only 1.2 to 1.8 times, and in the pressured stretches it may have got worse.

Everything here is one practitioner's self-report. The production figures come from a live run; the speed-up is an estimate against an imagined baseline; the two are not the same kind of evidence and should not be added together.

What it was for, and what the run produced

The system handles the path after a stranger is added on WeChat: send an invitation, verify that the person really joined a group, keep the record straight when the platform's answer and the real world disagree. The value sits in the intake, not the messaging. No price, contract or buyer appears in the record, so the commercial half of this section is missing — and so are the three maps. No budget line, no approver, no named role that loses anything.

The production run is the evidence that exists. Of 397 journeys, 287 reached the invitation stage, 72.3 percent, and 158 of those joined a group, 55.1 percent — 39.8 percent end to end. Median time from start to group was 13.88 minutes, ninetieth percentile 99.80 minutes. Thirteen of the 158 later left, leaving 145 and a 91.8 percent post-join retention rate.

A non-random comparison is included: 110 people handled manually or by another path reached 9.1 percent group entry, median 164.84 minutes. The owner states plainly that ten people prove nothing causal. That sentence is the most methodological thing in the share.

Where it leaked

Not in money. The record measures journeys and never converts them to revenue.

Of 110 people who never reached an invitation, 99 were deliberately intercepted — duplicates across systems, or already in a group. Eleven were genuine qualification-query failures. Of 287 invitations, 228 were accepted by the platform, but 59 were never actually sent because the friend relationship had lapsed, and nothing retried them. Of the 228 accepted, 158 joined, 53 did not, 17 were still pending.

That last cluster is the leak a dashboard would have hidden. The platform said accepted; the business fact was "not delivered". The system needed a fourth state between intent and outcome before any of it could be counted.

Where the judgement was wrong

Six self-reported errors, and one that is more interesting than the rest.

The ordinary ones: trusting platform documentation and API responses too early; building observability too late; reading an old database and drawing a wrong production conclusion; twice writing configuration that a newer version supported into an older one, causing restart loops.

The interesting one was a feature the owner built and then deleted: an automatic account pause triggered by a failure counter. It counted retries rather than distinct customers, so one unlucky customer could take an account out of service and the blast radius grew instead of shrinking. Deleting it was correct, and the reasoning is the reusable part — the unit of counting decided the behaviour.

The correction with the widest scope was commercial, not technical. Unregistered groups held 83.1 percent of existing member relationships but only 2.3 percent of new traffic in the same period, four of 174. The plan to bring all of them into the system was dropped. The material records version stages rather than week numbers, so the signal is "after the fourth version", not "in week three".

What lived, and what is not yet proven

The final version ran in production for roughly four days. Alive by the available evidence: invitation, join verification, the awaiting-result state, the persistent consumer that replaced the global loop, and the business rule that an order is a trigger rather than a permanent block.

Not alive by the standard this wiki uses. The four-week rule requires four consecutive weeks, and this has about four days. The owner says as much in a sentence worth keeping: a complete FDE-shaped delivery is not yet a proven, repeatable business model. The 91.8 percent retention figure is measured over days, not weeks.

What died

The auto-pause feature, deleted before it could do damage. The plan to import every unregistered group, dropped after the 2.3 percent measurement. The global processing loop, replaced because concurrency broke it. The earlier belief that a platform-accepted invitation was a delivered invitation.

In the language of the six-cause index, the workflow-change and unstable-data types come close without being exact. Most of these died as bad designs caught in the same week — the cheapest kind of death, and the kind a case should report most often.

What the multiplier actually multiplies

Three to four and a half times more code does not mean three to four and a half times more outcome, because the owner is still the only one who can decide. Dividing the share's own totals, 4.7 weeks works out to roughly 320 turns a week, about 16 pull requests to review, and about 13 corrections to make. Those are derived here by division, not reported.

The number that matters for planning is the last one. Sixty-one corrections across 75 pull requests means a correction on roughly four merges in five, and one correction every 25 turns. A schedule built from features rather than from those reviews is promising time the reviewer does not have.

A test before quoting any four-week build: list every decision only you can take — each merge to accept, each ambiguity to resolve, each external system whose behaviour must be established — and put a number per week beside each. If the list runs past what one person can sit through, the bottleneck is not code and more agents will not move it. The honest move is to cut scope until the judgement count fits, or to add a second person who can judge, which is a different hire from a second pair of hands.

Case details come from a public share and have not been independently verified.