Kent C. Dodds (00:00.500)
Hey everybody, it's Kent C. Dodds again and I am joined by my friend Rhys Sullivan. How are you doing Rhys?

Rhys Sullivan (00:06.460)
I'm doing good, how are you?

Kent C. Dodds (00:07.840)
Super, super excited to chat with you about product engineering and what it means to build the right thing, to build things for users that will help the users to accomplish whatever job and tasks that they've got. Even if that be something just for fun I guess. Sometimes we talk about the jobs to be done and it's like very productive focus. But sometimes the job to be done is spend more time with my kid. And so, yeah, excited to talk with you Rhys about the work that you have done in the past and what you're doing now and how product engineering factors into all of that. So let's get into it. Let's actually get an intro to your background and the things that you have done to kind of contextualize our conversation here.

Rhys Sullivan (00:52.980)
Yeah. So I've done just this kind of a mix of projects I've done both like work experience and then also like fun projects on Twitter or like personal projects. On the work experience side, I would say my kind of like most public facing like product experience work that I've done was I was just at Vesel for the part of the year. And as working on our kind of domains products listing a lot of like feedback from users both through Twitter, but also like through customer support tickets that we would get through like the feedback button that people would have in the product. Just kind of all of these sources and seeing how can we make that experience really just incredible. And we being kind of the team were able to take the product experience of domains of Vesel from kind of something that was kind of left aside a little bit over the time to experience. I'm just like truly, really proud of and feels good to use now. And then on kind of the personal side, I've got a project to maintain good on server flow, which does web indexing discord servers. And that one was kind of my experience of like building a product out completely kind of independently, seeing how to get people using it, understanding like what needed to be built for that. And then I've had a bunch of like kind of fun little projects in between, notably like ship talkers, which is comparing tweets to commit ratio. Another recent one in the same vein was are you going exponential, which is your kind of GitHub chart with a nice trend line. And then most recently now I'm working on kind of a new project full time, which is executed.sh, which is going to be like MCP gateway for all of your integrations, whether that's open API, MCP GraphQL, Google discovery. I try to fix how agents do tool tooling.

Kent C. Dodds (02:50.560)
Very cool. And of course, like you, you do have a day job too.

Rhys Sullivan (02:53.580)
Oh, you're working over at Cloudflare now, right? No, not Cloudflare. I was at open code for the stint before weeks.

Kent C. Dodds (02:59.740)
Oh, okay.

Rhys Sullivan (03:00.700)
But I actually just swapped to go to do executor full time.

Kent C. Dodds (03:05.360)
Oh, wow.

Rhys Sullivan (03:06.060)
Because I was like, there's the, I've been, I've been one shot it by the code mode primitives. Um, and like need to go see what that can be.

Kent C. Dodds (03:15.100)
Yeah. Wow. That, that's exciting. Yeah. I knew that you were at open code. Sorry about that. Um, but, uh, going full time on executor, um, full time on MCP. So like MCP is kind of a big deal for me. A year ago, just over a year ago, I decided to completely pivot over to MCP. I still care very much about that, even though I'm, I'm doing the product engineering stuff. Um, and I'm actively working on, uh, my own MCP server. That's, uh, in some ways related to what executor is doing, uh, lots of code mode stuff. Um, and, uh, it's, it's pretty fun. Um, so I want to ask you a little bit about, um, executor. I actually want to ask you about lots of these things. Yeah. Um, but yeah, seeing as executor is kind of your big thing. Um, I want to, uh, get a little more context on what executor is, what it does. And then I want to get some insights into how you make the product decisions on something like this.

