Large language models have now completed several difficult tasks in science, technology, engineering, and mathematics. Some systems have generated formally verified proofs, discovered improved mathematical constructions, solved elite programming problems, optimized production computing infrastructure, controlled laboratory equipment, and contributed to new experimental findings.

However, the word solved must be used carefully.

No LLM has solved mathematics, chemistry, biology, software engineering, or scientific research as a general discipline. Most credible successes fall into one of four narrower categories:

A specific, finite problem was solved and independently checked.
A previously best-known result was improved.
A measurable engineering or laboratory objective was optimized.
A benchmark task was completed under controlled conditions.

The central conclusion is:

LLMs have solved a growing number of narrowly specified and externally verifiable STEM problems, but they have not solved open-ended scientific or engineering work in general.

A Practical Definition of “Solved”

A STEM result should not be considered solved merely because an LLM generated a plausible-looking answer.

A strong claim requires some combination of:

objective verification;
formal proof checking;
executable tests;
experimental measurement;
expert review;
independent replication;
or deployment in a real system.

One way to represent the strength of a claim is:

\[\text{Evidence strength} = f( \text{novelty}, \text{verification}, \text{replication}, \text{deployment} )\]

This article uses the following classification.

Level	Meaning	Typical evidence
A: Verified solution	A specific problem was correctly solved	Formal proof, accepted program, or validated experiment
B: Best-known result improved	The problem remains open, but the previous frontier was advanced	Better bound, faster algorithm, or higher experimental yield
C: Working prototype	The system completed a meaningful workflow under controlled conditions	Laboratory or engineering demonstration
D: Benchmark progress	Strong benchmark performance without proof of general real-world reliability	Exam score, code benchmark, or simulated task

Executive Summary

The strongest examples available by July 2026 include:

Domain	Problem completed or advanced	Evidence	Verdict
Theoretical physics	Derived a closed-form gluon-scattering amplitude	Formula checked against physical consistency conditions	Specific research problem solved
Mathematics	Solved five of six 2025 IMO problems	Officially graded solutions	Competition milestone
Formal mathematics	Generated machine-checkable Lean and Isabelle proofs	Proof-assistant verification	Many individual theorems solved
Combinatorics	Found improved cap-set constructions	Programmatic mathematical verification	Open problem advanced
Algorithm design	Found a faster complex matrix-multiplication algorithm	Executable evaluator and mathematical checking	Best-known algorithm improved
Programming	Solved 10 of 12 2025 ICPC World Finals problems	Accepted contest solutions	Finite programming tasks solved
Computing infrastructure	Improved Google data-center scheduling	Reported production deployment	Real engineering optimization solved
Chip design	Proposed a verified TPU circuit rewrite	Hardware verification and integration	Specific design optimization solved
Chemistry	Planned and executed coupling reactions	Laboratory measurements and mass spectrometry	Laboratory workflow completed
Medicinal chemistry	Improved a difficult Chan–Lam reaction	More than 10,000 experiments and bench validation	Reaction conditions improved
Biology	Reduced cell-free protein-production cost	More than 36,000 automated reactions	Narrow optimization problem solved
Finite-element engineering	Generated usable FEniCS simulation code	Verification tests after limited revisions	Engineering coding substantially automated

The pattern behind these successes is important. LLMs perform best when embedded in a closed verification loop:

\[\text{LLM} \rightarrow \text{candidate solution} \rightarrow \text{external evaluator} \rightarrow \text{feedback} \rightarrow \text{revised solution}\]

The evaluator may be:

a theorem prover;
a compiler;
a unit-test suite;
a numerical simulator;
an optimization objective;
a robotic laboratory;
or a human domain expert.

The LLM supplies candidate ideas. The evaluator prevents plausible but incorrect ideas from being treated as discoveries.

1. Science

1.1 Theoretical Physics: A New Gluon-Scattering Formula

One of the clearest examples of an LLM contributing to a genuinely new scientific result appeared in the 2026 preprint Single-minus gluon tree amplitudes are nonzero.

