Nachrichten

In this tutorial, we implement SHAP workflows as a practical framework for interpreting machine learning models beyond basic feature-importance plots. We start by training tree-based models and then compare different SHAP explainers, including Tree, Exact, Permutation, and Kernel methods, to understand how accuracy and runtime change across model-aware and model-agnostic approaches. We also examine how maskers affect explanations when features are correlated, how interaction values reveal pairwise feature effects, and how link functions alter interpretation between the log-odds and probability spaces. Also, we use Owen values, cohort testing, SHAP-based feature selection, drift monitoring, and custom black-box explanations to build a complete interpretability workflow that can run directly in Google Colab. Copy CodeCopiedUse a different Browser !pip install -q –upgrade shap xgboost transformers import warnings, time, numpy as np, pandas as pd, matplotlib.pyplot as plt from scipy import stats from scipy.cluster import hierarchy warnings.filterwarnings(“ignore”) import shap, xgboost as xgb from sklearn.datasets import fetch_california_housing, load_breast_cancer from sklearn.model_selection import train_test_split from sklearn.metrics import roc_auc_score, r2_score shap.initjs() np.random.seed(42) print(f”SHAP: {shap.__version__}n”) housing = fetch_california_housing() X = pd.DataFrame(housing.data, columns=housing.feature_names) y = pd.Series(housing.target, name=”MedHouseVal”) reg = xgb.XGBRegressor(n_estimators=300, max_depth=5, learning_rate=0.05, subsample=0.9, random_state=42, n_jobs=-1).fit(X_tr, y_tr) print(f”Housing regressor R² = {reg.score(X_te, y_te):.3f}”) def reg_predict(X): return reg.predict(np.asarray(X)) We install the required libraries and import the core tools for SHAP, XGBoost, statistics, visualization, and model evaluation. We load the California housing dataset and train an XGBoost regression model. We also define a clean prediction wrapper so that SHAP can explain the model without running into compatibility issues with bound model methods. Copy CodeCopiedUse a different Browser print(“n” + “=”*72) print(“PART 1: Explainer comparison — correctness & speed”) print(“=”*72) X_sample = X_te.iloc[:25] bg_small = shap.sample(X_tr, 50, random_state=42) def _wrap_kernel(expl, X, bg_mean): vals = expl.shap_values(X, nsamples=200, silent=True) return shap.Explanation(values=vals, base_values=np.full(len(X), bg_mean), data=X.values, feature_names=X.columns.tolist()) runs = {} t0 = time.time(); tree_expl = shap.TreeExplainer(reg); sv_tree = tree_expl(X_sample) runs[“Tree (exact, model-aware)”] = (sv_tree, time.time() – t0) t0 = time.time() sv_exact = shap.Explainer(reg_predict, bg_small, algorithm=”exact”)(X_sample) runs[“Exact (model-agnostic)”] = (sv_exact, time.time() – t0) t0 = time.time() sv_perm = shap.Explainer(reg_predict, bg_small, algorithm=”permutation”)(X_sample) runs[“Permutation”] = (sv_perm, time.time() – t0) t0 = time.time() ke = shap.KernelExplainer(reg_predict, shap.sample(X_tr, 50, random_state=42).values) sv_kern = _wrap_kernel(ke, X_sample, ke.expected_value) runs[“Kernel”] = (sv_kern, time.time() – t0) ref = sv_tree.values.flatten() print(f”n{‘Method’:30s} {‘time(s)’:>8s} {‘ρ vs Tree’:>10s} {‘max|Δ|’:>8s}”) for name, (sv, dt) in runs.items(): flat = sv.values.flatten() rho = np.corrcoef(ref, flat)[0, 1] err = np.abs(ref – flat).max() print(f”{name:30s} {dt:8.2f} {rho:10.4f} {err:8.4f}”) print(“nTakeaway: Tree is the only exact + fast option for tree ensembles.”) print(“Exact ≈ Permutation when permutation has enough samples; Kernel is noisier and slowest.”) print(“n” + “=”*72) print(“PART 2: Maskers — Independent vs Partition under correlation”) print(“=”*72) corr = X_tr.corr().abs() top_pair = corr.where(np.triu(np.ones_like(corr, dtype=bool), k=1)) .stack().sort_values(ascending=False).head(3) print(“Top correlated pairs (|ρ|):”) for (a, b), v in top_pair.items(): print(f” {a:10s} {b:10s} |ρ| = {v:.3f}”) masker_ind = shap.maskers.Independent(X_tr, max_samples=100) masker_part = shap.maskers.Partition(X_tr, max_samples=100) sv_ind = shap.Explainer(reg_predict, masker_ind)(X_sample) sv_part = shap.Explainer(reg_predict, masker_part)(X_sample) a, b = top_pair.index[0] print(f”nMean |φ| for top-correlated pair ({a}, {b}):”) print(f” Independent : {a}={np.abs(sv_ind[:,a].values).mean():.4f} {b}={np.abs(sv_ind[:,b].values).mean():.4f}”) print(f” Partition : {a}={np.abs(sv_part[:,a].values).mean():.4f} {b}={np.abs(sv_part[:,b].values).mean():.4f}”) print(“Partition redistributes credit across correlated features (on-manifold semantics).”) fig, axes = plt.subplots(1, 2, figsize=(13, 4)) plt.sca(axes[0]); shap.plots.bar(sv_ind, show=False); axes[0].set_title(“Independent masker”) plt.sca(axes[1]); shap.plots.bar(sv_part, show=False); axes[1].set_title(“Partition masker”) plt.tight_layout(); plt.show() We compare multiple SHAP explainers, including Tree, Exact, Permutation, and Kernel, on the same regression model and sample data. We measure each method by runtime, correlation with TreeExplainer, and maximum attribution difference to understand the trade-off between speed and approximation quality. We then study Independent and Partition maskers to see how correlated features receive different attribution credit under different masking assumptions. Copy CodeCopiedUse a different Browser print(“n” + “=”*72) print(“PART 3: Interaction decomposition”) print(“=”*72) inter = tree_expl.shap_interaction_values(X_te.iloc[:500]) inter_abs = np.abs(inter).mean(0) diag = np.diagonal(inter_abs).copy() off = inter_abs.copy(); np.fill_diagonal(off, 0) main_share = diag.sum() / (diag.sum() + off.sum()) print(f”Total attribution mass: {main_share*100:.1f}% main effects, ” f”{(1-main_share)*100:.1f}% interactions”) pairs = [(X.columns[i], X.columns[j], off[i, j]) for i in range(X.shape[1]) for j in range(i+1, X.shape[1])] pairs.sort(key=lambda t: -t[2]) print(“nTop 5 interaction pairs (mean |φ_ij|):”) for a, b, v in pairs[:5]: print(f” {a:10s} × {b:10s} → {v:.4f}”) fig, ax = plt.subplots(figsize=(7.5, 6)) im = ax.imshow(off, cmap=”viridis”) ax.set_xticks(range(X.shape[1])); ax.set_xticklabels(X.columns, rotation=45, ha=”right”) ax.set_yticks(range(X.shape[1])); ax.set_yticklabels(X.columns) plt.colorbar(im, label=”mean |φ_ij|”); plt.title(“Pairwise interaction strength”) plt.tight_layout(); plt.show() a, b, _ = pairs[0] i, j = X.columns.get_loc(a), X.columns.get_loc(b) xs = X_te.iloc[:500][a].values; cs = X_te.iloc[:500][b].values fig, axes = plt.subplots(1, 2, figsize=(13, 4), sharex=True) axes[0].scatter(xs, inter[:, i, i], c=cs, s=12, cmap=”coolwarm”) axes[0].set_title(f”Main effect of {a}”); axes[0].set_xlabel(a); axes[0].set_ylabel(“φ_{ii}”) sc = axes[1].scatter(xs, 2*inter[:, i, j], c=cs, s=12, cmap=”coolwarm”) axes[1].set_title(f”Interaction {a} × {b}”); axes[1].set_xlabel(a); axes[1].set_ylabel(“2·φ_{ij}”) plt.colorbar(sc, ax=axes[1], label=b); plt.tight_layout(); plt.show() print(“n” + “=”*72) print(“PART 4: Link functions — logit vs probability space”) print(“=”*72) cancer = load_breast_cancer() Xc = pd.DataFrame(cancer.data, columns=cancer.feature_names) yc = pd.Series(cancer.target) clf = xgb.XGBClassifier(n_estimators=300, max_depth=4, learning_rate=0.05, eval_metric=”logloss”, random_state=42).fit(Xc_tr, yc_tr) print(f”AUC = {roc_auc_score(yc_te, clf.predict_proba(Xc_te)[:,1]):.3f}”) expl_logit = shap.TreeExplainer(clf) sv_logit = expl_logit(Xc_te) expl_prob = shap.TreeExplainer(clf, Xc_tr.sample(100, random_state=42), model_output=”probability”) sv_prob = expl_prob(Xc_te) print(f”nSample 0 reconstruction (φ should sum to f – E[f]):”) print(f” log-odds : base + Σφ = {sv_logit.base_values[0] + sv_logit.values[0].sum():+.3f}”) print(f” prob : base + Σφ = {sv_prob.base_values[0] + sv_prob.values[0].sum():.3f} ” f”(model proba = {clf.predict_proba(Xc_te.iloc[[0]])[0,1]:.3f})”) fig, axes = plt.subplots(1, 2, figsize=(15, 5)) plt.sca(axes[0]); shap.plots.waterfall(sv_logit[0], max_display=8, show=False); axes[0].set_title(“Log-odds space”) plt.sca(axes[1]); shap.plots.waterfall(sv_prob[0], max_display=8, show=False); axes[1].set_title(“Probability space”) plt.tight_layout(); plt.show() We calculate SHAP interaction values to separate main feature effects from pairwise interaction effects in the housing model. We identify the strongest interaction pairs and visualize their attribution strength using heatmaps and scatter plots. We then move to a classification task and compare SHAP explanations in log-odds and probability spaces using a breast cancer classifier. Copy CodeCopiedUse a different Browser print(“n” + “=”*72) print(“PART 5: Owen values from a correlation-based feature hierarchy”) print(“=”*72) D = 1 – X_tr.corr().abs().values np.fill_diagonal(D, 0) condensed = D[np.triu_indices_from(D, k=1)] linkage = hierarchy.linkage(condensed, method=”average”) masker_owen = shap.maskers.Partition(X_tr, clustering=linkage, max_samples=100) sv_owen = shap.Explainer(reg_predict, masker_owen)(X_sample) fig, axes = plt.subplots(1, 2, figsize=(14, 4.5)) hierarchy.dendrogram(linkage, labels=X.columns.tolist(), ax=axes[0]) axes[0].set_title(“Feature hierarchy (1 − |ρ|)”) plt.sca(axes[1]); shap.plots.bar(sv_owen.abs.mean(0), show=False) axes[1].set_title(“Owen values (cluster-aware)”) plt.tight_layout(); plt.show() print(“n” + “=”*72) print(“PART 6: Cohort comparison with bootstrap CIs and hypothesis tests”) print(“=”*72) sv_all = tree_expl(X_te) q1, q3 = X_te[“MedInc”].quantile([0.25, 0.75]) low = (X_te[“MedInc”] <= q1).values high = (X_te[“MedInc”] >= q3).values def boot_ci(v, B=1000, seed=0):