Rhys Sullivan (04:12.140)
Yeah. Um, so kind of the big picture for executor is as playing around with open claw, uh, probably like a month ago. Um, and I just found that I didn't love the, I, I love the concepts behind it, but the implementation just wasn't something that I like felt totally comfortable with. I, the, the, like, I, I mean, I like trust the models to be pretty aligned and like, I run like cloud of dangerously allow permissions. Like it's, um, there's like a, I have a good amount of trust for the models, but at the same time, like when I go to connect it to my Gmail, like it's spooky. I don't like, I, I'm with you. They, they're frighteningly helpful in a way. Um, and so my concern actually isn't that they act maliciously. My concern now is that they act helpfully, uh, and kind of think, Oh, I'll be helpful and I'll send an email. Not I'm getting prompt injected and I'll send an email. Um, so I like, I dunno, I, I, the whole thing is I need a thing that can go through my email and add things to my calendar. Uh, and it's a shock and it's like a shockingly, uh, deep problem. Um, and so what I was playing around with was the code mode stuff. Um, and I've done kind of like TRPC star things before where you have these like proxy objects that don't represent, uh, the real object. And I realized that I could like make these sub functions, um, that the agent cause and it, since it's an async function, you can just block until an approval comes in and the agent doesn't know that approval is happening. There's not all this like complex approval logic in execution flow. You just like block and, um, it happens. Uh, and then I just like, I, so playing around with that as a primitive, uh, then cloud flooded kind of more on the code mode stuff with the MCP server. Um, and I just kind of realized like this one primitive unlocks a ton of things around like gender UI workflows, like, um, the, I haven't built any of this yet, but like the agents can be able to like extend the product itself and like run like stuff in dynamic workload is and be at isolates. But then it's all like open source and can relatively new computer. Um, so yeah, that's the, that's kind of a lot of the vision for it.

Kent C. Dodds (06:30.000)
Yeah.

Rhys Sullivan (06:30.400)
Actually, there are probably people listening who don't know what we're talking about. Oh yeah.

Kent C. Dodds (06:35.040)
So like, and, and dynamic, uh, worker loaders and stuff. And so can you describe a little bit about what that is? I completely agree with you. It unlocks a lot and I've been used, I've been using the heck out of these. They're so, so cool. Uh, with my personal AI assistant, Cody, that is also an MCP accessible. But, uh, yeah, could you describe just briefly what this even is and why, um, your customers care?

Rhys Sullivan (07:00.420)
Yeah, I'll go, um, like super high level and just try and define each point. So MCP, um, is like the common gateway of getting a tool into an agent. We had this huge problem with MCPs where they would like blow up the context and you would want to add, you want to add your Gmail, your Google calendar, your for sale API, your cloudflare. You want to add all these tools, you want an agent to be able to call them. Um, but if you add all those just brought context window, uh, it blows up and you can't do anything. So enter code mode, which is a way of letting your agent. So the original pitch for it from Cloudflare was kind of let your agent call an MCP, um, by writing JavaScript. Uh, and what executor is, is it kind of takes that concept of letting your agent write code, but it makes it not so much MCP specific and more, um, like you can, if you just have a function name and optionally an input schema and an output schema, then your agent can like chain all of these things together. Um, and a bit of background on kind of why some like prior art on why this works so well, if you, is if you look at bash and like, if you're running a coding agent, you'll see it run all these bash commands and chain command together. You give it the same way of doing that, but you have this like much more enforceable permission model, uh, that can also be portable. And then the last part of it is the dynamic workloaders or sandboxing. Um, so you want your agent to, uh, what I think is really interesting is when you give the agent a sandbox environment, they'll try and break out of it. Um, they like really hate, uh, when there's like constraints and not trying to work around it. Um, so you need to give them an environment that they feel like they can, I can't believe I'm saying this about LLMs, but they can feel like they can like express themselves a little bit. Yeah. But they could like do the tool cores and the chains and all this stuff. Um, and so what's really cool about dynamic workload is, is it gives you a way to like run this untrusted code. Uh, you can do a similar thing locally with like quick JS or secure exactly as both great options. Uh, and then the last part of the super cool dynamic workload is, is you can install node modules and stuff. And so if you get into like MCB apps or general UI, like you can have it, right? These apps for you and load them dynamically. And I'm just like, this is a whole like area. This is like a whole new part of software engineering. It hasn't been explored yet, which I'm super excited about.

Kent C. Dodds (09:22.600)
Yeah. It's, it's super, super cool. Um, allowing the agent to, uh, to write code, um, opens up a lot of opportunities. Um, and, uh, the, it's just been a lot of fun to figure out how to, um, expose just the right amount of power to the agent, uh, while balancing the, like, I don't want it to, I don't want it to be too helpful.

Rhys Sullivan (09:47.800)
Yeah.

Kent C. Dodds (09:48.280)
Yeah.

Rhys Sullivan (09:50.040)
Um, yeah. Yeah.

Kent C. Dodds (09:51.720)
So, um, with executor, then this is intended to be a like consumer product or is this like supposed to be for developers? Like who, who are your customers for this?