The problem concerned scattering amplitudes involving:

one negative-helicity gluon;
multiple positive-helicity gluons;
and a special half-collinear configuration of particle momenta.

These amplitudes were commonly treated as zero under standard assumptions. The researchers showed that they are nonzero in a precisely defined region of momentum space.

According to the accompanying OpenAI research report, human researchers first calculated complicated expressions for cases up to six gluons. GPT-5.2 Pro simplified those expressions, detected a common pattern, and proposed a formula for arbitrary particle count.

An internal scaffolded model subsequently produced a proof. The authors then checked the result against:

the Berends–Giele recursion relation;
Weinberg’s soft theorem;
and direct low-particle calculations.

The scientific result was not simply an answer to a known textbook question. It was a new closed-form expression for a previously neglected physical configuration.

Verdict

Level A: a specific theoretical-physics problem was solved.

Important qualifications remain:

the result was produced through human–AI collaboration;
the paper was initially released as a preprint;
OpenAI researchers were among the authors;
and broader independent review is still important.

It nevertheless represents much stronger evidence than ordinary science-question benchmarks because the proposed formula was subjected to mathematical and physical consistency checks.

1.2 Chemistry: Autonomous Planning and Execution of Reactions

The peer-reviewed Nature paper Autonomous chemical research with large language models introduced Coscientist, a GPT-4-driven system connected to:

web search;
documentation retrieval;
Python execution;
robotic liquid handlers;
analytical instruments;
and cloud laboratories.

Coscientist was given natural-language goals such as performing Suzuki–Miyaura and Sonogashira coupling reactions.

The system:

searched for relevant reaction information;
selected compatible reagents;
calculated quantities and volumes;
generated robotic protocols;
corrected an API error by consulting documentation;
executed the protocols;
and produced the expected reaction products.

Gas chromatography and mass spectrometry identified the expected products for both coupling reactions.

The laboratory was not completely autonomous because humans manually moved some plates. However, the paper reports that no human chemical decision-making was required during the integrated reaction-design experiment.

Verdict

Level A/C: specific reaction-planning and execution tasks were completed in a controlled laboratory.

This does not mean arbitrary chemical synthesis has been solved. The reagent space, available equipment, and target reactions were constrained.

1.3 End-to-End Chemical Reaction Development

The Nature Communications paper An automatic end-to-end chemical synthesis development platform powered by large language models presented LLM-RDF, a GPT-4-based reaction-development framework.

The system contained specialized agents for:

literature searching;
experiment design;
hardware execution;
spectrum analysis;
separation planning;
and result interpretation.

It was demonstrated on copper/TEMPO-catalyzed alcohol oxidation. The workflow covered:

literature retrieval;
substrate screening;
condition screening;
kinetic analysis;
reaction optimization;
scale-up;
and product purification.

The system was also tested on additional reaction classes.

Verdict

Level C: a broad but controlled chemical-development workflow was demonstrated.

The workflow required automated laboratory infrastructure and expert oversight. It should not be interpreted as a general autonomous chemist capable of independently pursuing arbitrary research programs.

1.4 Medicinal Chemistry: Improving Chan–Lam Coupling

In 2026, OpenAI and Molecule.one reported a near-autonomous chemistry project in A near-autonomous AI chemist improves a challenging reaction in medicinal chemistry.

GPT-5.4 was connected to Molecule.one’s Maria chemistry agent and high-throughput laboratory. The system investigated a difficult version of Chan–Lam coupling involving primary sulfonamides.

The model proposed testing mild oxidants, including TEMPO. Across two experimental cycles:

10,080 reactions were executed;
yields improved for 88% of tested boronic acids;
yields improved for 83% of tested sulfonamides;
mean yield increased from 16.6% to 25.2%;
and the fraction of reactions exceeding 30% yield increased from 15.6% to 37.5%.

Human chemists subsequently repeated representative reactions at bench scale. Eleven of fourteen substrate pairs showed higher yields, and eight showed increases greater than twofold.

