Maggie Appleton on Design Engineering in the Age of Agents

Maggie Appleton tells Gergely Orosz how she moved from anthropology and illustration into design engineering. Her work at GitHub Next explores prototypes for how developers might collaborate with AI.

She studied anthropology after growing up across cultures. She was drawn to observing how people live and how practices that seem obvious in one setting can look different in another.

After university she worked in illustration and visual design. Creating illustrations about programming required her to understand the underlying concepts, which gradually drew her toward frontend engineering.

At Elicit she joined a small team as its only designer. She recalls shipping quickly and working closely with engineers, giving her experience in shaping both a product’s interface and its underlying concepts.

Orosz asks what designers actually do. Appleton describes work beyond colors and screens: making sense of a problem and choosing the concepts people will use to interact with a system.

She calls these concepts the product’s nouns and verbs. A noun might represent a collection or plan; verbs define what users can do with it. The relationships between them shape the user’s mental model.

A difficult part of product design is making a coherent system from underlying complexity. Simplifying a developer tool requires decisions about what to expose, what to hide and how the pieces fit together.

Appleton says designers and engineers may focus on different materials, but good collaboration benefits from understanding both visual choices and technical structure, including data, APIs and implementation constraints.

She describes a design engineer as someone who engages deeply with implementation, not merely someone who adds attractive animations. Other design roles can focus more on research or representing users; teams need different combinations.

At GitHub Next, she and engineering partners make prototypes to test ideas. They do not assume each experiment will become a product: the aim is to make an idea concrete enough to learn from.

Appleton describes working on an interface for decisions in coding-agent sessions. A long sequence of questions can become difficult for a person to absorb; she explores presenting decisions as separate, reviewable pieces.

Some questions, such as minor border shades, are better answered by showing alternatives than by asking a person to specify a number in the abstract. The interface should match the kind of judgment being requested.

She shows notebooks filled with sketches and visual experiments. Drawing externalizes a partly formed idea quickly, before she has enough clarity to write a detailed prompt or specification.

A sketch does not have to be a finished visual design. Boxes, arrows and rough layouts give fast feedback and make relationships visible; the low cost of changing them supports early exploration.

She sees language models as useful collaborators but says their way of responding does not always match how people think through a design. Choosing the right representation is part of making that collaboration useful.

Appleton’s interest in woodworking reinforces the idea of understanding materials and constraints. Physical projects involve measurements, joints and practical limitations, just as digital products have their own implementation realities.

She distinguishes serious design engineering from a narrow focus on visual polish. A design engineer can work through interaction logic, state, data flow and implementation with the engineering team.

One source of friction is a design that is difficult to implement efficiently on a target device. Understanding performance or platform limits earlier can prevent expensive back-and-forth and lead to better alternatives.

She suggests designers can use agents as learning partners when engineers identify an unfamiliar constraint. The designer still needs to check the explanation and collaborate with the people who understand the system.

Appleton uses Figma for rough layout and collaboration but does not always take a mockup to high fidelity. A browser prototype exposes actual rendering and interaction that a static image may not capture.

She builds small “jigs”: temporary controls that let her adjust live variables and see the result immediately. Once a value feels right in context, it can be carried into the actual implementation.

Her research role differs from designers maintaining a mature product and design system. A prototype can prioritize learning, whereas production work must also uphold consistency, accessibility and long-term quality.

AI-assisted code generation makes interactive prototypes cheaper for her to build. Compared with wiring every screen of a static mockup, a working prototype can let a participant explore more naturally during a test.

She treats many prototypes as disposable experiments, so the engineering standards appropriate to a production system are not necessarily the first priority. A prototype that becomes a product still needs proper engineering work.

The live controls in a jig reduce the gap between changing a variable and seeing its effect. She can adjust an interface in the environment where it will run, rather than repeatedly editing code and imagining the result.

Asked whether designers are still needed, Appleton says models can produce useful simple interfaces, especially when a team has no designer. She believes more complex work still benefits from judgment about interaction, context and quality.

Designing an interface involves identifying a useful representation of the data. The conversation gives an example where a set of stacked cards was eventually better understood as a table.

She demonstrates tuning layout, contrast and texture in a live browser. The goal is to compare choices in context, not assume that an abstract specification fully captures how they feel.

Appleton calls the unevenness of model capability “capability gaslighting”: a system may do one difficult thing impressively, then fail at an apparently simpler adjacent task. The mismatch can make users overestimate or underestimate it.

Her talk “One Developer, Two Dozen Agents, Zero Alignment” examines a team coordination problem. If each agent session is private and local, people can lose sight of decisions made elsewhere.

Shared context can let teammates see and contribute to an agent’s work, but it also introduces questions about ownership, access and who is responsible for decisions. She treats the tooling as still evolving.

The interview turns to craft. Appleton says attention to details and understanding the materials matter even when an agent does more of the implementation; people still need to decide what quality means for the work.

She discusses recognizable visual patterns in generated designs and how style changes with cultural context. A repeated design convention may become unfashionable once it becomes strongly associated with automated output.

Her digital garden publishes work at different stages of completion. Labeling a note as a seedling lets her share a partial thought and return to improve it later, rather than treating every page as finished.

She also describes “home-cooked software”: tools made for a person’s own needs instead of relying on a generic product. Agents can lower the effort of making such tools, although maintenance and security remain real responsibilities.

Nonprofessional or “barefoot” developers may need better foundations and support. Generating an app is only the beginning; understanding its data, operation and limits matters if others will rely on it.

For engineers who want to learn design, she recommends observing and asking designers about their decisions. An agent can also help explore alternatives, but direct collaboration and feedback remain useful.

Anthropology offers another lesson: assumptions about time, symbols and interaction vary across cultures. Designers should learn how their actual audience interprets a product rather than treating one convention as universal.

She recommends observing people in their real environment to understand when and why they use a tool. The surrounding work and social context can reveal needs that a detached interview misses.

Appleton recommends Addiction by Design as a way to think about how systems shape behavior. The conversation closes by emphasizing that design choices have consequences for the people using a product.