Rhys Sullivan (10:03.700)
Yeah. The, I see two kind of, um, customers and like markets for it. One is I have an organization, some of my API endpoints, I need to set like a Salesforce API key for, but I don't want like my employees having access to that. Salesforce API key. And then maybe I only want like my sales engineers to have access to the Salesforce API. Uh, and the other part of that is like, well, maybe I want all to be able to sign up that Gmail and have like their own connectors. Uh, so there's this like concept of like an organization and then kind of scoping that down to a workspace and then even scoping that down to an individual level. Um, I'm still figuring out, uh, what the right primitives are. And I'll kind of talk actually if you want a little bit about like how I think about that like product decision. Um, cause this is for the like product engineering part of it. Um, I really try and look at like what the right primitives are to build. Um, and so when I look at something like organizations or workspaces or accounts or like these concepts, I don't look at it so much from a scope of like, um, I try and basically look at what the common pattern is and like what the right design that'll work for as many like extreme cases as possible. Um, and I will say that it like slows down my iteration cycle. And so that's something to be like mindful of. Um, but like I could go ship this like organizations workspace concept tomorrow, but then it's like, you might have someone who wants a sub workspace of their workspace that your like data model or design didn't take into account. Uh, and so I try and like look at what the higher level like concept of that is and the higher level concept of that is like a scope. And so like an organization scope and a workspace scope and an account scope, and then you can like inherit from multiple scopes. And then what's really cool about that is you might have like a remote scope. That's like your like executed cloud. Then you have like some MCP servers that just run locally. But again, you want this to be able to chain together to like your cloud stuff where you can like merge a remote scope into your local scope. Um, so that's the like products like product that is being built one part of the product. And that was kind of like how I'm thinking about building that part. Um, yeah.

Kent C. Dodds (12:08.880)
Yeah. Yeah. Yeah. That I actually want to dig into that a little bit deeper. How do you go about, um, coming up with these kinds of primitives like scope? Um, like, uh, are you talking to customers? Are you just intuiting that from your past experience? Um, and like, uh, you clearly you've got a vision for what this product is supposed to be. Uh, how do you break that vision down into the proper primitives to unlock the, um, specific, uh, jobs to be done? The specific use cases that you've got.

Rhys Sullivan (12:42.360)
Yeah. For me, I really try and like look at what the extreme cases are. Um, so that's like, you have an organization like Microsoft and you might have like multiple organizations, like multiple workspaces in that, which then have multiple, like the, I really try and like think about like, if you're an employee at Microsoft using this product, what does that look like? Like, and what like enables you to use it properly. Um, and there's like pros and cons to it. Uh, because for it, the, you have to like, not get caught up too much in like landing on the perfect architecture. You have to like find something that lets you ship incrementally. Um, but I also just feel like I have kind of a lot of experience using products at this point. I try and be like pretty observant in like, like for example, I just signed up for the like, I needed to test the linear MCB. And so I made a fresh linear account. And when I was going through that onboarding, I was like, Oh, there's a really bunch of really great concepts in here around like how they do a, like how they have you set up your domain during onboarding.

Rhys Sullivan (13:57.680)
Um, and so I try and like observe all of these things from products. And then I just have like, uh, I have a discord channel, uh, and like a small brand group server that I just don't pull these notes into. Uh, and sometimes they'll also chime in with like observations. Um, I should probably convert that to the Kupathi second brand, uh, thing. Um, if anyone has suggestions for you'd want to use. Um, I'm going to try to get a little bit more. Um, I'm going to try to get a little bit more. Uh, yeah, I just, I shouldn't be very observant with products and how they can be used.

Kent C. Dodds (14:24.360)
Yeah. And, and like taking notes and, um, everything. And so when, when you go into, um, building out your, uh, the primitives for your use cases or for, uh, executor, for example, or any of these, um, you're kind of playing out the future a little bit, but also not too far, uh, so that it's scoped to something where you, you don't end up solving problems you don't have yet. That sort of thing.

Rhys Sullivan (14:49.780)
Yeah. It's a very tough balance to strike and I do not strike it perfectly. Uh, but like for example, um, I know that I want executed to be plugin based and everything to kind of, uh, match that model. And so like one of the trade offs that I've made right now is that everything is plugin based, but like, if you open up the code, you'll see plugins are defined in like five different places in terms of like getting them into the front end and the back end and like SDK. And there's not like a nice, like registry of them where you can't do like user loaded ones, but all of that is like possible because of the underlying architecture. And like, if you go like consume SDK directly, you can add a plugin. Um, it just like, there needs to be more kind of blood put in to get it user basing, but it doesn't like block on getting to this perfect architecture.