The relative increase in mean yield can be expressed as:

\[\text{Relative improvement} = \frac{25.2 - 16.6}{16.6} \times 100% \approx 51.8%\]

The system was not fully autonomous. Humans:

created steering and grading prompts;
selected proposals for laboratory testing;
corrected some experimental details;
handled physical laboratory operations;
and validated representative results.

Verdict

Level B: an LLM contributed to a novel and experimentally validated reaction improvement.

The result remained a preprint-level finding at publication time. Independent replication and a wider investigation of substrate scope are still needed.

1.5 Biology: Lower-Cost Cell-Free Protein Synthesis

OpenAI and Ginkgo Bioworks connected GPT-5 to an automated cloud laboratory to optimize cell-free protein synthesis. The results were reported in GPT-5 lowers the cost of cell-free protein synthesis.

Cell-free protein synthesis produces proteins without maintaining living cells. The process involves many interacting components, including:

DNA templates;
cell lysates;
salts;
energy sources;
buffers;
amino acids;
and other biochemical reagents.

The number of possible formulations makes manual optimization expensive.

The LLM-driven system operated as a closed loop:

GPT-5 proposed experimental compositions.
The automated laboratory executed them.
Experimental results were returned to the model.
The model analyzed the data.
New experimental batches were proposed.

Across six rounds, the system tested:

more than 36,000 reaction compositions;
across 580 automated plates.

The reported result was:

a 40% reduction in total protein-production cost;
and a 57% improvement in reagent cost.

The cost reduction can be represented as:

\[\text{Cost reduction} = \frac{ C_{\text{baseline}} - C_{\text{LLM}} }{ C_{\text{baseline}} } \times 100%\]

For the reported system:

\[\text{Cost reduction} = 40%\]

The system reportedly established a new low-cost frontier after three rounds of experimentation.

Verdict

Level B: a narrowly defined biological optimization problem was materially improved.

Limitations include:

only one protein, sfGFP, was studied;
only one cell-free synthesis platform was tested;
some formulations may be specific to high-throughput plate conditions;
and human oversight remained necessary.

The result is not evidence that general protein engineering or biological research has been solved.

1.6 Retrosynthesis and Reaction-Mechanism Reasoning

The paper Chemical reasoning in LLMs unlocks steerable synthesis planning and reaction mechanism elucidation studied LLM-guided search for:

strategy-aware retrosynthesis;
and reaction-mechanism elucidation.

Instead of asking the LLM to directly output a complete molecular route, the method used the model to guide a structured search process.

Chemists could specify constraints in natural language, such as:

preferring a particular type of bond formation;
preserving a functional group;
or following a named synthetic strategy.

The system identified meaningful strategies in routes longer than twenty reaction steps and recognized historically important syntheses such as Woodward’s synthesis of strychnine.

Verdict

Level C/D: chemical planning was substantially improved, but general retrosynthesis remains unsolved.

The evidence is stronger for ranking, steering, and searching routes than for guaranteeing that every proposed route will work experimentally.

2. Technology and Computer Science

2.1 International Collegiate Programming Contest Problems

An advanced version of Gemini 2.5 Deep Think was evaluated on the 2025 International Collegiate Programming Contest World Finals. According to the Google DeepMind report, it:

solved 10 of 12 problems;
operated under the five-hour competition limit;
would have ranked second among the university teams;
and solved one problem that no human team solved during the contest.

That unique problem involved optimizing the flow of liquid through a network of ducts and reservoirs.

The model formulated the problem using:

reservoir priority values;
dynamic programming;
the minimax theorem;
and nested ternary searches.

The ICPC organization confirmed that the submitted solutions were complete and accepted, although it did not audit the model architecture or the entire evaluation process.

Verdict

Level A/D: ten finite algorithmic programming problems were solved.

This is compelling evidence of advanced algorithmic reasoning, but competitive programming is still cleaner than production software engineering. Contest problems have:

precise specifications;
deterministic judges;
limited codebases;
and objectively verifiable outputs.