Most programming languages were designed for humans who read error messages, interpret warnings, and manually trace through stack output to fix bugs. AI agents do none of those things well. They work better with structured data: predictable tokens, stable codes, and machine-parseable repair hints. That gap is what Vercel Labs is trying to close by releasing Zero, an experimental systems language that is faster, smaller, and easier for agents to use and repair. What is Zero Language Zero is a systems programming language that sits in the same design space as C or Rust. It compiles to native executables, gives you explicit memory control, and targets low-level environments. What separates Zero from existing systems languages is that its compiler output and toolchain were designed from day one to be consumed by AI agents, not just human engineers. The Agent-First Toolchain The core problem Zero addresses is how agents interact with compiler feedback. In a typical development loop involving a coding agent, the agent writes code, the compiler emits an error as unstructured text, and the agent has to parse that text to determine what went wrong and how to fix it. This is fragile — error message formats change, messages are written for human readers, and there’s no built-in concept of a ‘repair action.’ Zero’s CLI emits structured JSON diagnostics by default. When you run zero check –json, the output looks like: Copy CodeCopiedUse a different Browser { “ok”: false, “diagnostics”: [{ “code”: “NAM003”, “message”: “unknown identifier”, “line”: 3, “repair”: { “id”: “declare-missing-symbol” } }] } Each diagnostic carries a stable code (e.g., NAM003), a human-readable message, a line reference, and a repair object with a typed repair ID. Humans read the message. Agents read the code and repair. The same CLI command surfaces both — there is no separate mode or secondary tool to run. The toolchain is unified into one binary: zero check, zero run, zero build, zero graph, zero size, zero routes, zero skills, zero explain, zero fix, and zero doctor are all subcommands of the same CLI. This matters for agentic workflows because agents don’t need to reason about which tool to invoke for which task. Two subcommands are particularly relevant to the repair loop. zero explain <diagnostic-code> returns a detailed explanation of a given diagnostic code, so an agent can look up NAM003 without parsing prose documentation. zero fix –plan –json <file-or-package> emits a structured fix plan — a machine-readable description of what changes to make to resolve a diagnostic — rather than requiring the agent to infer the fix from the error message alone. zero skills serves a different purpose: it provides version-matched agent guidance directly through the CLI. Running zero skills get zero –full returns focused workflows covering Zero syntax, diagnostics, builds, packages, standard library use, testing, and agent edit loops — all matched to the installed compiler version. This is notable because it means agents working with Zero don’t need to scrape external documentation that may be out of sync with the compiler they’re actually running. Explicit Effects and Capability-Based I/O One of Zero’s core design decisions is that effects are explicit in function signatures. If a function writes to standard output, accesses the filesystem, or makes a network call, it must declare that through a capability object. The canonical entry point in Zero looks like this: Copy CodeCopiedUse a different Browser pub fun main(world: World) -> Void raises { check world.out.write(“hello from zeron”) } The world: World parameter is the capability object that grants access to the outside world. A function that doesn’t receive World (or a capability derived from it) cannot perform I/O — the compiler enforces this at compile time, not at runtime. There is no hidden global process object. The check keyword handles fallible operations. If world.out.write(…) can fail, check surfaces that failure along the call stack. The raises annotation on main signals that the function can propagate errors — making error paths visible in signatures rather than buried in runtime exceptions. Getting Started Installation requires one command: Copy CodeCopiedUse a different Browser curl -fsSL https://zerolang.ai/install.sh | bash export PATH=”$HOME/.zero/bin:$PATH” zero –version The installer downloads the latest binary from the GitHub release and places it in $HOME/.zero/bin/zero. Packages are defined with a zero.json manifest and source files under src/, initialized with zero new cli <name>. A VS Code extension for .0 file syntax highlighting ships in the repository under extensions/vscode/. Marktechpost’s Visual Explainer Vercel Labs 01 / 09  ·  Overview Zero The Programming Languagefor Agents An experimental systems language that gives AI agents structured diagnostics, typed repair metadata, and machine-readable docs — alongside sub-10 KiB native binaries. Systems Language Agent-Native v0.1.1 Apache-2.0 Experimental Released May 15, 2026 Author Chris Tate · Vercel Labs Repo vercel-labs/zero File Extension .0 Context 02 / 09  ·  Why Zero Exists The Agent Repair Loop Problem Most programming languages produce compiler output written for human readers — unstructured text that AI agents must parse to determine what failed and how to fix it. This creates a fragile loop. Agent writes code — compiler emits an error as unstructured text Agent parses text — error format can change between compiler versions No repair hint — there’s no built-in concept of a “repair action” Human steps in — the loop requires manual intervention to resolve errors Zero was designed from day zero so agents can read the code, interpret the diagnostics, and repair the program — without human translation. Core Feature 03 / 09  ·  JSON Diagnostics Structured Compiler Output Running zero check ——json emits machine-readable diagnostics instead of plain text. Every error includes a stable code, a human message, a line number, and a typed repair ID. $ zero check –json { “ok”: false, “diagnostics”: [{ “code”: “NAM003”, “message”: “unknown identifier”, “line”: 3, “repair”: { “id”: “declare-missing-symbol” } }] } code — stable identifier agents can match reliably (NAM003) message — human-readable description of the error repair — typed repair ID agents can act on without text parsing Core Feature 04 / 09