Kent C. Dodds (15:36.340)
So, uh, I'm curious how, like, where did that experience come from when you decided upfront, like, you know what, I think this needs to be plugin based. Like you, you learned at some point that the plugin architecture was right for this. Uh, you didn't have to go and build exec, uh, executor, exec, executor, executor.

Rhys Sullivan (15:56.940)
Executor. Yeah.

Kent C. Dodds (15:57.840)
And then, uh, have to be like, Oh, I should have made this plugin base and start over from scratch. You, you had some experience where'd that experience come from?

Rhys Sullivan (16:04.960)
Yeah, that's a good, I did not land on the plugin approach immediately. Uh, originally it was, um, there's a good link to general thread here about building with AI. Uh, so I actually went through four versions of it to get to the current code base because I was like, I don't know, I like see people on Twitter say, Oh, I am like completely hands off. I don't need to look at the code anymore. And I'm like, okay, let me like try that, um, with this. And like, just kind of like vibe out these ideas and see where it ends up. Uh, and so the very first version, um, there was, so one of the like product requirements that I had for it was not losing fidelity when you, uh, import a specification. And so what I mean by that is if I have like open API and graph QL, uh, you can make some sort of like representation of those two. That's like, yeah, you can like do graph QL through post requests. And so you could like convert the graph QL schema to like some, the, what I ended up within the code base was like an intermediate representation with like just this JSON blob that was like, Hey, here's the HBM points you call. And like how it gets constructed. Um, and it just like, the, you feel this less now when you're like doing the agentic engineering, but like, I just felt the code base like fighting me a ton under that model. Um, and I was like, okay, let me like revisit this from like, how do I build a system? How do I like build a system that doesn't have those trade-offs? Uh, and I was kind of taking a look at like what people were really loving at the time, which is like pie and, uh, like extent was software. Uh, and that got me looking deeper at like going plugin based. And then I realized that I could put all of the like cooling implementation and complexity inside the plugin rather than the core product. And so then the core SDK becomes super minimal of, um, just like, Hey, you have some plugin, you have an ID and you have parameters you're passing to that, uh, plugin, but like, that's it. Um, and yeah, just like the, I like prototyped it with an LLM where I had it not implement the function. But I like had it stub out the functions, uh, and like really focused on what the DX would feel like. Uh, and then kind of work forwards from now. It's really interesting. I'm like, I've come kind of back around to like, I, I'm like manually staging all the code files that I generate now and like looking through every line. Um, and there's probably, there's like probably, there's like two subs, there's two groups that, well, there's gonna be one group that's like, that's crazy. You were ever not doing that. And there's gonna be another group that's like, that's crazy. You're not currently doing that. Uh, it's a fun, fun place to be.

Kent C. Dodds (18:55.240)
Yeah. Well, the, the pendulum certainly does swing.

Rhys Sullivan (18:57.940)
Yeah.

Kent C. Dodds (18:58.400)
Um, and so like, uh, I, I think that's one of the things that I love about this industry is that we're always just kind of changing our workflows and seeing what works and pushing the boundaries. Um, and, uh, yeah, I think, uh, right now, like it really depends on the project. I, I'm, I expect with the ship talkers and the GitHub trend line, you probably were just like, yeah, whatever. I don't care.

Rhys Sullivan (19:21.040)
GitHub trend line. I was waiting 30 minutes for a sandwich with my girlfriend and I did it from the line. And then we went to a park and I just like told Claude to deploy it. And I didn't even look, I completely deployed from my phone cause there's no secrets or anything. Like it's just public data. It's just a nice way to show public data. Um, I like deployed it from my phone and was like, if you could, I think you can see in the reply tweets, I go, if it looks bad on desktop, let me know. Uh, cause I couldn't, it's on my phone. I couldn't test it from desktop. Um, so yeah, it's, it's a fascinating time to do something too.