2.2 Real GitHub Issues and SWE-Bench

SWE-bench evaluates agents on issues extracted from real open-source repositories. Each task asks an agent to:

understand an issue;
inspect a repository;
edit multiple files;
and pass hidden tests.

Frontier systems made rapid progress on SWE-bench and SWE-bench Pro. However, the validity of these benchmarks has become a major concern.

In July 2026, OpenAI published Separating signal from noise in coding evaluations. The audit estimated that approximately 30% of the public SWE-bench Pro tasks were broken.

Identified problems included:

overly strict tests;
underspecified prompts;
insufficient test coverage;
and prompts that contradicted hidden tests.

Although reported pass rates rose from 23.3% to 80.3% within eight months, the audit concluded that benchmark flaws made it difficult to interpret these numbers as general software-engineering capability.

For a well-formed benchmark, pass rate is:

\[\text{Pass rate} = \frac{ \text{verified successful tasks} }{ \text{valid evaluated tasks} } \times 100%\]

If a substantial fraction of the denominator contains broken tasks, the resulting score is not a clean measurement of model capability.

Verdict

Level D: many repository-level tasks can be solved, but general software engineering is not solved.

Current coding agents can often:

implement localized features;
repair reproducible bugs;
write tests;
refactor small components;
and navigate unfamiliar repositories.

They still struggle with:

ambiguous product requirements;
architectural decisions;
long-term maintenance;
undocumented organizational context;
integration with external systems;
security consequences;
and determining whether tests actually represent the intended behavior.

2.3 Discovering New Algorithms with FunSearch

The peer-reviewed Nature paper Mathematical discoveries from program search with large language models introduced FunSearch.

FunSearch combined:

a pretrained LLM;
an evolutionary search process;
executable candidate programs;
and an objective evaluator.

It searched for programs rather than directly searching for isolated answers.

Given a scoring function:

\[S(f) = \text{quality score of candidate program } f\]

the idealized objective is:

\[f^* \in \operatorname*{arg,max}_{f \in \mathcal{F}} S(f)\]

The system repeatedly generated, executed, scored, selected, and modified programs.

FunSearch produced two important results.

Cap-set constructions

The cap-set problem asks for large subsets of a finite vector space that contain no three points on a line.

FunSearch found:

previously unknown finite-dimensional constructions;
improved asymptotic constructions;
and what the paper described as the largest improvement in approximately twenty years to one associated lower bound.

Online bin packing

Online bin packing requires placing arriving items into containers without knowing future items.

FunSearch generated interpretable heuristics that outperformed widely used baselines on evaluated distributions and benchmark instances.

Verdict

Level B: an open combinatorial problem was advanced and new optimization heuristics were discovered.

FunSearch did not close the general cap-set problem. It improved the best-known constructions.

2.4 AlphaEvolve: Algorithm Discovery and Production Optimization

Google DeepMind’s AlphaEvolve extended the FunSearch idea from evolving individual functions to evolving larger programs and algorithms.

AlphaEvolve combines:

Gemini Flash for broad candidate generation;
Gemini Pro for deeper proposals;
evolutionary selection;
automated execution;
and objective evaluators.

Matrix multiplication

AlphaEvolve found an algorithm for multiplying two complex-valued 4-by-4 matrices using 48 scalar multiplications.

The previously best-known general construction in this setting required 49 multiplications.

The objective can be represented as:

\[\min_{A \in \mathcal{A}} \text{ScalarMultiplications}(A)\]

subject to:

\[A(X,Y) = XY\]

for all valid input matrices.

Open mathematical problems

AlphaEvolve was applied to more than fifty problems in:

analysis;
geometry;
combinatorics;
and number theory.

According to DeepMind:

it rediscovered state-of-the-art solutions in approximately 75% of cases;
and improved the best-known solution in approximately 20% of cases.

One example was the eleven-dimensional kissing-number problem, where it found a configuration of 593 spheres and established a better lower bound.

Verdict

Level B: several best-known algorithms and mathematical bounds were improved.

