Sculpting a shapeless medium with Amelia Wattenberger June 2026 Most AI tools today are a chat box and a shrug, and Amelia Wattenberger thinks it's a shame. She's been articulating her point of view over years through essays "Our interfaces have lost their senses", "Fish eye for text", and "Why chatbots are not the future". She argues that flattening every interaction into natural language strips software of the affordances that made it usable in the first place. As designer-developer hybrid, her latest work on Intent is the sharpest articulation of that thesis: how do you build structured tools for a shapeless medium? Her answer, more or less, is that software still needs bones. Ryan Mather Hello Amelia we're so glad to have you! So, you just shipped Intent, congrats. Before we get into the product itself, can you set some context for us? What's your role at Sutter Hill Ventures, and how does Intent fit into the broader landscape of AI coding tools right now? Amelia Wattenberger My role at Sutter Hill is basically an in-house role where you are whatever shape person you are. I like to do design, development, and product, which is a large reason I've been at Sutter Hill — I don't want to be on a design team or be a developer. I like doing all of these things. I've been helping out this one company, Augment, and pushing them to be more opinionated and ambitious, exploring what we can build to supercharge development now that we have these crazy new tools. I've been prototyping different future tools, and we finally shipped one as an app, which is Intent. On the one hand, it feels like so much is changing. Every single day, there are like five launches in the same space I'm working in. Every tweet is, "if you're not doing X, Y, Z, you're dead in the dust! and you'll never get a job again." And people keep liking them. But if you zoom out, not much has changed. There are like four or five distinctive eras: There was the GitHub Copilot era, which was basically autocomplete Then it was, "AI is cool, actually, it answers questions, so we're going to have conversations with it" — let's put a chat sidebar in the IDE: The chatbot era. Then it was, "wait, AI can actually do things instead of telling me to do things" — let's give these chatbots agentic tools: The Agent era. Then it was, "wait, but I'm a developer, and terminals are where it is" — let's have ten terminals. I'm using tmux, I have a bunch of key bindings, I'm having ten conversations at once. Isn't this cool?: The Terminal/CLI era. And now it's, "wait a minute, I'm totally fried. And, you know, buttons are great, actually. So let's maybe try putting this in an interface." - Where we are now. RM What's crazy is that fourth era, (Terminals) feels like it lasted three months. Federico Villa Yeah, based on something you mentioned earlier, about there being this overwhelming feeling that there's a lot of information and noise, and how difficult it is to manage... what if anything helps ground you? AW The narrative that if you actually zoom out, things haven't changed that much, has been one of my coping mechanisms. There's just a lot going on and a lot of people trying to get attention. It makes it hard to be super creative, which is kind of interesting — to have longer-form, more distant thoughts, the more noise in the day-to-day, the harder it is. But designers need to do this even more. To do good work, I need to have my own thoughts. And it's hard to have my own thoughts when there's so much going on. This is something I've been intentionally making time for — just stepping back. The best thing I can do isn't quantity, it's quality. Especially as it's a race to the bottom, I think the only way to stand out is to have your own thoughts that deviate from the mean. FV I was watching Intent's launch video, and you mentioned that you can see things from a more high-level view, and you can work more in abstractions. Can you talk a little bit about that — how it's changed your behavior of how to approach work? AW Sure! Here's a little bit of my thinking leading up to Intent: going back to my time on the GitHub Next team, I did a project in 2022, (before AI was the most important thing ever.) With GitHub being fully remote, there was this question of how do we properly collaborate with our teams? It became obvious almost immediately that proper collaboration is not just multiple cursors in a code editor. It's all the other things that are part of a developer's work. It's the conversations you're having with your teammates that are usually in Slack. It's Linear issues, GitHub PRs, and the git branch you're on. There are a million things scattered everywhere that need to be put in the same place, because in order to have a conversation, you need to work with that foundation of what everyone's actually talking about. That project went nowhere. But I tried to bring some of the same thinking back, because I think it's more relevant than ever, now that we're trying to collaborate with a bunch of agents, that we just need that shared context where we can work with it, and not just inject it into each chat thread. So in Intent, the core unit of work is a workspace. It's not an agent chat, which I think most of the tools out there are centered around. You start a new workspace for any given task. There's an isolated copy of the codebase. There's zero to n agents that can delegate and talk to each other. There's one primitive, which is a rich markdown note — you can do that in a code editor, but we've been sneaking in affordances now that everything's integrated. We have Subtasks for example that agents can be delegated to work on. We even have interactive diagrams that link to GIFs and code files and step through states. Runnable CLI commands — you can add a button that says "start the dev server." We can metaphorically wrap any given task in a membrane, so we can deal with them one at a time, and maybe in parallel. Give one or two new primitives to help cohere everything and make communication easier and make everything really transparent. If I'm running things from the CLI, it's really hard to see what they changed and where I am in the status of a task. Once you put that stuff in a bundle, you can start layering more on. FV Has that changed the percentage of time you spend instructing the models? It feels like Augment is focused on the components that lead to better co-creation between you and your agents. AW Yeah, that sounds right. I do end up doing less prompting. I used to have keyboard shortcuts for snippets like, "I'm working in this folder, don't touch things outside that folder," or "the spec is here," or "we're working with these logs." By default, when you make a workspace, an agent will research and put together a spec for you. Working from the spec feels like you have this compressed description of the things you and the agent should be working on, that you don't need to repeat every time you start a new thread. It's living, so you can also use it as the steering panel — the control plane for what's done. Let me tweak it, that kind of thing. RM So kind of like a project-level, slightly-more-scoped agents.md or claude.md. AW Yep. I think about it like — if you had to understand what a codebase is from the commit logs, that's kind of what we're doing with agent chats. You're working with an agent on making a set of changes, but the only place I can look to see the state of the work is a chat history. RM What does it mean to design for agents to use something? Is "agent as a user" something you find yourself spending cycles thinking on? AW Within the app, we have a set of specialists, which are basically personas, and we ship with a default prompt for each of them. The coordinator's prompt is, "put together a spec, do your research, and then when the user is ready, delegate to implementer agents." Implementers are another specialist agent. Verifier agents verify the implementer's work. Those are three specialists we ship with. A little tangential, but I think this is one of the most interesting things I've been thinking about: that the behavior of consumer applications has been hardcoded. How does a game work? How does an app work? Once X happens, what happens after that? What are the components that work together? It feels like 80% of the app behavior is now baked into these prompts, which is really interesting, because users can go in and tweak the prompts and make their own specialists. It's a new dimension in which apps can be dynamic. We had image maps exported from Photoshop with a certain resolution, and then we were like, "wait, screens are going to be different sizes — this isn't going to work anymore." So we needed layout algorithms. Then users could interact and change what's on the page — so we made them dynamic through time. Users had preferences — so we made them dynamic based on the user. And now there's an additional dimension where even the app behavior itself can be completely changed - custom to you. So designing now is a dance of, what are the primitives to add to the structure? Are we using bricks or another building block? And then the user can fully configure the app's behavior, which I think is the only way to build a product now. Otherwise it'll be stale in five months. Someone else will build a new app that does something around the workflows that people want. RM If we keep drawing this line, does it mean designers will all be competing on the same generic product — which is "you can do absolutely anything"? AW I have a feeling that applications as a paradigm will not last much longer, at least as the main way we interact with computers. Things will be way more modular and definitely decoupled from the data. There will also be a strong remix culture, because people don't want to create everything they want from scratch, but they also want the ability to customize the things they use. So things are going to get super wacky. RM Stepping back — can you walk me through the key product decisions for Intent, and how you arrived at them? Regarding specialist agents in particular, how did you decide whether to have specialists, and which specific ones to have? AW Yeah, so, I was prototyping for a long time — by which I mean two months. I kept saying there are three pillars, three things that, if we build a harness around, will be superpowers for developers: | Spec-driven development, Agent orchestration with agents in parallel Bundling things together in a workspace. That was the brief. What do we build? Could be anything. It actually started as an extension inside their VS Code extension. We'd take over a webview, and things were pretty hardcoded. You'd start with a plan, which was checkboxes. At some point you were happy, and it would turn that into a spec, which was a long-form text spec. Then the agent would go through and check off those checkboxes. That's nice, because you get a lot more handholds — and we know what percent it is. When you have those rigid constraints, you get to build a lot more UI on top. But it just felt like it wasn't ambitious enough, and wasn't different enough. We’d ask “Is this really how I want to work?" I have tasks that don't fall into this flow, and why are we in VS Code if we're not even really using it that much anymore? So it evolved into a native app, but it still changed shape a few times. The tension was always — I'm used to designing in a world where I am pretty heavy-handed about how the app works and what it looks like. There were multiple stages of loosening that part and being like, wait, what does being more agentic and leaning into AI mean? Do we have to have steps and then a plan? Or maybe we just have notes that you can use in other ways. One of the coding companies made a really nice "walk me through a set of diffs" UI — it's hierarchical, goes through the diffs, has comments on the side. That's really nice. But what if we just added the affordances to a note, and then users could define how things were composed? People could share the way they had it set up. And it's natural language — so you're programming the app behavior. RM It strikes me that the move here in general is, how can we make this more of an open-ended playground, instead of designing a bespoke kind of thing. AW But then it's really hard to design. It's not just, what can you design — it's how do you instruct someone how to hold a tool that is the shape of Play-Doh? RM Imagine you give someone a hammer, and you're like, "oh, by the way, if you walk up to a tree and you go in this motion, it'll turn into a saw. It'll read your mind and transform into the tool you're thinking of." As the user holding that, you don't generally have thoughts in the form of "walk up to something and transform it." AW It's even more than that. To your earlier point about generic applications — it doesn't even look like a hammer. It doesn't look like anything. It's a chat box. Use this. Type into the chat box. RM Switching gears a bit, Intent launched in mid-February. What are you hearing from users? Any emergent behaviors that surprised you? AW We hear about this tension we're just talking about. Half the users are like, "I don't know how to use this." And it's even more than I expected, because what I've surmised is everyone's coming with a different baseline expectation. Some people are coming from no AI tool usage. Some are coming from VS Code agents, or Cursor, or Codex, or ten Claude Code terminals. Orchestration might be new. Workspaces and worktrees might be new. And it doesn't work the way any of them expect, because it's this new thing — but it looks like the old thing, because it has code files and agent chats and terminals. I just didn't do a good enough job explaining how it works, because I had been using it for so long. Obviously when you do this, you can have agents delegate to each other. But, you know, no ones probably ever explained it. So it's been half people being like, "this doesn't work like the tools I'm used to," either unhappy or confused — and half people who really get it, and it's super-charged the work they do. The other pitfall is, you can do more work, and then you have to pay more money, because work costs money now in the form of tokens. That's another thing we need to make more explicit. It's an interesting byproduct: we make it easy to switch tasks, which means you can do ten tasks at once, which means you're doing more work and also spending more money. RM We should just hook it up so startups connect their VC's bank account. You'll get more products faster. AW It's funny — every time I talk to someone who's a manager at a big company overseeing a bunch of devs, they're like, "how do I cap my developers' token spend to $100 a month?" It feels like the wrong attitude. You're not gonna win with that attitude. You're gonna fall behind. What you should be doing is maximizing the expertise your developers have in harnessing AI coding tools, as opposed to trying to cap that. FV How many agents do you have running at one time? AW Before the product was ready to use, I built a harness so I could run as many at a time as possible. I'd do a big refactor, and made this parallel agent running system where they could run in waves — up to twelve. FV How do you manage your governance as the central user? You're the orchestrator. I feel like I can only hold so much context in my mind before I have to talk about it with someone. As a manager, you're holding the context of all your reports. Does that carry over to a world where you're managing agents? AW One thing I'm really interested in is, what mechanics and paradigms can we steal from people governance — but also at the same time, what should we not steal? Because the physics are different. I think about big companies as elephants and small companies as ants. You can't just scale up an ant, because the insides are people. RM That's our tagline :) AW And to make it worse, the insides aren't people anymore. They're agents. Agents are different than people — they have different constraints. They work really quick, but have different pitfalls. There's a lot of interesting reflections to pull on here... OK, Let me actually walk through the app. So, everything here is a workspace. These are the things I'm working on — review PR, some tasks, a feature, a bug fix. Anything I'd have as a chunk in my head. My favorite demo is, "add dark mode to my website." So you can work on different projects off different branches. You can choose whether to use normal agent orchestration, which is our smart-default flow, or "Wild West, use your own specialist." We're kind of riffing on this. When I run "add dark mode," it creates a new workspace, which is some number of agents. It starts with a coordinator agent context, which is notes — it'll do research and write up a spec — and a clone of my codebase, which lives in a different folder. I can also open this in my normal editors. I don't think we get to take over developers' entire workflow. We have to let them use any of these 10,000 tools that exist in VS Code, or whatever they're used to using. The way I think about changes is kind of like blocks in a canal — you're increasing your confidence in the changes slowly. They start unstaged, at some point they get staged, then committed, then a PR, then merged. I've tried to be a little opinionated about the flow, because I think most developers have the same flow. So my boy Opus is looking around. Augment has a really good context engine, so it does these semantic searches about how things work right now. Then it comes back with a plan and a little summary. This is what a note looks like — an editable, rich markdown format with these subtasks. I can edit it. I can say, "no, I want it in the bottom right." At some point I approve the plan, and the coordinator looks at the subtasks, figures out what it can delegate in parallel so the agents don't step on each other, and creates new agents to work on specific tasks. FV Where is the coordinator on this screen? AW We have this kind of bonkers panel-tab system that mirrors VS Code. The coordinator thread is open here — the chat panel with the coordinator. Over here is the spec note. I can also open up the sub-agents. FV in essence you work on the context spec with the coordinator, and then the coordinator opens the layer down where it does the same thing with each specialist in a specialized format. AW Exactly. For each subtask, the scope is clear — usually it'll say "touch these files." And the implementer is a different type of specialist. It gets a prompt like, "this is your task, note, only do this task." You can see the pain behind that prompt. RM Going back to the agent overview screen. What's the story behind it? How do you think about it? AW There's an interesting dance between moving up the ladder of abstraction and getting more leverage so that fewer words do more. What's the Office Space line — "why say more words when few words do the trick"? I have a lot of leverage when I get to work at the level of "add dark mode." I was actually just putting together a diagram where I think of this as an expansion of text. On one side is my prompt. On the other side is the full code, which has all the detail. The spec lives in the middle. The agent has fleshed out what this might mean, so I can tweak it before it gets so big and unreadable. It's a timing thing, and also — what's the fleshed-out detail? What are the details important for me to change, but not so much detail that it's too much to read and hard to steer. FV You flashed a visual diagram a second ago. Do you still sketch? How do you sense-make nowadays? AW I'd love your thoughts on this. Development used to look like this — you'd do a little planning up front, then you implement, you go through the code, and then review afterwards. But really it looks like a recursive loop of plan, implement, review, where you work through the different parts of the code that need to be changed. We can all agree that agents have shrunk the length of time you spend on the implementation phase. But it's also removed the internal planning and reviewing loops, because you're not doing that work. And we do less planning up front, because we can say "add dark mode," and the agent will flesh out assumptions we'd otherwise have had to decide. We're like, YOLO, the agent can make whatever assumptions it needs. We've shrunk the amount of planning and thinking — and even then, planning was another word for also thinking, in some senses — that was built into the way we used to work. What I'm trying to argue is, we need tools that make this upfront planning better. This becomes most of the work. There are arguments to be made that reviewing is now the work, but I don't think that's the case. I think planning is the work. How do we build in these loops where we're planning and reacting in order to steer it more Intentionally — as opposed to just say "do dark mode," and then youre in a situation where you dont know if itlooks good or bad, and unsure what prompt you should put in the box next time?" Like tools for evaluating thought — sketching something down, looking at it, reacting to it, evolving your thinking as part of the process. How do we bake that into the tool so that we arrive at things that feel more intentional and more directed and more differentiated? Because if you don't steer it, you're just going to adhere to the mean. RM Let's revisit the three bets — specs, orchestration, workspaces. Start with specs. Are specs as useful as you thought they would be? Anything you've updated since launch? AW The thing that's most clear is how personal these things are. Everybody wants to think about things differently. That's partially why looking at someone else's Figma or someone else's code is so hard — it doesn't have the rigidity that forces you to normalize it. So it more represents the way I think about things, or the way you think about things. That's where the tension comes from. I don't want to be in Ryan's brain. I want to be in my own brain. We can at least agree to be in this middle ground, which documents make you do to some extent. With specs, some people are like, "I want them to be longer, or I want these sections, or I only talk to the agent, or I only look at the spec, and the spec is the way I steer things." Everyone does their own thing. That's the thing that has most stood out. RM When you launched, surely some cohort said, "the spec is dead! you can just express an idea, get an implementation, react to the implementation." What's your response to that? AW It's interesting because we haven't gotten any feedback like that. But I can definitely see people having that reaction. I think people have pushed on agents enough that they really feel where they fall down. And if you don't like the spec, you can just not look at it. So maybe that's contributed to the lack of spicy takes in that domain. RM That reminds me of this app my wife built - a sewing pattern finder app — you take a picture of any garment, and it finds a sewing pattern online that's similar. I think it would have gone much smoother if she'd built it in Intent. She kept hitting bugs and asking why it didn't work, and I was like, can you make me a diagram of how you wired it up? When she actually did, the spec would have been totally Byzantine — this hands off to that, which hands off to that. AW The way I think about agents is that they work really well within a certain scope, which is partially why splitting things up amongst agents is helpful. They're like, "this is my job, this is what I do." If you're working at different levels of abstraction, it's really hard. If you have one master plan, and each agent only works on this one task, you get a lot better results. The spec is the skeleton through which you can afford that. Otherwise it's like nailing jelly to a tree. It's an elephant and you're a blind man, and you're only looking at one part, and then the next part, and the next part, but there's no cohesive plan that anybody's in charge of. It turns into this weird Frankenstein where there's no structure, just kind of a mess, because you've tacked on duct tape too many times. RM This reminds me of your most recent post about making computer stuff feel more like painting, rather than making painting feel more like computer stuff. AW Yeah. We're just going down the CLI path again, is how I feel. We need to build the generic layer where you can kind of do anything and it's really flexible, in order to figure out what the interfaces are to build on top of it. People keep being like, "oh no, but text is so natural, it's natural language, this is going to be the end of interfaces. We're not going to have buttons or sliders anymore because we have chatbots." That's not a future I want to live in. RM Is that skepticism based on your own soul and heart, or on a pragmatic design lens — this is not optimal, there's a better interface out there? AW Both. I personally don't want it to just be text or speech. Speech is actually really cool. But I also think these open-ended, like -- natural language is really good for rough directions. You're starting somewhere, it could be anything — how do you narrow that down? An index of all the possibilities. What do you do when you go to Google Maps? You're like, "I want to look for restaurants" — I don't want to pick that out of a list. I went to the bank this morning. I'm not going to pick "bank" out of a list. I want to type it because the space is really large. But once it gets smaller, I want to see it on a map. I want to see the options in a specific way, see some data visualization, pan around the map. Imagine driving by voice. It's horrible, right? RM Driving by voice — that's kind of like sitting in a Waymo, which has its own unique benefits. AW Yeah. There's a spectrum. I'm fully in control, I'm not in control at all — and the AI’s doing it. Over here, delegating by voice is probably really nice. But the same things apply broadly. If I’m looking for directions, or for a pizza place — I want options, I want pictures, I want to react to things. Only having voice or chat is only optimizing for the parts where I don't really care to be in control. RM Do you have any thoughts on generative UI specifically — problems or opportunities that have surprised you? AW I haven't gotten to play with generative UI as much as I've wanted to. But what I have played with — you quickly run into questions about, when you take away the existing structure of interfaces where it looks the same for everyone and we know the flow, what structure do you add? I don't think you can just make everything loosey-goosey for that to work. You need to look along different axes for structure so the user has some dependable things. I think about a straw that's really bendy, and someone trying to do a thing with it — it's just not a very powerful thing. Or clay — you can't build super big things with clay, and you can't go really quickly, because it's infinitely moldable. Anything that's generic is the jack of all trades, master of none. If you want something really powerful, you need some structure there. You need bones, you need muscles, some affordances. You can't just be like, "oh, it's a pile of goop, and stuff arises from the goop, that's not what we all want." RM What advice would you give to someone who's stuck? I see this with students — a lot of student AI projects basically look exactly like ChatGPT. They're interested in working with AI but don't have ideas for interfaces that are differentiated or unique. AW I've been very spoiled because I've recently been working on developer tools. The key really is using it for specific use cases. I hear so many people pitching their product and they're like, "oh, you could use it for this." And it's like — but do you do that? Personally? Start with a use case. Start with three, but focus on one at a time. Even if you're like, "this is the general space I want to focus on," have one person, like a persona — Debbie wants to do this, I want to make Debbie's life really easy. Let's only focus on that for a few weeks. Okay, that one's good. Let's focus on this other person. You start narrow, but then you start broadening. That's the best way to make a general interface that's flexible, as opposed to starting broad and going in. Because then you don't know if it's helpful for anyone. RM There's a trick novelists use — if they're overwhelmed, they say, "I'm writing this book for one person, my brother." It can free you from feeling it needs to be everything to everyone. AW Yeah. I just need to please this one person. FV Something I think about is when do I benefit from collaborating with other people? It's usually when you're trying to form an idea and you don't know where it's going. I'm a talk-to-think thinker rather than a think-to-think thinker. When I'm working in Antigravity, I'm having to express myself in a way that doesn't feel natural to me, but it's very efficient for the type of work where you can have a swarm. For the planning part, what really matters is having a person who can hold the ambiguous context with you. How do you make those decisions Amelia, and do you think it's going to change? AW This is the thing I most want from AI tools, and that we have not found yet — how do we make it a tool for thought? It's something I keep pushing on with existing tools. I like to sit in the bathtub with my phone like, ChatGPT or Claude, and just talk at it and have it talk back to me, and be like, "that's wrong," or "let's go down this rabbit hole," or "can you flesh out my thinking on this?" The tools are not super satisfactory, because they haven't been built for it. It's more of a branching, going down rabbit holes. I think about sculpting a lot How do you unearth a structure from raw material ? It doesn't all happen at once, it doesn't happen linearly, you don't do the whole thing at the same time. I think about augment versus automate. What I want is for this to be a tool that keeps me working in a tight enough loop. You see developers really frustrated these days because they lost their flow. "Oh no, our job is dead because we don't have flow anymore." But really, we don't have the right tools that keep us in control, and the pace correct, such that we're steering and using our expertise in small bursts — as opposed to a big handoff, and then waiting for a long time. RM One of your strengths as a designer-engineer is creating prototypes. Do you have advice on how to approach prototyping? For some it can be intimidating to know where to start. AW A lot of prototyping tools go too far. You see something and it's like, "I did it, ta-da." You look at it and it could be good enough, but because it's gone so far so fast, you haven't been able to really craft the pieces that you’ve made. It becomes harder to focus on the details and really shape it, because there are so many points along the way where you're like, "that's good enough, that's good enough, that's good enough." And four hours later you're like, "wait, I don't like this." RM Your prototype for the "Our Interfaces Have Lost Their Senses" post — the brainstorming one — has these beautiful gradient outline things, and that stands out. I've vibe-coded prototypes and they all end up looking like the same Tailwind. How do you think about those details, and when it's worth focusing on them? AW A person I worked with used to say this a lot — what is prototyping? It's basically figuring out what is the question that next needs to be answered, and answering it. That weighs in here. It's cool that I can now scaffold all the things I'm not focused on right now. I'm like, "what I really want to explore is a weather app, so I can spin up something that fetches weather data. Make sure it pulls every minute. Make sure it works for all cities. Add some dummy data, because it's not important." Then you have the vague shape of a thing. And you're like, "okay, I really want to focus on the icons for the weather for different types. Make me a test page or Storybook page that has all the different card types I could possibly do." Then you can really craft that. I say this — I'm not good at this. It's really hard right now with the tools that we have. Once you do that, you're like, "okay, what's the next thing I want to focus on?" You have this stone block, and you're slowly working on different parts and honing different parts of it. That way of going forward is the right way to prototype. Whatever you're focused on, you can focus on, because the other parts kind of magically appear, even if they're not great. RM Coming back to the field guide ethos, probably half the design field is starting to use AI for the first time right now, and there's not a lot of great resources. So we're trying to demystify what it's like working with AI and give people inspiration and practical tips. What would you want to say to those designers? AW This is a very go-back-to-first-principles moment. Don't look at what everyone else is doing. Just play around with these models, see what they're capable of, figure out the texture of them and what they are as a medium. What are they good at? What's new? What are they bad at? And don't throw out all the old stuff. What I don't like to see is all these "AI-native" things — which just means only AI. AI coding tools where you're like, "let me move this function from this file to this file," and it rewrites one file and then rewrites another file, when we have the ability to just copy and paste, or move this file from here to here. Old-school coding is still great. This surfaces things like embeddings. I want to see people use embeddings more. We now have a way to turn language,thought and concepts into math. That's crazy. I don't see people playing around with it as much as I'd like. I'm not an expert and I can't do a deep dive on what embeddings are. In my head, they're vectors in a very high-dimensional space. They can be near each other or far away. With the pen pal thing I played around with, if you take two spots in latent space and create a spectrum between them, you can make arbitrary spectrums between cat and dog, or abstract and concrete, or happy and sad — and see where anything maps onto that, or how far away it is. That's cool. We can probably do really cool new things with that as part of a bigger system. That's where I think the really interesting interface breakthroughs will come from. RM Two themes I feel are emerging from your work are play and love. By love I mean, in your writing there's a yearning, an appreciation for what software could be, how things could feel. With play, a lot of what you're describing is about encouraging others to play. Does that bring anything up? AW That's interesting. I feel so lucky to be able to do the work I do in the time I do it. I've met designers who spend a year doing the undo button on Twitter, and if that were the way of things, I wouldn't do design — that's not what's interesting to me. What's interesting is, how does technology fit into our lives, and how does it enrich it? What are the things we can do now that we couldn't do before? When I joined The Pudding, they did these data-rich interactive articles. The underlying theme was — we took newspapers and put them online, we took books and put them online. That's what the majority of websites are. We have this new medium to work with where, even just the web, not AI, it's dynamic, it's interactive. Let's rethink things. Now there's a new level. We have LLMs, which turn fuzzy things into structured things, or structured things into fuzzy things — text into audio into images. There's so much room for exploration. All of that is coupled with a disappointment with seeing the same thing over and over again. Let's think a little bigger. Let's enjoy ourselves a little. Robin Chen Have you noticed how teams have changed their workflows to work with Intent? AW I think the boundaries between roles is definitely changing. The tool isn't designed for designers — Augment is more focused on enterprise developers — but we've onboarded designers at Sutter Hill Ventures, and they're getting a crazy amount of use out of it. It's no longer, "I made this thing in Figma, hand it off to an engineer, add notes for how to implement it." We connected Figma — you can load it within the app, select things, you have the coordinator chat, the Figma right next to it, maybe another tab with the actual implementation. You're just going at it with the coordinator. The loop is quick enough that — one of the designers in standup yesterday was like, "look at this animation that happens when I scroll to the right section." That fluency affords much more native-feeling websites than you would have gotten from Figma-then-handoff. That's the future we deserve IDE Integrated Development Environment — the application a programmer writes code in (VS Code, Cursor, etc.), bundling the text editor, file tree, terminal, and debugging tools into one window. EMBEDDINGS A way of turning text (or code, images…) into a list of numbers that captures its meaning, so software can measure how related two things are. They power AI search and "find me similar things" features. CLI Command-line interface — driving a program by typing text commands into a terminal, instead of clicking around a graphical UI. DEV SERVER A program a developer runs on their own machine to preview an app as they build it, auto-refreshing on each edit. DIFFS The added and removed lines between two versions of a file. "Reviewing the diff" is how developers — and increasingly AI agents — see exactly what changed. KEY BINDINGS Custom keyboard shortcuts a power user maps to actions so they can work without reaching for the mouse. SPECIALIST AGENTS AI agents each scoped to one job (writing tests, reviewing code…) and coordinated together, instead of one general agent trying to do everything. PRIMITIVE A basic building block of a system that everything more complex is assembled from. AGENTS.MD A common way to share information with agents, by writing notes down in a file they know to check first. TMUX A "terminal multiplexer" — a tool that splits one terminal into many panes, so a developer can run and watch several programs (or AI agents) side by side. PR Short for "pull request" - a list of pending changes a developer wants to make to a codebase, shared with others for approval. SPEC-DRIVEN DEVELOPMENT A way of programming where you begin by specifying the tests you want to pass, then work backwards from that. AGENT ORCHESTRATION The process of creating and organizing multiple agents with discrete roles around a complex task. COMMIT LOGS The messages developers (and coding agents) leave when saving a change to a codebase. HARNESS The tools and structure that you wrap around an LLM to form an agent. WORKTREES A way to set up separate working folders for a codebase that don't interfere with each other. REFACTOR A set of changes where you change how the underlying code for something is structured without changing the functionality, usually for better maintainability or performance. PEOPLE A mostly-hairless mammal with two legs, two arms, and a big heart :] OPUS Claude Opus, a class of model made by Anthropic SEMANTIC SEARCH A search based on meaning, not keyword matching, usually done with LLMs or embeddings. MARKDOWN A simple filetype for documents, like HTML without all the <marquees> STORYBOOK A tool for documenting design systems. SPEC Short for "specification". Usually, a binding document that expresses what a piece of software should do. AGENT An AI entity (usually a feature of an app) that can string together actions and LLM responses to achieve complex work. Hot Takes #1 What's a specialist agent that hasn't been invented yet that would instantly become your favorite? The first thing that comes to mind — I just today made a visual guide that will explain any concept to you, whether it's a task or a part of the architecture, in diagrams and code widgets, and it'll walk you through it. Quite excited about that. There are a bunch of really fun orchestration structures I haven't yet explored. One is, have two agents that ping-pong — one does something, the other critiques and does something. I also took the org-chart meme — the one with the different tech companies' org structures? In one of them they just point guns at each other. So I asked an agent to create a workspace that simulated a set of specialists for each of the tech companies' org structures. Some of it is actually hilarious. The Google one made teams that produced three separate implementations that competed against each other, and it was like, "alright, we're killing two of these, we're only going with this." One of them was Apple, and there was a Steve specialist that just said it was shit every time. #2 What's something you hope never gets automated? Not exactly an answer, but my take is — agents will never eat ice cream for us, because there's no point for them to do that. There's a core of what we find meaningful and what we enjoy. There is a point at which the "throw an agent on it, just do an agent," the meta-to-the-meta, will stop, because it doesn't make sense for that to be automated. #3 Who's a creative or hero of yours, not in the AI space, that you think would be a great AI designer, and why? He would hate being named here. But one of the evergreen people I always like to read from is Bret Victor. He thinks a lot about the environments in which we learn and think. There's not enough thinking about that, not enough creativity in that domain, not enough being grounded in the way people want to experience things and think about them. The other person is Barbara Tversky, who I always think about with embodied cognition — thinking through the rest of your body, instead of typing on a keyboard. #4 What are two services or objects that are very dear to you, that you can't live without? Whenever someone asks me a question like this, I'm like, I don't like anything. I like this laser cutter — you can do some cool things. I know there is an answer to this, but I will not think of it until I hit the end button on the call.