Can AI produce something genuinely new?

Three meanings of new

People use “novel” for different claims. Separating them prevents both overclaiming and needless dismissal.

The first two forms are common. A text generator can write a sentence that has probably never occurred exactly before, and a design system can combine familiar components in a previously unseen arrangement. Neither fact alone makes a scientific discovery, a patentable invention, a reliable medical finding, or an effective algorithm. The relevant standard changes with the field.

For an algorithm, the claim might be “this program sorts every permitted input correctly and has lower latency on specified hardware.” For mathematics, it might be a theorem, a construction, or a bound that can be independently proved. For materials science, it might first be “this crystal structure is predicted to be stable,” followed by a separate claim that it can be synthesised and has a useful measured property. In creative work, a work can be new to its audience without there being a single objective test of field-wide originality.

Novelty also does not settle whether a system is conscious, intentional, or creative in the human sense. Those are separate philosophical and social questions. A useful answer to the practical question asks what the system produced and how people checked it.

How AI contributes to a new result

AI can help when the possible combinations are too numerous for unaided search, while there is a useful way to score or reject candidates. The system may propose a program, molecular structure, proof strategy, circuit, or experiment. A search process then mutates, samples, or recombines candidates. A validator supplies feedback such as “the program fails this input,” “the proof step is invalid,” “the structure has high predicted energy,” or “this design performs worse than the baseline.”

That feedback loop matters. It lets a system go beyond fluent description and select candidates that meet a specification. In FunSearch, a frozen large language model generated code for an evolutionary program-search process, while an evaluator rejected incorrect or weak proposals. The Nature paper reports state-of-the-art results on established open problems and presents surpassing those results as evidence that the discoveries were not merely retrieved from the language model’s training data. Mathematical discoveries from program search with large language models

In this arrangement, the LLM proposes useful variations based on learned patterns. The evaluator, benchmark, theorem prover, simulator, or laboratory measurement decides whether a variation deserves further attention. A weak evaluator can reward an exploit, an artifact, or a narrow benchmark win. A strong evaluator makes it more plausible that the search has found a real improvement inside a clearly defined problem.

A worked example

Hypothetical example: A programmer wants a faster routine that sorts exactly five unsigned 32-bit integers on a named processor. They specify the input domain, plan property-based tests for ordering and preservation of all input values, including duplicates and integer boundaries, and measure latency against the existing routine on controlled hardware.

An AI search system produces a compact instruction sequence. It is new to the programmer immediately. It becomes a stronger candidate when it passes those tests and the benchmark shows lower latency under the stated measurement protocol. Passing sampled tests does not prove correctness for every possible input; that requires a proof or a justified exhaustive check. The programmer then searches technical literature, existing libraries, and relevant code history for an equivalent sequence, asks another engineer to reproduce the result, and tests nearby processor versions.

If the sequence still passes, it may be a new engineering result for that scope. If someone published the same technique earlier, it was not new to the field even though the AI found it independently. If it performs better only because the benchmark omitted an important input pattern, it is neither a useful improvement nor evidence of a new algorithm. The same chain of questions applies to a proposed proof, molecule, or research hypothesis, even though the validator changes.

Documented examples and what they show

AlphaDev used deep reinforcement learning to search assembly-level sorting algorithms. The researchers framed correctness and efficiency as a game, measured latency, and report that its fixed sort routines for three, four, and five values were new and more efficient than the human benchmarks. The paper says the routines were reviewed and included in LLVM’s libc++ sorting library. This is a strong example of novelty in a bounded engineering problem because the candidate had an executable specification, performance measurement, public comparison point, and downstream code review. AlphaDev’s methods and results

FunSearch is a useful example for mathematics and algorithms because it combines language-model proposals with a program evaluator rather than accepting prose as a solution. Its results apply to problems that admit an efficient evaluation function. That condition is substantial: many scientific questions do not have a fast, trustworthy score function, and an evaluator can only check the property it encodes. A claim about a proof still requires rigorous checking, and a claim about an open problem can change if overlooked prior work or an error is later found. FunSearch