The system is especially effective when candidate answers can be evaluated automatically. It is less directly applicable to problems where correctness or quality cannot be cheaply measured.

3. Engineering

3.1 Production Data-Center Scheduling

AlphaEvolve was used to improve scheduling in Google’s Borg data-center management system.

According to the AlphaEvolve technical report, the discovered scheduling heuristic:

was deployed in production;
had operated for more than one year;
and recovered an average of 0.7% of Google’s worldwide computing resources.

A simplified resource-efficiency objective is:

\[\text{Utilization} = \frac{ \text{resources performing useful work} }{ \text{total available resources} }\]

Even a fraction-of-a-percent improvement can be operationally significant at global data-center scale.

Verdict

Level A/B: a real production engineering optimization was solved well enough to deploy.

The evidence is company-reported rather than an independent audit, but production deployment is stronger evidence than a synthetic benchmark.

3.2 Hardware Design and TPU Circuit Optimization

AlphaEvolve proposed a Verilog rewrite for a highly optimized arithmetic circuit used in matrix multiplication.

The proposal:

removed unnecessary bits;
passed hardware verification;
preserved functional correctness;
and was integrated into an upcoming Tensor Processing Unit.

The essential engineering constraint was:

\[\text{Output}_{\text{optimized}} = \text{Output}_{\text{reference}}\]

for every valid input, while improving a target such as:

circuit area;
latency;
power consumption;
or implementation complexity.

Verdict

Level A/C: a specific hardware-design optimization was generated and verified.

This does not mean LLMs can independently design an entire modern processor. It shows that they can contribute useful local modifications inside a tightly verified design process.

3.3 Optimizing AI Training Kernels

AlphaEvolve also generated software-level improvements for AI infrastructure.

Reported examples included:

a 23% speedup for a matrix-multiplication kernel in Gemini;
approximately a 1% reduction in total Gemini training time;
and up to a 32.5% speedup for a FlashAttention kernel implementation.

These are particularly strong examples because:

the generated programs were executable;
correctness could be compared against reference implementations;
and performance could be measured directly on hardware.

A common objective is:

\[\text{Speedup} = \frac{ T_{\text{baseline}} }{ T_{\text{optimized}} }\]

Alternatively, percentage runtime reduction is:

\[\text{Runtime reduction} = \frac{ T_{\text{baseline}} - T_{\text{optimized}} }{ T_{\text{baseline}} } \times 100%\]

Verdict

Level A/B: several constrained software-performance problems were materially improved.

3.4 Finite-Element Simulation Code

The study Can ChatGPT implement finite element models for geotechnical engineering applications? evaluated ChatGPT-generated finite-element code for coupled hydro-mechanical problems.

The model was asked to translate:

governing equations;
constitutive assumptions;
boundary conditions;
and initial conditions

into executable numerical code.

When using the high-level FEniCS library, the generated implementation reportedly required only minimal revisions to pass verification and validation tests.

MATLAB implementations required substantially more intervention because the model had to explicitly construct:

shape functions;
element matrices;
global assembly procedures;
and lower-level numerical operations.

Verdict

Level C: high-level finite-element implementation was substantially automated.

The physical and mathematical formulation still had to be specified and checked by an expert. The model did not independently determine whether the governing model was appropriate for the real engineering system.

3.5 Network-Simulation Code

The SIMCODE benchmark evaluates the generation of ns-3 network-simulation programs from natural-language descriptions.

The benchmark tests whether generated code:

compiles;
executes;
implements the requested topology;
uses the correct protocol;
and produces expected simulation behavior.

Early results showed meaningful but incomplete performance. Even strong models failed many tasks because of:

incorrect API usage;
missing headers;
invalid configuration combinations;
and semantic mismatches between the prompt and the simulation.

Verdict

Level D: network-simulation generation has improved but is not solved.

The benchmark illustrates the gap between producing plausible code and producing an experimentally valid engineering simulation.

4. Mathematics

4.1 International Mathematical Olympiad 2025