Kent C. Dodds (19:57.100)
Yeah. So it really depends on, on the situation. Um, and that said, um, what doesn't depend on the situation is, um, like understanding what problem you're actually solving and getting that, that clarity in the problem. Uh, for really simple problems, the agent can typically get a pretty good idea, um, of what you're trying to accomplish and implement something that's, that's good enough. Um, but for what most people listening, uh, are building and getting paid to build, um, that process is a lot more difficult and, um, making that, um, experience, especially in a competitive space, making that experience, a delightful one that people want to use is challenging. And, um, from what I like, I actually am a user of Vercel domains. Uh, all of my, um, products and everything are hosted over there on, on Vercel. Um, and, uh, it definitely took, uh, a, uh, a marked improvement in over the last couple of years, uh, with the rewrite that, uh, you and Dylan and others did over at Vercel. Uh, I'd like to hear your perspective on how you made that transition. Like how did it go from what it was, which frankly was not great, uh, to what it is now, which is quite good. Um, what were the processes for you? Was it just intuition? You knew what people needed, or was there anything specific that you did to, uh, bring clarity to the problem and implement something that users would really love?

Rhys Sullivan (21:31.800)
Yeah. I have to decide how much I'm going to, uh, shell effect here. Uh, uh, yeah. So I'll, when we, when I kind of joined onto domains, I just like looked at like, what are the, like pinpoints? What, like, so the, in the, like first kind of weeks after joining, I like set up like some ports to customers. And I was like, Hey, what's like your biggest pinpoints? Where are you like feeling the hurt? Like, um, what can we, like this area of the product is now under my ownership. We are going to like, make it good and, uh, like improve it. Uh, and just from like those initial calls with, um, kind of the, some like the biggest users of the cell domains, one of the big places that stuck out was the, uh, like project domains page. Um, and so the project domains page is this like huge, like state machine implemented in the front end. Uh, and some customers like have like hundreds of thousands of domains on their project domains page. And it was never designed for that.

Kent C. Dodds (22:42.680)
Did you say hundreds of thousands of domains?

Rhys Sullivan (22:45.580)
Yeah. The ton of like, um, yeah, there's like tons of, so it was, it was never, it was designed for like 20 domains.

Kent C. Dodds (22:54.600)
Yeah.

Rhys Sullivan (22:55.980)
So it was designed for like two domains. You're, you're meant to have your WW and your main domain.

Kent C. Dodds (23:01.340)
Um, wow. Yeah. That, oh, that is so many. I mean, I, I've got more than 20. Um, but, uh, I can't even, I can't imagine.

Rhys Sullivan (23:11.880)
I can't fathom how to manage over a thousand. This is the one for your project though. The, yeah, there's like two, there's like the team domains page, which lists all the domains you've purchased. And then there's the product domains page, which lists the ones attached to your project. Um, and so some customers just have like a ton of demands point to the same project. Um, and so, yeah, the, that was a really interesting one to work on at first. Cause like, I knew everything that needed to be done there, but the, there's a couple of interesting constraints on it where the, this was before we have like decent AI tools. Like I looked back when I joined for sale, uh, as like, look, I'd like a notes. I looked back to the start and a year ago, I was impressed that an L I was looking for a link button and I told the LL to find, to find the link button for me. So I could go manually write it out, but I was just impressed that it like found that component for me. Uh, and so the thing about project domains page was there was a ton of like error states that had to be represented. Um, and none of that was like strongly typed coming from the, uh, front end. And I really do feel that, um, like good engineering and good product experience are closely tied. Uh, and so when I tried to do this rewrite with the page, I had to like go through and like manually find all of the areas that could happen and like re, uh, surface this. Um, and I really compare that to when we like moved the, this was, this was like before we moved to a, as far as like my work that we moved it to a whole new architecture and you like domains registrar. It was a little effect based. Those don't know effect. It's a way of like doing types of error handling and a bunch of other stuff in, so in TypeScript. Um, anyways, so I didn't have any of that when I was redoing this page and like manually cop, find all the error states, uh, over. Um, and that was kind of a big, one, one big takeaway for me is just like, if you don't have the right primitives, it becomes so much harder to build your products because you have to like the, after we like relaunched it, there were like these states that I just missed out on, uh, because I didn't have the full like, uh, idea of what the API could do. Um, which was like a pain point to miss on, uh, but we like kind of fixed up. Um, and so yeah, that was an, that was like an interesting kind of redesign on that.