In the final week of the Musk v. Altman trial, lawyers traded blows over Elon Musk’s and OpenAI CEO Sam Altman’s credibility. Altman was grilled on his alleged history of lying and self-dealing involving companies that do business with OpenAI. But he fired back, painting Musk as a power-seeker who wanted to control the development of artificial general intelligence (AGI)—powerful AI that can compete with humans on most cognitive tasks.  As evidence of their commitment to AI safety, OpenAI brought out a golden trophy of a donkey’s ass that was gifted to an employee after he was called a “jackass” for standing up to Musk’s plans to race toward AGI.  Lawyers for both sides also presented their closing arguments, floating unflattering mugshot-style photos of Musk and Altman next to each other on a giant screen. Musk’s lawyer Steven Molo argued that Altman and OpenAI president Greg Brockman broke their promise to use money Musk donated to maintain OpenAI as a nonprofit that develops AI for the benefit of humanity. Instead, they created a for-profit subsidiary that made them extraordinarily wealthy. OpenAI’s lawyer Sarah Eddy argued that Altman and Brockman never promised to keep OpenAI a nonprofit. She added that even though it’s been restructured, OpenAI remains a nonprofit dedicated to developing AI safely. She claimed that Musk sued too late—and that his real motive is to sabotage a competitor to his own AI company, xAI, which he launched in 2023.  Musk is asking the court to unwind the 2025 restructuring that converted OpenAI’s for-profit subsidiary into a public benefit corporation and to remove Altman and Brockman from their roles. He is also seeking as much as $134 billion in damages from OpenAI and Microsoft, to be awarded to OpenAI’s nonprofit.  The jury will begin deliberating on Monday and deliver an advisory verdict as soon as next week. The jury verdict is not binding on the judge, who will decide the case. If the judge rules in Musk’s favor, it could upend OpenAI’s race toward an IPO at a valuation approaching $1 trillion. Meanwhile, xAI is expected to go public as a part of Musk’s rocket company SpaceX as early as June, at a target valuation of $1.75 trillion. Musk the power-seeker, Altman the liar. In the first week of the trial, Musk said he was suing to save OpenAI’s mission to build AI safely for the benefit of humanity. This week, Altman denied Musk was a paladin of AI safety and painted him as a power-seeker who wanted to control OpenAI.  Altman told the jury that in 2017, when Musk and other cofounders were discussing creating a for-profit arm, they asked Musk what would happen to his control over such an entity if he died. “Maybe the control of OpenAI should pass to my children,” Musk said, according to Altman. Musk’s lawyer shot back, grilling Altman on his alleged history of lying. He pointed out that OpenAI’s former executives Ilya Sutskever and Mira Murati, and former board members Helen Toner and Tasha McCauley, all testified that Altman had lied to them. In 2023, Altman was briefly fired as CEO over the alleged behavior. Molo also pressed Altman about his personal investments in startups that do business with OpenAI. Altman testified that he tried to steer OpenAI to buying power from the nuclear energy company Helion Energy, a third of which he owns. (Last Friday, the US House oversight committee launched an investigation into Altman’s potential conflicts of interest. Attorneys general from more than a half-dozen states called for the Securities and Exchange Commission to review them.) During his closing statement, Molo put Altman’s credibility on the stand again. “Imagine that you’re on a hike, and you come upon one of those wooden bridges that you see on a trail, and it’s over a gorge,” he said. “A woman standing by the entry to the bridge says, ‘Don’t worry—the bridge is built on Sam Altman’s version of the truth.’ Would you walk across that bridge?” Altman, who sat behind his lawyers, looked up uneasily every time his name was mentioned.  During her closing argument, Eddy fired back. Musk “never cared about the nonprofit structure,” she said. “What he cared about was winning.”  Musk, though, was absent. Despite the judge’s order that he remain available, he flew to China with President Trump. Did Altman promise to keep OpenAI a nonprofit? During her closing argument, Eddy argued that no testimony or evidence showed any conditions on Musk’s donations, or any promises made by Altman and Brockman to keep the company a nonprofit. “No commitments or promises were made. No restrictions were placed on Mr. Musk’s donations,” she said. Eddy added that it was evident Musk wasn’t truly committed to keeping OpenAI a nonprofit. She noted that in 2017, he tried to create a for-profit subsidiary and fought a bitter battle with Altman and Brockman to have control over it. “I was not opposed to there being a small for-profit that provides funding to the nonprofit,” Musk told the jury earlier in the trial, “as long as the tail didn’t wag the dog.”  Eddy then argued that Musk sued too late, filing in 2024 after the statutes of limitations on his claims ran out. In 2019, OpenAI created a for-profit subsidiary, under which employees and investors received a capped return on their investment.  But Musk testified that he discovered OpenAI had abandoned its nonprofit mission only in 2022, when Microsoft was preparing to invest $10 billion in OpenAI—a deal that closed in 2023. “I was disturbed to see OpenAI with a $20B valuation,” he texted Altman after reading the news. “This is a bait and switch.” Musk told the jury that the $20 billion valuation made him realize “the for-profit is the tail wagging the dog.”  “The 2023 deal was different,” Molo hammered home during his closing argument. Is OpenAI still a nonprofit committed to its mission? A central question raised in the last week of trial was whether OpenAI remains a nonprofit