In 2025, an advanced version of Gemini Deep Think solved five of the six International Mathematical Olympiad problems.

According to the Google DeepMind report:

the model earned 35 of 42 points;
the solutions were graded by IMO coordinators;
the score met the gold-medal threshold;
the model worked directly from natural-language problem statements;
and it produced the solutions within the 4.5-hour contest limit.

This differed from DeepMind’s 2024 system, which required humans to translate problems into formal languages and took several days.

The 2025 system used:

parallel candidate exploration;
reinforcement learning;
mathematical problem-solving data;
and self-verification.

Verdict

Level A/D: five exceptionally difficult finite mathematics problems were solved.

It does not follow that advanced mathematics as a whole has been solved.

Olympiad mathematics is:

difficult and creative;
but restricted to carefully designed problems;
based mostly on pre-university concepts;
and constructed so that relatively short solutions exist.

4.2 Formal Theorem Proving in Lean

Formal theorem proving is an especially suitable application because every proposed proof can be checked by a proof assistant.

If a model produces proof term \(p\) for theorem \(T\), the relevant test is:

\[\operatorname{Check}(p, T) = \begin{cases} 1, & \text{if the proof kernel accepts } p \ 0, & \text{otherwise} \end{cases}\]

This removes much of the ambiguity involved in judging natural-language proofs.

The 2026 preprint LEAP introduced an agentic framework that:

decomposed proofs into subproblems;
generated informal proof plans;
translated them into Lean;
compiled candidate proofs;
and iteratively repaired failures.

Reported results included:

solving all twelve problems from the 2025 Putnam competition after formalization;
and increasing the solve rate on Lean-IMO-Bench from below 10% to 70% for general-purpose foundation models.

These results were mechanically checked by Lean.

Verdict

Level A/D: many difficult formalized theorems were solved.

The limitations include:

the theorem statement must already be formalized;
a suitable mathematical library must exist;
and the system may require substantial test-time search.

4.3 Industrial-Scale Verification with Isabelle

The 2026 paper Towards Real-World Industrial-Scale Verification: LLM-Driven Theorem Proving on seL4 studied LLM-generated proofs for the formally verified seL4 microkernel.

The proposed AutoReal-Prover was based on a fine-tuned 7-billion-parameter code model. It used:

chain-of-thought proof training;
project-context retrieval;
and Isabelle proof checking.

Reported results included:

a 51.67% proof-success rate over 660 selected seL4 theorems;
compared with 27.06% in previous attempts;
and a 53.88% success rate on 451 theorems from three security-related Archive of Formal Proofs projects.

Verdict

Level D: hundreds of industrial verification obligations were solved, but full autonomous verification remains unsolved.

A success rate near 52% is valuable for proof assistance, but it still leaves almost half of the target theorems unresolved.

4.4 Advanced Mathematical Analysis Remains Difficult

Formal theorem proving has not reached general graduate- or research-level reliability.

The 2026 MA-ProofBench benchmark contains formalized problems in:

measure theory;
integration;
complex analysis;
functional analysis;
and other advanced topics.

It contains separate undergraduate and PhD-qualifying-level sections.

The best evaluated model reportedly achieved:

16% Pass@8 on the undergraduate section;
and 5% Pass@8 on the PhD-level section.

Frequent failure modes included:

hallucinated library theorems;
incomplete proofs;
invalid transformations;
and inability to connect high-level ideas to formal details.

Similarly, Riemann-Bench, which contains expert-authored research-style mathematics problems, reported that frontier models remained below 10%.

Verdict

Research-level mathematics is not solved.

The contrast is important:

Olympiad problems: increasingly solvable.
Formalized benchmark theorems: partially solvable.
Broad graduate mathematics: weak.
Open-ended research mathematics: mostly beyond current systems.

5. What Has Actually Been Solved?

Based on the evidence, LLMs have solved or substantially completed the following classes of problems.

5.1 Finite Problems with Objective Answers

Examples include:

individual IMO problems;
individual Putnam problems;
ICPC programming problems;
formal Lean or Isabelle theorems;
and code-generation tasks with complete tests.