Kent C. Dodds (25:40.640)
Yeah. Okay. So you're, you said a couple of things that I wanted to dive in a little deeper. So, um, one thing that you said that stood out to me was, um, you're convinced or, or you still believe that good engineering and good product experience are closely tied. And, um, I'm sure I heard the phrase product experience before, but like thinking about it like that, we've got UX, we've got DX, and then we got PX. And, and, uh, my, uh, kind of a, a question that kind of, um, that made me think of is with UX so often, um, I know people are going to get mad at me for saying this, uh, cause it's very nuanced and it's not exactly true, but so often a good UX feels like a UI problem to solve. Um, and of course, like there's performance characteristics and everything that very much affects the, um, the UX and, and often that's going to be a backend concern, but, but it just feels like, okay, UX, that's, that's going to be about the user interface and making sure that things are laid out nicely and accessible and all that. With PX, I'm curious, uh, in your experience in improving the product experience of domains or, or anything else that you've worked on, do you find that, um, doing that work involves more front end and backend, or do you think it's related at all?

Rhys Sullivan (27:03.040)
Um, that's a good question.

Rhys Sullivan (27:08.220)
In the past, I would have said front end because like your API is just like, it, like people won't consume your API directly. But now like the, the way that I interact, the way that I want to interact with services has completely changed in the past year where I had to set a bunch of work OS DNS records on my domain on Vasell. And I did not go through the Vasell dashboard. I like gave it to my agent, which has my like Vasell API and executor. I just copied the domains over and I was like, Hey, go set these for me. And then the work OS, like dashboard updated. Uh, yeah. And there's probably this really interesting shift that's happening from like UX being UIs to UX being your backend. And an interesting part of that is actually like good DX is good UX now because like DX is how your agents interact with your services. Um, this was a, I need to do a like longer form, uh, explanation on this one. But like, this is also why MCP servers are still relevant because it's, oh, like the, your API is really great for like raw data access. But if you have to do an onboarding flow, you can implement that so much better as an MCP server that can like elicit input from the user or like take actions from them or like do it as an MCP app. Uh, and so I'm really, really excited to see how it evolves in the next, uh, probably year, year and a half. Um, and so, yeah, they, I think they're like pretty tightly coupled. It used to be front end now, probably more backend just because of how we're like changing how we interact with sites.

Kent C. Dodds (28:48.740)
Yeah. Yeah. That makes sense. And, and I completely agree. I, um, Netlify is trying to popularize the idea of agent experience, uh, which I think is where, where you're coming to like UX is now DX. Well, I think it's, it's really just about how easy is your thing for an agent to use.

Rhys Sullivan (29:05.540)
And, um, yeah, one, one, one more thing I would say on it is what I think is really interesting. It's like focusing on what good primitives you can control are and like deriving from those primitives, uh, and to make that less hand wavy. What I mean is that, um, companies that had like good docs and a good open API spec have been incredibly well positioned, uh, for like this whole, just every wave that's come, whether it's like an MCP server or making good UX on the front end or now, um, code mode or like any of these things, like. Um, the, having, uh, going back, I guess, uh, going back, like the primitives that you can use, like, it's another form of that, where you can like take this open API spec and it works really well for your front end developers. It works really well for any of the parties consuming your API. If you need to generate a CLI, you can do it from an API spec. Uh, and I think, and it's similar thing with like good docs where like you can generate skills from good docs that you can generate, um, an SDK. So you can generate skills from good docs. Your good docs gets indexed by search engines. Uh, there's like these like boring long tail problems that people don't care about, but actually like a hugely impactful, uh, which is really interesting.

Kent C. Dodds (30:25.980)
Yeah. Yeah. I, I think, um, being intentional about, well, really, I, I guess it comes back to thinking about your users and who's consuming your stuff. Yeah. Um, right now, if you're building, uh, some app that, um, helps grandmas connect with their grandchildren or something, maybe having a CLI or having an API, like may or may not be all that useful for them because grandmas are maybe not using agents just yet. Yeah. As like an active part of their workflow. Um, but I do expect that to change. Uh, and eventually, um, everybody is going to be using agents, uh, quite a lot. And so finding ways that you can expose the right things, um, to agents in the right way, um, to improve that agent experience is ultimately going to improve the user experience. Um, and I think that, um, agents are going to just decide, you know what, that was really hard for me to, to do. I'm going to go over to this competitor and I'm just, we're going to solve the user's problem this way. Yeah. Um, and so you do have to kind of appeal to the agents, um, a bit in that context.