Every year the World Health Organization publishes a global health statistics report. It features the numbers behind world health trends and, importantly, assesses whether we’re on track to reach ambitious goals set in 2015. It’s a bit like a health grade. The 2026 report was published on Wednesday. And the results aren’t looking brilliant. While we are seeing some improvements, they are uneven, and they’re far too slow. The targets themselves are part of the United Nations’ Sustainable Development Goals, a sprawling and ambitious plan focused on improving life around the world. The 17 goals were set to tackle poverty and climate change and to boost education, gender equality, health, and well-being, among many other quality of life issues. Those targets were meant to be met by 2030. Perhaps they were a little too ambitious. Here are the numbers and statistics that stood out to me on this year’s world health report card. 1.3 million new cases of HIV in 2024 Before the SDGs, there were the Millennium Development Goals. One MDG target was to halt and reverse the spread of HIV—and that target was exceeded by 2015. Back then, we were considered on track to “end the AIDS epidemic by 2030.” How depressing, then, to see that in 2024 there were an estimated 1.3 million new cases of HIV. That’s 40% lower than the figure from 2010. But it’s still 1.3 million additional people with HIV. The SDG target is to reduce HIV incidence by 90% by 2030—we’re not likely to meet it. 10.7 million new cases of TB The picture is even bleaker for tuberculosis, which ranks 10th on the WHO’s list of top global causes of death. The goal was to reduce cases by 80% between 2015 and 2030. So far, cases have only fallen by a measly 12%. And when you break the change down by region, the Americas saw an increase of 13% An 8.5% rise in malaria cases And then there’s malaria, the mosquito-borne disease with a 7% fatality rate. The European region has been free of malaria since 2015, but the disease is a significant concern in many countries in the Global South, particularly in Africa. The goal was to lower rates by 90% between 2015 and 2030. In 2024, there were an estimated 282 million cases of malaria globally—representing an 8.5% increase in incidence rates. Antimalarial drug resistance is a major challenge here—forms of the malaria virus that are resistant to drugs have been confirmed or suspected in eight countries in Africa, according to a separate WHO report. Mosquitoes that are resistant to commonly used insecticides are present in nine African countries. And climate change, which can alter mosquito habitats, may be making things worse. 42.8 million children are wasting We’re not meeting child health targets, either. Take malnutrition, for example. As of 2024, the global prevalence of wasting in children was 6.6%—that’s a staggering 42.8 million children who are literally wasting away because of a lack of adequate food. On the other end of the spectrum, 5.5% of children are now considered overweight. Both figures were meant to be below 5% by 2030, which now seems unlikely. Vaccination rates are dropping in the Americas Progress in improving childhood vaccination coverage has stalled. Globally, an estimated 76% of children are getting their second dose of a measles vaccine—a figure far below the the approximately 95% needed to prevent outbreaks. The Americas currently has lower rates of vaccine coverage for three of the four “core” vaccines than it did in 2015. This is partly due to a lack of investment, says Goodarz Danaei, an epidemiologist at the Harvard T.H. Chan School of Public Health. “But now we have a misinformation campaign going around vaccines that makes it worse,” he adds. The covid-19 pandemic didn’t exactly help, either. The impact on health services led to millions of children missing out on routine vaccinations. 22.1 million pandemic-related deaths And of course the pandemic affected progress toward health goals in more direct ways: 7 million people died of covid-19. The WHO report estimates that, for each of these, there were an additional two “excess” deaths related to the pandemic, due to disruptions in health care, for example. That puts the total figure at 22.1 million pandemic-related deaths. A woman dies every two minutes from “maternal causes” Maternal mortality rates fell by about 40% between 2020 and 2023. But today’s rate equates to 712 maternal deaths every single day. That’s one every two minutes. The WHO report notes that we’d have to reduce the mortality rate by almost 15% per year in order to meet the 2030 target. This seems incredibly unlikely, particularly given the recent decimation of US funding for global aid programs, which is expected to result in thousands of additional maternal deaths. Progress has also slowed in reducing the risk of death from noninfectious diseases like cancer, diabetes and cardiovascular disease. “Overall, neither the world nor any WHO region is currently on track to meet the 2030 SDG target,” the report states. 2.1 billion people struggle to afford health care Despite plans to make health care more affordable, a significant chunk of the population is being pushed into poverty by health-care costs. In 2022, 2.1 billion people faced financial hardship due to health spending—and 1.6 billion of them were living in or had been pushed into poverty. Across the board, there have been some important improvements in global health. But the achievements have not gone far enough. “The good news is that there is progress,” says Danaei. “But as always, the glass is half empty.” This article first appeared in The Checkup, MIT Technology Review’s weekly biotech newsletter. To receive it in your inbox every Thursday, and read articles like this first, sign up here.

