Lenny's Podcast: Product | Career | Growth
00:48:37 · Lenny Rachitsky, Dan Shipper
[00:48:37] S0: Okay. I want to try to wrap up our first bucket. There's so much to talk about. I made a little list of things that I think people should do based on your predictions to be successful. We'll talk about this at the end too, but just a few things. One is start using Codex or Claude Code more and more for the work you're doing and especially the browser, use tools inside of it. Two is allow agents to use your products. If you're building a SaaS tool, make it easy for agents to be a user essentially. Three is start thinking about some Slack bot that you can work with, like try out tools. I know Slack has their own Slack bot that I think is really good too and I haven't played with it, but people really like it. So look for, I guess, a tool that could become the AI agent within your company. Buy SaaS stock ASAP, not investment advice. [00:49:32] S1: I think that's totally right. My slight tweak is when you're thinking about building your software for agents, the current model is I'm building a CLI that an agent uses, but they're using it in a sort of like they're being... I delegated to task the agent and the agent's using the CLI. And where I think it's going is you and the agent are using the app together. The agent's probably using the CLI, but you're using the web interface and they both need to be in sync. And that is, I think, a new challenge that's really interesting. [00:50:06] S0: Awesome. Anything else before we get to our next category? [00:50:10] S1: Buy SaaS.
00:50:10 · Dan Shipper, Lenny Rachitsky
[00:50:10] S1: Buy SaaS. [00:50:12] S0: That's the title. Oh, man. Okay. So the second category of predictions is around just the shape of the work that we're going to be doing is going to change. What do you predict?
00:50:25 · Dan Shipper
[00:50:25] S1: There's all this interesting stuff in terms of the shape of work. Once you're in this land where you've got async agents off that you delegate work to, then you've got your Codex Claude Code work surface that starts to happen. So one thing that we see a lot internally, and you also see this in the big model companies, is the number of pull requests that you get is like skyrockets. We have people in consulting or in ops roles or whatever or editors just making pull requests. And A, that's really cool and that's a very different shape of work where you can expect that a higher percentage of your company or your users are going to be doing things that previously only technical users can do. And what that does is it creates all this pressure on the other end for the people who have to deal with all of the new code for how to deal with that. And so I think there's a lot of interesting things that happen with that. So for example, like OpenClaw, I mentioned that earlier. Pete gets thousands of poll requests a day on OpenClaw and then he just spins up 50,000 Codex instances and then sorts through them and then merges a thousand of them. It's really crazy. I actually think that that's going to be more and more common. It brings up a lot of really interesting questions around which poll requests should you merge. And whenever you add capacity in one part of your process, it breaks things. It used to be really hard to build things and now it's very easy. So the point is not, can we build it? It's like, would it make sense with the rest of what we've built and how do we keep a sense of a coherent whole. And also, what do we delete? I think Anthropic does this really well. They delete a lot of stuff from Claude Code to make sure that it's not bloated. So I think there's a lot of that going to happen on one side. There's a lot of non-technical people can do technical work and then technical people are in charge of making sure that that work gets into a product or into a process in a cohesive, coherent way. And also their product people are going to be doing that too. And I think that's quite cool.
00:52:52 · Lenny Rachitsky
[00:52:52] S0: Something I'm hearing from people is that now that everyone can do everything, like engineers can design, PMs can code, marketing people can ship stuff. There's just this confusion about what the hell is my job anymore. What am I responsible for exactly? Am I supposed to be shipping stuff? Am I still a marketing person? And it's just creating a lot of confusion and certainty in the world, just a comment.
00:53:15 · Dan Shipper
[00:53:15] S1: I mean, it's for real. And one of the things that I think is special about every is... Everyone is sort of a generalist and really loves having their fingers in a lot of different pots or whatever the metaphor is. I think that'll probably settle down at some point and it'll feel more normal. Marketing people are still going to do marketing even if they're touching the website. That's just part of marketing now. But I also think that you can get a lot further being a generalist now and that's like really cool, especially for smaller companies. The other thing that I think is interesting is there are definitely some new job roles that are a thing. And the thing that is becoming really clear is the whole forward deployed engineer concept I think is for real and it comes out of every agent needs a human. You go to the big model companies, they have these agents that run internally, they have like teams of people that run these agents and I don't think those teams are going away. The models are going to get more powerful, the agents are going to get more powerful and the number of agents is going to grow, but people are still going to manage them. And so that looks like a very specific kind of person. And we have a couple of those people internally here and it's like the people who are in charge of making sure your agents are working and doing the right thing. We also do consulting. So we lend that out to people and I think that's a big thing that people want. And it's another one of those places where you're like, hmm, automation was supposed to take away jobs, but it looks like it just created one or many. And there's a specific type of engineer that really loves... Nitesh, who fits this, he's an AI engineer and he fits this sort of forward deployed category and he's on our team. He spends most of his time actually talking to one of our agents in Slack. We have an agent internally called Claudy, which runs our whole consulting practice and he spends a lot of time in Slack. There is code and he is using Claude Code and other things like that, but a lot of it is just talking to it and being like, "Why did you do this dumb thing?
00:55:28 · Dan Shipper, Lenny Rachitsky
Let's fix that." And so there's certain kinds of engineers that I think love that and love having their hands on the latest thing and also love making this being that's in a workspace and it looks a bit different than more traditional, building more traditional software. [00:55:45] S0: And your sense there is we're not near a place where these agents don't need a human. You've said that so many times now that agents need a human and there's kind of like the setup part and then there's the maintaining it forever part and feels like both are important. Is what I'm hearing like this is going to be a job for a long time. AI is not going to get smart enough to just be fully automated for a while. [00:56:06] S1: Yes. I'm simultaneously extremely AI-pilled, extremely, and very bullish on humans and the role of humans and making sure that AI is working well. [00:56:16] S0: Interesting. Okay. So the two kind of buckets here that you're talking about, one is like the way I think I hear what you described earlier is just the pace of shipping software and everything is just increasing, which also means there's so much more work reviewing all this sloppy output. I was just talking to a data science friend and he was saying how his team is just, his data science team is just, their job used to be do analysis, answer questions, see if this experiment was a good, was positive. Now it's just everyone's doing that and they're sharing their results and they're like, "No, this is not correct." And most of their job is now reviewing bad data science work.