Rhys Sullivan (31:32.340)
There's a, there's an interesting part on that on security as well, where, um, I really hope this one that like, I don't know what people are doing with like agents authenticating to things and using websites, but I hope that the people that are in the know, uh, figure that one out. Um, because it's really interesting. We're like pushing people into these like terrible insecure methods right now. Uh, where it's like, if you're, um, the, it's really a funny example of this is a lot of companies like launch them CP servers or you like watered down, uh, because they were worried about agents doing a bunch of actions on their behalf. But now a bunch of age, a bunch of companies have like shipped CLIs that like export those, like that have like an API command, uh, that lets the agent like run whatever they want on the API. Um, and we're seeing a similar thing with browsers with like computer use agents and like browser scraping all this stuff where like the agents are going to find ways to interact with your product. And like worker, like people are going to find ways to work around whatever, like guardrails you try and put up and those ways are generally going to be like worse and less secure than like official methods you can provide. There's really like a, uh, figure out ways to embrace it. Obviously we have like caveats that, um, you know, agent usage is totally different. I mean, I think the, the GitHub trends are really interesting watching those. You see the like tweet from the CEO, uh, chief operating officer, officer of GitHub that was like, yeah, last year we did a billion commits. Now we're going to 14 billion or something like that.

Kent C. Dodds (33:08.380)
That's so wild.

Rhys Sullivan (33:09.780)
The, the, the, the usage patterns are totally crazy. It's really interesting.

Kent C. Dodds (33:14.880)
Yeah. Uh, and, and that makes your GitHub trend line, um, so much.

Rhys Sullivan (33:19.320)
Oh yeah. Mine, mine's going up. It's, uh, it's interesting.

Kent C. Dodds (33:23.880)
Yeah. It's kind of fun to, uh, to watch. I, I, um, I feel a little bit, uh, seen by ship talkers, um, because, cause I do post a lot. Um, but I, I do also, that's like, I'll see some people like, look, I ship so much more than I post. I'm like, you basically never post. And you also basically never ship.

Rhys Sullivan (33:45.540)
My, my two regrets on ship talkers are the like comparison wasn't good enough. Like it should have maybe used a fixed scale for everyone rather than a relative scale. Because someone like Theo, Theo has like 50,000 tweets, but he also has like 50,000 commits. Like he just does a lot. Like, like, like there's same with like me to a lesser extent, like sure you as well. Like there's like people that like do a lot of like things, uh, both tweeting and committing. My other big regret on ship talkers is, um, I should have used like a push method when refreshing the data. At the moment it like wipes it out. And like, I could have done like a year later. Here's where everything stacks up. Um, you can like go get that data from the Twitter API. Uh, but it's, it's a, it's like other things that I have to do with my time. And I don't want to spend like 10 grand in API credits to do it, but it'd be really interesting. Like here's how your trend line is going. Yeah.

Kent C. Dodds (34:46.240)
Yeah. Yeah. I wonder if, uh, AI affects that trend line for some people I'm sure it does.

Kent C. Dodds (34:53.340)
Yeah. Well, uh, cool. So, um, yeah, we're, we're, as we kind of get closer here to the end, uh, Reese, is there anything about product engineering, tightening the feedback loop with users, anything that we didn't talk about that you really want to, and also like keep in mind that I'm going to ask you for a homework assignment that you can give to, uh, listeners, like something specific to help them, uh, with their, uh, uh, improving their product sense. So, but before we get to that is, yeah, is there anything else that, uh, you feel like is really critical for product engineers to know, uh, that we haven't talked about?

Rhys Sullivan (35:30.720)
Yeah. I'll, I'll rip, I'll rip hot takes. Hot takes. Uh, one is, I mean, this one's not a hot take, but like, you don't have to ship everything your users are asking for. Um, the, yeah, like there's, and like related to that, you don't have to like sacrifice the like product quality to ship something immediately. If you have kind of a way to accomplish it over time. Um, I would say like, you know, provide ways for your like users to work around you, especially for agents. I think it's so interesting with like open source where like, um, you can just fork the product and, or if it's open source, you can like pull the product and start working right way around it. Um, but it's kind of like your vision, your, your job to like make a cohesive product that like works well together and really try and take in as many signals you can and like find the right primitives and build a great product out of that.

Kent C. Dodds (36:29.200)
Yeah. That, uh, I think that's really, I agree. Not, maybe not necessarily a hot take, but, uh, definitely something that, um, we struggled to do sometimes.

Rhys Sullivan (36:39.380)
Especially if it's so easy with agents to just be like, yes, everything incredible, like ship it all. Um, yeah.

Kent C. Dodds (36:46.360)
Yeah. This is actually a recurring theme, um, in this series is people saying, just slow down