The AI coding agent market looks almost unrecognizable compared to 2024 or even early 2025. What started as inline autocomplete has evolved into fully autonomous systems that read GitHub issues, navigate multi-file codebases, write fixes, execute tests, and open pull requests — without a human typing a single line of code. By early 2026, roughly 85% of developers reported regularly using some form of AI assistance for coding. The category has fractured into distinct archetypes: terminal agents, AI-native IDEs, cloud-hosted autonomous engineers, and open-source frameworks that let you swap in whatever model you prefer. The problem is that every tool claims to be the best, and the benchmarks used to justify those claims are not always measuring the same things — and in some cases are no longer credible measures at all. This article features the most important AI coding agents by the metrics that actually matter for production software development, while being honest about where those metrics have broken down. If you are an AI/ML engineer, software developer, or data scientist trying to decide where to invest your tooling budget in 2026, start here. How to Read These Benchmarks — Including Why the Most-Cited One Is Now Disputed Before the listing, an important calibration on the numbers — because one major benchmark shift happened mid-cycle and is not yet reflected in most tool comparison articles. SWE-bench Verified has been the industry’s standard coding benchmark since mid-2024. It presents agents with 500 real GitHub issues drawn from popular Python repositories and measures whether the agent can understand the problem, navigate the codebase, generate a fix, and verify that it passes tests — end-to-end, without human guidance. It was a credible proxy. In February 2026, that changed. On February 23, 2026, OpenAI’s Frontier Evals team published a detailed post explaining why it had stopped reporting SWE-bench Verified scores. Their auditors reviewed 138 of the hardest problems across 64 independent runs and found that 59.4% had fundamentally flawed or unsolvable test cases — tests that demanded exact function names not mentioned in the problem statement, or checked unrelated behavior pulled from upstream pull requests. More critically, they found evidence that every major frontier model — GPT-5.2, Claude Opus 4.5, and Gemini 3 Flash — could reproduce the gold-patch solutions verbatim from memory using only the task ID, confirming systematic training data contamination. OpenAI’s conclusion: “Improvements on SWE-bench Verified no longer reflect meaningful improvements in models’ real-world software development abilities.” OpenAI now recommends SWE-bench Pro as the replacement for frontier coding evaluation. This does not make SWE-bench Verified scores useless. Other major labs continue to report them, third-party evaluators continue to run them, and they remain useful for broad directional comparison. But any ranking that presents SWE-bench Verified scores as clean, objective measurements of real-world ability — without this caveat — is giving you an incomplete picture. All scores in this article are flagged accordingly. SWE-bench Pro is harder to interpret than Verified because published results vary significantly by split, scaffold, harness, and reporting source. The benchmark contains 1,865 total tasks divided into a 731-task public set, an 858-task held-out set, and a 276-task commercial/private set drawn from 18 proprietary startup codebases. When the original Scale AI paper measured frontier models using a unified SWE-Agent scaffold, top scores were below 25% — GPT-5 at 23.3% — reflecting a genuinely harder evaluation. However, current public leaderboard and vendor-reported runs now show substantially higher scores under newer models and optimized agent harnesses: OpenAI reports GPT-5.5 at 58.6% on SWE-bench Pro (Public), while Anthropic’s comparison table lists Claude Opus 4.7 at 64.3% and Gemini 3.1 Pro at 54.2%. These numbers should not be directly compared with the original sub-25% SWE-Agent results without noting the scaffold and split differences — the benchmark has not changed, but the evaluation conditions and model generations have. When you see a 60%+ SWE-bench Pro score alongside a sub-25% one, they are measuring the same benchmark under very different conditions, not two separate tests. Terminal-Bench 2.0 evaluates terminal-native workflows: shell scripting, file system operations, environment setup, and DevOps automation. As of April 23, 2026, GPT-5.5 leads at 82.7% on this benchmark — confirmed in OpenAI’s official release. Claude Opus 4.7 scores 69.4% (Anthropic/AWS-reported), and Gemini 3.1 Pro scores 68.5%. An important methodological caveat: different harnesses produce different numbers for the same model. Anthropic’s Opus 4.6 system card showed GPT-5.2-Codex scoring 57.5% on the independent Terminus-2 harness vs 64.7% on OpenAI’s own Codex CLI harness — a 7-point gap from harness alone. When comparing Terminal-Bench figures across sources, always check which execution environment was used. One final cross-benchmark caveat: agent scaffolding matters as much as the underlying model. In a February 2026 evaluation of 731 problems, three different agent frameworks running the same Opus 4.5 model scored 17 issues apart — a 2.3-point gap that changes relative rankings. A benchmark score labeled with a model name reflects the model and the specific scaffold wrapped around it, not the model in isolation. 10 AI Agents for Software Development A Note on Claude Mythos Preview The current leader on SWE-bench Verified among third-party trackers is Claude Mythos Preview at 93.9%, announced April 7, 2026 under Anthropic’s Project Glasswing. It is not generally available. Access is restricted to a limited set of platform partners; Anthropic has stated it does not plan broad release in the near term, in part due to elevated cybersecurity capability concerns. It sits outside the main comparison below because developers cannot access it through standard channels. Its existence does, however, signal that the practical capability ceiling sits substantially above what any publicly available tool currently delivers. #1. Claude Code (Anthropic) SWE-bench Verified (self-reported): 87.6% (Opus 4.7) / 80.8% (Opus 4.6) SWE-bench Pro (Anthropic internal variant): 64.3% (Opus 4.7, #1) / 53.4% (Opus 4.6) Terminal-Bench 2.0: 69.4% (Opus 4.7, Anthropic-reported) CursorBench: 70% (Opus 4.7, Cursor-reported) Claude Code subscription: $20–$200/month | Opus 4.7 API: $5/$25 per million tokens Claude Code is Anthropic’s terminal-native coding agent and the leader on code quality metrics across