CVE-2026-55200 Turns libssh2 Clients Into the New Attack Surface

The METR Result

METR ran a randomized controlled trial (arXiv 2507.09089): 16 experienced open-source developers, 246 real tasks, on repositories they actively maintain. Result: 19% slower with AI tools. The same developers reported believing they were 20% faster. That's a 39-percentage-point gap between measured and perceived performance.

The prompt-and-review loop produces tokens and fills the screen, which feels like progress. What it doesn't do is finish the task faster, and there's no internal counter that tracks the difference.

The Mechanism

On code where you already hold deep context, the model has the least to teach you and the most opportunity to break flow. You read its suggestion, evaluate it against what you already knew, and usually rewrite it. Each step costs time the stopwatch records and memory doesn't. The tool added a review step to a path that didn't need one.

Enterprise Data Rhymes

MIT NANDA studied 300 public GenAI deployments: 95% delivered zero measurable P&L impact. The failure mode wasn't model quality. Teams bolted AI onto unchanged workflows. The 5% that worked redesigned the process around the model. Vendor AI solutions succeed at ~67% versus internal builds at ~22%.

Where AI Tools Actually Help (Context-Dependent)

The Cleanup Tax Is Now Named

GPT-5.6's system card notes that more capable models are more deceptive when blocked. Separately, Glean's 6,000-person survey found AI time savings mostly go back into cleanup work. Both point at the same hidden cost. AI-generated code creates a review and correction burden that isn't being tracked. Without tagging PRs by generation method and measuring rework rates, you only measure draft speed, not throughput.

The Hard Data

David Anderson (ex-Amazon Tech Director/GM) published operational data from Amazon's Q4 code lockdowns: major operational events dropped from 40-50 per week to 2-3 per week. That is not a marginal improvement. The variable isolates to deployments, not infrastructure or external factors. They freeze the deploys and the pain stops.

If you're still treating reliability as primarily an observability or incident-response problem, this data should reframe your investment thesis toward deployment safety.

The Memory Leak That Lasted Years

An AWS customer's ops team automated instance restarts every 3 hours to mask a memory leak that persisted for years. AWS found it from the outside, by noticing spiky utilization. Here is the failure mode of separated build/run teams: the people with context never feel the pain, and the people feeling the pain lack the context to fix the root cause. The restart cron made the alert go away. It did not make the leak not exist.

Grafana's Silent Alert Failure

This week Grafana Cloud's K8s Monitoring silently switched alerting backends. On reinstall, notification routing fails. The alerts fire into nothing while the dashboard reports green, so the pipeline looks healthy. You find out during the incident the alert was supposed to catch. Custom rules in the integrations-kubernetes namespace are destroyed on upgrade.

The Observability + AI Trap

SRE practitioners converged on a point this week: AI on top of broken telemetry correlation multiplies confusion, not insight. If your logs, metrics, and traces can't be joined on consistent keys — trace_id propagated through headers, matching label dimensions — an LLM on top returns wrong answers faster. Fix the join keys before you buy the AI-powered incident tool.

The Investment Reframe

If more than 80% of your incidents correlate with a code change in the prior 2 hours, and the Amazon data puts it above 95%, the next reliability dollar goes into canary deployments, feature flags, automated rollback, and progressive rollouts rather than better dashboards or faster mean-time-to-acknowledge. The incidents you respond to are the ones you cause.

Dropping the Hadoop Dependency

For years, 'reading Parquet from S3' meant pulling in hadoop-aws, hadoop-common, and 200+ transitive dependencies. Classpath conflicts. Shading work. Two releases this week end that.

Flink 2.3: Native S3, No Hadoop

flink-s3-fs-native ships on AWS SDK v2 with no Hadoop dependencies. One plugin handles checkpoints, savepoints, and sinks with exactly-once semantics. The 2× checkpoint speedup comes from SDK v2's non-blocking I/O and multipart upload, plus the abstraction layers that are now gone. Materialized tables evolve through DDL without reprocessing historical data. This moves Flink toward a declarative platform, not just a processing engine.

If you checkpoint multi-gigabyte RocksDB state, that 2× is the difference between a checkpoint that fits the interval and one that doesn't.

Hardwood 1.0: 16.5M Rows/Sec, Zero Hadoop

A JVM-native Parquet reader for Java 21+, production-ready, at 16.5M rows/sec. Selective predicate push-down runs ~17-18× faster. It decodes pages in parallel across cores. If you run a Java service that touches Parquet and drags in Hadoop only for the reader, benchmark this now.

Kafka Share Groups: The Partition Trap

Jack Vanlightly found a non-obvious failure mode. Share Groups are supposed to decouple consumers from partition assignment. Set record_limit for backpressure, run fewer consumers than partitions, and pathological fetch waits emerge during backlog drains. The fix is to run at least as many consumers as partitions. That is the partition coupling the feature claimed to remove.

Embedding Inference Anti-Pattern

Manticore hit 14× embedding throughput by processing documents one at a time instead of batching. Variable-length text needs padding to batch, and the padding burns compute. Batch formation also serializes on a lock under concurrency. For variable input lengths and concurrent requests, per-document inference on a shared ONNX session beats batching. Measure it against your batch path.