Rhys Sullivan (36:51.960)
a little bit, uh, be thoughtful. I wonder if we're, I wonder if we're right. It'll be an interesting thing to see in the longterm, but every time I've like tried to speed, every time I've tried to speed up, I found that like the output quality has gotten worse and like the trend of where it's going is not like in the direction that I think is good. With the caveat of like, I'm really, I really hope that model has solved all these problems. Like I actually, I love the engineering work, but I don't want to like be bottlenecked by it. Um, and so I'm really excited for a world where like we can do the speed up and quality isn't lost. Uh, but you know, I mean, we all made the jump to agentic coding like six months ago. Like it's incredibly, incredibly new and early. I also want to see more creative ideas. No one's getting creative with things. I'm like tired of the chat interface. I want my agent to like pop open windows and like explain things to me and like quiz me. I really want to see more innovation in that area.

Kent C. Dodds (37:44.700)
Yeah. That, um, integrations are always like the worst part, literally every project, um, whatever the domain. Um, yeah, I, I, uh, I think that, um, as a, like as agents continue to improve, which I expect that they will, like, we're not at the end, uh, here at all. Um, the, the skills that we develop as knowing, um, what to build, um, and being intentional about that, um, is going to be paramount. And yeah, like maybe we will be able to, uh, to ship. Um, like I, I, I actually think that we can ship more faster. Like I, I don't like, that's definitely the case. Um, but still slowing down a little bit to be intentional about the product that you're creating, uh, seems like a good idea.

Rhys Sullivan (38:36.320)
Yeah. I think it's like finding ways to ship things faster while like not sacrificing qualities would be interesting.

Kent C. Dodds (38:44.720)
Yeah. Yep.

Rhys Sullivan (38:45.860)
Yeah.

Kent C. Dodds (38:46.260)
Well, cool. Uh, so did you got a specific homework assignment to send us home with what, what should people do that can, uh, like a specific thing that can check off of a list said, I did this thing and it's going to improve my product sense a little bit.

Rhys Sullivan (38:59.720)
I I'll go with the, like one I mentioned earlier of like set up a notes channel. When you see a product that's doing well, like have a place that you can take notes and go back and reference that. Um, I don't have like one notes channel. I've got, we've got the like difficult hand that I use. I also have like a bunch of Twitter bookmarks. Um, yeah, just like have a place that when you see a product doing something well, like you take note of it and especially with agents now, like there was this deck I had to go implement off and Dax has two tweets about companies doing author wrong. And I just gave them to the agent and I was like, Hey, let's do what, let's do off correctly. Uh, and so they're just, there's all these like nuggets of wisdom out there that you could use the, uh, to make a great product.

Kent C. Dodds (39:47.460)
Super, super homework assignment. Everybody make, make a place. If you don't already have a place, make a place to be able to just drop product experience notes. And, um, yeah. And then feed that into your agent and make your PX better.

Kent C. Dodds (40:04.000)
Well, I, I think I, from the very beginning of our conversation where you talked about the, uh, primitives that we, um, need to, I actually think that's a really big one that, um, coming up with the, the right primitives that you can then build upon, uh, makes you so much better. Um, and then all the way to like building really good agent experience. I think that we've had a really awesome chat and hopefully people have gotten a lot of things out of this. So thank you so much, Reese. Uh, what is the best place for people to connect with you and keep up with the stuff that you're working on?

Rhys Sullivan (40:37.300)
Yeah. Um, Twitter is probably the best place. It's Reese Sullivan, uh, on Twitter. And then, uh, if you're like interested in Executor, it's all open source and you can find that, uh, I like Reese Sullivan slash Executor and, um, yeah, excited to, yeah. I'm so excited for the future. It's going to be, I'm like, there's, there's so much, uh, interesting stuff happening with AI.

Kent C. Dodds (41:02.840)
Yeah. We definitely couldn't have predicted a year ago.

Rhys Sullivan (41:05.520)
Oh, that's what it would be like now. Yeah.

Kent C. Dodds (41:07.160)
And so who knows what it'll be like a year from now. Hopefully good.

Rhys Sullivan (41:11.280)
Yeah. Hopefully.

Kent C. Dodds (41:13.060)
Well, thanks so much, Reese. Uh, appreciate you having, uh, giving us some time and we'll see everybody. In the next one.

Rhys Sullivan (41:19.140)
Well, thank you.