# Where does the thinking happen now? An agent can return a finished interface before you have decided whether it is the right interface. Amelia Wattenberger’s work asks how to preserve the observing, comparing and shaping that used to happen while writing code. By John Lindquist. Independent field guide. Research checked 2026-09-02. This is an independent John Lindquist field guide, not Wattenberger’s website or official Intent documentation. Intent is an Augment team product. Her authorship and product leadership are not sole engineering credit. All three workbenches are original, fictional and deterministic; they do not connect to Intent or run a model. ## Contents - [Who is shaping these experiences?](#practitioner) - [What did writing code give us besides code?](#thinking-loop) - [What makes a specification alive?](#living-spec) - [Which context is missing from the recommendation?](#human-context) - [What should stay under direct control?](#direct-editing) - [How do you keep the loop intact?](#returning) - [Browser interface](#browser-interface) - [Sources and boundaries](#sources) ## Who is shaping these experiences? Wattenberger’s work connects interface design, web development and data visualization with AI-assisted development. The current Augment author biography identifies her as Product Lead for Intent and Partner at Sutter Hill Ventures. Her public GitHub profile also describes building at Sutter Hill Ventures. Those sources are more useful for current role attribution than her personal homepage, which still describes a GitHub Next role. This guide treats GitHub Next as earlier work, not an assumed present employer. [A01](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration) [A09](https://api.github.com/users/Wattenberger) [A08](https://wattenberger.com/) Her website provides a concrete body of interface experiments: writing tools, brainstorming, data visualization and developer experiences. It describes Code Atlas, Copilot for Docs, code brushes and collaborative workspaces among work undertaken at GitHub. These are project references, not evidence that all remain available or that she was their only contributor. The Code Brushes project page specifically names her and identifies the exploration as concluded. Its Copilot Labs technical preview ended on December 15, 2023. [A08](https://wattenberger.com/) [A05](https://githubnext.com/projects/code-brushes/) The distinction between using AI to make something and making an AI experience is important here. In LLMs as a tool for thought, she describes using chatbots to pin ideas, explore analogies and ask about the shape of a writing draft. In Building faster than you can think, she recommends specifications and side-by-side prototypes as ways to protect deliberation during AI-assisted work. Those are concrete author-reported practices and proposals, not a claim that her products are entirely generated or that a particular productivity improvement has been measured. [A07](https://wattenberger.com/thoughts/llms-as-a-tool-for-thought/) [A02](https://www.augmentcode.com/blog/building-faster-than-you-can-think) Intent makes the product-design side explicit. Her launch account describes a workspace organized around coordinating agents rather than adding another chat sidebar to an IDE. The interesting continuity across these projects is not an anti-text aesthetic. It is the question of where the human gets a useful representation of the work, and which operations that representation makes possible. That continuity is this guide’s interpretation of the sources. ## What did writing code give us besides code? Building faster than you can think starts with the painter who alternates between making a stroke and stepping back. Wattenberger’s point is that doing and evaluating are both part of the work. A compile, a walk or an awkward bug could once create a pause without anyone deliberately protecting it. If implementation gets shorter, that pause may disappear while the need for judgment remains. Her essay argues for making it intentional, not for restoring slow tools. [A02](https://www.augmentcode.com/blog/building-faster-than-you-can-think) This matters in agent-assisted design because a plausible first result can conceal an unresolved product choice. A generated filter panel may work perfectly while filtering the wrong thing. A passing check can establish behavior without establishing usefulness. The designer still needs to decide what to compare, whose task matters and what would count as a reason to change direction. An implementation is evidence for those decisions, not a substitute for them. In Code was our medium for thought, she develops the same concern through a visual account of software creation. Coding, checking the rendered result, browsing examples and discussing a detail with a teammate are presented as one evolving process. The essay asks what could replace that thinking surface when agents perform more of the implementation. Its custom chart playground is an illustrative demonstration of a possible interaction, not proof that agents can reliably produce any editing environment on demand. [A06](https://wattenberger.com/thoughts/code-is-a-medium-for-thought/) A practical method follows from this: ask for contrasting prototypes rather than a stream of arbitrary refinements. Decide what distinction the prototypes should expose before generating them. Perhaps one interface preserves a compact reading order while another makes relationships spatial. Compare both against the same task. Wattenberger explicitly recommends looking at multiple approaches side by side; our addition is to keep the comparison criterion visible while making the choice. [A02](https://www.augmentcode.com/blog/building-faster-than-you-can-think) The limit is easy to miss. More alternatives can become another form of avoidance. A collection of ten screens is not ten useful experiments if they all test the same assumption. The pause is doing work only when it changes your understanding, your chosen direction or your confidence for an identifiable reason. No claim about minutes saved is needed to make that useful. ## What makes a specification alive? Wattenberger’s Intent introduction was published February 10, 2026 and marked updated June 18, 2026 in the source retrieved for this guide. It describes isolated workspaces backed by Git worktrees, with agents, terminals, diffs, browsers and Git operations collected around a task. The article presents Intent as public beta and names support for Auggie as well as Claude Code, Codex and OpenCode. Those are source-described availability and integration claims, not integrations exercised by this publication. [A01](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration) The workflow begins with a coordinator that proposes a plan as a spec. The person reviews and approves it before implementation. Implementor agents can work in waves; a verifier checks their results against the spec before handing the work back for human review. Wattenberger describes this default setup as customizable. The important design mechanism is a shared reference across different roles, not the proposition that three agents are always the correct number. [A01](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration) The spec evolves as work proceeds. In her account, agents read and update it so that humans and agents can stay aligned as code changes. That is different from pasting a requirement into several independent prompts and hoping none becomes obsolete. A living specification has to preserve the relationship between current intent, assigned work and returned evidence. Without that relationship, the document can be frequently edited and still fail to coordinate anything. [A01](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration) The local lesson models that relationship with explicit versions. A design objective and interaction requirement form the spec. Approval records that version. A simulated implementor produces two dependency-ordered waves and a result packet. The verifier compares the packet’s version and interaction evidence with the current requirement. An intentionally stale packet can report completed work and still fail acceptance. We authored this versioning rule to teach the problem; it is not a reverse-engineered description of Intent’s internal implementation. Try changing the interaction requirement after approval. The fixture removes the old approval and implementation evidence. Then run the stale packet and inspect the mismatch. In a real workspace, you would need a richer policy for ongoing work, cancellation and partial reuse. The underlying question stays the same: which decision was this work answering, and what evidence makes it fit the decision we have now? Do not mistake a worktree for a permission boundary. It separates working copies and branches, not every possible side effect of an agent or shell. Likewise, a verifier is another fallible participant unless its checks and evidence are inspectable. This guide does not inherit the launch article’s broad claims about conflict-free parallelism as a safety guarantee. ### Keep implementation attached to a living spec Compare dependency-ordered implementor packets against an approved, versioned design spec. Completion is distinct from matching the current requirement. Try implementing before approval. Approve, simulate and verify a current packet. Then choose stale, simulate again and inspect the mismatch. Change the interaction requirement to see old approval disappear. Goal text is recorded but not semantically interpreted. Local only: static fictional fixtures. No model, network, shell, real team review or security boundary. JavaScript is required to operate these controls. In this Markdown edition, the complete fixture and procedure are readable here. JavaScript operates the controls in the HTML edition. Fixture: ```json { "taskGraph": [ { "id": "tokens", "dependsOn": [], "produces": "shared design tokens" }, { "id": "component", "dependsOn": [ "tokens" ], "produces": "filter component and interaction evidence" } ], "packets": { "current": "Carries the approved version and selected interaction.", "stale": "Carries the preceding spec version and pointer-only evidence." } } ``` Controls: - Design objective (`spec-goal`), action `set-goal`, initial value "Help readers filter saved research notes.". - Required interaction (`spec-requirement`), action `set-requirement`, initial value "keyboard". - Implementor packet (`spec-packet`), action `set-packet`, initial value "current". - Approve the local spec (`spec-approve`), action `approve`. - Simulate implementor wave (`spec-implement`), action `implement`. - Compare packet with spec (`spec-verify`), action `verify`. - Reset lesson (`spec-reset`), action `reset`. Initial status: Ready. Static fictional fixture only. Initial result: No result yet. ## Which context is missing from the recommendation? Putting knowledge in its place reverses a common framing. We spend effort giving a model context, but what context does the model’s answer give a person? Wattenberger compares a chatbot explanation of condensation with a phase-transition table, and a direct Svelte answer with documentation that exposes neighboring concepts. Her argument is not that the answer is necessarily wrong. It is that an isolated answer can make it difficult to discover questions you did not know to ask. [A03](https://wattenberger.com/thoughts/this-is-not-a-rant-about-chatbots/) This is directly applicable to a design agent. A generated screen might be accompanied by a confident explanation while hiding the range of alternatives. Why a dropdown rather than a segmented control? Why a linear history rather than a spatial workspace? A person cannot evaluate a recommendation well if the interface shows only the winner and erases the dimensions on which the decision was made. Our transfer is to show the chosen option inside a small, relevant comparison space. The essay extends the point to task-oriented agents with a pizza-ordering example: an order confirmation alone does not reveal whether the selected option was inexpensive, highly rated or a compromise. That is a design argument about orientation, not a request to expose every available data point. Wattenberger also acknowledges privacy and overload as constraints. More context is not automatically useful context. [A03](https://wattenberger.com/thoughts/this-is-not-a-rant-about-chatbots/) Our second lesson compares three invented interfaces for research notes: a compact list, a spatial canvas and a hybrid. The capabilities are declared fixture facts, not usability findings. You choose a requirement, inspect either the single recommendation or the full matrix, and check a selected candidate. A keyboard requirement eliminates the fictional canvas because that prototype lacks keyboard navigation. Requiring spatial grouping as well leaves the hybrid, with its explicit cost of keeping two representations synchronized. The checker does not announce a universally best interface. It reports whether the selected candidate has the named capabilities, along with its missing features and tradeoff. This distinction is the lesson. A recommendation can be valid for a requirement without becoming a general design ranking. Change the requirement and the comparison must be recomputed rather than leaving an old green result beside a new question. For real work, make a table with three alternatives, two non-negotiable capabilities and one meaningful tradeoff for each. Ask an agent to help build prototypes that expose those differences. Then observe people trying the task. Capability presence is only the first layer of evidence; a technically keyboard-operable interface can still be difficult to understand. The matrix helps frame the evaluation, but it cannot replace it. ### Compare a recommendation with its neighbors Place one recommended design inside a matrix of alternatives, required capabilities and explicit tradeoffs. A fitting candidate is not automatically a universal winner. Inspect a single candidate and attempt to justify it. Switch to the full matrix, require both capabilities and try the compact list. Then choose the hybrid, inspect again and check it. All capabilities are invented fixture facts, not measured usability. Local only: static fictional fixtures. No model, network, shell, real team review or security boundary. JavaScript is required to operate these controls. In this Markdown edition, the complete fixture and procedure are readable here. JavaScript operates the controls in the HTML edition. Fixture: ```json { "candidates": [ { "id": "compact", "name": "Compact list", "capabilities": [ "keyboard" ], "tradeoff": "Ordered list; no spatial grouping." }, { "id": "canvas", "name": "Spatial canvas", "capabilities": [ "spatial" ], "tradeoff": "Spatial grouping; this fictional prototype lacks keyboard navigation." }, { "id": "hybrid", "name": "List with spatial overview", "capabilities": [ "keyboard", "spatial" ], "tradeoff": "Both capabilities; two representations must stay synchronized." } ], "requirements": { "keyboard": [ "keyboard" ], "spatial": [ "spatial" ], "both": [ "keyboard", "spatial" ] } } ``` Controls: - Design requirement (`context-need`), action `set-need`, initial value "keyboard". - Recommendation context (`context-view`), action `set-view`, initial value "single". - Candidate design (`context-choice`), action `set-choice`, initial value "compact". - Inspect alternatives (`context-compare`), action `compare`. - Check this selection (`context-justify`), action `justify`. - Reset lesson (`context-reset`), action `reset`. Initial status: Ready. Static fictional fixture only. Initial result: No result yet. ## What should stay under direct control? Our interfaces have lost their senses argues that the interface should fit both the machine and the person. Wattenberger distinguishes the strengths of text, visualization, sound and haptics, and the different jobs served by typing, pointing, dragging, gestures and speech. This is an exploration of interaction possibilities, not a claim that all modalities belong in every product. The useful question is which channel lets a person express or notice the particular thing that matters. [A04](https://wattenberger.com/thoughts/our-interfaces-have-lost-their-senses/) Code Brushes provides a historical concrete example. GitHub Next’s January 2023 exploration asks whether editing code can feel more tactile, like painting. The described interaction is select a few lines, choose a brush and inspect the changed code. The page includes examples such as making code more readable, adding types and fixing simple bugs. Because the technical preview ended in December 2023, treat it as an interaction precedent rather than an extension to install today. [A05](https://githubnext.com/projects/code-brushes/) Selection carries context. A named brush supplies the transformation. A visible result lets the person compare the before and after. This is a different contract from sending an open-ended request and receiving a large replacement whose scope must be reconstructed. Our interpretation is that narrow editing surfaces can preserve agency even when a model proposes the content. Scope, preview and recovery have to remain explicit; tactile language alone does not make a transformation trustworthy. The third workbench uses two fields of fictional design copy rather than executable code. Select a heading or body, choose a shorten or question brush, and preview an exact replacement. Applying changes only the selected field and retains a one-level undo snapshot. Changing the target or operation clears the preview, preventing an old suggestion from silently applying to a new object. The replacements come from a fixed table, not a language model. A deliberate refusal appears if you apply before previewing. Reapplying a brush that would produce identical text reports no change. Undo restores the previous document, not an invented successful remote action. These small boundaries make the effect explainable. They also expose a limitation: one-level undo is not a durable edit history, and a string replacement says nothing about whether a rewrite preserves the author’s meaning. When designing with a real agent, use direct controls for choices that are easy to point at or compare, and language for choices that need explanation. A motion parameter, a selected region or a chosen variant need not be repeatedly translated into prose. Conversely, a visual control should not conceal the reason for a consequential decision. Good agent interfaces can combine forms instead of asking one text box to carry the entire workflow. ### Preview a bounded edit and reverse it Preview a fixed text transformation on one selected field, apply it, and undo exactly one edit. The unchanged field stays intact. Attempt to apply without a preview. Preview shortening the heading and apply it. Inspect the unchanged body, then undo. Try changing selection after previewing; you must make a new preview. This is a deterministic text fixture, not Copilot Labs. Local only: static fictional fixtures. No model, network, shell, real team review or security boundary. JavaScript is required to operate these controls. In this Markdown edition, the complete fixture and procedure are readable here. JavaScript operates the controls in the HTML edition. Fixture: ```json { "original": { "heading": "Explore all of your saved research ideas", "body": "This collection groups the notes you saved for later exploration." }, "replacements": { "heading": { "shorten": "Explore saved ideas", "question": "Which saved idea will you explore?" }, "body": { "shorten": "Your saved notes, grouped for exploration.", "question": "How would you group these notes for exploration?" } } } ``` Controls: - Selected design text (`brush-target`), action `set-target`, initial value "heading". - Text brush (`brush-operation`), action `set-operation`, initial value "shorten". - Preview local edit (`brush-preview`), action `preview`. - Apply preview (`brush-apply`), action `apply`. - Undo last edit (`brush-undo`), action `undo`. - Reset lesson (`brush-reset`), action `reset`. Initial status: Ready. Static fictional fixture only. Initial result: No result yet. ## How do you keep the loop intact? LLMs as a tool for thought describes a rhythm of externalizing ideas, receiving suggestions and reconsidering the whole. Wattenberger reports pinning thoughts for later and asking for analogies or feedback on the flow of a draft. Her point is broader than answer retrieval: the interaction can help a person create distance from their own thinking. Her confidence about remembered context is a report about that practice, not a storage or memory guarantee this guide extends to every model. [A07](https://wattenberger.com/thoughts/llms-as-a-tool-for-thought/) A workspace for agent-assisted design can support that rhythm by preserving a legible task state. On return, a person should be able to distinguish the current spec, exploratory alternatives, accepted changes and unfinished questions. A long transcript may contain the information but still be a poor re-entry surface. Intent’s living spec is one attempt to collect it; the structured context essay explains why the human also needs a map. [A01](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration) [A03](https://wattenberger.com/thoughts/this-is-not-a-rant-about-chatbots/) Start with one bounded experiment. Write the intended outcome and a testable interaction requirement. Ask an agent for contrasting implementations, then pause to compare them. Keep the accepted direction attached to the work, inspect the actual result and leave a short reason for the next person returning to it. If you revise the requirement, revisit the evidence rather than simply relabeling the old result. The final transfer test is not whether an agent can make the screen. Ask whether a person can explain the current choice, discover a plausible alternative and reverse a local change without reconstructing hidden history. Those are concrete interface behaviors a new designer can work on now, even while model capabilities and product packaging continue to change. ## Browser interface Open this page in a JavaScript-enabled browser and call `window.AmeliaGuide.discover()` in its main realm. Require `ready: true`, then inspect a lesson before acting. Native controls and agent requests use the same dispatcher. See the [interface contract](https://pure-maple-xmr8.here.now/agent-interface.html), [schemas](https://pure-maple-xmr8.here.now/agent-interface.json), and [skill catalog](https://pure-maple-xmr8.here.now/.well-known/agent-skills/index.json). This is not an HTTP action service or an MCP server. Every admitted action, including a domain refusal, advances the shared revision. Read the receipt's `ok`, not only `executed`. Reset clears lesson state but retains receipts; reloading creates a new page instance and clears both. No lesson changes an upstream product. ## Sources and boundaries Nine primary resources were read directly: eight substantive author or project pages and one public identity API. Sources include personal essays, Augment articles and a GitHub Next project page. Videos and animated demonstrations were not browser-tested. Intent, real coding agents and the researched prototypes were not run. Exact dates appear only where the source provides them. The personal homepage’s GitHub Next role is not used as current affiliation evidence. ### A01: Intent: A workspace for agent orchestration [Amelia Wattenberger / Augment Code](https://www.augmentcode.com/blog/intent-a-workspace-for-agent-orchestration). Source date: 2026-02-10; updated 2026-06-18. Accessed 2026-09-02. Intent team product, product-lead biography, worktree-backed workspaces, coordinator/implementor/verifier roles, approval, living specs and source-described beta status. Vendor-authored product account; no independent performance, security, conflict-free operation or live integration verification. ### A02: Building faster than you can think [Amelia Wattenberger](https://www.augmentcode.com/blog/building-faster-than-you-can-think). Source date: 2026-03-09; updated 2026-06-18. Accessed 2026-09-02. Deliberate pauses in AI-assisted work, specifications as thinking tools, side-by-side prototype comparison. Practitioner argument, not measured efficiency evidence; numeric fatigue and productivity claims are not adopted. ### A03: Putting knowledge in its place [Amelia Wattenberger](https://wattenberger.com/thoughts/this-is-not-a-rant-about-chatbots/). Publication date not asserted. Accessed 2026-09-02. Human-facing context, neighboring concepts, structured representations, tradeoffs and overload/privacy boundaries. Design examples and argument; no controlled evidence that a particular representation improves outcomes. ### A04: Our interfaces have lost their senses [Amelia Wattenberger](https://wattenberger.com/thoughts/our-interfaces-have-lost-their-senses/). Publication date not asserted. Accessed 2026-09-02. Task-appropriate modalities, direct manipulation, embodied interaction and the value of active participation. Speculative interaction essay; multimodal experiences and animation were not exercised. ### A05: Code Brushes [GitHub Next; project page credits Amelia Wattenberger](https://githubnext.com/projects/code-brushes/). Source date: January 2023; technical preview ended 2023-12-15. Accessed 2026-09-02. Selected-code brush interaction, concrete transformation examples, Wattenberger attribution and concluded project status. Historical research, not a currently available service. Examples are not endorsed as general code transformations. ### A06: Code was our medium for thought [Amelia Wattenberger](https://wattenberger.com/thoughts/code-is-a-medium-for-thought/). Publication date not asserted. Accessed 2026-09-02. Coding as a thinking surface, loss of product/code/team context and proposed custom editing playgrounds. Argument and illustrative interactive demo, not proof that agents reliably synthesize arbitrary interfaces. Raw source text read to recover truncated ending. ### A07: LLMs as a tool for thought [Amelia Wattenberger](https://wattenberger.com/thoughts/llms-as-a-tool-for-thought/). Publication date not asserted. Accessed 2026-09-02. First-person idea pinning, analogies, writing-flow feedback and an observation/planning/action rhythm. Anecdotal practice; no promise of indefinite model memory or measured cognitive benefit. ### A08: Amelia Wattenberger personal website [Amelia Wattenberger](https://wattenberger.com/). Publication date not asserted. Accessed 2026-09-02. Self-published portfolio of AI writing, brainstorming, data visualization and GitHub Next project references. Homepage still describes a GitHub Next role; not treated as current affiliation evidence. Linked videos not watched. ### A09: Public GitHub profile: Wattenberger [Amelia Wattenberger / GitHub public profile](https://api.github.com/users/Wattenberger). Publication date not asserted. Accessed 2026-09-02. Name, matching personal domain, handle, Sutter Hill Ventures bio and authentic public avatar URL. Identity and portrait metadata only; no follower counts or activity metrics are used. Portrait bytes not downloaded or visually verified. On your next visit, inspect the living-spec mismatch first if work has drifted, the alternative matrix if the choice is unclear, or the brush preview if a change feels too broad. Preserve the loop between making and understanding. The output is only one part of the work.