Extract, Edit, Apply – a design pattern for AI

Sharing a write-up of one of our investigations at GitHub Next: Extract, Edit, Apply.

Spec-oriented programming is usually seen as “Spec-first”, with a compilation step to turn specs into code: Specs are permanent, and Code is ephemeral. This has many obvious problems, including:

• The instability of LLM code-generation under otherwise small or unimportant changes to inputs.

• The inherent ambiguity of language.

• The absence of specifications or documentation in many existing codebases.

• The difficulty of maintaining natural language specifications and documentation under change.

• The difficulty for non-native speakers to work with highly technical language.

• The non-deterministic nature of LLMs including code generation, even when intent is unambiguous.

Another human problem arises with natural language programming: at each creation or task description the user must “find the words” – find the vocabulary, the concepts and the precision to describe the change they intend. Often the user has no idea how to do this – words can be hard! A similar problem is the “reference problem”: users must find words to refer to exact code locations, functions, methods, classes, feature points, design layers, visual elements and other logical entities sufficiently unambiguously. This can be extremely difficult.

But what if we turn this on its head? What if Code is permanent, and Specs are ephemeral – but we can still edit specs? This was a concept we played with in 2023 and 2024 at GitHub Next, and which we keep coming back to in our AI-for-code design conversations. It is so ubiquitous, so general, so powerful that we summarize it as a new design pattern for AI-for-Code features called Extract, Edit, Apply or EEA.

EEA embraces ephemeral, editable, partial specifications. Users can edit either the code or ephemeral specs: code summaries or extracts that can be generated, modified, and discarded as needed. If the user edits an ephemeral specification, the toolchain will offer a code change corresponding to the spec change. The user can then accept/reject the code change.

Generality

EEA gives different approaches to task formation, including:

• Tasks by changing extracted properties
• Tasks by changing extracted examples
• Tasks by changing extracted contracts
• Tasks by changing extracted designs
• Tasks by changing extracted tests
• Tasks by changing extracted requirements
• Tasks by changing extracted formal language

Examples of these are described in the report.

EEA and Vibe coding

EEA is strongly related to vibe programming (“chat to change” in the IDE) and can be seen as a more rigid, structured approach to generating tasks by editing extracts.

Today, contextualised, chat-based task formation has come to dominate AI dev tooling through vibe coding, and the power of “chat to change” is incredible. That said, the more structured EEA modality is still an intriguing point in the design space, for many of the reasons we outline in the report. We hope these notes on the design pattern prove useful or inspiring to AI tool designers.

Core Idea

What if we start from the opposite position: what if code is primary, and specifications (words) are secondary, while still embracing natural language as a valid way of describing change? This is the starting point of the Extract, Edit, Apply (EEA) concept we have been exploring at GitHub Next.

EEA revolves around the notion of ephemeral, editable, partial specifications. The paradigm is to make code permanent and specifications ephemeral: users can edit either the code or ephemeral specs, which are essentially code summaries that can be generated, modified, and discarded as needed. If the user edits an ephemeral specification, the toolchain will offer a code change corresponding to the spec change. The user can then accept or reject the code change, and the toolchain will apply the change to the codebase.

Report

A GitHub Next technical report is available.

Summary

The Extract, Edit, Apply (EEA) concept represents a new class of assists that can be used to incorporate natural language summarization and editing even when working with complex artifacts. In this report we are reporting a concept: it is one we have implemented, used, and liked, and believe is promising. EEA is not a replacement for existing approaches, but rather a new way of thinking about how to integrate natural language into the software development process.

Thank you to Jonathan Carter, Eddie Aftandilian, Eirini Kalliamvakou, Rahul Pandita, Tamás Szabó, Cole Bemis , Terkel Gjervig Nielsen, Johan Sebastian Heesemann Rosenkilde, Russell Horton, Anthony van der Hoorn, Devon Rifkin and many others.