GNoME illustrates a different threshold. Its authors reported 2.2 million crystal structures predicted to be stable relative to the Materials Project, including 381,000 new stable structures made available on the convex hull. Those are valuable new computational candidates, especially because they give scientists a much larger search catalogue. Their novelty is computational and provisional. Synthesis, measurement of the desired property, and reproducibility remain separate scientific work. Scaling deep learning for materials discovery

Together, these examples show why “AI made a novel output” is too imprecise. The confidence in a novelty claim rises with the quality of the problem definition, the search coverage, the validator, the comparison against prior work, and independent replication.

Checking whether a candidate is new to a field

No one can prove a claim is absent from every document or every person’s knowledge. Researchers and engineers instead build a proportionate case. A candidate for field-level novelty should have a specific claim, such as a formula, source file, molecular structure, or experimentally measured result. Vague claims such as “an original idea for batteries” cannot be searched or tested well.

1. Define the claim and its conditions. Record the candidate, the system that produced it, input data, constraints, date, and intended comparison. A performance claim needs the hardware, dataset, metric, and baseline. A scientific claim needs the materials, protocol, and observed outcome.
2. Search relevant prior work. Look in the field’s primary literature, preprints, technical standards, repositories, and, where the purpose requires it, patent databases. Search for equivalent methods and results, not only the AI’s wording. This reduces the risk of renaming an existing idea as a discovery.
3. Validate independently of the generator. Use a proof checker, property tests, held-out benchmark, simulator with known limits, or real experiment. Repeat the test from the saved candidate, not from the AI’s narrative description.
4. Seek review and replication. A knowledgeable reviewer can spot an unsearched precedent, hidden assumption, or invalid comparison. High-impact claims deserve independent reproduction by people who did not design the prompt or reward function.

Search and validation answer different questions. A literature search may find a predecessor but cannot show that a candidate works. A successful test may show that it works under specified conditions but cannot show that it was never known. Using both is how a project moves from “interesting output” to a defensible novelty claim.

Training data makes originality uncertain

Models learn from prior human work, which is often exactly why they can make useful proposals. But a user usually does not know the full training corpus, how much a particular source influenced an output, or whether an output is a close paraphrase of a source. Even systems trained with public data can memorise and emit particular sequences. Carlini and colleagues recovered hundreds of verbatim examples from GPT-2, including personal data and code, through black-box queries. Extracting Training Data from Large Language Models

That finding does not mean every output is copied. Research on non-adversarial language generation finds novelty in new n-grams, morphological combinations, and syntactic structures, while also acknowledging that neural networks can memorise material. How Much Do Language Models Copy From Their Training Data? The sensible conclusion is narrower: surface novelty is evidence only of a new-looking expression, not proof of independent invention or clean provenance.

For text, images, code, and designs intended for publication or commercial use, compare the candidate with known work and keep the search record. Use plagiarism, code-similarity, or image-similarity tools as screens, then inspect meaningful matches yourself. These tools cannot establish authorship or clear every rights issue. If the work will support a patent, a research claim, or a product release, use the appropriate professional prior-art, legal, and technical review rather than relying on the model’s statement that it created something original.

Using AI well for exploratory work

An AI assistant is often valuable before novelty is established. It can enumerate assumptions, generate candidate designs, translate a verbal hunch into a testable specification, find alternative formulations, and help write test cases. Its suggestions are most useful when you can ask a narrow question and check the answer outside the model.

For a learner or small project, start with a constrained problem and a way to test it. Ask the model for several candidate approaches and the assumptions each uses. Pick one candidate, reproduce it in your own environment, and compare it with a known baseline. Then look for related work before calling it new. This is more productive than asking a chatbot, “Has anyone ever thought of this?” because the chatbot cannot perform a comprehensive, reliable prior-art search from its internal memory.

When a system's proposal seems surprising, preserve the exact artifact and the evidence around it: prompt or search configuration, model and tool versions, evaluator, baseline, source data, and results. That record lets another person check whether the effect was real, whether an evaluator was accidentally gamed, and whether the claim should be narrowed. The same discipline makes a genuine discovery more credible and a false lead cheaper to correct.