These tasks have clear acceptance criteria.

5.2 Search Problems with Cheap Evaluators

Examples include:

matrix-multiplication algorithms;
combinatorial constructions;
scheduling heuristics;
kernel optimization;
and bin-packing rules.

The LLM does not need to know with certainty that its first proposal is correct. It can generate many proposals and retain only those that pass the evaluator.

5.3 Experimental Optimization Problems

Examples include:

lowering cell-free protein-synthesis cost;
increasing reaction yield;
optimizing chemical conditions;
and selecting useful experimental follow-ups.

These tasks become tractable when the LLM is connected to:

automated experiments;
structured measurements;
and iterative feedback.

5.4 Translation from Natural Language to Formal Systems

Examples include:

natural language to Lean;
natural language to Isabelle;
natural language to Python;
natural language to FEniCS;
natural language to robotic protocols;
and natural language to Verilog.

The LLM is acting as an interface between human intentions and systems with stricter semantics.

6. What Has Not Been Solved?

6.1 General Scientific Discovery

No current LLM can reliably:

choose an important scientific question;
establish that it is novel;
design all necessary experiments;
operate the laboratory without assistance;
identify hidden confounding factors;
interpret unexpected results;
and produce independently replicated knowledge.

Current systems automate parts of this loop, not the entire scientific process.

6.2 General Mathematics

LLMs cannot reliably:

resolve arbitrary open conjectures;
build long theories over months or years;
detect subtle hidden assumptions;
or work consistently across all areas of graduate mathematics.

Gold-medal-level olympiad performance is a major milestone, but olympiad mathematics is not equivalent to mathematical research.

6.3 General Software Engineering

Coding agents cannot yet replace the full engineering process.

They remain unreliable at:

ambiguous requirements;
multi-team architecture;
security-critical systems;
long-running migrations;
production incident response;
undocumented business rules;
and maintaining systems over many years.

6.4 General Engineering Design

LLMs can optimize components when supplied with:

a simulator;
a specification;
a test suite;
or an objective function.

They cannot reliably determine whether the specification itself captures:

safety;
manufacturability;
regulation;
fatigue;
environmental conditions;
maintenance;
and human factors.

6.5 End-to-End Drug Discovery

LLMs can help with:

literature analysis;
target identification;
molecule generation;
synthesis planning;
experiment selection;
and laboratory optimization.

However, drug discovery also requires:

toxicology;
pharmacokinetics;
manufacturing;
clinical trials;
regulatory review;
and long-term safety monitoring.

No LLM has autonomously produced a medicine through the entire process from hypothesis to approved treatment.

7. Why Verifiable LLM Systems Work

The most successful systems are not plain chatbots.

They combine an LLM with several additional components:

\[\text{Successful system} = \text{LLM} + \text{tools} + \text{memory} + \text{search} + \text{verification} + \text{iteration}\]

7.1 Generation

The model proposes:

proofs;
programs;
algorithms;
hypotheses;
reaction conditions;
or experimental designs.

7.2 Verification

An external system checks the proposal using:

a proof kernel;
a compiler;
a test suite;
a simulator;
a numerical score;
or a physical experiment.

7.3 Selection

Invalid or low-quality candidates are removed.

7.4 Feedback

Errors and measurements are returned to the model.

7.5 Iteration

The system generates improved candidates.

A simplified optimization loop is:

\[x_{t+1} = \operatorname{LLM} \left( x_t, E(x_t), H_t \right)\]

where:

\(x_t\) is the current candidate;
\(E(x_t)\) is evaluator feedback;
and \(H_t\) is the history of previous attempts.

The process continues until:

\[E(x_t) \geq \tau\]

where \(\tau\) is a predefined acceptance threshold.

This architecture converts the LLM from an unreliable answer generator into a proposal engine operating inside a more reliable computational or experimental system.

8. Evidence Quality and Important Caveats

Not all evidence has equal weight.

Strongest evidence

The strongest evidence comes from:

