# AI Agents, Workspace Primitives, and the Last 30% Problem

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-04-24

## Transcript

What's up?
Welcome back to The Changelog.
I'm Adam Stachowiak, and it's been a minute.
I've missed you.
You know, sometimes you have to retreat to attack.
I've said that before in this podcast.
How can you push at sustained high output thresholds when you need to slow down and check yourself?
Get centered, get focused, and then get back in a groove and do your best work.
Rest assured, my friends, The Changelog is here to stay.
Nothing's changing.
And I'm working on some really big ideas, and I cannot wait to share them with you.
Today, I'm talking with Amelia Wattenberger, designer, data viz veteran ex GitHub Next, and now designing intent at augment code.
What if the last 30% of any software project you're working on is about to become the hardest part you've ever done?
That's the argument Amelia is making today.
We discussed the identity crisis developers are having as agents take over the keyboard.
The epic redesign of developer tooling in this agent first world we're in.
The arc from autocomplete to chat to CLI back to UI.
Why intent treats a workspace as their core primitive and not a chat thread.
The treehouse between one work tree per agent versus one work tree per task.
And.
why she thinks prototyping just got easier, but finishing got harder.
A massive thank you to our friends at Fly.
Without them, this pod would not be here.
They're such good friends, great partners.
We love them.
Check them out.
Use them.
We use them.
Fly.io.
Okay, let's talk to Amelia.
Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of WorkOS.
Michael, off for agents.
I feel like this is burgeoning.
It's kind of happening all of a sudden.
What's the state of the world for Auth4Agents?
Yeah, it feels like Auth4Agents is one of those things that nobody knows what it means, but it's very provocative.
Everybody wants to talk about it.
Practically speaking, I think there's two things here.
The first is when you say Auth4Agents, you're talking about how do I get the data into an agent that it needs to be able to do its job?
And for that, we built something called WorkOS Pipes.
It's actually more of an integrations product.
It helps you take your agent and connect it to your customer's Google Drive and connect it to Salesforce and HubSpot and connect it to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed.
That's one type of auth for agents, kind of data access auth.
The other type is actually authorization.
It's like permissions for what the agent is going to go do because you connect it to all these systems, but then you say, what capabilities does it actually have?
How can I restrict the agent behavior so it doesn't go off the rails and go do a bunch of crazy stuff?
That's a lot of stuff we're building today.
We don't have a product announced yet for that, but we've been working on it.
The third, I would say, is probably the identity layer for agents.
How do I identify an agent by its name?
That's really coming from the enterprise identity systems that are out there.
If you look at Microsoft's Entra agent ID, they're doing a lot of interesting work there.
There's also expansions to OpenID Connect and SCIM.
for agents.
We're building all of this into the WorkOS platform.
So if you're looking for an identity stack that will support agents, again, feature proofing, WorkOS is a great place to go.
But it's changing really quickly.
You know, none of us were talking about OpenClaw, you know, like weeks or months ago.
And that's a new paradigm I think we're going to see not just within consumer software, but in the enterprise too.
So it's an area of very, very rapid development.
Well, it makes me think about agents versus people, not negatively, but This world where we'll have more agents than people.
You know, today, if we have seven or eight billion people on the planet, in the future, we're going to have trillions of agents going off and doing things.
And so the challenge around identity and authentication for agents is actually significantly bigger than just how people interact.
In the same way, like, you know, GitHub isn't going to work super well for agentic coding because you'll have so much more code getting written.
The same is true for identity and permission and logging systems.
when agents start doing stuff with it.
So we're building for that future today.
All right, friends, the next best step is to do what I've done, which is use AuthKit.
Okay, that's how I authenticate my CLIs, my APIs, my applications, all that good stuff.
WorkOS.com is where you go.
Try it out today.
A million users with AuthKit for free.
You can't beat that deal.
It's literally free.
Again, WorkOS.com.
Try it out today.
Friends, I'm here with...
A friend, JS Partier slash friend of the developer world, Amelia Wattenberger.
It is my first time actually, I think, having a deep conversation with you, Amelia.
So I'm looking forward to this very much.
We come from similar roots of desire.
I haven't been to the labs you've been to in the GitHub Next as you've been to in the depth that you've been to.
I love the visual design you've done in the world and I've always been a fan of yours.
So finally having a chance to go deep with you is...
a joy so thank you for coming and welcome to the show yeah happy to be here it's long overdue it is long overdue i wonder why we haven't done it sooner we always say that right when we do the fun things in life why didn't we do this sooner every single time we're just too busy working you know it's too much work to do i do want to understand how you're looking at the world we're in right now because there's some there's some change if you didn't notice amelia What do you feel about this change?
I know our audience is like, gosh, can we get done with this AI stuff?
I don't think we can.
I think it's here to stay.
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.
Yeah, I would agree with that.
And so I've been paying attention to this space pretty closely since, gosh, what was that?
2021, 2022.
And I don't remember.
And it feels like things have been accelerating as far as like how.
quickly things are changing and how receptive we are to that change.
But 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.
ChatGPT 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.
For like the first three years, it was like, okay, so what are we doing?
Are we actually changing that much?
And now it feels like, oh yeah, we're like, we're like, but like it is important to take a longer view of it because day to day it feels exhausting, right?
There's five new things every single day.
So it's good to have a little bit of a weight is actually changing that much that quickly perspective.
Can you, Can you expose the insides of GitHub Next and what brought on Copilot and what brought on this world?
I do agree with you that that feels like the first version of this for developers was autocomplete from GitHub Copilot.
And really a lot of pushback even from GitHub and Microsoft for open source code and training models.
It was like the first thing was really less about what we can do with it and more about why did you do this with our code?
Damn you, GitHub, Microsoft.
So you were on the inside of all of the lab work there.
The beakers, porn things and things blowing up and maybe not blowing up.
Take us into that world.
Yeah, so I don't want to claim any ownership or intellectual ownership over Copilot because I joined right when we launched.
I helped with the launch.
There are some interesting things that are part of my experience of that time.
There was a lot of pushback initially, even internally.
And then the first users, every time it was introduced to somebody, they're just like, yeah, we have autocomplete.
It's just better autocomplete.
This is not very exciting.
And then a day, two days after anyone started using it, it's like, whoa, this is actually very different.
Because mechanistically, It's not so different than the tools that we already had.
But in practice, it's very, very different.
And I think those earlier days in AI, there was 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.
Let's focus on those things first.
This was GitHub Next though, right?
Wasn't this a product of that or did it come out of research from GitHub Next?
And wouldn't the next thing, I remember having conversations about that early on, like that was the whole point, wasn't it?
Like to do research and to do exploration?
Yeah, exactly.
So GitHub Next was kind of formed around that time.
It actually started as the office of the CTO before Jason Warner left.
That's right.
Yeah, that was kind of, those are, and those still are the marching orders of like, just like explore, right?
It's one of my favorite places that I have worked where it's just a lot.
It's quite a small team, maybe like 15 people and just like very experienced product engineers, researchers who all have these different backgrounds.
That just bring a lot to the table.
And then you have this really nice Venn diagram of ICs of individual contributors who just really know their stuff, but they know different stuff.
So and like they have some overlap with each other.
So you get to like figure out what to prototype and make squads.
And it's very like autonomous.
And, you know, what do you think comes next?
Let's explore that until we convince ourselves that it is or isn't the next thing.
I have a lot of love for that team.
What was your role there?
You were doing a lot of data visualization, which is such a long word to even say.
I don't know how you can say that perfectly three times straight fast.
I know I would struggle there.
But nonetheless, it is very cool and is very beautiful.
What were some of the things that you did there to contribute and things that you really enjoyed doing?
Yeah, what projects did I work on?
in the beginning, it wasn't all about AI.
So we did some fun explorations around like making data easy to work with.
And how does that loop into actions?
Like, how do you have these, like, how do you handle...
Like GitHub actions, you mean?
Or do you mean actions in general?
Yeah, GitHub actions.
Okay, cool.
GitHub actions is one of the coolest pieces of tech ever, honestly.
It is so inventive.
It's one of those things that once you use it and you really, really appreciate it and understand it and you examine it, you're like, wow, this is a very thoughtful piece of software.
Yeah, yeah.
It can be a little frustrating to work with because it's, you know, CI.
But the way it was designed is actually quite elegant and it's actually really, really powerful.
It's almost like separating compute from storage in a way or the way that you do that in distributed computing.
where you have the platform itself and then the runners.
You sort of separate the engine that is the smart, the if-then-else kind of scenarios with workflows and whatnot.
It's really just, I think it's a pretty wild piece of software.
Yeah, and I also think a lot about the way it's integrated with the code base.
This is relevant these days with agent roles, right?
What goes in the code base and what doesn't?
And what should be coupled with Git and Git branches and what shouldn't?
And I think the way actions work, where they have to be checked into the code base is really nice because you get a lot of power out of that.
So it's something I think about a lot.
Let's go back to exploring because I agree with you.
What do you think about this world we're in right now?
I feel like personally as a developer, what I'm doing is a lot of exploration.
I feel like everything I build makes me build one more thing to make that thing smoother, better, whatever.
And now I can because I have superpowers.
And so I don't feel encumbered by what I know.
I feel unencumbered by what the agent knows.
And I feel like every time I hit a problem, like, gosh, can somebody just solve?
Wait, hang on a second.
Let me solve that.
Let me see if I can think about that a little bit.
Because much like you, I have this product manager, user experience and design background that I don't really.
that I haven't, you know, I use day to day, but it's not on my, the front and center of my resume, so to speak, because I've been a podcaster and software developer for so long that I've sort of left my roots in a way from the public eye.
But internally, all Adam thinks about is design, intent, specification, how things should work.
Why does it work that way?
Oh my gosh, a user would just be so frustrated by that.
And so that therefore I have tastes that I just can't seem to let go of.
What do you think about this state we're in with exploration, being able to explore more with software?
Yeah, it's really empowering.
It feels like these agents are 80% good at doing anything, which really levels you up.
There's this concept I've been thinking about that I'm going to not put into words well, because these are kind of half-baked thoughts.
But if you think of...
For any given thing that you're going to work on, if you think of the work linearly, right?
Like zero to 0.5 is half of the work.
0.5 to one is all the way done.
Right.
It's linear because, you know, that's the way we think about our work because it's been pretty static.
Like what takes a long time for a long time.
And now that agents are here, they're kind of like blowing up that our expectation of how long things take and how valuable they are as a result.
So that like what used to be, you know, 70 percent of the project is now like you throw a prompt in the box if the prompt's good enough.
And maybe there's some back and forth.
You get 70 percent of a thing.
Right.
And like that number will go up.
But like that 70 percent has been squished into, you know, 10 percent of the project.
And then that last 30 percent is actually really hard now.
Because we're starting all these new things.
I'm like, oh, I want to do A.
I want to do B.
You know, why don't we throw C, D, and E in?
Because they're so easy to do.
But then you have to, at that point, decide, like, do I keep going with this thing?
Because there's actually quite a lot of work to go from, like, oh, here's, like, a kind of rough prototype to, like, here's, like, a polished version of the thing.
And I've been very intentional and thoughtful about what it looks like and how it acts.
And it actually feels a lot harder to do that because like you've stepped off the, the moving sidewalk, right?
You're like used to going fast and then you're like, wait, no, I have to go slow again.
And like, agent can't do this part for me.
And it's really frustrating.
And I have like six things that I'm juggling at once.
So it's like, it changes the nature of things where as someone who's like, I love prototyping.
It's like one of my favorite things.
It's actually.
How I think of myself as a builder is I'm pretty much just a prototyper.
I believe very strongly that that is the way to get to really nice, informed products.
It's just like exploring within the medium.
It makes that part way easier, which is great.
But then it makes other parts feel a little bit harder.
Yeah.
In my opinion.
Do you feel then that you...
As a product expert, do you feel like you, I mean, I see your work, at least with what's in the public eye, maybe not what's behind the scenes on your easel that's, you know, got to cover over it so nobody can see your painting kind of thing.
I knew an artist at one point, I'd always peek in their studio and I was, I always loved it because I got to see behind the scenes of what no one else got to see.
And I got to see the, the unfinished, the exploration, the.
Oh, this was red.
Now it's, let me just paint over the whole thing again kind of thing.
So that's why I say that, but I always appreciate that.
But when we look at the way you prototype, do you feel like it's hard to get to finished then considering that?
Or do you feel like you're in a, in a place where polish is just the hard part and that's the product in the end.
And that's the part that takes probably the majority of the time is like taking this thing that works for me.
or work for me in my scenario or my team's scenario to something that actually scales to multiple teams and is sign upable and usable and viable and installable and instantiatable and all those things.
Yeah.
It's interesting.
Like, how do you break that part down?
You can break it down into like, like polish and craft and like the art side of like what it is, what is it that we think is valuable as a society?
It's going to have to change because, you know, that 70 percent, again, is so easy that like, which also makes it hard to throw away.
You know, you like throw in a prompt and it like builds a whole app for you.
And you're like, this isn't exactly what I want, but it feels really wasteful to throw this away because that would have taken me a long time.
Oh, yeah.
We become hoarders in a way, right?
A little software hoarders.
I got some software hoarding going on over here.
So I'm empathizing big time.
I've been running out of disk space.
A lot.
You almost write a lot of software.
That's a lot.
I tell agents to write a lot of software.
Gotcha.
So our impression of how valuable that part is is going to change.
And then what do we think is valuable as a society and what do we want to pay for?
There's questions around that.
And then there's also questions around how do you get it fully functional?
If I ask an agent to make a game or make like an infinite canvas, there's usually like a lot of iteration and back and forth or just like manually getting into the code to get things like really feeling nice and working functionally.
And like, I feel like those are the two hard parts that are left in that like 30% of like polish and finishing up, you know, the last 20% that is.
The 80%.
Yeah.
You know, I think polishing a product and delivering it to folks is actually the hard part.
I feel like I've been building a lot of personal software and I'm kind of okay with that.
I've been, in a way, feeling guilty for not releasing some of it to open source.
But I'm like, well, then I would have the burden of open source and maintainership, which I don't mind if I plan to, if my intent is to make it a product and give it to others, which I would like to do, given infinite time.
I think at some point maybe agents can solve some of those challenges as an agent maintainer in a way, potentially.
I just don't have the time to release it as open source and deal with potential issues or just somebody else's problems or they want to contribute a different direction.
I'm like, hang on a second.
This was a personal project.
It's a USB stick on my curb.
I gave it to the world.
It is what it is.
It's open source, not open to contributions.
I don't know if I want to be that guy either.
I don't know if I want to be that person.
I'm like, not invited.
Can't contribute.
So I just sort of just like hold it back.
How do you feel about the state of the world?
Do you feel like every developer is in this version of a predicament?
Yeah, the open source thing is really hard.
There's the question of like, because these agents are getting better, how valuable?
how does that change how valuable open source projects are and like like you know npm packages which is kind of interesting there's also like can we make it easier to do open source right to like maintain an open source project um you asked previously about what projects i worked on at github next and one of the things that we worked on was called doc pilot or co-pilot for docs i think is what we called it in the end 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 where my experience is.
Or really, we could like check their GitHub to see what they're really familiar with.
Can you...
answer this question about the docs or do a walkthrough for me, knowing who I am as a person and what this code base is.
And there were some really interesting future directions, possible future directions around, can we actually just make it easier for open source maintainers?
Because 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.
So there are interesting like directions around we can automatically write these docs.
And then if there are things that aren't 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.
I don't know.
It was a long time ago.
And 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 basically not having to maintain it.
The docs are written up.
You have agents figuring out whether they should update it in a way that users want.
I saw one of the AI coding apps added a feedback form that was like, suggest a prompt for the code base.
If they liked the prompt, they would just throw it at an agent and then polish it up and that's a new feature for the app.
It feels like maybe you could do the same thing with an open source library that is kind of community grown because agents are doing a lot of the hard work of maintaining the code and aggregating across a lot of qualitative data, which is users asking for things.
It feels like we could push that pretty far in an interesting direction.
Yeah.
Yeah, I think there's a lot of influx to open source now.
But then I, you know, when we're talking about this subject, I'm thinking about the things I'm making.
And while it's not polished, maybe it would be useful to somebody else.
Maybe my design thoughts and traits and tastes actually translate to, you know what, I know I could generate that, Adam, but I like the way you thought about it.
So maybe it's more of a personal.
solution to how I solved a problem or how I think about problems and how I break them down.
I've mentioned on the podcast a couple of times, I don't know if you know about this, but I've been working on something I've got called agent flow.
And it's not at all like intent, which we'll talk about here in a minute from Augment, friends of ours at Augment, and something you've designed.
But I've thought about this problem of how can we how can we as technologists build software?
And I keep thinking of it like a knowledge base.
And the language of the agent is very much Markdown.
Like I never thought I would care about how much Markdown.
And like you were just saying about developers don't want to write docs.
I'm like, you know what?
I kind of like writing docs now, okay?
It's like, it's my ability to control that future in a way.
Like if the doc says this thing or if the spec says this thing or...
I've adopted the way Python directs itself with PEPs.
Python, I think they're called Python Enhancement Proposals.
And I just swapped out Python for projects.
So they're called Project Enhancement Proposals.
And that's where the work gets done.
So if it's a specification, it could be some research.
It can be a knowledge-based article.
It could be, I even have my agents write blogs.
I call them builder logs.
It's so cool.
When we're done with a journey, I'm like, hey, can you just write a story about that?
And I use it to learn because I'm often exploring places where I don't know a lot and I need to get caught up.
And I'm the kind of developer who just wants to sit there and say, just do all the things, prompt a magical way and don't have any understanding.
A lot of the reasons why I'm building software isn't just to build the software and solve the problem.
It's to understand the software that should be written to get there.
And maybe in the future, that doesn't matter.
But all I have to say is that I think a lot about this process of getting to good software.
And I question, you know, is my software worthy of open source?
Does somebody else want to use my stuff?
And how will open source change when essentially generating a solution, whether you have taste or not, is the closest version of free we've ever had?
Yeah.
One, I want to check that out.
That sounds really cool.
Also, you're really good at naming things.
Asian flow is cool.
Two great gems in there.
And two, just like, what does the world look like when we have software on demand and I don't know, software too cheap to meter?
I think whenever I think down the path of like, oh, what if software is just instantly generated on the fly?
I always come back to like, people don't want to make all of their software, right?
Like.
I don't want a blank phone and to be like, oh, you know what?
There's folders and I have an app where there's emails in here.
I don't want to have to think about that.
I want these smart defaults or tasteful things that I've decided that this is the way I want to work because I see it out there in its fully fledged form.
Doing a lot of abstract thinking and projects.
Talking about abstract things is really hard because you could say words and there's a picture in your head and then the person you said those words to has a completely different picture in their head.
So the farther you are away from something tangible and something fully fledged, the harder it is to communicate about, even if LLMs are so good at English and language.
So there's got to be some room for taste.
like opinions and um like having proposals for the ways things are put together and how software works in in that world and like maybe things look more like some kind of like remix culture right where i i say like i want to use atoms and then like i can change it right like i can change it on the fly but like i i don't want to go from like zero to one all by myself i want to like from 0.5 to one i'm gonna go from 0.5 to one i've thrown a lot of numbers around and i don't know if they all make sense well you know zero to one is a well-known term i like zero to 0.5 that's because that's where i feel i'm at i feel like a lot of my things are at 0.5 and 0.5 is usable by by adam and adam likes it okay yep i like my stuff you know i'm constantly working on it Hey friends, I'm here with Dan Mangus, co-founder and CEO of RWX.
Dan, what makes RWX and the way you're doing CI so different and interesting to our audience?
You know, obviously we're talking to you because we want to promote what we're doing.
We want more engineers to become aware of what we're doing at RWX.
But I think the thing that's interesting to me is that RWX is really kind of the first major evolution in CI and the approach for CI.
And this is just highly relevant with agentic-driven coding.
You know, CI has largely been the same since the advent of the practice.
But these platforms were created when being able to run code in the cloud was really valuable.
The fact that you could spin up virtual machines that would run some automation on a Git push was, you know, really impactful for engineering teams trying to like build good developer processes and tools.
But that's kind of the extent.
What we've done at RWX is we've taken state-of-the-art techniques used in build systems at organizations like Google and Meta.
Google has their internal build system Blaze that inspired the open source Bazel tool.
But every engineering team I've talked to that wants to adopt Bazel has just found it extraordinarily difficult to use and configure.
You have to have a dedicated engineering team to build and maintain the rules.
It's hard to extend it to work with different types of languages and frameworks that engineering teams are looking to adopt.
So it's been too prohibitive to actually adopt those technologies.
But the ideas behind Bazel are really impactful.
They're similar to a lot of the ideas behind Nix.
I would say Nix is kind of very similar, you know, in the difficulty to adopt.
And effectively what we've done in RWX is we've taken those techniques and we've made it very easy for engineers or agents to actually adopt and utilize those, which namely are the automatic content-based caching and the graph-based task execution, which means that RWX eliminates all redundancy.
Whereas other platforms are having to run the same setup steps on the same jobs in every virtual machine that's spinning up, RWX can run the setup once on one machine and then fan out accordingly based on just your dependency graph.
So effectively with RWX, you never have to think about parallelization at all.
On other platforms, it's always like, well, do I add this onto the existing job?
Do I make a new job for it?
But then I have to duplicate all that setup.
With RWX, you just define the tasks you want to run and the dependencies between it.
And we will run it with maximum parallelization based on your dependency graph.
Well, friends, a good next step is to go to rwx.com, learn more, check out CI in a whole new way.
Once again, rwx.com.
I was telling you before that I feel like I get so far into one thing I'm trying to get it to be usable by the masses.
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.
Do you know what Incas is, Amelia?
I do not.
This is the coolest new thing, by the way.
It's not new.
It's Canonicals LXD.
Relicensed 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.
Because if we can, that means prod is ephemeral in a way.
And we can get back to zero or get back to one quickly.
And so as I'm building this thing out and doing all this stuff, I'm like, there's a product here, Adam.
Cause like, I want to do this, not for just this software, but for other things I'm working on.
And so I started to get into this point where like, I stopped working on the main thing, you know, and now I'm over here working on this side project, this side quest that actually is really, really cool.
So that's it.
Like, that's what's happening.
I was like, I'm trying to go this direction, but I get shiny objected.
And now I'm over here building a side quest.
It's kind of cool.
Are you doing things like that too?
Or is it just like you just go straight and you're good?
There's no straight in my world.
There's no straight?
Gauntlet sounds very cool.
There never has been.
And it's even worse now than it has been, right?
Like it's so easy to build things that we're like doing it more and more.
So we wanted to talk about Intent, which is the app that I've been working with with Augment Code.
A lot of the motivation for that is like we there are existing problems within software development that like we have never solved and we're kind of just accelerating things.
And it's kind of like, can we can we just solve these first so we can 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 like.
To work collaboratively with other developers has never been easy, right?
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.
Is that right?
PR is where it happens.
In my experience.
Yeah, I guess the old way.
The new way is not so much.
That's why it's surprising, I guess.
I've been so steeped in this new way, I'd forgotten the old way that nothing happens until PR.
If you're talking about agents or other, like, do you work with other developers before?
No, I mean, a lot of it is not collaborative.
I mean, in open source, yes, other developers, 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?
It is.
Especially if we work on, I know, as a lone wolf developer, I kind of like it.
But, like, things should be shareable, right?
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 local VS code.
And then I write code on it.
And the output's 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, feature B.
There's a like, you know, there's a bug 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?
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 our work as developers is only partially code.
A lot of it is just context integration and testing and all these other things.
And so 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 collaboration is even more important now.
Because the same tools that would make things 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 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 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 like add this primitive of a workspace.
And then now that we have that, so within the app, everything's a workspace.
It's not like an agent chat.
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.
Right.
And then, you know, that has its own like get work tree.
It has its own set of agents.
It has its own set of like rich markdown documents to explain all the context and the spec.
And then.
Because that's all isolated, I can like switch between 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.
Like this last weekend, I was adding, you know, 10 separate features to this app and it's still a little bit crazy making, but it's so much easier.
Well, the challenge, I think what you may have solved for, and if I understand correctly, a workspace probably has its own Git work tree, which means it's not the same shared code base.
It's not really a true GitHub fork kind of thing or a Git fork thing, but it's literally, it's a separate instantiation of the code base with its own Git history that it pushes probably to main or to a branch if you're branching.
That's exactly, you know, I was just thinking about this this week really with AgentFlow.
It was like, The next way to get to where you want to go, I don't want to swarm a bunch of agents, but I do want to work in parallel.
I want to have a couple at least because there's things that might require a CLI touch and an API touch, which are two different code bases.
I want to keep the CLI maybe open source and the API is proprietary.
Maybe it's source available.
So you've got different kind of layers to your product.
While one agent's working on the CLI, the other one's working on the API.
I'm actually working in a model repo that has multiple sub repos because I'm trying to keep the agent in one repo kind of thing.
Which I think now Codex actually happily just goes wherever it wants to.
Whereas Claude seemed to be like, you know what?
I'm only here, okay?
If you tell me to go over there, I'm going to get confused.
This is me right here wherever you instantiated me at.
And that's a new word, instantiated me.
Instantiated.
I like it.
You know.
Just this idea, though, that that's spot on.
That's exactly where it needs to be.
Because if I'm going to have more than one agent, we have to have more than one code base.
If they're stomping each other's toes, it's like two devs working on the same repo trying to commit the same.
It's like, no, that is not how it should be.
How did you, I mean, it seems obvious, but how did you get to that realization from a technical standpoint and also from a design standpoint?
uh mostly just trying to constantly pushing the bounds but like they call it the bleeding edge because it's you know painful right like trying to use all the new tools and like 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 just toes and like They start accusing you of changing things, right?
They're like, 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.
The agent's very apologetic.
I'm not committing that.
I can't own that.
I didn't do that.
I got that one yesterday, by the way.
That was pretty funny.
Really?
Yeah, I was like, okay, chill.
I'm with you.
I know the other agent did it.
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 the, so two things, two things about what you're talking about.
When is like a lot of the like new explorations from the other tools are around a work tree per agent.
So each agent has its own get work tree.
And that's actually not the direction we went down.
We have one work tree per task.
And there's kind of these pros and cons for multiple agents working on the same task 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, 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 because i was doing large refactors where i was like i'm gonna make a markdown file and it's gonna like be split into 10 tasks and then i'm gonna kick off like 10 agents in parallel because 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.
Yeah.
I think there's mayors and stuff like that.
Citizens.
I don't even know.
I didn't go that deep yet.
That's exactly it, right?
It's like impossible to follow when you're just like starting from the primitives, which are like an agent.
So there's like a lot of really interesting things as far as orchestration that I feel like are just now being explored.
And there's a lot more that can be done there.
But I think we just need the tooling to make it easy to understand who's doing what and et cetera.
Take me into 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?
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 is one coordinator that you start a space with and it does all the research in it.
writes the spec and it makes sure like, it's usually the main thing that you're working with as a developer.
And then that coordinator on the fly can create other agents, like either blank ones or specialists.
So we, in our default prompt for the coordinator, we say for the subtasks, delegate them to implementer agents and implementer agents.
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.
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.
Right.
Like I'd be like, I don't know what's the scope of my work.
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 case.
And that verifier just knows exactly what the work is that just completed.
And it like goes through and verifies it.
You know, it runs the tests.
It runs the app and looks at it and 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.
So it's been kind of an interesting change in pace of how I do the work with agents.
Yeah, that's exactly where I've landed, too.
I mean, it's funny how we think like this, because I basically said to the agent, your work here is too important for you to do the work.
You're the planner.
You're my orchestrator.
You check on things.
You confirm the task is clear.
We subagent that.
And because, unfortunately, Codex isn't smart enough to have subagents yet.
or at least that I'm not aware of.
And I just haven't explored that.
So open a new tab and we create a flow essentially.
And I'm calling them flows where I want to get to, you know, from 0.5 to one or whatever, whatever phrase would apply to that.
You know, I want to have this task done, but you're my planner.
You're the orchestrator, even between a couple of repos.
So in the case of the sandbox, I have the main repo where, where I've got, I thought we actually landed on the fact that I just need like, one primary operator because I was trying to have an operator for that repo and an operator over here.
And I'm like, well, hang on a second.
Now they don't know what you're doing.
You have all the context and it got messy.
And so even with one operator between two repos and sort of two different versions, like you're here to battle test this thing and they're over there coordinating work on the product to evolve it.
And so it just made a lot more sense.
They're like, it got confusing for them and for me even.
So I'm like, your work here is too important to do the actual work.
You're my planner.
You're my verifier.
We are real time.
If we see a bug, we log a bug kind of thing.
If we have a thought about something, we'll spike out an idea or drop a document in there.
But really it came down to that as like, I want to have sub agents.
They go and do the work.
And yeah, you're right.
If you had sub agents or multiple agents working in a room together and they weren't told to introduce themselves, that would be weird.
That would be weird, right?
Like, well, hang on a second.
There's somebody touching my files over here.
There should be nobody in this room.
And, you know, they've got no eyes and no hands, so to speak.
So we kind of have to give our agents to do this work.
We kind of have to give them eyes to see something and give them hands to maneuver something.
And at the same time, I've learned, tell me if you've heard this before, if you feel this way, at least when I say this, trust the model.
Does that ring a bell or resonate anything inside you, Amelia?
Trust the model.
It makes me uncomfortable.
It makes you uncomfortable.
I have the opposite philosophy.
Okay, gosh, let's dig into that then.
So I've pushed on the model to not trust it.
And I don't know about you, but lately I've been just specifying things I want to do so well that when they come back with feelings, I guess, I don't know how to, their intentions or their thoughts on what I'm putting out there.
A lot of my responses end up being, I like that.
What are your suggestions for this?
I review their suggestions.
And I'm like, a lot of my responses is some idea.
They go and turn on it.
I review it.
And I'm like, this is awesome.
And then I ask it for clarity and blind spots.
And like they go back and review what we've done because I don't got time to do that.
Go and review it for clarity.
Is this clear?
Are there any blind spots?
We're not thinking about that.
If we started to implement this now, the agent could do it, but it would be guessing along the way.
And then that's not my intent.
That's not my intention.
And so then they come back like, well, here's five or six things that is unclear.
And here's like six major.
Here's two high blind spots and here's two sort of mediocre ones.
And so I can think about those for sure.
But I'm busy podcasting, responding.
Like I have a job.
My only job isn't this.
If this was my only job, I would probably read a lot more of it.
So then my next question is to the agent.
What are your suggestions on those things?
Because I want to review your suggestions because you've got the time to examine it, agent, not me.
And so that comes back with these suggestions.
I read those.
I'm like, yeah, those are great suggestions.
My next response, Amelia, is what?
Do it.
So a lot of my interaction with the model is, in a way, trust the model.
Not because I blindly trust it, but because I've learned.
that it's got some pretty good thoughts and it's a heck of a lot smarter than me and certainly way faster.
And so a lot of it is my intention, my ideas, my desires, my problems.
It's helping me solve.
And my responses are pretty mediocre.
It's like, what do you think about that?
And do it.
It's like, if you looked at my history, my up history is like a lot of that.
Like, what do you think about that?
Do it.
What do you think about that?
Do it.
You know, I don't know.
Anyways.
revealing too many of my cards here in terms of like just how much I do trust the model when it comes to what I'm making.
No, that's exactly right.
There's Augment launched this feature a while ago.
And a lot of these agents have this, which is enhanced prompt, which is like you write a little bit and then you ask it to enhance the prompt and it turns your, you know, 10 words into a hundred words.
And like, I like this because, This is in a lot of ways what we're doing, right?
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?
And this wouldn't work.
previously with code because there's a lot of um 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 um 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.
Please do.
I like your numbers.
Don't feel bad about it.
0.75 to one.
Okay.
From add dark mode to, this is the code for adding dark mode.
I feel like enhanced prompt goes from zero to 0.1.
We're like, Nice.
It's a little, it's the negative TLDR, right?
Like it's a little bit more like, this is what you mean when you say that.
And then the way enhanced prompt works, it's really nice because you can edit it, right?
You can read through, okay, this is a little bit expanded and like, oh, you're going to assume I mean this.
Let me actually tweak that because I see it and like, it's actually not what I want.
And then like extrapolate a little bit more, you get to this, like a spec, right?
Like that's like the spectrum development.
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.
Or like that would be hard to read through.
And, you know, I can go from 0.5 to one and make assumptions like those assumptions along the way.
Let's like get out the like big decisions.
and like agree on them before we do the work.
So like, 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 flesh it out for us and turn it into code.
This episode is brought to you by our friends at NordLair.
Here's a weird asymmetry in the security world.
The tools that protect the Fortune 500s, the big guys.
The ones that actually stop ransomware before it encrypts everything.
They aren't available to most companies that need them most.
You, me, small businesses, mid-sized teams, startups.
They get breached constantly.
We see this every single day in our news cycles.
And the reason usually isn't that they're careless.
It's that the enterprise-grade stack assumed that you had a dedicated security team to run it.
most small businesses medium businesses startups they just don't have this nord layer is closing that gap it's a network security platform that combines vpn access control and threat protection into one place built on zero trust deployable in under 10 minutes no hardware no quarter-long rollout and friends this is affordable plans for just eight bucks a month enterprise-grade security minus the enterprise-sized team needed to run it.
Get up to 22% off NordLayer yearly plans plus an extra 10% off with the coupon code changelog-10-nordlayer.
Yes, the code is changelog-10-nordlayer or hyphen, whichever you choose.
Try it risk-free with a 14-day money-back guarantee.
Check it out at nordlayer.com slash the changelog.
And we use our link.
As you know, you're supporting our show.
We appreciate that.
Once again, NordLayer.com slash the changelog.
My audience knows this.
Love Augment.
I use Augie on the daily.
Augie is my one-shot tool.
I love to just give Augie something just to churn on for a while.
Like I'll do a lot of thinking with Cloud, with Codex.
I'm no fan of just one particular.
I feel like any developer really should use.
everything they can actually afford and get their hands on.
And I'll even just let me mention, you mentioned, how did you describe it?
You said token, I don't think you said token efficiency, but where you want it to be, what'd you say?
Do you remember what you said about it?
I mentioned before, like people are differently token sensitive.
Token sensitive.
I like that phrase a lot.
I feel like that needs to be a phrase in our world because there are some that are more token sensitive.
I'm like, hey, listen, when we're in, when we're orchestrated while you're telling this agent what to do, we're going to use codecs or a GPT 5.3 codecs like on high.
We don't care.
Like I want the best code we can.
I have plenty of usage space.
So don't, you know, take me down to a lesser model.
And I don't care about speed.
I just, you know, it's working in the background.
So I'm not trying to get there in two minutes when five minutes is better.
Or whatever the case might be.
So being token sensitive, I think, is really an interesting place to be.
And I'm just sort of like, you know what?
I have access.
I'm going to use access.
And maybe somebody is a little less like that.
I'm trying to figure out where I was trying to go with that because I kind of sidetracked myself getting on token sensitivity there.
You're talking about like enhanced prompt.
Yes.
How much I like Augie.
Yeah, my one shot.
Yeah.
Thank you for bringing me back there.
I really appreciate that.
So big fan of Augie and how this is the feature I've never used though.
I've never used this prompt enhance and so I'm going to have to try it.
And I guess my challenge there is that when we put our little pros into the text box, the CLI, the web app, I think Codex now has a an app version, which felt so non-hacker, so I had to go back to terminal.
Even though they gave me 2x usage, I'm like, no, no, no.
I'm going back to where I feel hacker, okay?
CLI is just where it's supposed to be.
Don't take us away from that.
I guess maybe intent did that too, so sorry about that.
It's okay.
Maybe you have some thoughts on that front there.
I feel like hacker is the way.
Don't take me too far away from hacker.
I feel at home in the terminal.
You know, it's about feeling good.
But here I am in the terminal, and it just...
I have no affinity to which model I'm using or which platform I'm using, but I've never used this enhancement.
Because I feel like, at least for me, and why I haven't leveraged it, is because part of it is this dance.
Part of it is this trust the model.
And I'm not just trying to get to software.
I'm trying to get to reasoning for myself, not just for it.
Even though I say, hey, what suggestions do you have?
Do it.
That whole mantra back up.
a minute or two ago despite saying that i still want to learn along the way and so part of that learning is is my troglodyte prose into it that comes out the other end with clarity and it's that back and forth that i feel like it's like a potter and clay in a way it's like the it doesn't turn into the bowl right away or this beautiful thing like for example here this my coffee cup is it's a hansami it's japanese like This is Japanese slavery here, Amelia.
It's just a typical coffee cup.
But somebody made this with their hand.
And it's amazing.
I love that.
To get to that, you have to feel all the bumps.
You have to feel all the pressure.
And so I haven't wanted to enhance my prompts because I feel like, not that I'm against it, but me sort of feeling the pace, feeling the pressure, the back pressure of...
my dumb idea turned into a good idea to understanding that it's a good idea, to understand a new paradigm, to a different way of thinking about it, maybe introducing Bun versus Go or Svelte with SvelteKit versus something else versus Tanstack Start.
Like, oh my gosh, the war's out there, right?
You know, like the wars are immense.
But I feel like that's where I'm personally learning.
And maybe that's a today problem, which I think is really important to mention, right?
This is 2026.
And this is how I feel today.
This is the problem of today.
Maybe in six months from now, I won't care so much because the agent is just so smart.
I should just forget trying to understand.
I don't know.
What do you think?
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?
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 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 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.
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.
can we leverage 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 feelings behind it.
So that it's not just like type prompt into box and it's fit something out, but it's not the usual like paint that we work with as painters.
Right.
And I feel like this applies to code, too, where like, how do we how do we leverage AI to act like a tool and not like just an automation of what it is that we do as developers?
And I think that's like a little bit for me what you're getting at.
Very much.
Yeah.
Like, what do we want out of this, really?
Yeah, it's like it's like trying to build a house and you're framing and instead of having one framer with one nail gun, you have.
infinite in a sense or unlimited nails or just something that not so much speeds it up it's it speeds up the idea of thought you know you'd mentioned um as a designer I feel like I'm a software designer now not a software developer in a way yeah uh I'm designing it rather than developing it but it's kind of a both but it's more design than development and I think you're spot on with the identity crisis I think a lot of people even listen to this it's probably somebody Not listening now because he got upset midway.
Maybe you're mentioning more numbers potentially.
I'm just kidding.
I love that.
Maybe it's something I said.
But I think we're all having this identity crisis to what are we really trying to do here?
And I think you're right too.
It depends on your motivation and how you leverage the tool.
I think the way I look at what AI is today.
for developers and how I'm using it is very much like a tool, not a create this thing for me.
It's helped me create this thing.
Help me use your infinite knowledge so I can connect my own dots, you know, my own problems.
That's why I keep inventing new software.
My wife is, I think she might be on the edge of being not cool with it anymore.
We'll see.
Because I will often say to her, In the morning or in the evening we go to bed.
Babe, I invented something new today.
And this is a very common occurrence.
Like I mentioned gauntlet.
And then there's agent flow.
And then there's BKT.
A lot of these things are acronyms for some reason.
My son's like, dad, why are you naming all these things acronyms?
And it's not really intentional, I guess.
They're not really acronyms.
But agent flow is an acronym.
It's a full phrase.
So get off my back.
But although the command for agent flow is AF, Amelia, how cool is AF, right?
As a command, you type into a prompt.
I think you win at naming things.
Yeah.
Well, thank you.
It's not the millennial version of AF.
It's just kind of cool either way.
It's super short, super slim.
Hey, millennial stuff is cool.
I'm an older fella, so I think I'm Gen Z, Gen X.
I think I'm Gen X.
If I recall correctly, I forget which gens there are.
I just know that I'm old now.
I feel like I still feel young, but I am old.
So I'm often like in a room of folks.
I'm like, yeah, you're kind of like 10 years older than we are.
I'm like, sorry about that.
Just maybe 16 years older than you are.
Maybe even you, you, you underaged me.
Thank you very much.
It's weird how that happens.
But very much in this identity crisis, very much trying to use AI as a tool to help.
me create and invent and design new things versus simply magic box.
Give me something.
You know everything.
I know nothing.
Thank you very much.
Software created, product made, open source done, you know, 10 million ARR.
You know, like that's not my world, you know?
I'm not even trying to vibe my way to get there.
And I empathize with those trying to get there because the world, the world says be richer.
The world says make more.
The world says ARR.
The world says high valuation.
The world says raise $100 million.
And kudos to those folks there.
By the way, Michael Greenish, congrats on the 100 mil for WorkOS.
Big fan of Michael and WorkOS, but they just raised their 100 mil just yesterday.
And he's coming on the podcast this Thursday, so it'll come to the actual airwaves here soon.
But no knock against that.
That's cool.
And he started WorkOS before the advent of AI.
And now AI is sort of reinventing.
or helping folks reinvent their platforms?
Because, well, now, Amelia, you don't have to just support Go as your SDK because you're a Go shop.
Now you can support TypeScript.
God bless you.
Go.
Pick your language that you want to.
Maybe even Ruby again.
Who knows?
Because that's the fringe.
That's the edge case.
What are your thoughts on that?
It's like not just a tool to make more, but a tool to sort of flatten things because rather than just support...
an interface for my software, an API for my software that is only an API in this way.
Now I can have an MCP server, I can have SDKs, and I can actually have good SDKs because we can move a little faster and support more of a footprint.
That the footprint can widen because we have this new invention tool, this new design tool we have.
I feel like my answer isn't super different 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 percent 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 yeah 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's a new muscle that I have to exercise.
Right.
Yeah, for sure.
Your choice is your superpower, Amelia.
Are you a fan of Notion?
Because I think there's some change in the Notion world, which is interesting.
I just saw something.
You thought Notion was just docs.
Everything just changed.
And so now they're like a version of Clot, I guess, in a way where they have Notion agents and they're a sponsor.
I'm not sure if they're sponsoring this podcast and they may get upset, but that's just how it works.
But I think I'm kind of confused by Notion because I like Notion.
I use Notion for what it...
What it has been, let's just say.
Not what it was.
What it has been, which is a place to organize teams of folks or one people or many and collaborate with external folks on documents, workflows, statuses.
It's a version of a document state machine, right?
Comments can happen there.
You can invite people in there.
And I think what inhibited my usage of it is just the difficulty it is to manage.
that kind of workspace anyways.
So kudos to them for throwing agents in there or Notion AI, which I use, and I think it's super awesome.
But now I'm not sure what Notion is because if Notion is where I go to build agents that don't even belong in Notion, what is Notion?
So it kind of comes to this notion or to this thought that you had here, which is, you know, if we have no restraints and we can just put, we can just build anything.
what shall we build?
I'm paraphrasing what you said, and I don't remember perfectly my brain and feel free to restate your, your phrase, but how do you feel about that?
I suppose, where you've got a tool that was sort of known for one thing and now it's almost reinventing itself to the point where you're like, wait, now I go to notion for the thing I didn't go to notion for.
And I'm just using them as an example because it's the most clear recent example of a, not so much a major reinvention, but a major, major new feature that sort of makes you rethink.
And they even said in their advertisements on who they are, we're not this anymore.
You thought we were just this.
Now we're 60%, not just the 40% you thought we were before.
So what do you, what do you think about that with this massive reinvention and just doing more than you should could?
Yeah.
I think it's like this reckoning of how do we use computers?
There's, there's two analogies that I have in my head.
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.
And 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.
um, where like, you can talk to an agent about all your workspaces.
Um, 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 where like, we're, it's like, 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 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 then.
And I feel like a lot of software is just going along this, this trend of like, okay, like the way we interact with this is changing and how do we design around that?
And how does that change our identity as software?
Yeah, I like that idea.
I mean, that's exactly, it's exactly what I want.
You know, as I mentioned before, I confided in you and to the rest of the audience that I have a hoarding problem with my software and I can't stop inventing new things because I keep finding more problems that I want some else to solve.
Then I'm like, well, why don't you just take a stab at it?
Because what's the worst thing going to happen?
Like, will you fail?
to yourself like what's the big deal to just do it right right and it's the tension between like i want to feel the medium still right and i want to do more things right so we need interfaces that make it possible to move between those two levels i think about maps a lot right like a map is like an amazing feat of design like google maps right we have static maps but like google maps right like it like first of all it's just amazing that we've mapped you know basically everything in the world But like, if you think about all of the design decisions that go into, like, think of the map of your town at a high level.
You see all the highways and like what's green and what's not green.
Where are the busy areas?
You zoom in a little bit.
You start seeing like smaller streets.
You zoom in more and you see like paths and you see buildings and you zoom in more.
You can even go inside a building.
Like, it's just like.
amazing the like perspective shift that they have to manage in like one interface and like the fact that you can seamlessly zoom in from like inside a building to like a whole town to like a whole country like it blows my mind and I keep thinking about that it's like how do we design other things that way now that qualitative things are a little bit more malleable yeah yeah I kind of want to either have own or create a software factory not so i can churn out software but because i think and maybe at some point everyone else will truly be a builder because this will just flatten but i think for now it's the was developers to be software designers or whatever our identity crisis is leading us towards is that i really want to have a software factory but like i said not because i just want to churn out software i want to have the zoom in i want to have the macro and the micro because i want I want to have the big picture designer idea.
I want to have the intent idea.
I think the name intent by Augment was just spot on.
I don't know if you were involved in the naming of that, but was that your name?
Did you name it?
That was not me.
Were you in the work for the scrum or whatever you want to call it to sort of think through the name?
Yeah, we kicked out around a lot of names.
It started out as workspaces, which is very literal.
A little, yeah, a little bland.
You hear it and you're like, okay, I kind of get what that is.
But like we kicked around a bunch and intent.
Yeah.
Intent.
I still like it, which means a lot.
I think intent is a pretty good name for where it's at.
I'm not sure because even with my own names, I'm like, eh, I don't know.
You know, I don't know.
All of the names you've mentioned have been grade A.
Well, thank you.
I think it's fun.
As a designer, as someone with intent and good taste, I think I have good taste.
I've learned to trust my taste because I keep solving my own problems.
And I think there's this agent psychosis thing that I think people have talked about.
And I'm like, Adam, do you have agent psychosis because all your ideas are good?
But it's not the agent telling me my ideas are good.
It's me making the thing and using the thing and being like, okay, the idea is good.
And so I don't feel.
Like I have this agent psychosis, although I am very aware that it is a phenomenon happening to folks.
But I do want to zoom in because I want the understanding and reasoning.
I do want to understand my choice between.
So here's something I deliberated between recently, which is I like languages that compile to a binary.
So Rust, Go, Button.
And then there might be more, but I'm just not familiar with every language it does.
And so I largely deliver most of my software in Go for those reasons.
It's just easier to deliver a binary, right?
So easy.
Rust is a harder language to reason about.
So I like Rust.
I like to use Rust when it makes sense.
But largely my language of choice for most things is Go.
And then I recently was building something with Ruby because I really want to get back into Ruby and particularly like Ruby on Rails.
Because Rails does APIs very well, and it obviously does web UIs extremely well.
It's got models, views, context.
It has all that stuff.
Sorry, controller, not context.
But then I was like, I got to a certain point with this application where Ruby on Rails could have done it.
But then it posed some challenges to deliver us.
I won't go into the details, but you can't compile a Ruby on Rails app to a binary.
It's just not possible.
And I'm not going to solve that problem.
Yet.
I don't think I'm ever going to solve that problem.
Maybe somebody else is trying to.
So then you have Bun.
And you're like, well, Bun can deliver me a TypeScript application compiled down.
And because of the way SvelteKit works and Svelte works, it's just writing.
It's an abstraction above plain old JavaScript, which I don't want to write because who wants to do that anymore, right?
It's not smart.
It's like not using agents.
So I want to use SvelteKit.
And I want to make some really good friend UI and just...
different things in the JavaScript ecosystem.
And I want to leverage NPM and all the goodies that are there.
But I can still have a compiled binary, right?
I can take a Svelkin app inside a BUN and compile down to one thing.
And so all that to say is like, you know, when I explore my world, I want that.
I want that micro.
But then I want to zoom out to the macro and say, show me the map.
Where's the United States?
Where's Earth?
And Earth is like all my projects.
And so I very much as a software designer, developer, builder, identity crisis, whatever you want to call me or us, I want the micro and I want the macro.
So I applaud you for that work on intent to just give the zoom in and the zoom out.
It's very much important.
Yeah, this is actually like, it's something I've grappled with for a long time is like, how do you represent something?
At the macro.
How do you represent a code base at the macro?
And it's a really, really hard problem for many reasons.
One is which, like, there's no one representation that will satisfy everyone because we all have different mental maps of a code base.
And there is no, like, you either visualize it as, like, this is the directory structure because that's the only, like...
pseudo spatial thing that we have or like you use the AST to generate a map or you do something more semantic that's like in my head the structure is like here's the front end here's the back end here are the API routes so there's just like a lot of there's a huge exploration area as far as like what is a way to visualize code bases and tasks and like monorepos and sets of code bases and like how do you zoom out and what does that look like and what are the affordances that I want at that level so it's something that I'm very excited to explore more but has also been virtually unexplored so there's there's a lot we can do in the short term and in the long term I wonder, Amelia, if we're just code explorers in the end, you know, if we just become that and just become code explorers.
I don't know.
Every time I hit a hurdle, I want to explore further.
And then I got to leverage my taste and justification for should I build that or should I pull back?
Should I do that?
Should I add this feature?
Should I not add this feature?
So I very much feel the tension that you described here.
What is the best way to get started with intent?
Is it just, if you had to give someone an on-ramp, go here, do this, what would it be?
You built the thing, show off how you're proud.
Come use it.
We love feedback.
It's free.
Bring your own agent.
You can use Cloud Code or Codex, or we recommend Augment's agent because it's really good at saying grounded, especially in complex code bases.
Augmentcode.com slash intent.
Download it.
We have a Mac release right now and we've got Windows and Linux in the works.
And just like open it up, start, tell it what task you want to do and it'll make a spec for you and go from there.
It's been really fun playing with it.
And it's like it should be a very, very smooth, fast onboarding where you just hook it up to your existing CLI agent.
Yeah, I love that.
I already had Augie installed on myself.
And so I was like, yep, sweet.
Already got that.
I chose a repo to play in.
I started playing with it.
Of course, I went straight to my micro version of it, which was just me and an agent versus the swarm.
I know we can go right or left, which I think is kind of cool.
You can bifurcate the direction you want to go to there.
But I was like, I'm comfortable here for now.
Although I do think I want to swarm or have multiple agents.
I forget what the terminology was that you used, but it was something like swarm.
or multi-agent or something like that.
So for any given workspace, you can choose the specialist that you start with.
And so you either choose the coordinator, which does all this orchestration, or you can just do like one agent that doesn't delegate.
It just writes a spec for you.
And then you ask it to, yeah, more of a back and forth.
Yeah, that's where I'm at for now.
I'm still getting comfortable with.
Trusting the models and trusting the agents to do all my things.
But I do like the exploration of this world.
Anything in closing, Emily, anything I didn't ask you that we can tell out?
How could people track you, trace you, follow you, pay attention to what you're putting down?
I know you have a blog.
Do you still write a lot?
How do you feel about writing?
How should people keep up with you?
What's the best way?
I have so many thoughts and yet so little time to write them down.
I do have a blog.
If you search, if you can spell my last name, you can find me on all the things.
W-A-T-T-E-N-B-E-R-G-E-R.com.
Nailed it.
Exactly.
I had it written right here.
I was on your website.
Yep.
Wattenberger.
I have monopolized my family name online.
Sorry, everybody in my family.
Well, you know, when you're famous, you're famous, right, Amelia?
Yep.
Yep.
Very famous.
Well, thank you so much.
It's been so awesome going deep with you on this conversation.
The intent we have is super important.
And as tastemakers, we have to align that with the future we're trying to get to.
And it's subjective to where we're trying to go and how we use these tools.
But I love the conversation.
Thank you so much for spending time with me.
Much appreciated.
Thanks so much, Adam.
This was a lot of fun.
Well, that's it.
This show's done.
Thank you so much for your patience, you all.
You know, I know change is challenging and I know information and lack of information when change happens is kind of a bummer.
And I get that.
And I will tell you that I want to share everything with you.
I want to share where I'm at.
I want to share where I'm going.
I want to share where the show is going.
And I want you to rest assured that nothing is changing, but kind of everything is changing in a good way.
This show is going to get better.
This show is going to have more.
And I'm going to diversify a bit, work some software.
Go behind the scenes a bit.
I've got some plans, but I'm in the middle of re-architecting things.
So be patient with me.
Be patient with the process of this podcast.
And just know that I have good will for you and your best interests at heart.
Many of you out there, I call my dear friends.
And I am so thankful for you listening all these years, your loyalty, and of course, your friendship.
But this show today with Amelia is very cool.
Talking about agents, it's kind of all the rage.
As you know, it's everywhere.
We can't avoid it.
But this replatforming, the perspective that she brings to the table is such a unique perspective in her design skills, her intention on intent.
The product is paramount and so cool.
And so going back through her journey, talking about intent and what they're doing with it was so cool for me.
And I enjoyed it.
I hope you enjoyed it, too.
Big thank you to our friends again over at RWX.
our friends at WorkOS, our friends at NordLayer, and of course, our friends and partners at Fly.io.
The Beats, as always, by Breakmaster Cylinder.
Those fantastic beats.
And thank you so much for listening.
That's it.
The show's done.
We'll see you next week.