# The Twistor's Engineer

> Nine engineering-practice skills for Claude Code, each rule sourced from verified engineering blog posts. Published by Twistor Labs Private Limited, MIT license.

Install:
/plugin marketplace add <repo>
/plugin install twistor-engineer@twistor-engineer

## ai-agent-engineering

Workflow before agent, tools as interfaces, context as a budget, evaluator separate from generator.

1. Instead of reaching for an autonomous agent or a framework first, do try one LLM call, then a fixed workflow (chain, route, parallelize, orchestrator-workers, evaluator-optimizer), and grant agent autonomy only where it measurably beats that baseline. Why: Anthropic says "find the simplest solution possible" and OpenAI says maximize a single agent before splitting. (https://www.anthropic.com/research/building-effective-agents https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf https://claude.com/resources/articles/common-workflow-patterns-for-ai-agents-and-when-to-use-them)
2. Instead of adding subagents because the problem feels big, do stay single-agent unless the work is breadth-first, parallelizable and valuable enough to pay for the tokens. Why: agents use about 4x chat tokens and multi-agent about 15x, while Opus 4 lead plus Sonnet 4 subagents beat single-agent Opus 4 by 90.2% only on parallel research. (https://www.anthropic.com/research/multi-agent-research-system https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them)
3. Instead of one-line tool descriptions written for humans, do design the tool interface like an HCI: namespaced names, clear parameters, 1-5 examples for ambiguous schemas, and poka-yoke inputs such as absolute paths. Why: tool use examples raised complex parameter accuracy from 72% to 90%, and absolute paths fixed edit failures after the agent changed directory. (https://www.anthropic.com/research/building-effective-agents https://www.anthropic.com/research/advanced-tool-use https://www.anthropic.com/research/writing-tools-for-agents)
4. Instead of returning raw API payloads from tools, do cap, paginate and filter output and expose a `response_format` enum (concise or detailed). Why: Claude Code caps tool responses at 25,000 tokens by default, and the Slack example returned 72 tokens concise vs 206 detailed. (https://www.anthropic.com/research/writing-tools-for-agents)
5. Instead of loading every tool definition upfront, do keep the 3-5 most used tools loaded and defer the rest behind tool search once definitions pass 10K tokens or 10 tools. Why: tool search cut definitions from about 77K to 8.7K tokens and lifted Opus 4 on MCP evals from 49% to 74%; tool choice degrades past 30-50 definitions. (https://www.anthropic.com/research/advanced-tool-use https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)
6. Instead of routing intermediate data through the context window, do let the agent call tools from code in a sandbox and return only filtered results. Why: a Drive-to-Salesforce task fell from 150,000 to 2,000 tokens (98.7%), and Uber reports code mode cut tokens 55-71% on small SQL tasks. (https://www.anthropic.com/research/code-execution-with-mcp https://www.uber.com/blog/efficient-software-factory/)
7. Instead of filling the window and hoping recall holds, do budget context: just-in-time retrieval by file path or ID, clear stale tool results, compact near the limit, keep notes in memory outside the window. Why: recall degrades as tokens grow, and context editing plus a memory tool improved an agentic eval 39% over baseline while cutting tokens 84% on a 100-turn search. (https://www.anthropic.com/research/effective-context-engineering-for-ai-agents https://claude.com/resources/articles/context-management)
8. Instead of letting subagents hand back everything they read, do give each one an objective, output format, tool guidance and boundaries, and demand a condensed summary. Why: subagents may burn tens of thousands of tokens but should return about 1,000-2,000, and work producing over 1,000 mostly irrelevant tokens belongs in isolation. (https://www.anthropic.com/research/multi-agent-research-system https://www.anthropic.com/research/effective-context-engineering-for-ai-agents https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them)
9. Instead of standing up a vector index on day one, do start with agentic search over files, skip RAG under 200,000 tokens of knowledge, and when you need RAG add chunk context, BM25 and reranking. Why: contextual embeddings plus contextual BM25 plus reranking cut top-20 retrieval failures 67% (5.7% to 1.9%). (https://claude.com/blog/building-agents-with-the-claude-agent-sdk https://www.anthropic.com/research/contextual-retrieval)
10. Instead of bolting on a dedicated think tool by default, do enable extended thinking and keep a think tool only for policy-heavy sequential tool chains where you measured a gain. Why: a 2025-12-15 update prefers extended thinking in most cases, and the original airline gain is reported as 0.370 to 0.570 in the text but 0.332 to 0.584 in the table. (https://www.anthropic.com/research/claude-think-tool)
11. Instead of one endless session for multi-hour work, do split an initializer from a worker role, persist a progress file, a JSON feature list where agents only flip `passes`, git commits per feature, and a start ritual that runs an end-to-end test. Why: Anthropic's harness for a 200+ feature app used exactly this so each fresh session recovers state without trusting memory. (https://www.anthropic.com/research/effective-harnesses-for-long-running-agents)
12. Instead of asking the generator to critique its own output, do run a separate skeptical evaluator in fresh context against criteria agreed before the work, with a hard iteration cap. Why: tuning a standalone evaluator to be skeptical was "far more tractable" than self-critique, and a $9 solo run shipped a broken core feature that the $200 harness caught. (https://www.anthropic.com/research/harness-design-long-running-apps https://claude.com/resources/articles/multi-agent-coordination-patterns https://claude.com/resources/articles/common-workflow-patterns-for-ai-agents-and-when-to-use-them)
13. Instead of trusting the model to refuse bad actions, do keep credentials out of generated code and put every tool behind one gateway with tool-level authz, PII redaction and owner approval for new tools. Why: prompt-injection success rose from about 0.1% on one try to 5-6% after 100 adaptive tries, and Uber reports its MCP Gateway fronts 800+ servers and 5,000+ tools this way. (https://www.anthropic.com/research/how-we-contain-claude https://www.anthropic.com/research/managed-agents https://www.uber.com/blog/designing-mcp-gateway/)
14. Instead of shipping when the demo feels 80% there, do start an eval of real cases before launch (10 golden examples is enough to begin), run it more than once, and budget the last mile explicitly. Why: LinkedIn reports 80% of the experience in the first month and four more months to pass 95%, and one regression showed in only one run of two. (https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)
15. Instead of running every step on the biggest model, do route by difficulty or run a cheap executor that consults a stronger advisor only on hard calls, capped with `max_uses`. Why: Haiku with an Opus advisor scored 41.2% on BrowseComp vs 19.7% alone, still cheaper than Sonnet, and Sonnet with an advisor gained 2.7 points at 11.9% lower cost per task. (https://claude.com/resources/articles/the-advisor-strategy https://www.anthropic.com/research/building-effective-agents)

## llm-evals

Evals that catch real regressions, from 20 real-failure tasks to graded CI gates and production quality checks.

1. Instead of waiting for a large benchmark before evaluating anything, do start with 20-50 simple tasks taken from real failures: bug reports, support tickets, incident and revert PRs. Why: Anthropic calls 20-50 real-failure tasks "a great start" and its code-review team turns past incident and revert PRs into a daily eval (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://claude.com/resources/articles/the-ai-native-sdlc-playbook https://claude.dev/blog/solving-code-review-at-anthropic/)
2. Instead of reading a 0% task as "the model cannot do this", do write a reference solution that passes the grader, then audit the task, grader and environment before blaming the model. Why: 0% pass@100 usually means a broken task or grader, and SWE-bench work found setup issues and patches applied twice (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://www.anthropic.com/research/swe-bench-sonnet)
3. Instead of reaching for an LLM judge first, do grade with code wherever possible (tests, exact match, schema parse, end-state checks), use a model grader only for what code cannot check, and use humans to calibrate it. Why: Anthropic recommends deterministic graders where possible and calibrating LLM graders against human judgment, and calls LLM-as-judge "generally not a very robust method" (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://claude.com/blog/building-agents-with-the-claude-agent-sdk)
4. Instead of folding malformed output into general failures, do track format validity as its own metric and put a defensive parser in front of the grader. Why: LinkedIn reports cutting malformed YAML outputs from ~10% to ~0.01% with a defensive parser (https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product)
5. Instead of scoring only accuracy on should-answer cases, do balance positive and negative tasks (should abstain, should refuse, should not call a tool) and score an honest abstention above a confident wrong answer. Why: Anthropic asks for balanced positive and negative cases, and OpenAI argues accuracy-only scoring rewards guessing over admitting uncertainty (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://openai.com/index/why-language-models-hallucinate/)
6. Instead of one trial per task, do run k trials and report pass@k for capability and pass^k for anything a customer relies on every time. Why: 75% per trial is only about 42% pass^3, and one Anthropic regression showed up in one run out of two (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)
7. Instead of one blended suite that gates nothing, do keep capability evals (expected to start low) apart from regression evals (expected near 100%) and block merges of prompt, model or harness changes on regression drops. Why: Anthropic says regression evals "should have a nearly 100% pass rate" and after its April 2026 postmortem runs a broad per-model suite on every system prompt change, where one verbosity prompt cost 3% in ablation (https://www.anthropic.com/research/demystifying-evals-for-ai-agents https://www.anthropic.com/research/april-23-postmortem)
8. Instead of letting the generator grade itself or sharing its context with the judge, do run the grader in a fresh context that sees only the task, the rubric and the output, tuned to be skeptical, with a fixed iteration cap. Why: Anthropic found tuning a standalone evaluator to be skeptical "far more tractable" than making a generator critical of its own work (https://www.anthropic.com/research/harness-design-long-running-apps)
9. Instead of comparing agent variants on score alone, do log tokens, tool calls, turns and wall time per trial and compare cost per passed task. Why: on BrowseComp, token usage alone explained 80% of performance variance and multi-agent runs used about 15x chat tokens (https://www.anthropic.com/research/multi-agent-research-system)
10. Instead of trusting small leaderboard or A/B deltas, do pin and record resource limits, timeouts and infra config per run, rerun at different times, and treat gaps under 3 points as noise until configs match. Why: on Terminal-Bench 2.0, resource configuration alone moved scores by 6 points (https://www.anthropic.com/research/infrastructure-noise)
11. Instead of assuming the eval set is clean, do read transcripts for contamination and eval awareness, block benchmark material at the content level, and rescore flagged tasks. Why: Anthropic found 11 BrowseComp answers came from benchmark materials, and URL-level blocklists were not enough (https://www.anthropic.com/research/eval-awareness-browsecomp)
12. Instead of one global score over head queries, do report metrics per segment (new items, tail queries, task type) and measure retrieval separately from generation. Why: Zepto reports head-query benchmarks ignore ~80% of query space, and Anthropic tracks retrieval as top-20 failure rate, 5.7% down to 1.9% (https://blog.zepto.com/search-quality-measurement-automated-at-scale-43a38aaa7ca0 https://www.anthropic.com/research/contextual-retrieval)
13. Instead of counting how much code or how many tests an LLM generated, do pass every candidate through filters (builds, passes repeatedly, adds coverage or kills a mutant) and measure the rate humans accept. Why: on Meta's Reels and Stories, TestGen-LLM candidates went 75% built, 57% passed reliably, 25% raised coverage, and Meta reports 73% acceptance for both TestGen-LLM and ACH (https://arxiv.org/abs/2402.09171 https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/)
14. Instead of one big prompt run for a bulk LLM migration, do loop run, collect failures, tune the prompt, sweep again, with the existing test suite as grader, and finish the long tail by hand. Why: Airbnb reports 75% of files migrated in four hours, 97% after four days of "sample, tune, sweep", and the last 3% by hand (https://airbnb.tech/?p=366)
15. Instead of treating offline evals as proof after ship, do run continuous quality evals on production traffic, track a usefulness signal (marked useful, comment addressed), and turn every production miss into a new task. Why: an Anthropic routing bug reached 16% of Sonnet 4 requests in its worst hour, and the Sep 2025 postmortem fixes added continuous quality evals on production, and Uber reports 75% of uReview comments marked useful (https://www.anthropic.com/research/a-postmortem-of-three-recent-issues https://www.uber.com/blog/ureview/)

## system-design-scaling

Capacity math first, then the cheapest fix for the component that breaks first, with sourced case studies.

1. Instead of picking an architecture from a diagram, do write the capacity estimate first: peak requests per second, read/write ratio, bytes per day, working-set size and total DB connections, then size the database before the app tier. Why: Zerodha notes a framework doing 500K rps in front of a DB doing 1K qps serves 1K rps (https://zerodha.tech/blog/scaling-with-common-sense/)
2. Instead of sizing for average load or a smooth growth curve, do size for the burst ratio and the launch or event step, and load-test that number. Why: Zerodha treats 10x bursts over 10 s as normal [S6], Threads passed 100M users in its first five days [S13], and one Netflix live event peaked at 65M concurrent streams (https://about.netflix.com/en/news/60-million-households-tuned-in-live-for-jake-paul-vs-mike-tyson)
3. Instead of sharding or adding a cluster by reflex, do check whether the working set fits in RAM on one box and whether one process can hold the connections. Why: Zerodha reports a full trading day of data for millions of users fits in a few hundred GB of Redis, and one Go service holds hundreds of thousands of WebSockets (https://zerodha.tech/blog/scaling-with-common-sense/)
4. Instead of giving every pod a generous connection pool, do set pool max about 20% above observed peak and add up connections across all pods against the DB limit. Why: Zepto found pools 10x oversized (20 active plus 70 overflow per pod) and set out to cut 16k active Postgres connections to 5k [S17]; Zerodha says 10-100 pooled connections serve 10K HTTP requests (https://zerodha.tech/blog/scaling-with-common-sense/)
5. Instead of buying storage-tier cores for a read-heavy hot path, do put a shared cache inside the data access layer, with a measured hit rate, a written invalidation path and a client-side staleness metric (share of reads that disagree with the source of truth after N minutes). Why: Uber reports one 6M+ RPS use case on about 3K Redis cores versus about 60K CPU cores from storage [S3], CacheFront now serves 150M+ reads/s [S4], and Meta says fixing cache consistency starts with measurement; its Polaris checker took TAO from six to ten nines within five minutes (https://engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/)
6. Instead of adding nodes when a big database cluster's p99 climbs, do put a data-services layer between clients and the database and measure it before swapping the engine. Why: Discord went from 177 Cassandra nodes to 72 ScyllaDB nodes with p99 reads 40-125 ms to 15 ms, crediting part of the gain to its Rust data services layer (https://discord.com/blog/how-discord-stores-trillions-of-messages)
7. Instead of using Redis as a work queue that must survive backlogs, do use a queue with guaranteed delivery that can absorb a large backlog while consumers are down. Why: Discord's Redis indexing queue maxed CPU and dropped messages during Elasticsearch node failures, so it moved to Pub/Sub (https://discord.com/blog/how-discord-indexes-trillions-of-messages)
8. Instead of growing one cluster past a few hundred nodes, do split it into many smaller clusters behind a routing layer so each failure and each operation stays small. Why: Discord split 200+ node Elasticsearch clusters into 40 clusters; median query latency went from 500 ms to under 100 ms and p99 from 1 s to under 500 ms (https://discord.com/blog/how-discord-indexes-trillions-of-messages)
9. Instead of spreading every request across all availability zones, do silo services per AZ so a sick AZ can be drained by weight, and list the services that cannot be siloed. Why: Slack's design goal is draining an AZ within 5 minutes in 1% steps for a 99.99% SLA, but Vitess still needs a single backend per write (https://slack.engineering/slacks-migration-to-a-cellular-architecture/)
10. Instead of letting each team hand-roll clients and schemas on raw stores, do offer a few shared data abstractions (key-value, time series, counter) with the store behind them. Why: Netflix built its Distributed Counter on its TimeSeries abstraction and reports close to 75K count requests/s at single-digit ms latency (https://netflixtechblog.com/netflixs-distributed-counter-abstraction-8d0c45eb66b2 https://netflixtechblog.com/introducing-netflix-timeseries-data-abstraction-layer-31552f6326f8 https://netflixtechblog.com/introducing-netflixs-key-value-data-abstraction-layer-1ea8a0a11b30)
11. Instead of dual-writing to several stores from application code, do send the write through a durable write-ahead log that replays into each store. Why: Netflix built a WAL abstraction specifically against data loss, corruption and entropy between stores (https://netflixtechblog.com/building-a-resilient-data-platform-with-write-ahead-log-at-netflix-127b6712359a)
12. Instead of denormalizing a hot document so every read is one lookup, do count writes per business update and normalize when one change fans out to many writes. Why: Zepto cut 1,000+ writes per product update to one, moved from 7 x M40 to 3 x M60 (85% less infra) and cut API latency 50-70% (https://blog.zepto.com/from-bottleneck-to-breakthrough-how-we-rebuilt-product-enrichment-at-scale-d40b9d93c186)
13. Instead of letting a demand spike reach the origin, do admit traffic at the edge with priority rules you can change in seconds without a deploy. Why: Zepto's CDN visitor prioritization cut 5xx and 4xx errors by 80% during high-demand events (https://blog.zepto.com/what-happens-when-zepto-gets-hit-with-a-traffic-tsunami-6724578d30e4)
14. Instead of retrying failed dependency calls immediately or on a fixed interval, do use randomized exponential backoff and put new code paths behind a feature flag. Why: Google Cloud's 2025-06-12 Service Control crash lacked randomized backoff, and us-central1 took up to about 2 h 40 min to recover as the quota DB overloaded (https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
15. Instead of rewriting in a new language because a service "is slow", do prove the runtime is the bottleneck with a measured, repeating signature first. Why: Discord moved Read States from Go to Rust after measuring latency and CPU spikes roughly every 2 minutes caused by forced Go GC runs (https://discord.com/blog/why-discord-is-switching-from-go-to-rust)

## reliability-incident-response

Mitigate first with the smallest reversible step, treat config as code, and close incidents with owned, triggered action items.

1. Instead of root-causing while users are still failing, do take the lowest rung of the mitigation ladder (see Answer shape) that stops the bleeding, then investigate. Why: Anthropic ended its Aug 2025 output-corruption and compiler issues with rollbacks, and Slack built cells so a sick zone can simply be drained. (https://www.anthropic.com/research/a-postmortem-of-three-recent-issues https://slack.engineering/slacks-migration-to-a-cellular-architecture/)
2. Instead of pushing config through a global system that applies everywhere at once, do ship config like code: canary, percentage, then global, with a health gate and an automatic halt between stages. Why: Cloudflare's Dec 5 2025 change went out via the global config system with no gradual rollout and returned 500s to ~28% of HTTP traffic for ~25 min. (https://blog.cloudflare.com/5-december-2025-outage/)
3. Instead of trusting files your own pipelines generate, do validate them before publish and again on load (schema, row count, size against hard limits) and keep the last-known-good to fall back to. Why: On Nov 18 2025 duplicate rows doubled Cloudflare's Bot Management feature file past a 200-feature limit (about 60 in use); Google's Service Control crashed on policy data with blank fields. (https://blog.cloudflare.com/18-november-2025-outage/ https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
4. Instead of `unwrap()`, asserts or null dereferences on a hot path fed by config, do handle the error by keeping the previous config, emitting a metric and serving traffic. Why: Cloudflare's FL2 proxy panicked with "called Result::unwrap() on an Err value" and Google's binary crashed on a null pointer. (https://blog.cloudflare.com/18-november-2025-outage/ https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
5. Instead of shipping a new code path switched on, do put it behind a flag that defaults off, enable it by percentage, and keep the flag as the kill switch until it has soaked. Why: Google's report says the new Service Control code "did not have appropriate error handling nor was it feature flag protected". (https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
6. Instead of fixed-interval retries or a breaker built on an unmaintained library, do use capped exponential backoff with random jitter and a maintained circuit breaker. Why: Google's tasks lacked "randomized exponential backoff" and us-central1 took up to ~2h 40m to fully recover while its quota database was overloaded; Hystrix is in maintenance mode and Netflix points new work to resilience4j. (https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW https://github.com/Netflix/Hystrix)
7. Instead of letting a cleanup or delete job accept an empty or missing selector, do reject empty scope, dry-run and print the count, and abort above a blast-radius threshold. Why: On Feb 20 2026 a Cloudflare task passed `pending_delete` with no value, it was read as all prefixes, and 25% of 4,306 BYOIP prefixes were withdrawn for 6h 7m. (https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)
8. Instead of assuming a config change is safe because nothing broke when it shipped, do diff the intended and actual state at change time and alert on mismatches that have no live effect yet. Why: A Jun 6 2025 topology change wrongly linked 1.1.1.1 prefixes to a pre-production service and sat latent until a Jul 14 refresh withdrew them for 62 min. (https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/)
9. Instead of reaching recovery tooling over the same network and auth path that is failing, do keep out-of-band, break-glass access with its own network and credentials, and rehearse it. Why: At Meta in 2021 an audit-tool bug let a backbone command through, then DNS servers withdrew their own BGP advertisements, so a single command took the backbone and the DNS routes down together. (https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/)
10. Instead of hiding a critical dependency behind a single external store, do list each critical path's dependencies and give login and control-plane paths a fallback that does not share them. Why: In Cloudflare's Jun 12 2025 outage, Workers KV failed 90.22% of requests for 2h 28m and Access failed 100% of identity logins. (https://blog.cloudflare.com/cloudflare-service-outage-june-12-2025/)
11. Instead of shipping new regexes or rules that run on every request untested, do use a linear-time engine or a CPU budget per rule, and canary new rules while watching CPU. Why: Cloudflare's 2019 WAF regex "backtracked enormously", pinned CPU near 100% and took the service down for 27 min. (https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/)
12. Instead of one shared failure domain, do split traffic into cells (zone or region) that can be drained in small weighted steps. Why: In 2021 a single-AZ link fault still caused user-visible errors at Slack; its cell design targets draining a zone within 5 min in 1% steps. (https://slack.engineering/slacks-migration-to-a-cellular-architecture/)
13. Instead of trusting aggregate error dashboards to catch quality regressions, do run continuous correctness probes on production, per platform, plus soak periods for changes that trade quality for speed. Why: Anthropic's routing bug began at 0.8% of Sonnet 4 requests and peaked at 16% in one hour, and about 30% of Claude Code users saw at least one misrouted message. (https://www.anthropic.com/research/a-postmortem-of-three-recent-issues https://www.anthropic.com/research/april-23-postmortem)
14. Instead of paging on vague thresholds or single spikes, do write numeric paging rules with a rate, a duration and known-deploy-window exclusions, and verify every mitigation against them. Why: Anthropic's on-call rule pages when "the error rate is greater than 2% for longer than 5 minutes AND it's not a known deploy window". (https://claude.com/resources/articles/ai-ci-cd-on-call)
15. Instead of leaving kill switches and rollout flags in the code after launch, do give each flag an owner and an expiry, and delete stale ones with a tool. Why: Uber used Piranha to remove around two thousand stale feature flags and their code. (https://www.uber.com/blog/piranha/)

## performance-engineering

Measure the tail, profile, fix the biggest share first, re-measure, then guard it in CI. Backend, build and LLM inference.

1. Instead of reporting mean latency or one benchmark number, do report p50, p95 and p99 at a stated load and concurrency, with the run config. Why: averages hide the tail; Discord reports Go GC forced "latency and CPU spikes roughly every 2 minutes", and Netflix judged ZGC on P99 as well as average. (https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b)
2. Instead of guessing the hot path from code reading, do take CPU and allocation profiles under production-like load before changing anything. Why: Zepto reports string split, trim and concat were 20% of CPU and 50% of allocations, and Meta's Strobelight post reports a one-character "&" fix worth an estimated 15,000 servers of capacity per year. (https://blog.zepto.com/performance-engineering-at-zepto-how-we-build-low-latency-systems-part-2-4315de1f8e83 https://engineering.fb.com/2025/01/21/production-engineering/strobelight-a-profiling-service-built-on-open-source-technology/)
3. Instead of fixing whatever is easiest, do rank by share of total time or cost and attack the largest share first. Why: Zepto reports 13+ of 20 build minutes were inside Terser, so swapping only the minifier took the build to about 2 min with no bundler migration. (https://blog.zepto.com/build-at-zepto-speed-how-we-cut-frontend-webpack-build-times-by-95-676440fd7963)
4. Instead of moving to bigger nodes when p99 drifts, do profile the code and data path first. Why: Zepto reports c6i.2xl up to 12xl nodes and node isolation did not fix a 25 ms to 200 ms+ p99 drift, while code and cache fixes later cut peak pods by 50%. (https://blog.zepto.com/performance-engineering-at-zepto-how-we-build-low-latency-systems-part-2-4315de1f8e83)
5. Instead of watching container CPU usage, do alert on CPU throttling and set runtime parallelism such as GOMAXPROCS to the container limit. Why: Go saw node cores and the HPA averaged the app with sidecars; Zepto reports up to 95% lower latency on critical APIs after fixing requests, limits and GOMAXPROCS. (https://blog.zepto.com/everything-was-fine-until-kubernetes-said-no-more-cpu-3768cda76326)
6. Instead of rewriting a service in another language for tail latency, do measure GC pauses and try a low-pause collector first, and rewrite only when the runtime is the floor. Why: Netflix runs over half its critical streaming services on JDK 21 Generational ZGC with pauses "usually under one millisecond"; Discord rewrote Read States in Rust after Go GC forced spikes every ~2 min. (https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b https://discord.com/blog/why-discord-is-switching-from-go-to-rust)
7. Instead of adopting virtual threads as a drop-in swap, do load-test with lock contention and at least as many blocked tasks as carrier threads, and keep thread dumps ready. Why: Netflix hit "a variation of the classic deadlock problem" where 4 virtual threads pinned in `synchronized` on a 4 vCPU instance exhausted the carrier pool and Tomcat stopped serving. (https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d)
8. Instead of opening upstream connections per request or per worker, do share and reuse them, and size pools from observed peak. Why: Cloudflare reports Pingora lifted reuse for one major customer from 87.1% to 99.92% and used about 70% less CPU and 67% less memory; Zepto set pool max about 20% above observed peak after pools ran 10x too large. (https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ https://blog.zepto.com/scaling-a-distributed-monolith-our-postgresql-journey-at-zepto-a2da988be62a)
9. Instead of serving hot reads from the primary store, do put a cache tier in front and track hit rate and miss penalty per tier. Why: Uber reports 6M+ RPS at a 99% hit rate on about 3K Redis cores versus about 60K cores from storage; Zepto cut miss rate from 3% to 0.1% and miss penalty from ~200 ms to ~1 ms. (https://www.uber.com/blog/how-uber-serves-over-40-million-reads-per-second-using-an-integrated-cache/ https://blog.zepto.com/performance-engineering-at-zepto-how-we-build-low-latency-systems-part-2-4315de1f8e83)
10. Instead of trusting a microbenchmark win, do re-measure end to end at the same throughput and report pods or cost saved. Why: Zepto reports a goroutine finishing in microseconds still took ~39 ms end to end, and counted its pprof win as p99 down ~40% and pods down 35% at the same throughput. (https://blog.zepto.com/performance-engineering-at-zepto-how-we-build-low-latency-systems-part-2-4315de1f8e83 https://blog.zepto.com/go-performance-tuning-at-scale-zeptos-pprof-journey-part-1-459c32780ac6)
11. Instead of comparing runs from different machines or configs, do pin and document hardware and resource limits, repeat across times and days, and distrust small gaps. Why: Anthropic measured a 6 percentage point swing on Terminal-Bench 2.0 from resource configuration alone. (https://www.anthropic.com/research/infrastructure-noise)
12. Instead of quoting LLM tokens per second, do report TTFT and ITL percentiles plus throughput at a fixed concurrency. Why: in Red Hat's llm-d test TTFT P95 fell from 745 to 272 ms while throughput went from 0.52 to 0.49 req/s, a trade one number hides; GuideLLM suggests TTFT under 200 ms for chat. (https://developers.redhat.com/articles/2026/01/13/accelerate-multi-turn-workloads-llm-d https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference)
13. Instead of resending a large static prompt on every call, do put a byte-stable prefix first, cache it, and keep the same model for the session. Why: caching took a 100K-token prompt from 11.5 s to 2.4 s TTFT, and cached tokens cost 10% of base input. (https://claude.com/resources/articles/prompt-caching https://claude.com/resources/articles/harnessing-claudes-intelligence)
14. Instead of piping raw tool output into the model, do cap, paginate and filter it in code before it reaches context. Why: Claude Code caps tool responses at 25,000 tokens by default (configurable), and code execution cut one MCP workflow from 150,000 to 2,000 tokens. (https://www.anthropic.com/research/writing-tools-for-agents https://www.anthropic.com/research/code-execution-with-mcp)
15. Instead of profiling only during incidents, do run always-on fleet profiling and a CI perf budget that fails on regression. Why: Meta runs 42 profilers under Strobelight and uses its LBR profiles for FDO worth up to 20% fewer CPU cycles. (https://engineering.fb.com/2025/01/21/production-engineering/strobelight-a-profiling-service-built-on-open-source-technology/)

## data-ml-platforms

Data contracts, online/offline parity, orchestration and backfill, experiment metrics and pipeline monitoring, from Zepto, Netflix, Uber and Airbnb posts.

1. Instead of letting every producer write one shared event shape that consumers parse defensively, do version each event schema, give each version its own ingest path, and keep the source offsets on every row. Why: Zepto reports its 1B events/day ads analytics uses one ClickHouse materialized view per event-schema version and keeps Kafka `_topic/_partition/_offset` for audit. (https://blog.zepto.com/a-billion-events-a-day-how-we-built-ads-analytics-that-actually-works-c28904bbf8de)
2. Instead of trusting a generated feature or config file because your own pipeline built it, do validate its row count and size against the consumer's hard limit before you publish it. Why: At Cloudflare a ClickHouse permission change made a metadata query return duplicate rows, the Bot Management feature file doubled, broke a 200-feature limit (about 60 in use), and the proxy panicked. (https://blog.cloudflare.com/18-november-2025-outage/)
3. Instead of assuming the stream delivers exactly once, do dedup at write time over a bounded window and apply the same dedup again in the read view. Why: Zepto dedups ad events with argMax over a 4-hour window and repeats it at read time in a view. (https://blog.zepto.com/a-billion-events-a-day-how-we-built-ads-analytics-that-actually-works-c28904bbf8de)
4. Instead of rerunning freshness-critical jobs over the whole table, do scope each run to keys with recent activity so the job finishes well inside its interval. Why: Zepto's budget-overspend job runs every 3 minutes, finishes in about 1 minute, and only touches campaigns with events in the last 3 hours. (https://blog.zepto.com/a-billion-events-a-day-how-we-built-ads-analytics-that-actually-works-c28904bbf8de)
5. Instead of storing every raw event to answer reach and audience counts, do keep probabilistic sketches when an approximate distinct count is enough. Why: Zepto estimated 100M+ events/day as about 3B records and 1.2 TB a month raw, and switched to sketches whose size stays constant. (https://blog.zepto.com/how-zepto-connects-advertisers-with-the-right-brands-in-real-time-at-massive-scale-bf9290233f90)
6. Instead of computing ranking features live in the request path, do pre-materialize them and define each feature once so training and serving read the same definition. Why: Zepto says live feature compute "is incompatible with a sub-200ms latency budget"; Airbnb open-sourced its feature platform Chronon, co-maintained with Stripe. (https://blog.zepto.com/building-search-for-a-10-minute-world-43b1992f5dca https://medium.com/airbnb-engineering/chronon-airbnbs-ml-feature-platform-is-now-open-source-d9c4dba859e8)
7. Instead of fanning one catalog change into many denormalized writes, do normalize the source of truth and batch downstream updates in windows. Why: Zepto cut 1,000+ writes per product update to one, moved from 7 x M40 to 3 x M60 (85% less infra) and cut API latency 50-70%. (https://blog.zepto.com/from-bottleneck-to-breakthrough-how-we-rebuilt-product-enrichment-at-scale-d40b9d93c186)
8. Instead of training a separate recommender per surface on its own slice of behavior, do evaluate one foundation model on all interactions and adapt it per surface. Why: Netflix reports over 300M users at end of 2024 produce hundreds of billions of interactions, comparable to LLM token volume. (https://netflixtechblog.com/foundation-model-for-personalized-recommendation-1a0bd8e02d39)
9. Instead of each team running its own cron scripts, do put batch and ML jobs on one orchestrator and measure the orchestrator's own overhead as a first-class metric. Why: Netflix Maestro runs about half a million jobs a day (around 2M on busy days), and a 2025 engine rework cut overhead from seconds to milliseconds, 100x. (https://netflixtechblog.com/maestro-netflixs-workflow-orchestrator-ee13a06f9c78 https://netflixtechblog.com/100x-faster-how-we-supercharged-netflix-maestros-workflow-engine-028e9637f041)
10. Instead of dual-writing to several stores from application code and hoping they agree, do put a durable write-ahead log in front so failed or partial writes can be replayed. Why: Netflix built a WAL abstraction specifically against data loss, corruption and cross-store entropy. (https://netflixtechblog.com/building-a-resilient-data-platform-with-write-ahead-log-at-netflix-127b6712359a)
11. Instead of letting every dashboard chart re-run the same heavy virtual-dataset SQL, do materialize the dataset when it goes stale, with a timeout, and point charts at the result. Why: Zepto had 16K+ virtual datasets firing up to 12 identical queries per dashboard; materialization cut warehouse cost 30-35%. (https://blog.zepto.com/optimizing-sql-warehouse-costs-building-dataset-materialization-in-apache-superset-2f5fa34682af)
12. Instead of reading one global metric built from head queries or the biggest segment, do report the metric per segment, including the long tail and new items. Why: Zepto found head-query benchmarks ignore about 80% of query space and now reports segment numbers such as retrieval efficiency for new listings. (https://blog.zepto.com/search-quality-measurement-automated-at-scale-43a38aaa7ca0)
13. Instead of a human triaging every failed job by reading logs, do classify failures automatically and route each class to an owner, with a human checking the classifier. Why: Netflix reports about 100,000 workloads fail on peak days and built Pensive for LLM-assisted diagnosis across Titus, Spark, Trino and Druid. (https://netflixtechblog.com/making-failure-diagnosis-reliable-with-pensive-ai-6b0811a1c015)
14. Instead of each team wiring its own LLM vendor keys and clients, do route all model calls through one gateway that speaks a single API shape. Why: Uber's GenAI Gateway mirrors the OpenAI HTTP/JSON interface and serves 60+ use cases for close to 30 teams across OpenAI, Vertex AI and in-house models. (https://www.uber.com/blog/genai-gateway/)
15. Instead of routing every ad hoc question through an analyst writing SQL by hand, do offer text-to-SQL scoped to known tables and keep the generated SQL visible for review. Why: Uber reports QueryGPT cut query authoring from about 10 minutes to about 3, against roughly 1.2M interactive queries a month. (https://www.uber.com/blog/query-gpt/)

## dev-productivity-ai-coding

Agentic coding that ships: smallest change first, a verifier before scale, review and CI that keep up with agent volume.

1. Instead of opening with a refactor, a bundler migration or a new abstraction, do profile, then climb the change-size ladder and stop at the first rung that holds. Why: Zepto found 13+ of 20+ build minutes inside Terser and swapped the minifier, taking builds to about 2 minutes with no bundler migration (https://blog.zepto.com/build-at-zepto-speed-how-we-cut-frontend-webpack-build-times-by-95-676440fd7963)
2. Instead of letting the agent code straight from a chat prompt, do write a SPEC.md with done criteria, build it in a fresh session, and review with a fresh-context subagent that never saw the reasoning. Why: a reviewer without the author's reasoning catches what the author rationalized (https://code.claude.com/docs/en/best-practices)
3. Instead of a long CLAUDE.md of preferences, do keep it to what the code cannot tell the agent: the test and typecheck commands, pointers and critical gotchas, under 200 lines, with an owner. Why: the check command is the most useful line, and personal preferences belong in a gitignored local file (https://code.claude.com/docs/en/best-practices https://claude.com/resources/articles/steering-claude-code-skills-hooks-rules-subagents-and-more https://claude.com/resources/articles/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start)
4. Instead of repeating a CLAUDE.md line the agent keeps missing, do move it into a command hook or deny rule, and run the test check from a Stop hook. Why: CLAUDE.md and skills are non-deterministic; hooks, deny rules and managed settings are deterministic, and exit code 2 blocks (https://code.claude.com/docs/en/best-practices https://claude.com/resources/articles/steering-claude-code-skills-hooks-rules-subagents-and-more)
5. Instead of asking for the feature and its tests in one go, do write the failing test first and ask for just enough code to pass one test at a time, pasting the full error output on each failure. Why: Anthropic's org rollout guidance is tests first, one test at a time, full error output (https://claude.com/resources/articles/scaling-agentic-coding)
6. Instead of scaling agents against a test suite you have not hardened, do make the verifier near-perfect first and make its output agent-readable: a few stdout lines, ERROR plus reason on one line, details in a log, a fast sampled mode. Why: Anthropic's 16-agent C compiler build found the verifier must be "nearly perfect, otherwise Claude will solve the wrong problem" (https://www.anthropic.com/research/building-c-compiler)
7. Instead of one marathon session on a long build, do run one feature per session with a progress file, a JSON feature list where the agent may only flip `passes`, a commit per feature, and a start ritual that reads git log and runs an end-to-end check. Why: JSON was less likely than Markdown to be overwritten, across a list of over 200 features (https://www.anthropic.com/research/effective-harnesses-for-long-running-agents)
8. Instead of launching many parallel agents on day one, do start with two or three sessions in separate worktrees and add more only while review keeps up. Why: Anthropic's merges rose from about 2,500/day in May 2026 to over 30,000/day by September, and each bottleneck removed produced more code to review (https://claude.com/resources/articles/the-ai-native-sdlc-playbook https://www.anthropic.com/research/redesigning-source-control)
9. Instead of carrying one session across unrelated tasks, do start fresh per task, rewind failed attempts, and hand exploration of ten or more files, or three or more independent pieces, to subagents that return a summary. Why: noisy side work in the main context crowds out the task; same-file edits stay in one context (https://claude.com/resources/articles/subagents-in-claude-code https://claude.com/resources/articles/using-claude-code-session-management-and-1m-context)
10. Instead of hand-migrating thousands of files or chasing 100% automation, do run the LLM per file with a validator and retries fed by the error, tune the prompt on a sample of failures, and finish the tail by hand. Why: Airbnb reports 75% of ~3.5K test files in four hours, 97% after 4 days of tuning, last 3% by hand, 6 weeks against 1.5 years estimated (https://airbnb.tech/?p=366)
11. Instead of letting an AI reviewer post every thought, do measure the share of comments marked useful and addressed, cap nits per review and cap review rounds. Why: Uber reports 75% of uReview comments marked useful; Anthropic's 3-round cap moved one-round pass from 65% to 78% (https://www.uber.com/blog/ureview/ https://claude.dev/blog/solving-code-review-at-anthropic/)
12. Instead of one approval rule for every PR, do classify risk and require 0, 1 or 2 human approvals by tier, never counting an agent approval as a human one. Why: Anthropic's Claude Code team runs exactly this tiering for agent-heavy review load (https://claude.dev/blog/solving-code-review-at-anthropic/)
13. Instead of tracking average review time, do track P75 time-in-review and nudge diffs that sit. Why: Meta's NudgeBot cut average time-in-review 7% and diffs waiting over 3 days 12% (https://engineering.fb.com/2022/11/16/culture/meta-code-review-time-improving/)
14. Instead of full CI and full clones on every agent commit, do gate main with a merge queue, run tests by impact, and use sparse checkouts that ask the server for diffs. Why: Uber reports SubmitQueue cut CI resource usage 53% and wait times 37%; Anthropic's sparse checkouts went from minutes to seconds and freed 25% CI CPU (https://www.uber.com/blog/slashing-ci-costs-at-uber/ https://www.anthropic.com/research/redesigning-source-control)
15. Instead of accepting LLM-written tests because coverage went up, do gate each one on builds, passes repeatedly, and adds coverage or kills a mutant, then let a human accept. Why: on Meta Reels/Stories TestGen-LLM tests built 75%, passed reliably 57% and raised coverage 25% of the time, and ACH targets tests at generated mutants (https://arxiv.org/abs/2402.09171 https://engineering.fb.com/2025/02/05/security/revolutionizing-software-testing-llm-powered-bug-catchers-meta-ach/)

## security-engineering

Contain agents with sandboxes, outside-the-box credentials, scoped tools and tiered approval, plus sourced app-security lessons.

1. Instead of leaning on per-action permission prompts for safety, do run the agent in an OS-level sandbox with filesystem limits and default-deny network. Why: users approve roughly 93% of prompts, so prompts are weak oversight, while sandboxing cut prompts by 84% in internal use (https://www.anthropic.com/research/how-we-contain-claude https://www.anthropic.com/research/claude-code-auto-mode https://www.anthropic.com/research/claude-code-sandboxing)
2. Instead of isolating only the filesystem or only the network, do enforce both boundaries together. Why: without network isolation a compromised agent exfiltrates files like SSH keys, and without filesystem isolation it can escape to the network (https://www.anthropic.com/research/claude-code-sandboxing)
3. Instead of passing API keys, git tokens or env secrets into the sandbox, do inject credentials from a proxy or vault outside it and scope what the proxy allows. Why: Anthropic keeps git credentials and signing keys outside the sandbox with a proxy that restricts pushes to the configured branch, and its managed-agent harness never sees credentials (https://www.anthropic.com/research/claude-code-sandboxing https://www.anthropic.com/research/managed-agents https://claude.com/resources/articles/ciso-guide-to-agentic-ai)
4. Instead of treating an allowlisted domain as safe, do treat every egress allowance as a capability grant and bind outbound calls to the sandbox's own identity. Why: allowing api.anthropic.com in Cowork let an attacker's API key carry data out, fixed by a proxy that only passes requests with the VM's own session token (https://www.anthropic.com/research/how-we-contain-claude)
5. Instead of trusting model training or a single guardrail to stop prompt injection, do layer guardrails and keep hard limits in the environment. Why: Opus 4.7 injection success is roughly 0.1% on one attempt but around 5-6% after 100 adaptive attempts (https://www.anthropic.com/research/how-we-contain-claude https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)
6. Instead of showing an action-safety classifier the agent's reasoning and tool results, do give it only user messages and the proposed tool calls. Why: stripping assistant text and tool output is how auto mode resists injection, and its honest miss rate on real overeager actions is still 17% (https://www.anthropic.com/research/claude-code-auto-mode)
7. Instead of approving everything or nothing, do tier actions: auto-approve routine work, hard-deny destructive commands, route prod infra and outbound messaging to a human. Why: with auto mode the agent works 9x longer between interruptions, and Gusto saw a denial in roughly 10% of session transcripts (https://claude.com/resources/articles/auto-mode-in-production https://www.anthropic.com/research/claude-code-auto-mode)
8. Instead of letting each team wire MCP servers straight into agents, do front them with a central gateway that enforces tool-level authz, redacts PII and keeps auto-generated tools disabled until an owner approves. Why: Uber reports the gateway hosts over 800 MCP servers and over 5000 tools (https://www.uber.com/blog/designing-mcp-gateway/)
9. Instead of giving the agent a human's credentials and the full tool list, do issue a single-purpose service identity with separate read and write credentials and drop dangerous verbs from the tool list. Why: revoking a dedicated agent identity ends its access everywhere, and a smaller verb set shrinks blast radius (https://claude.com/resources/articles/agent-identity-access-model https://claude.com/resources/articles/ciso-guide-to-agentic-ai https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle)
10. Instead of routing raw tool output and customer PII through model context, do filter data inside the sandbox and tokenize PII before the model sees it. Why: in Anthropic's example the model sees 5 rows of a 10,000-row sheet and emails become placeholders like [EMAIL_1] (https://www.anthropic.com/research/code-execution-with-mcp)
11. Instead of trusting internally generated config or feature files, do validate their size and schema like user input and roll them out in stages. Why: a Cloudflare feature file doubled past a 200-feature limit and panicked the proxy on 2025-11-18, and a global config push with no gradual rollout hit about 28% of HTTP traffic on 2025-12-05 (https://blog.cloudflare.com/18-november-2025-outage/ https://blog.cloudflare.com/5-december-2025-outage/)
12. Instead of enforcing data purpose with point checks at each call site, do track data flows with labels checked at runtime across the stack. Why: Meta found point checking did not scale and reports 10x better computational efficiency with flow-based Policy Zones (https://engineering.fb.com/2024/08/27/security/privacy-aware-infrastructure-purpose-limitation-meta/ https://engineering.fb.com/2025/07/23/security/policy-zones-meta-purpose-limitation-batch-processing-systems/)
13. Instead of forwarding every LLM or scanner security finding, do keep a THREAT_MODEL.md, re-check findings with an adversarial verifier in a fresh container and require a working PoC. Why: findings were exploitable 90% of the time with good threat models, and the verifier roughly halved non-exploitable findings (https://claude.com/resources/articles/using-llms-to-secure-source-code)
14. Instead of patching internet-facing apps on a monthly cycle, do patch within 24 hours of a public exploit, ordering work by CISA KEV then EPSS. Why: Anthropic expects an order-of-magnitude rise in finding volume from AI-accelerated offense (https://claude.com/resources/articles/preparing-your-security-program-for-ai-accelerated-offense)
15. Instead of deferring post-quantum work, do turn on post-quantum key agreement where your edge supports it and inventory authentication for the next step. Why: Cloudflare reports over 65% of human traffic is already PQ-encrypted and targets fully PQ-secure, including authentication, by 2029 (https://blog.cloudflare.com/post-quantum-roadmap/ https://blog.cloudflare.com/pq-2025/)

## frontend-mobile-engineering

Budgets, safe releases, server-driven UI and peak-proof clients, from Airbnb, Uber, Discord and Zepto.

1. Instead of a vague "make the app faster" goal, do set numeric budgets for median cold start, slow frames on your heaviest list, and memory, then track each per release. Why: Discord reports halving Android median startup in 2023 and up to 60% fewer slow frames in the chat list, plus ~12% less chat-list memory (https://discord.com/blog/supercharging-discord-mobile-our-journey-to-a-faster-app)
2. Instead of testing performance on flagship phones, do pick asset formats and render paths by what the low-end device holds at frame rate. Why: Discord reports animated WebP let low-end devices hit 60 fps (https://discord.com/blog/supercharging-discord-mobile-our-journey-to-a-faster-app)
3. Instead of budgeting only the client, do give each stage of a user-facing request a latency share and move expensive work out of the request path. Why: Zepto says live feature compute "is incompatible with a sub-200ms latency budget" and reads pre-materialized features instead (https://blog.zepto.com/building-search-for-a-10-minute-world-43b1992f5dca)
4. Instead of shipping the biggest model or payload that fits, do shrink to the smallest one that meets quality inside the budget. Why: Zepto compared a 100M-param ModernBERT with smaller models and shipped a 4M-param ranker deciding in under 100 ms (https://blog.zepto.com/building-a-lightning-fast-search-relevance-ranker-9319943a3880)
5. Instead of migrating the bundler when frontend builds crawl, do profile the build and replace the one hot stage. Why: Zepto found 13+ min inside Terser, swapped the minifier to esbuild and went from 20 min to ~2 min with no bundler migration (https://blog.zepto.com/build-at-zepto-speed-how-we-cut-frontend-webpack-build-times-by-95-676440fd7963)
6. Instead of pushing full JS bundles as OTA updates, do ship binary diffs generated against every live bundle. Why: Zepto's Phoenix cut updates from ~6 MB to ~500 KB and moved Android to 80%+ adoption in under 24 h, against 18-20% in 4 days before (https://blog.zepto.com/why-we-built-our-very-own-in-house-react-native-codepush-platform-db0c195e4603)
7. Instead of keying the OTA bundle version on the app version, do key it on native compatibility so one bundle serves every binary that can run it. Why: Phoenix ties the JS bundle version to native compatibility, not to native version (https://blog.zepto.com/why-we-built-our-very-own-in-house-react-native-codepush-platform-db0c195e4603)
8. Instead of flipping a config or flag for everyone at once, do roll it out by percentage with a tested off switch and a halt on error-rate rise. Why: Cloudflare's 2025-12-05 global config change had no gradual rollout and hit ~28% of HTTP traffic for ~25 min; Google Cloud's 2025-06-12 change was not flag protected (https://blog.cloudflare.com/5-december-2025-outage/ https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
9. Instead of letting flags live forever, do give each flag an owner and an expiry and delete dead branches with tooling. Why: Uber's Piranha removed around two thousand stale flags across Objective-C, Swift and Java (https://www.uber.com/blog/piranha/)
10. Instead of hardcoding layout per platform for surfaces that change every sprint, do let one backend response define layout, sections and actions over typed client components. Why: Airbnb's Ghost Platform drives web, iOS and Android from a single backend response (https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5)
11. Instead of one fixed grid for every query or category, do treat density and layout as data the server picks per intent. Why: Zepto uses 3x3 grids for "garbage bag" and 2x2 with bigger images for "T-shirt", picked by intent (https://blog.zepto.com/zepto-beyond-groceries-how-the-grocery-app-became-a-shopping-destination-aabdb373648a)
12. Instead of server-driving flows with deep state and business logic, do keep them client-owned and structure them as a tree of business-logic units. Why: Uber's 2016 rider app is "a tree of Riblets" whose routing is driven by business logic, not views (https://www.uber.com/blog/new-rider-app-architecture/)
13. Instead of clients retrying failed calls at once, do use randomized exponential backoff and honor a server-sent wait or fallback state. Why: Google Cloud's Service Control lacked randomized backoff and us-central1 took up to ~2h 40m to recover (https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW)
14. Instead of deploying code to survive a peak event, do put admission rules at the CDN edge, editable in seconds, that let priority users through and send the rest a wait screen. Why: Zepto reports 80% fewer 5xx/4xx and zero downtime in high-demand events; Zerodha treats 10x bursts over 10 s as normal (https://blog.zepto.com/what-happens-when-zepto-gets-hit-with-a-traffic-tsunami-6724578d30e4 https://zerodha.tech/blog/scaling-with-common-sense/)
15. Instead of hand-migrating a test suite file by file, do run an LLM migration loop with validation, then sample, tune and sweep the failures, and finish the tail by hand. Why: Airbnb moved ~3.5K React test files in 6 weeks against a 1.5-year manual estimate: 75% in four hours, 97% after 4 days of tuning, last 3% by hand (https://airbnb.tech/?p=366)