formal proof assistants;
accepted competitive-programming submissions;
reproducible code execution;
peer-reviewed laboratory papers;
independently repeated experiments;
and verified production deployment.

Moderate evidence

Moderate evidence includes:

technically detailed preprints;
company reports with disclosed measurements;
expert-reviewed but not independently replicated experiments;
and benchmark results with public solutions.

Weaker evidence

Weaker evidence includes:

self-reported exam scores;
demonstrations without released methods;
selected anecdotes;
model-generated evaluations;
and benchmarks with contamination or test-quality problems.

A useful hierarchy is:

\[\text{Formal verification} > \text{independent experiment} > \text{peer-reviewed demonstration} > \text{reproducible benchmark} > \text{company report} > \text{anecdote}\]

This ordering is not absolute. For example, a production deployment may provide stronger practical evidence than a small peer-reviewed benchmark.

9. Overall Assessment

As of July 2026, LLMs have crossed an important threshold.

They are no longer limited to explaining known STEM material. In carefully structured systems, they have:

generated new mathematical constructions;
produced formally verified proofs;
solved elite mathematics and programming problems;
derived a new theoretical-physics formula;
optimized production data-center infrastructure;
contributed verified hardware modifications;
designed and executed chemical experiments;
improved medicinal-chemistry reactions;
and reduced the cost of a biological production process.

The most defensible conclusion is not that STEM has been solved.

It is:

LLMs have become useful search and reasoning components inside verifiable STEM systems.

Their current advantage is greatest when:

the problem can be precisely specified;
candidate solutions can be generated as text or code;
correctness or quality can be measured;
many attempts can be evaluated;
and humans can review the final result.

Their current weakness is greatest when:

the objective is ambiguous;
validation is expensive;
causal structure is uncertain;
requirements change over time;
or failure has serious real-world consequences.

The frontier is therefore moving from:

\[\text{LLM answers a question}\]

toward:

\[\text{LLM proposes} + \text{tools verify} + \text{experiments measure} + \text{humans judge}\]

That hybrid model—not a standalone chatbot—is responsible for most of the credible STEM breakthroughs attributed to LLMs so far.

References

Alfredo Guevara et al., Single-minus gluon tree amplitudes are nonzero, 2026.
OpenAI, GPT-5.2 derives a new result in theoretical physics, 2026.
Google DeepMind, Advanced Gemini with Deep Think achieves gold-medal standard at IMO 2025, 2025.
Google DeepMind, Gemini achieves gold-medal level at the ICPC World Finals, 2025.
Bernardino Romera-Paredes et al., Mathematical discoveries from program search with large language models, Nature, 2024.
Google DeepMind, AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms, 2025.
Daniil A. Boiko et al., Autonomous chemical research with large language models, Nature, 2023.
Ruan et al., An automatic end-to-end chemical synthesis development platform powered by large language models, Nature Communications, 2024.
OpenAI and Molecule.one, A near-autonomous AI chemist improves a challenging reaction in medicinal chemistry, 2026.
OpenAI and Ginkgo Bioworks, GPT-5 lowers the cost of cell-free protein synthesis, 2026.
Bran et al., Chemical reasoning in LLMs unlocks steerable synthesis planning and reaction mechanism elucidation, 2025.
Kim et al., Can ChatGPT implement finite element models for geotechnical engineering applications?, 2025.
Wang et al., SIMCODE: A Benchmark for Natural Language to ns-3 Network Simulation Code Generation, 2025.
Kung et al., LEAP: Supercharging LLMs for Formal Mathematics with Agentic Frameworks, 2026.
Zhang et al., Towards Real-World Industrial-Scale Verification: LLM-Driven Theorem Proving on seL4, 2026.
Pu et al., MA-ProofBench: A Two-Tiered Evaluation of LLMs for Theorem Proving in Mathematical Analysis, 2026.
Garre et al., Riemann-Bench: A Benchmark for Moonshot Mathematics, 2026.
OpenAI, Separating signal from noise in coding evaluations, 2026.