What's up, welcome back to the ChainLog, I'm Adam Stikoviak and it's been a minute. I've missed you. You know, sometimes you have to retreat to attack. I said 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 the groove and do your best work. Rest assured my friends, the ChainLog is you're just a, nothing's changing and I'm working on some really big ideas and I cannot wait to show them with you. Today, I'm talking with Amelia Wottemberger, designer, DataViz, 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 Agentverse World War Inn, the arc from auto-complete to chat to CLI back to UI, YIntent treats a workspace as a core primitive and not a chat thread. The tree off between one work tree per agent versus one work tree per task and YXI thinks prototyping just got easier, but finishing got harder. Hey, man, so thank you to our friends at Fly Without Them.
This probably 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, offer agents. I feel like this is burgeoning.
It's kind of happening all of a sudden. What's the state of the world for author agents? Yeah, it feels like author agents 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 author agents, 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 WorkQuest Pipes. It's actually more of an integrations product.
It helps you take your agent and connect it to your customers, Google Drive, and connect it to Salesforce and HubSpot and connect 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. The other type is actually authorization. It's like permissions for what the agent is going to go do because you connected 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 do a bunch of crazy stuff? That's a lot of stuff we're building today. We don't have a product announced yet, 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 around there. If you look at Microsoft and Microsoft's Intra 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 this into the WorkQuest platform. So if you're looking for an identity stack that will support agents, again, future proofing, WorkQuest is a great place to go, but it's changing really quickly. None of us were talking about Open Claw 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.
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 7 or 8 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 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 agent 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 feature 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 CLI, 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 be that deal.
It's literally free. Again, workOS.com, try it out today. Friends, I'm here with a friend, JSPartier, slash friend of the developer world, my one burger. It is my first time actually, I think, having a deep conversation with you.
I'm looking forward to this very much. We come from similar roots of desire. I haven't been to the lab you've been to, but they can have next as you've been to and the depth that you've been to. I love the vision design you've done in the world and I've always been a fan of you or so.
Finally, having a chance to go deep with you is a joy. So thank you for coming and welcome to the show. Yeah, how can I be here? It's long overdue.
It is long overdue. I wonder why we haven't done it sooner. We always say that, right? We do the fun things in life.
Why didn't we do this sooner? Everything 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 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 thing? I don't think we can.
I think it's here today. Yeah, yeah. A little bit of background about me that might inform my perspective. So I come from like design development database background and I joined the GitHub next team, which is like the R&D team at GitHub shortly before we launched GitHub Co-pilot, which in a lot of ways feels like the beginning of this craze.
It does. I would agree though. And so I've been paying attention to this space pretty closely since, gosh, what was that? I think it was 2022 and I don't remember.
It feels like things have been accelerating as far as 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. It's been like four plus years. And there has been a pretty coherent arc of first we did auto-complete, then we were like, we want to have chat conversations, chat GPT came out.
Let's ask agents. Let's ask LLM's 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, so what are we doing?
Are we actually changing that much? And now it feels like, oh, yeah, we're like, yeah. But like it is important to take a longer view of it because day to day it feels exhausting, right? So it's good to have a little bit of a wait is actually changing that much, scientifically perspective.
Can you can expose the insides of GitHub next and what brought on Co-Pilates and what brought on this world? I do agree with you that that feels like the first version of this for developers was auto-complete from GitHub Co-Pilate. And really a lot of pushback, even from GitHub and Microsoft for open source code and training models, 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 like any ownership or like intellectual ownership over Co-Pilate because I joined like right when we launched, like I helped with the launch.
There are some interesting things that are part of my experience of that time. Like there was a lot of pushback initially, like even internally. And then like the first users every time it was introduced to somebody, they're just like, yeah, we have auto-complete, right? Like it's just better auto-complete.
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, because mechanistically it's not so different than the things that we already had. But in practice, it's very, very different.
And I think like those earlier days in AI, there's 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. This was GitHub next though, right?
Like wasn't this a part of that or did it come out of research from GitHub next? And wouldn't the next thing, I remember having conversations about that earlier, like that was the whole point. Wasn't it like to do research and 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. And 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. So I have a lot of love for that team. What was your role there?
You were doing a lot of digitalization, which is such a long word to even say. I don't know how it 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 was some of the things that you did there to contribute and things that you really enjoyed doing?
Yeah, what projects did I work on? When I, in the beginning, it wasn't all about AI. So we did some fine 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 know, do you mean actions in general? Yeah, I get a back. Cool. Back to just one of the coolest pieces of tech ever, honestly, is so inventive.
It's one of those things that once you use it and you really, really appreciate it, understand it and you examine it, you're like, wow, this is 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. It's actually really, really powerful. It's almost like separate and compute from storage in a way or the way that you do that in distributed computing, you know, where you have the platform itself and then the runners, you sort of separate the engine that is the smarts, the if then else kind of scenarios with workflows and whatnot.
It's really just a, I think it's a pretty well piece of software. Yeah. And I also think a lot about the way it's integrated with the code base. Like this is, this is relevant these days with like agent roles, right?
Like what goes in the code base and what doesn't and like what should be coupled with get and get 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 something I think about a lot. Let's go back to exploring because I, 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 super powers 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 wait, hang on a second. Let me solve that. Let me see if I can think about that a little bit because it's much like you.
I have this product manager use 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 it's because I'm a podcaster and software developers along that I sort of left my roots in a way from the public eye. But internally, all I don't think about is design, intent, specification, how they should work. Why does it work that way?
Oh my gosh, I usually 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 where you're with exploration, being able to explore more? What software?
Yeah, it's really empowering. Like 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 big thoughts. But like if you think of like for any given thing that you're going to work on, if you think of the work linearly, right, like 0 to 0.5 is half of the work point probably up to one is all the way done.
Right. It's linear because 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 70% 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% of a thing, right? And like that number will go up, but like that 70% has been squished into 10% of the project. And then that last 30% 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 CD 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 it's actually quite a lot of work to go from like, oh, here's like a like 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 moving sidewalk, right?
You're like, you used to going fast and then you're like, wait, you don't have to go slow again. And like, you 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. Like 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 pro director, 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 no, we can see your painting kind of thing.
I knew an artist at one point, I'd always peak 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 unfinished, the exploration, the, oh, this was red. Now it's, let me just paint over the whole thing and kind of things.
That's why I say that. But I always appreciate that. But when we look at the way you product, 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 it polishes 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 actually scales to multiple teams and is sign up a bone, usable and viable and installable and instantiable 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 is going to have to change because, you know, that 70% 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 holders. Yeah, exactly.
I got some software and going on over here. So I'm empathizing big time. I've been running out of disk space. But what?
It's a lot of software. That's a lot. I tell agents to write a lot of software. So like that, like our impression of the valuable, like how valuable that that part is is going to change.
And then like, what do we think is valuable as a society and what do we want to pay for? Like, there's questions around that. And then there's also questions around like, how do you get it fully functional? Right?
Like, 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 less the less 20% that is 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 open source. But I'm like, well, then I would have the burden of open source and maintain your ship, 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 a 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 where 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 I sort of just like hold it back. How do you how do you feel about the state of the world?
You feel like every developer is in this version of a predicament? Yeah, the open source thing is really hard. There's a question of like, because these agents are getting better, how valuable, like, how does that change how valuable open source projects are and like, you know, MPM 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. 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-bilot 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 or my experiences or 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 the tedious annoying thing that they have to do. And once they write the docs, they're stale. So they're 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 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 suggested prompts for the code base.
So if they liked the prompt, they're 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 like a building.
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, I know I could generate that. And but I like the way you thought about it. So maybe it's more of a personal solution to how I solve the problem or how I think about problems. Now I break them down.
I 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 our friends of ours, but it's something you've, you know, you've designed. But you know, I've thought about this problem of how can we, how can we as technologists build software? And I keep thinking about like a knowledge base and the language of the agent is very much marked down.
Like I never thought I would care about how much markdown and like you were just saying about developers and write docs. I'm like, you know what? Kind of writing docs now. Okay.
It's like, it's my ability to control that future in a way. Like if the docs 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 and Hands My Proposals. And I just swapped out Python for projects. They're called Project, Enhanced My Proposals.
And that's where the work is done. You know, so if it's a specification, it could be some research, it could be a knowledge base 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 it says is that I think a lot about this, 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 is the closest version of free we've ever had?
Yeah. Also, you're really good at naming things. It's a plus one. Two great jumps 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 like a blank phone and to be like, oh, you know what, there's folders and I haven't ever where there's like emails in here, right?
Like, I don't want to have to think about that. I want like these smart defaults or like, like, tasteful things that I've decided that this is the way I want to work because I see it out there. And like, it's fully fledged form, right? Like, doing a lot of abstract thinking and products, 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 too has a completely different picture in their head. So like, the farther you are away from something tangible and something fully fledged, the harder it is to communicate about, even if LLMs are, you know, so good at English and language. So like, there's got to be some room for taste and like, opinions and like having proposals for the ways things are put together and how software works in that world. And like, maybe things look more like some kind of like, remix culture, right?
Where 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 don't want to go from like, zero to one all by myself. I want to like, I want to like, to one.
To one. I want to go from five to one. I would throw in a lot of numbers around and I don't know if they all make sense. Well, you know, zero to one is one in turn.
I like zero to point five. That's because that's where I feel I'm at. I feel like a lot of my things are point five and point five is usable by Adam and Adam likes it. Okay.
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 and CI and the approach for CI. And this is just highly relevant with a gigantic driven code in, you know, CI is largely in the same sense the end 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 and run some automation on a gift 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. You know, Google has our internal build system plays inspired the open source basil tool. But every engineering team I've talked to you that wants to adopt basil is just found it extraordinarily difficult to use and figure if they 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 and engineering teams are looking to adopt.
So it's been, you know, too prohibitive to actually adopt, you know, those technologies. But the idea behind days is really impactful. They're similar to a lot of the ideas behind NEX. I would say NEX is kind of very similar, you know, in the difficulty to adopt.
And effectively what we've done are to be honest, 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 it already eliminates all redundancy. You know, whereas other platforms are having to run the same set up steps on the same jobs, and every virtual machine that's spinning off, 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. You know, another platform is always like, well, I added this on to the existing job, I make a new job for it, but I have to do it all that setup.
With RWX, you've just defined the task that you want to run and the dependencies between it. And we will run it with maximum parallelization based on your dependency graph. What friends are 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 like get it to be usable by the masses. But to get there, I got to solve some other problems. So, one thing I did recently was I created this thing called gauntlet, 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 a femoral ink is containers involved. There's, do you know what ink is, Amelia? I do not.
This is the coolest new thing, by the way. It's not new. It's a canonical's LXD, Relicence because they had a license challenge and one of the original creators, maintainers, part of that. Fortit, Happily, Stefan, I forget his last name in the moment, but ink essentially is system-level containers and virtual machines.
So, think of a hypervisor, we're going to instantiate an LXD container or a VM pretty easily on some of the 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. Then I'm like, I get so shiny object, shiny object did.
And I have this idea to 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 the prod is prod and sandbox is sandbox.
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 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 a femoral 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 pod here out.
I'm 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 before I stopped working on the main thing. Now I'm over here working on this side project, this side quest. And actually it's really, really cool.
So that's it. That's what happened. I was like, I'm trying to go this direction, but I get shiny out to do it. 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.
That 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 want to talk about intent, which is the app that I've been working with with Augment code. And a lot of the motivation for that is like, there are existing problems within software development that we have never solved. And we're kind of just accelerating things. And it's kind of like, can we just solve these first so we can accelerate faster?
So there's actually a project I did at GitHub next. Work spaces are something where GitHub's fully remote. And this is right after COVID. And like to work collaboratively with other developers has never been easy.
Right? Like GitHub says it's like the social hub for developers, or at least they used to. But like we don't really work together before the PR. Like before that we're kind of just in our own heads.
Is that right? PR is where it happens. Yeah, I guess the old way. The new way is not so much.
If you're surprising, I guess, I guess I've been so steep 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, you have been sourced, yes, other developers.
But that's usually the potential of the call center. It's not a lot of like team collaboration getting to X. It's more like solo getting there. Which is weird, right?
Like it is. Especially if we work on, I know, as a lone wolf developer, I kind of like it. Like, I think it should be shareable, right? Like especially teams working on the same feature.
We're doing all this like duplicate conversations in Slack, like explaining the code that we're writing locally. And like there have been a few stabs at it and replic 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 a linear issue, I have a GitHub issue, maybe there's a sentry bug, I look at it, I talk about it, maybe if it comments on a talk in the ocean. And then I make a branch in my like local VS code.
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, feature B. There's like, you know, there's a bug in Prado.
No, let's fix it. And I like go back to my future 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 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 the 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, I've been 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, my demo I keep doing is adding dark mode to my website.
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 any blog posts, right? And those can have agents like whole team 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 work spaces, I have the visual manager of like maybe the browser is open or the spec is open.
And I know like exactly 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 the 10 things I'm working on at once. Like this last weekend, I was adding 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 finish correctly, it's probably has its own get work tree, which means it's not the same shared code base. It's a true get up for kind of thing or get for saying, but it's literally it's a separate instantiation of the code base with its own get 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 agent flow is like the next way to get to where you want to go.
I want to swarm a bunch of agents, but I do want to work in parallel. I want to have a couple of these things that might require a CLI touch and an API touch, which are two different code bases that keep the CLI maybe open source and the API is proprietary. Maybe it's source available. You know, so you've got different kind of layers to your product.
I'm like, wow, one agent is 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. What do you think now?
CodeX actually happily just goes wherever it wants to, whereas cloud seemed to be like, you know what, I'm only here. Okay, if you tell me to go with it, I'm confused. This is me right here, where you're in Stancia to me at and that's new word, in Stancia to me. It's just this idea though that that is 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 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?
Mostly just trying to constantly pushing the bounds, they call it the bleeding edge because it's painful, right? Trying to use all the new tools and I found myself running eight different agents at the same time, all working on different tests, and they step on each other's toes and they started accusing you of changing things, right? They're changing the file. They're changing the file I didn't do just so you know, okay, it wasn't me.
It's very apologetic. I'm not going to stop it. I didn't know that. I didn't do that.
You got that one yesterday, by the way, that was funny. I was like, okay, chill. I'm with you. I know the other agent did it.
I should be smarter and have intent here and do multiple work spaces and be smarter about them, so I'm just not there yet, okay? It's not going. Yeah, it is interesting. Two things about what you're talking about.
One is like a lot of the new explorations from the other tools are around a work tree per agent thread, so each agent has its own Git work tree. That's actually not the direction we went down. We have one work tree per task. There's these pros and cons for multiple agents working on the same task within the same environment.
That's kind of an interesting research exploration. I find it works quite well. As long as the agents know what each other is doing and are able to see, okay, these are the three other agents within the work space. This one's working on subtask A and I'm working on subtask B.
You really don't run into issues. The one set of issues that we did see a lot was we have them auto-committing. It's like a setting. You split a task into subtask and you say you tackle these three subtasks in parallel.
Then auto-commit when you're done. The way Git works is you have to stage files for hunks and then write a commit message and run the commands like that. They would step on each other's toes. We added a tool for queuing auto-commits.
Other than that, you get all of the benefits of one's working on creating a component, the other one's adding the component to the layout or another one's working on global style changes. You do want some of these tasks to be done within the application. You want to split things into tasks and link together. You need those to be in the same place.
You want visibility between those agents. You don't want a completely new cloud environment for all of these agents as they're working on the same thing. It's been interesting exploring what do you want at Sandbox at any given time. The other thing that's been interesting is just like orchestration paradigms.
With our given tool, it's hard to explore any kind of orchestration. I had a home-cooked parallel running system. I was doing large refactors. I'm going to make a markdown file and be slid into ten tasks.
I'm going to kick off ten agents and parallel it works faster. I can use cheaper agents when it's all spelled out. It was not conducive to exploring how to make that really nice. If you have the primitives to kick off different types of agents and they all have visibility into what each other is doing, there's some really interesting paradigm.
Our default paradigm within the app is the work space starts with a coordinator agent which writes the sec and then it delegates sub-task to implementers and then it in waves and then it asks the verifier to validate those changes and it works really well. There's other paradigms like spin up two agents and they ping pong between each other. Agent A goes and it critiques what Agent B did and does its own thing. They level each other up as they go.
There's all these really interesting paradigms that I really want to explore. Then you look at Gastown. There's a deacon. It's all town.
We have these mayors and stuff like that. I didn't go that deep yet. That's exactly it. It's impossible to follow when you're just starting from the primitives which are an agent.
There's a lot of really interesting things as far as orchestration that I feel like are just now being explored. There's a lot more that can be done there. I think we just need the tooling to make it easy to understand who's doing what and etc. Take me into this exploration around coordination.
That's probably the hardest part once you have multiple agents. I do think it's smart to do a task-based versus agent-based because you may want to have multiple agents. But then you have the issue of stomping on toes. You have to coordinate it.
Do you have a coordinator or an orchestrator or do you give them hats? Do you give agents a K agent? You're the verifier now. Now they assume this role.
How do you trust the model to let it explore and push back on the other agents? I guess that's how you want to frame it? Yeah, that's a good question. We have the concept of a specialist, which is like a persona.
It's like a prompt and a default model instead of tools. We ship the app with a default set of specialists. We have a coordinator, a verifier, a PR reviewer, a UI designer. There's some things to get people started.
But users can tweak those or make their own specialists. The default flow we have that we've found actually works really well is one coordinator that you start a space with. It breaks the spec and makes sure 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.
In our default prompt for the coordinator, we say for the subtasks, delegate them to implement agents. And implement agents depending on how token sensitive you are, it can be a cheaper model. Or it can be more expensive. I really want this to be as robust as possible.
And those implementers get their own sub task. And it's a note that they can write in and read from. It's 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. It's just the agents know and have visibility into who else is working. And it would be weird to join a team and not know who else was on the team or what they were working on.
I don't know what's the scope of my work. It's just this really smooth flow of coordinator delegates to implementers. And then we also found that agents don't always do exactly what they say they did. And maybe this will change.
But for now, sometimes an agent will be like I did xyz and you look at it and they only did xy. And so the coordinator is also told to delegate a verifier agent, which could be a cheaper model. You could use a code x 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 goes through and verifies it. It runs the app and looks at it and keeps everyone to task. And it reports that to the coordinator. And it's actually kind of a really interesting flow.
I get meaning to post about it of having this one chief of staff that you talk to for everything. And it delegates to other agents. So it's an interesting, it's a different flow where the work can be happening. And then 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 that output, I'll keep telling the bugs to the coordinator. And because it's not doing the work, sending messages is not like doing 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 what I've landed to. I mean, it's funny how we think like this because I basically said that the agent, your worker is too important for you to do the work.
You're the planner. You're my orchestrator. You check on things. The task is clear.
We sub-agent that. And it's because unfortunately Codex isn't smart enough to have sub-agents yet. Or at least 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 it flows. Where I want to get to, you know, from point five to one or whatever.
If I want to have this task done, but you're my planner. You're the worker shooter, even between a couple of repos. So in the case of the sandbox, I have the main repo 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 operator over here. And I'm like, well, hang on a second.
They don't know what you're doing. You have all the context and they 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, they got confusing for them and for me even. So you're work here is too important to do the actual work. You're my planner.
You're my verifier. We are real time. If you see a bug, we log a bug kind of thing. If you have a thought about something, we'll spike on an idea or drop a document in there.
But really came down to that. And I'm like, I'm not going to have subagents. They go and do the work. And yeah, you're right.
If you had subagents 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, hang on a second.
There's something touching my files over here. There should be nobody in this room. And they've got no eyes in their hands, sub-speaks. 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 know?
Trust the model. That makes me uncomfortable. It makes you uncomfortable. I have the opposite philosophy.
Okay, guys, I want to stick into that then. So I've pushed on the model to not trust it. And I don't know about you. I still hear 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 do 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.
I'm like, a lot of my responses is some idea. They go and turn on it. I review it. 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 have time to do that. Go and review it for clarity. Is this clear?
Are there any blind spots when I'm thinking about that? If we sort of implement this now, the agent could do it, but it would be guessing along the way. And then that's not my intention. And so then they come back like, here's five or six things.
There's this 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.
I had a job. My only job isn't this. If this is 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 responsibility is what? Do it. So a lot of my interaction with the model is in a way, trust the model, not because I've blindly trusted because I've learned that it's got some pretty good thoughts and it's heck of a lot more than me and certainly way faster. And so a lot of it is my intention, my idea is my desires, my problems, it's helped me solve and my responses are pretty mediocre.
It's like, what do you think about that and do it? And so if you look at my history, my history is like a lot of that. Like, what do you think about that? Do it.
What do you think about that? Do it. 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 an augment launch 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 10 words and 200 words. I like this because this is in a lot of ways what we're doing. We're trying to have a compressed version.
This is what talking is. You have an accidentally 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, I dark mode to my site. 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.
First of all, what is dark mode? What does this person mean when they say dark mode? Or what pages should this apply to? Should this have some kind of affordance to switch between dark mode and light mode?
And there's a set of less and less obvious assumptions that you can make about what the person means when they say these words. And you're doing, not going to bring out numbers again, but you're extrapolating. Please do. I like your numbers.
Going from... Okay. From ad dark mode to... This is the code for adding dark mode.
I feel like enhanced prompt goes from 0 to 0.1. Where like, it's a little... It's the negative TLDR. It's a little bit more...
This is what you mean when you say that. And then the way enhanced prompt works is really nice because you can edit it. You can read through, okay, this is a little bit expanded and like, oh, you're going to see my mean this. Let me actually tweak that because I see it and it's actually not what I want.
And then extrapolate a little bit more. You get to this spec. That's the spectrum development. Where 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 1 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 into code. This episode is brought to you by our friends at NordLayer.
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 the most. You, me, small businesses, midsize teams, startups, they get breached constantly.
We see this every single day in our news cycles. And the reason usually isn't there. Careless is 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.
NordLayer is closing that gap. It's a network security plan from the combines VPN, access control and threat protection into one place built on zero trust, deployable in under 10 minutes, no hardware, no cordolone rollouts and friends. This is affordable. Plans are just eight bucks a month.
Enterprise grade security minus the enterprise size team needed to run it. You have to 22% off NordLayer yearly plans plus an extra 10% off with the coupon code change log-10-Nordlayer. Yes, the code is change log-10-Nordlayer or hyphen, whichever you choose. For free with a 14 day money bag guarantee, check it out at Nordlayer.com slash the change log and we use our link as you know, supporting our show.
We appreciate that. Once again, Nordlayer.com slash the change log. My audience knows this. Love Augment.
I use Auggie on the daily. Auggie is my one shot tool. I love, I love just give Auggie something just to churn on for a while. I do a lot of thinking with, with cloud with codecs.
I'm, 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 you mention you mentioned, how did you describe it? You said token, I don't think it's a token efficiency, but where you want it to be. What'd you say?
I mentioned before, like people are differently token sensitive. Token sensitive. I like that phrase a lot. I feel like that needs to be, you know, 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 working straight away, you're telling this agent what to do, we're going to use codecs or 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, I'm, 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 might 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, I have access. I'm going to use access and maybe somebody is a little less, a little less like that. I'm trying to figure out where I was trying to go with that. I kind of sidetracked myself getting on token sensitivity there, but you're talking about like an enhanced prompt and talking about your own shot.
Yeah. Yeah. Thank you for bringing back there. So big fan of all you know, this is the feature I've never used though.