Flash Fill and the Pre-LLM History of Programming by Example
Years before large language models generated code from natural-language prompts, programming-by-example systems such as Flash Fill synthesized small programs from demonstrations of the desired result.
AI-assisted programming did not begin with large language models
Long before code-focused LLMs, researchers were building systems that inferred programs from specifications, constraints and examples. Microsoft Research defines program synthesis as automatically discovering executable code from user intent expressed through examples, demonstrations, natural language or other constraints.[1]
One of the most visible deployments of this idea was Flash Fill in Excel, which lets a user demonstrate a text transformation and then infers a program that generalizes the transformation to additional rows.[2]
Programming by example changed the form of the specification
In ordinary programming, the user describes a procedure explicitly. In programming by example, the user supplies one or more input-output demonstrations and asks the system to infer a procedure consistent with those demonstrations.[3]
The shift is subtle but important: the computer is no longer only executing a program written by the user. It is searching through a space of possible programs on the user’s behalf.
Examples are powerful because they are easy to produce
A spreadsheet user may not know how to write a string-manipulation expression, yet can often show the desired result for one or two rows. PBE turns that concrete demonstration into a specification.
Examples are ambiguous because many programs can fit them
A single input-output pair can be explained by many candidate programs. The synthesis system therefore needs search and ranking mechanisms to guess which generalization the user intended.[4]
Flash Fill came from data-wrangling problems rather than conversational AI
Sumit Gulwani has described the practical motivation as repetitive spreadsheet transformations that users often solved manually or with one-off formulas and scripts. Microsoft brought the research into Office 2013 as Flash Fill.[2]
The interface was intentionally lightweight: the user demonstrated a transformation inside the spreadsheet instead of entering a separate programming environment.
A domain-specific language constrained the search
Microsoft’s PROSE framework explains that PBE systems generally search inside a domain-specific language whose operators describe the kinds of transformations the application is prepared to synthesize.[5]
Restricting the language makes inference tractable and helps keep synthesized programs within a meaningful family of operations.
Deductive search prunes impossible programs
PROSE uses witness functions and deductive backpropagation to reduce a desired output constraint into constraints on smaller subexpressions, avoiding blind enumeration of every possible program.
Ranking resolves multiple consistent solutions
When many programs satisfy the examples, learned or hand-designed ranking features can favor transformations that are more likely to match human intent.
The system was symbolic even when machine learning helped rank candidates
PBE is historically important because it does not fit a simple symbolic-versus-statistical story. The generated program comes from a structured DSL and logical search, while ranking can use machine-learning techniques to choose among candidates.[3][4]
This hybrid structure foreshadowed later AI coding systems in which generated suggestions are filtered, tested or constrained by deterministic tools.
Flash Fill made synthesis invisible to ordinary users
Most Excel users do not need to know that a program has been synthesized. They see a feature that recognizes a pattern and fills the remaining values.
This invisibility is a recurring design goal in AI-assisted programming: move some of the work of formalizing intent from the user into the system while preserving a fast way to inspect and correct the result.
The limitations are as historically important as the success
PBE systems work best when the target behavior lies within the available DSL and when a small number of examples disambiguate the intended rule. They are not general-purpose software engineers.
That limitation makes them different from modern generative code models, but it also gives them useful predictability: the search is bounded by an explicit language and specification.
Why Flash Fill belongs in the lineage of AI coding
Flash Fill demonstrated a practical form of intent-driven programming before natural-language code generation became mainstream. A user expressed what they wanted through examples, and the computer produced an executable transformation.
The deeper lineage from program synthesis to LLM-based assistance is therefore not simply ‘AI got better at autocomplete.’ It is a long-running attempt to reduce the distance between human intent and executable behavior.
Works Cited
- 01Microsoft Research — Program Synthesis microsoft.com
- 02
- 03
- 04
- 05Microsoft Research — PROSE Framework Tutorial microsoft.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead