▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=KZSzF0KEFRg
• Original title :: Design Engineering with Maggie Appleton

Maggie Appleton — cultural anthropologist turned illustrator turned staff research engineer at GitHub Next — on what design engineering actually is, why she still starts every project with pen and paper, and how agents have and have not changed the design process. An unusually visual episode: she brought her sketchbooks.

From anthropology to design engineering

Appleton studied cultural anthropology, fell into freelance web design out of necessity, spent four years as an illustrator and art director at Egghead (where she learned React by having to understand what she was illustrating), then was the founding and only designer at AI startup Elicit for two years, shipping a feature a week.

She defines product design as problem-solving with different materials than engineering — space, size, weight, color, motion, copy — plus the harder work of choosing a product's nouns and verbs. Easy for a sneaker store; brutal for dev tools and agentic products, where nobody yet knows what the primitives are. Sessions, plans, MCPs, skills: which of these should be first-class, and can you fork an agent session? The craft is reducing that complexity to a small canonical set users can point at without being surprised by the result.

A design engineer, to her, is a designer who genuinely engages with the engineering — understands the backend shape, the architecture, what the models can do — and usually implements the front end themselves. She dismisses the Twitter usage of the term for people who make nice hover effects: an agent can do those without you reading a line of code.

Why designer-engineer friction is a tools problem

The classic tension — a pixel-perfect Figma file the engineer cannot implement, a gradient that wrecks scroll performance — she blames on Sketch and Figma having no relationship to the constraints of the medium. You must understand the materials you build with, the same way a furniture designer knows how oak behaves. She is hopeful agents fix this by letting designers step into the engineering side and use the agent as a patient tutor for error states, state machines, and backend shape. The same works in reverse: engineers can ask an agent to teach them typography or sidebar principles, knowledge that used to require being on a design team.

Paper, jigs, and the new process

She still sketches on paper first, because agents take only text, are bad at spatial reasoning, and cannot see. Drawing an idea is faster than describing it, and the sketch stays on the desk tomorrow instead of vanishing from a screen. Gergely draws the parallel to whiteboard architecture sessions.

Figma stays medium-fidelity — enough to settle contrast and text size — then straight into the browser. From there she builds jigs: the term comes from woodworking, a little device that does one specific job. She asks the agent to attach live sliders and color pickers to whatever variables she is unsure about — animation speed, gravity on the stars, glass opacity, grain — tweaks them in the running page, then commits the values she likes. She demos one built for a new GitHub Next homepage with an animated spinning constellation. She calls it building your own Figma as needed, and connects it to Bret Victor's argument for direct, live feedback.

Prototyping is a different game now: she can hand an agent a Figma file with instructions to screenshot and loop until it matches, run it overnight, and have the interface waiting in the morning. What used to be days of throwaway grunt work is gone; the work that remains is everything before the handoff, plus PR review.

On whether engineers still need designers

Asked about the engineer who generates 20 high-fidelity alternatives with Claude and iterates, she is pragmatic: if you have no designer and need to validate a hypothesis, do it. But she looks at model output and sees obviously generated, poor-quality work — agents apply universal design principles too rigidly, labelling everything in text where an icon button would do. What a designer brings is someone assigned to think the problem through properly: experiments, user testing, finding out what people actually understand.

Two related observations. Capability gaslighting — her term, arrived at independently of Ethan Mollick's jagged frontier — is the feeling of a model impressing you on one task, failing the next, and your prior belief in its competence hiding how badly it failed. Unlike a human expert, models are inconsistent day to day.

And AI design has a fashion problem. The Linear/Vercel minimalist look, or Claude's cream-background house style, is becoming a tell that no human was involved — and people may start rejecting it out of hand. Design lives in a cultural context that shifts; models cannot see that context. Gergely notes he has the same instant recognition for AI-written prose.

Her Elicit story cuts the other way too: the team tried infinite canvases and stacked cards to replace scientists' spreadsheets, and every user interview asked for a table. Sometimes the UI of AI is just the familiar primitive with more power layered around it.

Collaboration is the unsolved problem

Her talk "One developer, two dozen agents, zero alignment" argues the bottleneck has moved. Individuals with agents are fast; teams are not, because no agentic coding tool is real-time multiplayer — sessions are private and local. GitHub Next's ACE prototype (Slack-like interface over shared sandboxes and microVMs) proved too ambitious for a four-person team, though its sandboxes shipped into the GitHub desktop app. Gergely points to Ramp, which built a forced-collaborative internal version where anyone can join and redirect any session.

Even with multiplayer, she argues, decisions need to become a first-class primitive: large enough on screen to actually understand, with the right interface per question (show me the architecture diagram, not three text options), assigned to a named human for the audit trail. Her current prototype attacks exactly this — planning today means being grilled by 30-odd A/B/C questions until your brain shuts off and you just press enter on the recommended option. Agents emit reams of text, which is a fine output for them and a terrible input for humans.

The team's next question: if intelligence were free and you had 100 background agents, what is the least annoying way to consume their output?

Craft, and a few other ideas

On whether craft decays as you delegate: she is not precious about clean code, but agents cannot design to her standard, so she is still in there fixing transitions and padding values. Design skills that encode her preferences do not apply reliably. She wonders whether she would enjoy it if they suddenly worked.

Other threads: digital gardens — a blog where posts carry seedling / budding / evergreen stages so unfinished work can go up honestly, which cured her perfectionism and let her publish far more. Home-cooked software (Robin Sloan's term) and barefoot developers, after Maoist China's barefoot doctors: lightly trained power users who build the small software their community actually needs. She argues they need local-first frameworks with sane security and data persistence, since vibe coders are otherwise building on terrible foundations.

Advice from anthropology: read enough of it to internalize how varied human worldviews are, and if engineers gain free time, spend it on user research — embedding with the people you build for. Book recommendation: Addiction by Design by Natasha Dow Schüll, an anthropologist's study of Las Vegas slot machines and the people who design them to be addictive.