A post from Meta's engineering blog last week landed with a specific number I wasn't expecting: their Capacity Efficiency program has recovered hundreds of megawatts of power - enough to power hundreds of thousands of American homes for a year - by building AI agents to do the investigation and code-fix work that engineers technically could do but rarely got to.
The underlying problem is one that scales deceptively. When your code serves 3 billion people, a 0.1% performance regression doesn't feel catastrophic - until you math out what 0.1% of 3 billion means in continuous server power draw. Meta's in-house regression detection tool, FBDetect, can catch regressions as small as 0.005% in noisy production environments. It was already catching thousands of regressions every week. The bottleneck wasn't detection. It was that every regression then required a human engineer to investigate, root-cause it, and write a fix.
That investigation averaged around 10 hours. The AI version does it in about 30 minutes and produces a ready-to-review pull request for the engineer who wrote the original code.
What made this work at scale wasn't the model. It was an architecture decision: they separated the platform into generic MCP tools (query profiling data, fetch experiment results, retrieve configuration history, search code) and domain-specific skills (encoded reasoning patterns from senior engineers, like "check recent schema changes if the affected function handles serialization" or "look for logging-related causes if the regression appeared after a deployment"). The same tools power both offense (finding optimization opportunities before they're missed) and defense (catching regressions after they ship). New operational workflows just need new skills, not new data integrations.
Within a year, the same foundation powered capacity planning agents, efficiency assistants, personalized opportunity recommendations, and AI-assisted validation workflows - all composing existing tools with new skill layers.
The thing I keep thinking about is how many similar bottlenecks exist at companies running at much smaller scale than Meta. The constraint wasn't compute or model quality - it was that engineers had higher-priority work and the investigative steps were too tedious to prioritize consistently. What performance or reliability work at your company is currently slipping through cracks not because people don't know it matters but because it's always deprioritized against product work?
[link] [comments]