Exploring With Agents  🔗 **Source:** [Exploring With Agents](https://share.snipd.com/episode/535c7835-5387-4192-b0f9-2cbde7882768) ## Highlights - **Agents Shift Effort From Prototyping To Polish** - Agents compress the early work of a project so prototyping becomes much faster, shifting effort from initial implementation to later polish. - Amelia frames this as agents delivering ~70% quickly, making the final 30% (polish, craft, edge cases) comparatively harder and more important. Transcript: Amelia Wattenberger Yeah, yeah. A little bit of background about me that might inform my perspective. So I come from like design development data biz background, and I joined the GitHub Next team, which is like the R&D team at GitHub shortly before we launched GitHub Copilot, which in A lot of ways feels like the beginning of this craze. It does. Adam Stacoviak Yeah, I would agree with that. Amelia Wattenberger And so I've been paying attention to this space pretty closely since, gosh, what was that? 2021, 2022. And, um, I don't remember. And, um, it feels like things have been accelerating as far as like how quickly things are changing and how receptive we are to that change. Um also if you take a longer view, they don't feel like they've changed that much, right? It's been like four plus years. And there has been like a pretty coherent arc of like, first we did autocomplete, then we were like, we want to have chat conversations, came out. Let's ask agents, let's ask, not even agents, let's ask LLMs about our code bases. And then we gave them tools, right? And they started writing code for us. And then we moved to the CLI. And now we're kind of in this like, let's go back to the UI and apps arc. But like over four plus years, that's not that much change to have happened. I do think it's accelerating. So for like the first three years, it was like, okay, ([Time 0:06:12](https://share.snipd.com/snip/da843c4b-2dd7-410f-97c0-b1dfd057e056)) - **Copilot Looked Like Autocomplete Until People Used It** - Amelia joined GitHub Next around Copilot's launch and recalls initial skepticism that faded after daily use. - Early users thought it was just better autocomplete, but within a day or two they realized it behaved very differently in practice. Transcript: Amelia Wattenberger Yeah, so I don't want to claim like any ownership or, or like intellectual ownership over copilot because I joined like, but right when we launched, like I helped with the launch. Um, there are some interesting things, um, that are part of my experience of that time. Um, like there was a lot of pushback initially like um even internally and then like the first users every time it was introduced to somebody they're just like yeah we have autocomplete Right like it's just better autocomplete this is not this is not very exciting and then like a day two days after anyone started using it, it's like, whoa, this is actually very different, Right? Like, cause mechanistically it's not so different than the things, the tools that we already had. Um, but in practice it's, it's, it's very, very different. Um, and I think like those earlier days in AI, um, there is way more pushback of like, do we really need to do this? Look, we have so many things to do as a business at GitHub. Like, let's focus on those things first. ([Time 0:09:07](https://share.snipd.com/snip/2466176a-c0a7-4a5b-9b9f-4ed411c29595)) - **Agents Can Auto Maintain Open Source Docs** - RAG-style tooling can auto-generate docs and keep them fresh by grounding answers in the codebase and emailing maintainers for gaps. - Amelia's Doc Pilot concept would index repos, personalize docs for users, and auto-interview maintainers when explanations are missing. Transcript: Amelia Wattenberger And it was like an early exploration of RAG, essentially, where we would index open source code bases and then have these kind of like chat or bespoke docs where developers can come in And say like, I'm this type of developer. I'm good at these things. I'm bad at these things. This is where my experiences are really. We could like check their GitHub to see what they're really familiar with. Can you answer like this question about the docs or do a walkthrough for me, knowing who I am as a person and what this what this code base is? And there were some really interesting future directions, possible future directions around like, can we actually just make it easier for open source maintainers? Because like writing docs is usually not the highlight of what they do. It's like this tedious, annoying thing that they have to do. And once they write the docs, they're stale. Um, so there are interesting like, uh, directions around, uh, we can, uh, automatically write these docs. And then if there are things that aren't, uh, fully explainable from the code base, we can just email the maintainers, right? Like we can just interview them whenever something comes up where there's a gap. And so they wouldn't have to go like make a doc site and like write all the content. Instead, it would be auto-generated, but also be grounded within the code and be grounded within their answers. And I think like, you know, that was two, three, three and a half. Don't know it was a long time ago and um like the things that we can do now feel even more crazy right like you could imagine being able to open source something and just like basically not Having to maintain it right like the docs are written up, like you have agents like figuring out whether they should update it in a way that users want. I saw one of the AI coding apps added like a feedback form that was like suggest a prompt for the code base. So if they liked the prompt, they would just like throw it at an agent and then, you know, polish it up. And that's a new feature for the app. Like it feels like maybe we could, you could do the same thing with like an open source library that like is kind of like community grown because agents are doing a lot of the hard work of Like maintaining the code and like aggregating across a lot of qualitative data, which is users asking for things. ([Time 0:22:30](https://share.snipd.com/snip/39a786eb-3b09-4a01-95bf-7d04b91c1731)) - **Building A Personal Gauntlet With Incus Sandboxes** - Adam describes building a personal 'Gauntlet' sandbox using Incus (LXD fork) on Proxmox to battle-test code in ephemeral VMs. - He uses system-level containers and ZFS-backed instances to tear down and rebuild prod-like sandboxes quickly. Transcript: Adam Stacoviak But to get there, I've got to solve some other problems. So one thing I did recently was I created this thing called Gauntlet. I just bought the domain and it's going to send my software into the Gauntlet. So rather than CI, it's really like a battle tested ground. There's ephemeral Incas containers involved. There's, which is, do you know what Incas is, Amelia? Amelia Wattenberger I do not. Adam Stacoviak This is the coolest new thing, by the way. It's not new. It's Canonicals LXD, re-licensed because they had a license challenge, and one of the original creators, maintainers, is a part of that. Forked it happily. Stefan, I forget his last name in the moment, but Incas essentially is system level containers and virtual machines. So think of like a hypervisor where it can instantiate an LXE container or a VM pretty easily on something like Proxmox, something like that, but super, super fast and built on top of ZFS and just phenomenal piece of software. And so here I am trying to solve this one problem. And then I'm like, I get so shiny object, right? Shiny objected. And I have this idea to like turn my code base into a sandbox. And I have a virtual machine over there on Proxmox. I'm like, listen, agent, let's just build out a sandbox. And prod is prod and sandbox is sandbox. And maybe the developers who have been down this road, this is like normal. For me, I'm like, okay, this is a brand new world. Let's figure out what sandbox feels like. We can break everything in here. We can tear it down and build it back up again. In fact, that's what we want to do. ([Time 0:33:07](https://share.snipd.com/snip/439cec1b-e12e-45c5-a466-1bc8a2ff0a93)) - **Workspace As Primary Primitive** - Intent treats a workspace as the core primitive: each task gets an isolated workspace with its own worktree, agents, and rich docs. - Amelia designed workspaces so multiple parallel tasks/agents avoid stomping on each other and preserve context and handoff. Transcript: Amelia Wattenberger And it's kind of like, can we, can we just solve these first so we can, you know, accelerate faster? So there's actually a project I did at GitHub Next called like workspaces or something where GitHub is fully remote. And this was right after COVID. And to work collaboratively with other developers has never been easy. GitHub says it's the social hub for developers, or at least they used to. But we don't really work together before the PR. Before that, we're kind of just in our own heads. Adam Stacoviak Is that right? PR is where it happens. Amelia Wattenberger In my experience. Adam Stacoviak Yeah, I guess the old way. The new way is not so much. That's quite surprising, I guess. It's like, I guess I've been so steeped in this new way, I'd forgotten the old way that nothing happens until PR. Amelia Wattenberger If you're talking about agents or other other like do you work with other developers before really no i mean a lot of it is uh not collaborative i mean in open source yes other developers Adam Stacoviak But that's usually the potato over the wall it's not a lot of like team collaboration getting to x it's more like you know solo getting there which is weird right like it is like especially Amelia Wattenberger If we work on i know as a lone wolf developer i kind of like it but like things should be shareable right it like especially teams working on the same feature we're doing all this like duplicate Conversations in slack that like explaining the code that we're writing locally. And like there have been a few stabs at it and Replit kind of does this a little bit, but like by and large, you know, typically a project is like, I have a Slack conversation. I have the linear issue. I have a GitHub issue. Maybe there's a century bug. I look at it. I talk about it. Maybe I put comments on a doc in notion and then I make a branch in my like local vs code um and then I write code on it and you know the outputs in the browser and then like oh wait I have to work On this other thing so I like commit it and I put the branch down and then I like go work on you know know, feature B there's a, like, you know, there's a bug in, in Prado. No, let's fix it. And then I like go back to my feature branch, but it's like, wait, what was I working on? And like, what's the progress and what were the conversations I was having around this? Um, and like the proposal is just like, let's have a new primitive, which is a workspace where everything lives so that it's easy for me to put down and pick up and hand off and share. And like our work as developers is only partially code. A lot of it is just like context integration and testing and all these other things. And so like, let's build a primitive that works with that and stop pretending that everything's code all the time. All right. So that project was at GitHub next. And now it feels like I'm just watching things and like collaboration is even more important now because the same tools that would make things a collaborative with other teammates Feel like the same tools that we need to work with agents where we kind of just need like a room for everything for a specific task so that like the agents all know what each other are working On and I know who made what change and like we're having conversations in in public where like I'm talking to agent a and agent b knows about it and we're all working off like the same spec And documents and, you know, like embedded web browser. So that, that was kind of the like core, the spiritual core of this new app that I've been working with augment code on called intent where let's, let's like add this primitive of a workspace. And then now that we have that, so within the app, uh, everything's a workspace. It's not like an agent chat. Um, anytime you want to start a new task, you would create a new workspace. So you say for this repo, I'm going to add, I keep my demo I keep doing is adding dark mode to my website. Um, and then, you know, that has its own, like get work tree. It has its own set of agents. It has its own, um, set of like rich, uh, markdown documents to explain all the context and the spec. And then because that's all isolated, I can like switch between, uh, adding dark mode to my site and like maybe adding a new blog post. Right. And those can have agents like whole teams, swarms, whatever orchestrations of agents going at the same time. And they don't get confused between each other. And then when I switch between the workspaces, I have the visual reminder of like maybe the browser is open or the spec is open. And I know like exactly like what the progress is and who's working on what. So it's a little bit of like a redesign of how do we want to work and can we build an environment where that's easier. And then to come back around to what we were talking about, it just makes it so much easier to work on, you know, the 10 things I'm working on at once. ([Time 0:35:50](https://share.snipd.com/snip/096a0b8e-e4d0-4f22-a67e-dbf5a1c865cd)) - **Isolate Tasks In Shareable Workspaces** - Use isolated workspaces to make multitasking and handoffs easier: include specs, browser state, agents, and a worktree per workspace. - Intent's UI shows progress and context so developers can switch tasks without losing state or conversations. Transcript: Adam Stacoviak Potato over the wall it's not a lot of like team collaboration getting to x it's more like you know solo getting there which is weird right like it is like especially if we work on i know Amelia Wattenberger As a lone wolf developer i kind of like it but like things should be shareable right it like especially teams working on the same feature we're doing all this like duplicate conversations In slack that like explaining the code that we're writing locally. And like there have been a few stabs at it and Replit kind of does this a little bit, but like by and large, you know, typically a project is like, I have a Slack conversation. I have the linear issue. I have a GitHub issue. Maybe there's a century bug. I look at it. I talk about it. Maybe I put comments on a doc in notion and then I make a branch in my like local vs code um and then I write code on it and you know the outputs in the browser and then like oh wait I have to work On this other thing so I like commit it and I put the branch down and then I like go work on you know know, feature B there's a, like, you know, there's a bug in, in Prado. No, let's fix it. And then I like go back to my feature branch, but it's like, wait, what was I working on? And like, what's the progress and what were the conversations I was having around this? Um, and like the proposal is just like, let's have a new primitive, which is a workspace where everything lives so that it's easy for me to put down and pick up and hand off and share. And like our work as developers is only partially code. A lot of it is just like context integration and testing and all these other things. And so like, let's build a primitive that works with that and stop pretending that everything's code all the time. All right. So that project was at GitHub next. And now it feels like I'm just watching things and like collaboration is even more important now because the same tools that would make things a collaborative with other teammates Feel like the same tools that we need to work with agents where we kind of just need like a room for everything for a specific task so that like the agents all know what each other are working On and I know who made what change and like we're having conversations in in public where like I'm talking to agent a and agent b knows about it and we're all working off like the same spec And documents and, you know, like embedded web browser. So that, that was kind of the like core, the spiritual core of this new app that I've been working with augment code on called intent where let's, let's like add this primitive of a workspace. And then now that we have that, so within the app, uh, everything's a workspace. It's not like an agent chat. Um, anytime you want to start a new task, you would create a new workspace. So you say for this repo, I'm going to add, I keep my demo I keep doing is adding dark mode to my website. Um, and then, you know, that has its own, like get work tree. It has its own set of agents. It has its own, um, set of like rich, uh, markdown documents to explain all the context and the spec. And then because that's all isolated, I can like switch between, uh, adding dark mode to my site and like maybe adding a new blog post. Right. And those can have agents like whole teams, swarms, whatever orchestrations of agents going at the same time. And they don't get confused between each other. And then when I switch between the workspaces, I have the visual reminder of like maybe the browser is open or the spec is open. And I know like exactly like what the progress is and who's working on what. So it's a little bit of like a redesign of how do we want to work and can we build an environment where that's easier. And then to come back around to what we were talking about, it just makes it so much easier to work on, you know, the 10 things I'm working on at once. ([Time 0:36:52](https://share.snipd.com/snip/d6dad1e9-32a5-4091-997a-77a18c44d1e3)) - **Orchestrate Agents With A Coordinator And Verifier** - Use a coordinator agent to delegate subtasks to implementers and a verifier to validate results rather than letting each agent act independently. - Intent's default flow has coordinator write spec, spawn implementers, then run a verifier to run tests and report back. Transcript: Amelia Wattenberger Mostly just trying to, constantly pushing the bounds. They call it the bleeding edge because it's painful, right? To use all the new tools and I you know I found myself running eight different agents at the same time all working on different tasks and like they step on each other's toes and like they Adam Stacoviak Start accusing you of changing things right they're like yeah you gotta stop changing this file there's changes in that file I didn't do just so you know okay like it wasn't me i'm not Committing that i can't own that i didn't do that i got that one yesterday by the way that's pretty funny really yeah i was like okay chill i'm with you i know the other agent did it i'm i should Be smarter and have you know intent here and do you know multiple workspaces and be smarter about them so i'm just not there yet okay stop yelling i'm coming yeah it is interesting like Amelia Wattenberger The so two things two things about what you're talking about um when it's like a lot of the like new explorations from the other tools are around a work tree per agent thread. So each agent has its own get work tree. Um, and that's actually not the direction we went down. We have one work tree per task. Um, and there's kind of these pros and cons for, uh, multiple agents working on the same tasks within the same environment. That's kind of been like an interesting research exploration. And I find it actually works quite well, where as long as the agents know what each other is doing and are able to see like, okay, these are the three other agents within the workspace. And like, this one's working on subtask a and I'm working on subtask b you really don't run into issues um the the one set of issues that we did see a lot was like we have them auto committing Um it's like a setting so like you split a task into subtasks and then you like you say like you three tackle these three subtasks like in parallel and then auto commit when you're done And because git is like the way git works is like you have to stage files or hunks and then write a commit message and like run the commands like that they would step on each other's toes With that so we added a tool for like queuing auto commits. And other than that, like you get all of the benefits of like, you know, one's working on creating a component, the other one's working on adding the component to the layout or another One's working on like global style changes, right? Like you do want some of these tasks to be done within the same environment because like usually when you split things into tasks, they're inherently linked together and like you know Api change as well as like another one's making the page right like you need those to be in the same place and like you want visibility between those agents you don't want just like completely New cloud environment for all of these agents as they're working on the same thing so like it's been interesting exploring like what do you want sandboxed at any given time and then the Other thing that's been really interesting is just like orchestration paradigms right like yes with our given tools it's hard it's hard to explore any kind of orchestration like i Actually had like a home cooked, like parallel running system. Cause I was doing large refactors where I was like, I'm going to make a markdown file and it's going to like be split into 10 tasks. And then I'm going to kick off like 10 agents in parallel. Cause it works faster and I can use cheaper agents when it's all spelled out. And like, it just like was not conducive to like actually exploring like how to make that really nice. But like if you have the primitives to like kick off different types of agents and they all have visibility into what each other is doing, there's some really interesting paradigms. So like our default paradigm within the app is a workspace starts with a coordinator agent, which writes the spec, and then it delegates subtasks to implementers and then in waves, And then it asks a verifier to validate those changes. And it works really well. But there's other paradigms like spin up two agents and they ping pong between each other. Right. And then like agent A goes and it critiques what agent B did and does its own thing. And like they kind of like, you know, level each other up as they go. And like there's all these really interesting paradigms that I really want to explore. And then like you look at Gastown, right? And there's like, you know, like there's a deacon and, you know, it's a whole town. Adam Stacoviak Yeah. Yeah, I think there's mayors and stuff like that citizens i don't even know it's like a boot i didn't go that deep yet i um but is it like that's exactly it right it's like impossible to follow Amelia Wattenberger When you're just like starting from the the primitives which are like an agent um so there's like a lot of really interesting things as far as orchestration that I feel like are just now Being being explored. And there's a lot more that can be done there. But I think we just need the tooling to to make it easy to understand who's doing what and et cetera. Adam Stacoviak Take me into this this this exploration around coordination because i feel like that's probably the hardest part once you have multiple agents i do think it's smart to to do a task-based Versus you know agent-based because you may want to have multiple agents but then you have the issue of stomping on toes so you have to kind of coordinate it. Do you have like a coordinator or an orchestrator or do you kind of give them hats? Do you give agents like, hey, agent, you are, you're the verifier now. And now they assume this role. Is it stuff like that? How do you, how does the agent know? And then how do you trust the model to let it explore and push back on the other agents, I guess, thoughts, if that's how you want to frame it? Amelia Wattenberger Yeah, yeah, that's a good question. So we have the concept of a specialist, which is just it's like a persona, right? And it's like a prompt and a default model and set of tools. So we ship the app with a default set of specialists. Like we have a coordinator, an implementer, a verifier. There's like a PR reviewer, UI designer. There's some just like things to get people started. But users can tweak those or make their own specialists. And the default flow we have that we've found actually works really well ([Time 0:43:10](https://share.snipd.com/snip/4654fce3-413b-4521-8ec8-0ad2b751dd85)) - **One Worktree Per Task Avoids Stomped Changes** - Intent chose one worktree per task (not per agent) so linked subtasks can share environment and visibility. - That design required solving auto-commit conflicts by queuing commits to prevent agents from stepping on each other's staged changes. Transcript: Amelia Wattenberger So each agent has its own get work tree. Um, and that's actually not the direction we went down. We have one work tree per task. Um, and there's kind of these pros and cons for, uh, multiple agents working on the same tasks within the same environment. That's kind of been like an interesting research exploration. And I find it actually works quite well, where as long as the agents know what each other is doing and are able to see like, okay, these are the three other agents within the workspace. And like, this one's working on subtask a and I'm working on subtask b you really don't run into issues um the the one set of issues that we did see a lot was like we have them auto committing Um it's like a setting so like you split a task into subtasks and then you like you say like you three tackle these three subtasks like in parallel and then auto commit when you're done And because git is like the way git works is like you have to stage files or hunks and then write a commit message and like run the commands like that they would step on each other's toes With that so we added a tool for like queuing auto commits. And other than that, like you get all of the benefits of like, you know, one's working on creating a component, the other one's working on adding the component to the layout or another One's working on like global style changes, right? Like you do want some of these tasks to be done within the same environment because like usually when you split things into tasks, they're inherently ([Time 0:44:28](https://share.snipd.com/snip/44f6d6f2-a9ee-4016-ad82-1681739ed0d2)) - **Give Agents Team Visibility To Prevent Conflicts** - Tell agents who else is on the team and what they're doing to reduce conflicts and improve coordination. - Intent gives agents visibility into co-workers and subtasks so parallel implementers avoid duplication and know scope. Transcript: Amelia Wattenberger So we, in our default prompt for the coordinator, we say for the subtasks, delegate them to implementer agents. Ander agents, um, depending on how token sensitive you are, like it can be a cheaper model or it can be more expensive. I really want this to be as robust as possible. And like those implementers get their own sub task. Um, and it's the note that they can like write in and read from. And like, so they like, it's like kind of scoped, it's really well scoped for them, but they're also told who else is working within the workspace. And I feel like that's made a lot of difference is just like the agents know and have visibility into who else is working, right? Like it would be weird to join a team and like not know who else was on the team or what they were working on yeah right like i'd be like i don't know what's the scope of my work um so it's just Like this really smooth flow of like coordinator delegates to implementers and then we also found that agents don't always do exactly what they say they did And like, maybe this will Change. But for now, sometimes an agent would be like, I did X, Y, Z. And then, you know, you'd look at it and they only did X, Y. And so the coordinator is also told to delegate a verifier agent, which again could be a cheaper model. It could not be. You could use like a codex model if you feel like that works better for this, this case. Um, and that, that verifier just knows exactly what the work is that just completed. And it, it like goes through and verifies it, you know, it runs the tests, it, uh, runs the app and looks at it and, uh, keeps everyone like to task and it reports bets of the coordinator. And it's actually kind of a really interesting flow. I keep meaning to post about it of like having this one chief of staff that you talk to for everything and like it delegates to other agents. So it's like an interesting, it's a different flow where like the work can be happening and I can talk to the main agent about the work that's happening or like, oh, I found a bug and I'll Just like, as I go through the output, I'll keep telling the bugs to the coordinator. And because it's not doing the work, sending messages is not like queuing messages because they get sent right away. And it's not like interrupting an agent because the work doesn't stop. ([Time 0:50:33](https://share.snipd.com/snip/7dba26d4-8158-40d4-ba20-73fb2465ace9)) - **Enhance Prompts Into Editable Specs Before Implementing** - Iterate prompts: start small, use an enhanced-prompt step to expand assumptions into a readable spec, then edit that spec before asking agents to implement. - Amelia recommends enhancing terse inputs like “add dark mode” into detailed specs and then adjusting assumptions. Transcript: Amelia Wattenberger We're, we're trying to have a compressed version. And this is what talking is, right? Like you have a maximally compressed version of what it is that you're trying to represent that lives in your head, or maybe doesn't even fully live in your head. It's just like add dark mode to my site. Right. Like, and this wouldn't work previously with code because there's a lot of things that are inherent and you would have to assume in order to turn those words into an implementation, Right? Like, first of all, what is dark mode, right? Like, what does this person mean when they say dark mode? Or like, what pages should this apply to? Should this have like some kind of affordance to switch between dark mode and light mode? And there's like a set of like less and less obvious assumptions that you can make about what the person means when they say these words. And like you're doing, you know, I'm not going to bring out numbers again, but you're like you're extrapolating. Adam Stacoviak Please do. I like your numbers. Don't feel bad about it. You're going from 0.75 to 1. Okay. Amelia Wattenberger From add dark mode to this is the code for adding dark mode. I feel like enhance prompt goes from 0 to 0.1. Adam Stacoviak Okay, nice. Amelia Wattenberger It's a little, it's the negative TLDR, right? 10% there, okay. Like it's a little bit more like, this is what you mean when you say that. And then the way enhance prompt works is really nice because you can edit it, right? You can read through okay this is a little bit expanded and like oh you're gonna assume I mean this let me actually tweak that because I see it and like it's actually not what I want um and Then like extrapolate a little bit more you get to this like a spec right like that's like the spectrum development um where like a spec is supposed to be somewhere further along that Spectrum of like, let's add more detail into what that would mean in the code, but we're not going to have the fully fledged implementation because that would be the code. Right. Um, or like that would be hard to read through and, you know can go from 0.5 to 1 and make assumptions, like those assumptions along the way. Let's get out the big decisions and agree on them before we do the work. So that's kind of how I think about the way we work with these language models is like we say a little bit and then they basically flush it out for us and turn it into code. ([Time 0:58:31](https://share.snipd.com/snip/01e08773-da87-46ba-b6e3-c4880c78ff72)) - **Developer Identity Splits Between Craft And Design** - Developers face an identity shift: some will enjoy low-level craft, others will move toward design and intent as AI handles implementation. - Amelia frames this as choosing whether you value the craft of code or the joy of imagining and shipping products. Transcript: Amelia Wattenberger I have a lot of thoughts there. And I'm trying to think of like, what would actually be most interesting? Like, I feel like as developers, we're kind of having an identity crisis, right? Where like, are we potters? And are we supposed to be opening like a pottery factory? And like, that's, you know, like there's two main joys that I feel with being a developer. One is like the craft of the code and learning the tools and knowing what are the bricks that you can build your buildings with. And the other is just like building things and like thinking of something and then it exists. Right. And I think the way you might feel about this new wave of tools lies along those lines of like, which is the greater joy for you? And what do you find the most meaning from? And I've always been like, which is why I've moved more and more towards design. You know, like I started as a developer and now recently I've had more and more design roles. Is that it's just so interesting to be able to imagine something and then it like comes to life. Yeah. Like that is amazing to me. And like a lot of these are things that did not exist before, you know, like whether they're good or bad, this is the first time that they exist. And there's something like really amazing in that. And a lot of I feel like your your main motivations and what you find the meaning in it informs the way you use these tools. That's true. And I do think it's important to still feel the clay, right? Like you still want to be in touch with the physics of what it is that you're working on. And you want to feel in charge and in control and not like, like I think about, um, art, right. And like how generative art is changing. And like, people are kind of having to think about like, what is art and like, what do we find meaningful? And like, um, if I type a prompt into a box and something comes out and it's like the Mona Lisa, right. Which honestly I think is overrated, but it's a good example. How does that change how I value the thing that came out of the box? And can we have workflows where the thing that we think is meaningful, which is usually effort and thought and the humanness that goes into it. Um, can we, uh, leverage Gen, Gen AI to make tools for which people to like make a thing and then like really sculpt it and craft it and like put intention and effort and human, uh, feelings Behind it. ([Time 1:07:47](https://share.snipd.com/snip/bab3e58e-1707-48d4-b1ab-d9ca951b9360)) - **Say No More Often To Preserve Product Focus** - Practice design restraint: when agents make many features easy, decide intentionally what not to build so your product retains focus. - Amelia warns that eliminating backlog quickly risks shipping everything and diluting product meaning. Transcript: Adam Stacoviak Faster and support more of a footprint that the footprint can widen because we have this this new invention tool this new design tool we have i feel like my answer isn't super different Amelia Wattenberger Than what we've talked about before, where it's like, now that we can build anything, what is it that we built? Right? Like, it's so tempting to add, you know, 10 new features to an app. Especially with, you know, you get the 70% really quickly. Like, why don't you just polish that up and ship it out? And, you know, you're done. You know, your, your app does, you know, it's an IDE and it's, you know, notion and it's linear. Um, but then you just have this massive app and like, why, why, right? Like you can only have so much intention behind what you build. That it's it feels like it's becoming the question is what you don't build as opposed to what you do build. Right. Like if we if we can virtually eliminate our backlog in a week. How does that change what we decide to ship? Because the answer can't be ship everything. Yeah. Because then, you know, your stuff, it doesn't stand for anything, right? If it stands for everything. So it's been, as someone who likes to do scope creep, because I like like fully fledged versions of things and like really thinking through you know what is what is it if it does everything Um it's become like it it's a new muscle that I have to exercise right restraint no to things yeah ([Time 1:15:51](https://share.snipd.com/snip/79dd2bde-c53a-4eb1-97c3-ac70a020b6b8)) - **Tools Must Support Zoomable Abstractions** - Software interfaces must evolve up the abstraction ladder as humans move from primitives to intent; tools will need zoomable macro/micro views. - Amelia compares this to Google Maps’ multi-scale design and wants similar seamless shifts for code and workspaces. Transcript: Amelia Wattenberger One is like the IDE was invented almost half a century ago. Right. And it's very good at working with the primitive of code and you're always working at the code level, right? You're reading the code, you're writing the code, you're clicking between files. Um we like through AI is chat on like on the side. And we're like, okay, these agents are going to write and read the code for you. So that's like, there's like step one, which is like, what are the primitives? Build the UI around the primitives. Step two is throw AI so it can also use those primitives. And then step three feels like kind of like reinvent the tool. Now that our role in the system is changing, right? Where we're no longer mainly working with the primitives. We're like moving up a level on the ladder of abstraction and focusing more on like for code, the meta of like, what's the intent? How, like, what are we building? What are we changing about it? What exists in the code base? And it feels like Notion's kind of going through the same, okay, we had documents and then we threw ai on the side of those documents and now they're kind of moving to step three which is Like let's work on the meta right like i have this long list of bugs in my app can you transform that into like a summary or into some like higher level representation of this so that I can Interact with it in like a much higher leverage way. And then there's like a next step, which I'm super excited about adding to intent, which is you can go up another level, which is like if you add AI at a higher level, which I guess is kind Of what Notion is doing, where like you can talk to an agent about all your workspaces and you can say like, hey, what are my last 10 PRs? Can you make a workspace for each one of these? And then you're like, what happened in my workspaces last night? And oh, like move, like nudge along these three tasks right like we've gone another level on the left up on the ladder of abstraction we're like we're it's like um moving higher in the Air where the things on the ground there's more of them but they're smaller and like they're individually like taking up less uh of like our view as far as like our perspective is moving Up and up and we can do more and more, but we can't use the same representations that we have been. ([Time 1:20:05](https://share.snipd.com/snip/1ddeb306-f6a8-4896-88c0-c604125bfbf2))