Loading summary
Transcript57 lines
- [00:00]
Kari
Everyone will have many agents and companies will build their own agents. Linard becomes kind of like a system for guiding the agents and building this context.
- [00:08]
Dan Shipper
This is the perfect business for this era because it's still SaaS. You're the one who has this sort of sticky interface because it's where everyone is kicking things off from and where they're recording all the information. But you don't have to pay for any of the actual tokens. Kari, welcome to the show.
- [00:40]
Kari
Oh, thanks, thanks for having me.
- [00:41]
Dan Shipper
Really, really great to finally meet you. You are the co founder and CEO of Linear. Little known fact, the first time I ran into Linear it was because we were using it in 2020 at the very beginning of every to act as our content management system for the newsletter. And at the time it was like this very kind of like hush hush. You couldn't get access to it, but everyone if you knew, you knew that Linear was amazing. And we used it for a while and really loved it. But then we realized it was made for software, not publishing articles, so we moved off of it. But it was really cool while we did it. And I've always admired the level of taste and craft that you bring to what you build and also I think the level of thoughtfulness and patience that you build it with. And I think that's one really interesting thing is the way that you built the company originally was to keep it closed for a while, not raise too much money, not put too crazy expectations on the company and be patient and willing to build something quality over the long term. And I think that that's also has something to do with how you approached AI. You guys are really in AI right now. When I think about the companies that are successfully transitioning into this moment that were started in the pre AI era, linear is definitely on that list. OpenAI came out with Symfony the other day and the main thing that it hooks into is Linear and you've successfully transitioned the product to be really agent native. But when GPT3 first came out, I didn't see anything about that on Linear. So I'm sort of curious about that transition for you. What was that like emotionally to have built this product for a particular way of working in a particular way of building software and then see the world change, but maybe not be totally sure if this was going to be the thing and then eventually be like this is the thing, we need to rebuild the product or change how the product works in a significant way. Talk to me about that.
- [02:55]
Kari
Yeah, well, first of all, thanks for Being an early user. And I think the thinking, I think, has always been the same. It's like we just want Linear to be the best product in this category and helping companies move work forward and often build software products. And it's like, in some ways, this new AI stuff, it doesn't really change that mission. It kind of maybe even improves it. And our goal was always that ganlinear take more of the burden of running these product teams or figuring out things to do or figuring out when to do them, and let the product teams on the individuals actually build the things. And now it's also like they build it with the AI or the AI builds it. So I think in some ways the mission for us didn't change. Actually, I think the AI is making it better because now we can automate more and take more of that burden and let people do it, kind of like use their craft or use their taste or thinking or something in it. But, yeah, I think we do have. I personally always have this problem, a way of addressing problems, which is like, I come from a design background, so a lot of times the way I approach things is first I'm trying to understand them. So this sounds kind of obvious, but then I think what happens in the tech world a lot of times is like, people don't try to understand things. They often jump into the like, oh, I can do this, so I'll do it now. But did you think, should you do it or does it actually help you? So that was kind of like our thinking with the early AI and the chatbots. Every company is rushing into this moment. It's like, hey, we are now an AI company because we have this chatbot integrated. And we tried that too internally. And then we just realized this is not really that useful. How do you actually use. What is the workflow where you would actually need this or use this? So we have spent all this couple years now trying to understand these workflows. How do people actually want to use these things? And we did a couple of things well, though. I think we released this agent platform. So it's an open platform. It has very good docs, and the agents can build the integration themselves using the docs. And because of that, we now have most of the coding agents or agents out there integrated with linear. And this is like OpenAI brought their codex, kind of like cloud agent in there because we just had this available. So I think we kind of saw this world that I don't think there's going to be one agent, but everyone will have many agents. And companies will build their own agents, which we're now seeing with Coinbase and Ramp, who are our customers. And they built their own homegrown coding agents, which then integrate with linear. So LINEAR becomes kind of like a system for guiding the agents and building this context. But we don't try to own everything in this world or in this market. We can play with other companies too. So I think the approach was much more like, how do we understand the workflows, what is actually valuable and what people could use these tools for versus just jumping into like, well, everyone else is doing this thing, so we should do it too. And by the way, now we are adding kind of like a chat interface into linear, but it's a lot more like we kind of like there's tools and there's skills and there's more of like understanding. We gather, like how you should use it. Like you can use it to kind of synthesize customer requests. Because that's like LINEAR can handle that, Linear as a place for customer problems or requests or other things. So now a LINEAR agent can kind of natively work through those and see patterns or things like that. And that's kind of like we're trying to bring a clarity and context to the organization, which they can then use as part of the AI building workflows. Because I think once the AI builds more and executes more, the problem becomes how do you productively harness this in a good way? You can task a million agents doing something, but what are those things they should be working on? Probably not all of those. If you don't think about probably a lot of those work is not necessarily that useful. You need to have some kind of decision making progress of is this actually important? Should we do this? And LINEAR is a way to do that and build that intent and build that context and then go to build it with the agents.
- [07:40]
Dan Shipper
There's an interesting, I don't know if it's a meme or a mind virus or what going around right now, but the stock market thinks that SaaS is dead. And I think you're pointing to something really interesting, which is this dynamic of a couple years ago, A lot of companies, including a lot of SaaS companies rushing to chatbots. And I think a big part of that is, well, we know this thing is happening, so we have to at least show that we're doing something. And I think the market is starting to, the public markets are now starting to look at that and require that. And I imagine when the AI stuff was coming out and you guys were maybe testing AI features but weren't releasing them. I imagine there was some pressure maybe from investors or from yourself or maybe internally to do something. And it seems like you waited until you had the fat pitch. And I'm curious if that is true, what that was like and what you think it means for all of the public market companies, all the public market SaaS companies that are down right now and whose CEOs are like, well, I guess we really need to launch an agent platform or whatever, you know.
- [09:00]
Kari
Yeah, I mean, I think there's, we don't really have a pressure from investors. Like, that's like one benefit of picking the right investors. And also they trust us to make the right calls. And then also, we obviously did talk about this, but then we also had that discussion. It's like we just don't see the value right now doing it this way. We need to find actual real value here that actually helps these companies. And so I think it wasn't like that bad. Yeah, there was definitely internal pressure. And now I think the speed of the market has picked up a lot. Like every month or a couple weeks there's something changing. And we are tracking those changes and kind of try to see where all of this is going. But there's also, it creates a lot of noise in the market that there's this like, oh, now this week someone is doing these loops and then a couple weeks later people are like, no, the loops are a bad idea. And then we kind of like, you shouldn't like, I think those things are like signals that you should read and understand. But you also need to know that a lot of this stuff is not tested. And a lot of times people also testing these things are not testing it in some large organizational context that where things actually matter if they work or not. And so I think there's that we haven't tested all these things, so we can't make these predictions of how things are exactly going to change. I think on the SaaS narrative, I do think it's probably directionally correct that with SaaS companies you probably have to as an investor, you kind of have to. There's more uncertainty of the future cash flows because if the landscape is changing, you can't expect that everything will stay the same. But I think the narrative is kind of simplistic like, oh, people wipe code their own CRM tools. And I don't think that's exactly going to happen. But I think what might happen is there's new companies that come out or I think a lot of the public companies are not the most, I don't know, flexible or the most robust solutions out there. They are the big solutions that the big companies use and there's a certain kind of inertia in there. So I would say that, yeah, I think the public companies probably get hit the hardest here because their moats are kind of disappearing in a way, I think even for us, we consider now it's like we need to live in this day one world again where we can't rely on our previous decisions anymore. We have to look at these problems in a fresh way. What happens when these things change? What happens when the agent come into this product development process? What are the new problems that come out of it and how do we help that? We shouldn't be tied into the past product we have, but see what the future product should be. I think this is harder for large companies and companies that have existed for decades. So I don't think it's an easy task and I think their growth companies or startups can do it a lot better.
- [12:16]
Dan Shipper
How big is the team now?
- [12:18]
Kari
About 120total. I think I would say about half of them, like 60 people are on the product team.
- [12:26]
Dan Shipper
And what has that transition been like? I assume that over the last couple of years there have been a lot of divided opinions on is AI coding really a thing? Is it just glorified autocomplete? Is it going to eliminate programming as a job? And then how has that change cycle been to actually go change your workflow, figure out what the new programming workflow is like? How did you get the team in shape to do that and what did you learn in that process?
- [12:54]
Kari
Yeah, I think there was definitely a time in a company to we had to encourage people to use these tools more. I think there's always that there can be habits where you always done stuff this way so you are kind of less and less interested in trying new tools. But I think now I'd say probably all of the engineering and sometimes our design and vms also are now using agent coding or coding tools. But we don't track any kind of specific to me, I joke about this sometimes on Twitter now it's like the biggest vanity metric is how much of your code is agent written or how many BRs are you merging. And I think that's not the right metric. It measures output, but what does that output do? Does it actually generate value? Is it improving the product you need to have? If you're measuring these kind of metrics, you need some kind of counterbalance. What Is actually the quality of this work and is it actually meaningful? And I think that's also, I think what's playing out in the market is we have large companies that are token sellers and then when you have a lot of incentives, your business model is to spend more tokens and our revenue will be higher and our market share will be higher. So I think there's a lot of incentives saying, people, you should spend more tokens and not saying, well, you think about things and spend it well. So I think there's again, I think people are maybe looking at it too simplistically or kind of like, oh, there's a good thing. If we just spend more tokens, things will be better. But I don't think that's ever been the case in, in building products. Yeah, there's some value and speed and making changes. But then you should also understand any change or addition you make, it can also have a negative impact. So it's not always activity is always positive. Sometimes it can be negative too.
- [15:04]
Dan Shipper
What do you think is a more nuanced metric for? If you're judging how in this AI world are we, how well are we doing our job of figuring out these new workflows and adapting to them and using them in our own work? If you know, tokens or number of PRs submitted or percentage of agent generated code is, are not necessarily the right metrics. Maybe even in isolation they're not the right metrics. What do you look at or how do you think about it?
- [15:29]
Kari
I mean, I think it's still the classic metrics of like profits or revenue or user, like love or some of these things are like what you should be aiming for.
- [15:40]
Dan Shipper
Those seem like lagging indicators, right?
- [15:41]
Kari
Yeah, they are. But yeah, there isn't. Like I think you should still measure some of these things like token usage per person or by different teams or something. But you shouldn't take it to the extreme of this is the only metric that matters now. You should be use it as a signal that are we doing something and then think like, well, is our product actually improving? Can. Do we have any indication of this product is actually improving? Do we get comments on the new features? Is there less bugs? I think bugs is actually measurable metric. If you run honest bug tracking process where you actually track bugs. And then I think now I almost feel like with the agents and AI it's almost like, why do you even have bugs in your product? There's no excuse for it anymore. And internally we have the zero bugs policy, which is like we have A linear team triage and any bugs go there. Then there's a one week SLA that every bug needs to be fixed. And then now I think with the coding agents, the coding agents actually can do the first pass on it and then once it's done the fix, it will kind of attack the engineer on it and the engineer maybe doesn't like it or there's some changes they want to make. They can do it also now inside linear and they can review the code in linear. So there's this very good workflow for now. But I think it still starts from the fact that do we care if our product is buggy or not? And we have made the choice. We think its bugs are kind of like bad things or mistakes and we should fix them as quickly as we can. And that's like a priority to everyone. So I think it's still a choice if you care about the quality of the output or you are just wanting more of the output.
- [17:42]
Dan Shipper
What are the ways that these tools have changed your product building workflow, both personally and as an org, and what are the most effective ones? That might be surprising.
- [17:57]
Kari
Yeah, I think on the product side, I think it's definitely a lot better. I think with Linear Analytics, I have this skill where it's like I fed some of our internal docs and blog posts about how we think about product development and made this a linear way skill. And then it writes synthesizer. I tell it, okay, look at this. Help me understand this feature request. We collect this feature request inside linear and then for example, there is a request like multiple assignees per issue. It's requested by lots of people, like hundreds of people. And so I'm kind of tell it to go synthesize, help me understand what are the different reasons people want it. So it kind of starts with explaining the problem, trying to understand the core problem, which is usually what I want to know. So this helps me, when I, when I see a new request, I might go into linear and say, oh, do we have this kind of request already? And then help me understand it. And then it helps me kind of give an understanding, which then helps me potentially, should we actually tackle this now or is this something we could do later or maybe never? So there's that before we start building anything. It's helping me kind of understand the problem and in a very quick way. I don't have to go ask around or find people to do it for me. On the design front, I actually don't personally use it much. I actually like the manual design process. I still have Figma open and then when I have a problem or idea, I just draw it in there. And to me it's like my work is often more that kind of exploring things. So I actually don't think the speed really helps there. I actually like the slowness of the manual thing. Like you draw things manually. Every time you draw something you have to kind of check on yourself. It's like, why am I drawing it this way or should I draw it different way? But then the Proter team, the design team, when they work on problems, I think now they are building a lot more prototypes and we have this quite robust build system. So you can actually build it into the like you can make a BR and then it will run the build and you get the preview link to the build and then you can use it live in the product. So it helps the testing it or the prototyping stage of it. But I still tell the designer, so I kind of explore more freely in Figma first or wherever and try to think about how do you approach the problem? Not just like, let's just jump into doing it. There's projects like that too where it's very clear what needs to be done. But then if it's a bigger project, I think they should still spend that time. And then, yeah, engineering side is probably similar to a lot of other ones that. Where we can kind of fix problems a lot faster once we identify them and decide to do it. We use Slack a lot and with our Slack agent we have a discussion and then we eventually decide, yeah, we should do this. And then we just tackle in there, in there saying, hey, can you create the issues out of this conversation? And then we'll do it. So it helps us come back to it later and actually make it actionable right away versus like, oh, we need to have a meeting and then we start a project and then we start assigning people. So I think there's. I think it's kind of like, I would say kind of like the pattern in all of those things is like it's shortening some kind of loop there and making it faster. You can do the thing right away versus waiting, I don't know, next week or some other time to do it. It's very little effort to do it
- [21:52]
Dan Shipper
right away, which is interestingly, sometimes it seems like you're the exact opposite of your preferred outlook. Actually we shouldn't do things faster. Actually we should take things a little bit slower. How does having tools that make you go much faster interact with that outlook?
- [22:18]
Kari
Yeah, and I Think it's a good point. I think it's more like I think we shouldn't go fast in deciding things or just kind of like speed running the decisions or not even doing a decision. I think there's this some people do it now where they just have an idea, then they build it and now we are all looking at this idea that no one really know why it exists and should we even do it. And it's like every new prototype or idea can kind of seem useful, but then you now don't have a good way of framing it. How useful this is versus other things. Should we spend the time actually now committing on this idea? Because we already had decided on some of the other ideas. So I think there's this danger of you don't have some kind of decision making way. We don't have a lot of processes in linear, but it's more like we want to commit on this. Once we commit on the thing or the fix or the project, then I want it to improve fast. I want the loop to be fast to actually work on the problem. But I don't want the problem finding to be fast. You should take the time to find the right problem and the right approach for the problem. And then once you decide that, then you can go faster on it.
- [23:36]
Dan Shipper
Here's a simple test for whether your AI is actually ready for production. Would you stake a business decision on what it just told you? If the answer is not yet not alone, the gap is in capability. Because AI can do a lot. It's really about trust. You can't verify the output of the AI, you can't trace its reasoning and nobody with real domain expertise has touched it. Dialect is a new system from Scale AI that captures how enterprises make decisions and closes that gap. It puts your actual experts in the loop, AKA the people with years of institutional knowledge and encodes their judgment into to your AI systems. Every correction, every override comes with full context. It's actually really interesting. So the next time your AI makes a call, there's an expert's reasoning behind it. That's how you go from a cool AI demo to an AI system you can trust. Visit SCL AI dialect. That's SCL AI dialect. To learn more while I'm doing that back to the episode, one thing that what you're saying makes me feel is is I totally get that approach and also for myself as a product builder, I often don't know what I'm doing until I do it. And I can't think it through until I've done like five different things that I can't explain. And then I'm like, okay, here's the thing and I understand it. Is what you're saying different from that or is it the same? Just like said differently?
- [25:00]
Kari
Maybe it's different, but I can see that workflow. I feel like that workflow is kind of like. Kind of like understanding. You're trying to understand what you're doing
- [25:09]
Dan Shipper
and it's like making things as understanding.
- [25:13]
Kari
And I think that's fine. I think the problem there just becomes like, sometimes it's like you kind of don't know. I think conceptual work, sometimes in design, I consider this like a conceptual work where it's like the output of this is a concept. It's not like, like we just shouldn't deliver this necessarily. But this is like I made this, like, I went through this process of understanding this problem and like, I have a concept for it or like, I have.
- [25:40]
Dan Shipper
What's an example? Because I would assume that the output of a design process would be figma, you know, a figma that you could export. So what's an example of a concept that comes out of a design process?
- [25:51]
Kari
Well, I, I think like in the, in the past, like in large companies, I've used a concept term to like, not to scare people. So. So usually it's like rethinking some area completely and that's like a concept. It's like a concept car. So it's like this car won't go into production, but here's some ideas that could influence the next car. So it's like you're trying to. Sometimes people, I don't know, this is partly like a large company thing, but I think it can happen in small companies too. Is that once you see something very different, your fears might start coming up. Like, well, if we change this, what else? What is going to happen? What's going to break? But the point is not right now to decide that. We decide does this concept, this new idea, have merit? And do we think it's important enough for something to take it further and then deal with the problems later? So it's kind of like you are kind of like trying to divide the decision which decisions you are making now. And I've used it in our company and other companies. I just completely rework a surface and say, hey, I think the project should look like this, which is completely different from what it currently is. And then people are like, oh, that's actually interesting. Or they're like, well, it won't work for this. And that and I'm like, okay, that's fine. And it's a way to. And then it's maybe like a figment design or a prototype. So it's just like. I think there's. Even with all this tooling, the output shouldn't always be like we ship something. Sometimes the output can be something internal that, hey, now we have a better understanding of this problem. We can tackle it better and we can actually make it into a shippable thing. But we first try to think about it before doing it right.
- [27:47]
Dan Shipper
And to you, thinking about it can include building stuff. It's just the reason you're building stuff is not to ship it the next day, it's to understand it better. But thinking can be designing it, can be writing it, can be talking about it. That kind of stuff.
- [28:00]
Kari
Yeah. And something I did have to share with the company recently was that we always care about the quality bar a lot. But I think and kind of this thinking process of are we doing the right thing? Is kind of like what we are trying to do decide sometimes. Now with AI, it's actually like hard to tell. It's kind of like if the tooling changes all the time. The LLMs are not deterministic anyway. You always know how useful this thing could be. And then there's a moment you just have to decide like, yeah, I think we should. Obviously we can try this internally, but we also need to try it with customers and you kind of put it into some kind of beta or something. So I think there's definitely nuance to this right now that there are situations where it's always, with product building, there's a limit how much you can think about it inside your company until you need to actually put it somewhere to someone else to use and then you learn from that use case. But again, it's more like every stage you have some kind of goal in mind. Now we put it to beta. The goal should be understand the workflows and how people use it and how they want it to be better, not to something else, not to try to ship it as fast as we can or something. We should be honest about what is the actual goal for this stage.
- [29:29]
Dan Shipper
We've talked about how AI has changed your internal workflow. I'm also curious how it has changed your product strategy and how you think about building products. Not like the actual work of building products, but what kind of product to build. And what, for example, should you let AI agents connect into your product, which I know you've done, versus build your own AI into the core feature. Should you have both, what should they be able to do? How does it affect your product strategy and your vision for what a good product is?
- [30:02]
Kari
Yeah, I mean I would say we are now adding agent like Linear Agent that has context of your work and the context of the organization and the products you build that you can use in different ways in the BM workflows. You can also as a designer use it the way to understand the problems. And then we will also do a coding agent where you can actually start writing code with the agent and interesting. You can see the diffs online. So it's kind of like a cloud conductor environment where you can kind of see the changes and you can guide it. And we think the strategy has definitely changed and we are just trying to understand what are the problem set of today. We think one of the things is what is changing is that I think historically people thought issue tracking is this kind of a ticketing system for the kitchen, but engineering. So it's like order comes in, someone orders fish. So now that fish goes into the kitchen, there's a ticket like make fish. And that's kind of like people think about issue tracking and we kind of never thought about it that way. For us, Linear is more like the backbone. We rely on collecting signals and collecting problems or collecting decisions like we should do this thing. So I think there's definitely a shift we have to teach people. These products is really meant to improve your team's workflow, not to be this kind of weird ticketing system for different parts of your organization. And that's kind of probably going away with the agent. So you don't need that anymore. The agent can do those tickets and they can also complete them. But we think there's still value of collecting that context and make the shaping that work something actionable and providing agents good context from the environment. But the one lesson we learned with the agents is that it's tough when we are not ourselves in control of it. It's like we do want to support all companies and all agents as much as we can, but then if we have ideas for it, we can't do it. It's on them to do it. So now one of the reasons we are doing this coding agent is we actually think we see this a lot more smoother end to end workflow where you start your. You don't have to do everything but you start some of your tasks in linear. You can ask the agent, hey, does this thing exist already? Or if not make an issue, make a work stream out of it and then start working on it and then start writing the code. And then you can see the diffs coming in. You can review it and you can merge it, or you can see the prototypes. So it's just like trying to. One of the problems I see when I use this Claude or ChatGPT or some of these tools or Codex, is that I have to really explicitly tell the agent, the tool always, what context to bring. And then I think the value with linear is the context lives there. And then if we kind of inject it smartly part of the work stream, it's much more natural. We can design the flow that makes sense and we don't spam the context windows or something. And I think we see this feature as like, you probably have this linear as kind of like the multiplayer or the organizational context of what's happening in the product and what is potential future state of it. You might still run local agents, but there's situations where you should just automate some of the bug fixes, or you should automate the small task and just do it in linear and then let it run in the background in a sandbox while you run your own work in your own computer or somewhere.
- [34:15]
Dan Shipper
That's really interesting. I think from a product strategy perspective. I'm really curious about the decision to integrate your own agents, because before we did this interview, I didn't know about the linear agent and I was sitting here thinking, wow, this is the perfect business for this era because it's still SaaS. There's no AI token costs, but it is the place where you control all of the AI. So all the other companies have to deal with all the other coding agents and whatever, have to deal with all the token costs. OpenAI and anthropic and whatever. But you're the one who has the sort of sticky interface because it's where everyone is kicking things off from and where they're recording all the information. But you don't have to pay for any of the actual tokens. And it sounds like you're adding a layer where you will have to pay for the tokens. And you may prefer that. And I think the reason you're saying is because a tighter integration between the two means you can do more interesting, more powerful things. How did you think about that from a business perspective? Changing your margin profile that much, I assume. I don't know. I don't know off top of my head how much linear costs a month, but I assume there's a lot of interesting discussion there about how adding in token costs change the business model.
- [35:37]
Kari
Yeah, I mean, honestly, I think it's something we'll have to see in the future more. We definitely thought about it and have some calculations or thinking on it. I think on the coding agents we do have to offer usage based billing because it can get very expensive. On the basic linear agent functionality that answers questions for you that should be more included into the system and we'll have a lot more. We'll have to see how much the usage actually is. But Linear is still is going to be just fairly focused platform for certain kind of things. You shouldn't be running random things here. I think it should be still pretty clear what you should be doing inside Linear and what kind of workflows are you running there or workloads. So we're not trying to build this very generic agent platform. It's just more like the product context or the product memory platform where you can integrate those agents and you can use linear agents from other tools too or you can bring other tools into Linear. So it's just a way to work around your product and it's kind of like an API into the product thinking versus using more of the normal tools where it's like you always have to tell it to go fetch this thing, go find this thing, because it doesn't have any understanding what do you generally do or what kind of context that might be existing already.
- [37:14]
Dan Shipper
Can we see a demo? I'd love to see it.
- [37:16]
Kari
Yeah. Is the screen sharing okay?
- [37:26]
Dan Shipper
Yes.
- [37:29]
Kari
All right. Yeah. So what we have coming up, like this is actually my real linear instance. And what do we have come up is we do have now if you do a new tab inside Linear, there will be the classic box of what do you want to do. There's also this other interface where you can, if you are inside some context like a project or something, you can kind of do the work there. But for example, we will have skills and these skills, we will have guidance like organizational guidance and a personal guidance. And you can have personal skills or organizational skills. So for example, what I was mentioning earlier is that sometimes I want to understand problems. So I want to understand this problem of multiple assignees. So I made the skill, which is essentially I fed some materials from our blog and then it's like act like a linear product teammate. And then it has this format of it starts with the underlying need and it has this way it goes through the problem. So I made this to kind of help my workflow just quickly and trying to understand sometimes this feature request so I can do it like, well, let's do the multiple workspaces. So we have this collection of stuff about multiple workplaces. And then it can kind of go through there. There's probably many different requests. And it will try to start thinking through it. They will look into the customer activities, they will look through the different things.
- [39:17]
Dan Shipper
What model is it under the hood?
- [39:20]
Kari
I think we'll eventually allow multiple models, but now we use Claude.
- [39:25]
Dan Shipper
Claude for this Sonnet or Opus.
- [39:29]
Kari
Sonnet, actually. No. So it starts going through. It's like, okay, there's a real need, but it's more complicated than it sounds. So companies maybe want this multiple workspaces for different reasons. And I think my understanding generally is that they want one place to have this billing and governance. But then they might have multiple different divisions in the company. And so they would want to divide the workspace more. But they might still have some kind of overarching control. So it goes through the kind of trying to explain what is missing and what is good about it. It also makes this few recommendations of the product direction. So do this or that and that. So it helps to make this, something that is quite complicated into some kind of actionable thing. And we can talk about this as a team or something. But similarly, more like a micro example is that if there's like, I want to make a new theme, like new dark theme.
- [40:51]
Dan Shipper
What's a theme?
- [40:52]
Kari
Themes are just like in our app. So you can have.
- [40:56]
Dan Shipper
Okay, got it. Yeah. Like the way it looks. Yeah, for the way.
- [41:00]
Kari
So maybe I want to create a new version of a dark theme, like make it just black. So I can now task a coding agent on it and it should start looking into. It can look into the code base and it can try to understand the code base, obviously. And then at first it's turning it into an issue and then delegating into. Into an issue. So I created this issue. It's in progress. It's delegated to linear. And then now LINEAR starts working on it. It's spinning up the sandbox for it. And I think one of the benefits of nature is now people know I'm doing this. So the team knows I'm doing this. And I can say, hey, none, FYI, I'm like, I'm doing this. So he can also come here to look at this, what is happening. And then the thing is, this agent session is visible to everyone. So it's visible to me and to him. So I can call once. It will take a while, but once it does it, we can both jump into this Chat and tweak it together if we want to or just see what happened here. So it's similar to what you do on your computer but then now it's kind of happening in a shared context and there's more like understanding. Where did this come from? Okay, it came from me. This could come from a customer discussion
- [42:35]
Dan Shipper
or the shared context is interesting. So two people can be in the same chat.
- [42:39]
Kari
Yeah,
- [42:41]
Dan Shipper
that's really cool.
- [42:42]
Kari
I don't have Non ready to demo this, but we did have this instance kind of accidentally we noticed this is actually useful sometimes it's like that Non was our head of product and Connor who is our head of design. They both were working on some tweaks on the inbox. So they could go back and forth like a BM and a designer could go back and forth. It's like, no, it's not quite right, let's fix this thing. And then they could both see the kind of like the preview link. Let's say if I have something here. Okay, so there's one like my previous pull request. So we will have pull request here. You can kind of see the activity but you can also see the code. So you see the code divs and then if you want to comment on it or you want to work on this code with the agents, like no, this is not right. And then I can work on it. And similar workflow works for code reviews where engineer might come in and say this is not right. They could just task the agent to fix it versus telling the other engineer to fix it. So I think it kind of collapses the cooperation loop a lot more and allows multiple people use the agents to work on one thing. And then here this is only a backend change. So there's no client review I can do. But if this would be a client facing thing, I could kind of like open the preview link and then like actually see like how does it look live?
- [44:19]
Dan Shipper
That's interesting.
- [44:20]
Kari
But yeah, those are a few things we are like adding.
- [44:24]
Dan Shipper
I'm curious about this. One interesting thing about this is it seems to increase the surface area of the product a lot. You have to build a lot of different things that already exist to some degree somewhere else. And obviously there are things that you can do differently. So you can have multiple people in a chat, it's more plugged into, linear more generally. But you kind of have to recreate a lot of stuff that's already being built by a lot of other companies. So how do you think about that and the trade offs of that and doing that well, especially entering something like AI coding, where all the big companies are just going as hard and as fast as they can to build AI coding agents.
- [45:10]
Kari
Yeah, I think there's definitely the question we need to keep asking ourselves. What is our advantage or unique advantage here? And I think, honestly I don't think we will solve all the different coding needs, but we don't necessarily also have to. I think it's what we see. The value is kind of like sitting upstream where the work is coming from. There's really good leverage there that we can offer to companies where it's like work comes in or bugs come in. They automatically get spawned into agents, delegated to the agents. Engineers never even see them. Or if they see them, they see them. Once there's a fix already being built. And so it doesn't maybe work for all kinds of situations. It's not the agents you go through like, hey, build me a new product. We don't think that's where we should be working in. It's more like you have a large company, you have a lot of things requested from you, a lot of bugs filed in. How do we reduce that workflow for you automatically? And then, yeah, you can use the other coding agents to do other kinds of work. But this is where we kind of focus on.
- [46:19]
Dan Shipper
That's really interesting.
- [46:20]
Kari
But then, yeah, generally we've been thinking about the problems. We don't want to be a kitchen sink product. We do everything for everyone. And sometimes companies end up in the state because you have the enterprise buyers and you have the checklist and then you just need to get the check mark into the right spot on the checklist. And we don't think those things don't create a good product experience. So the way we always thought about it and built the products is like, we try to feel like what is like a natural next step in this workflow. So if we go from an issue it's like, yeah, the natural next step is like someone needs to fix this. And so how do we help people to fix it faster? So one option is like we do this cloud agents and then they can fix it. But now the cloud agents does this stuff like, how do you know it's good? So then you need to see the code, you need to see the diffs and you need to run the builds and whatever. So it's like we are more always focused on the workflow and how do we improve it? How do we kind of help companies to output better and faster versus trying to own every surface? So we don't have to own every piece of the surfaces. But we are kind of trying to find this optimized workflow for people to do certain kind of like product things.
- [47:47]
Dan Shipper
So we're almost out of time. My last question for you is if you had to project how product development will change over the next five years, let's say what will be different and also what will be the same.
- [48:06]
Kari
I think that the one difference I think there's going to be more of this like self driving aspects of like you can set up some kind of rules or guidance and we even are building something around a project memory so you could have a common workflow. What we do is we have projects going on. It's like a project is often a feature, a part of the interface or part of the product and then we have a lot of feedback and requests and things coming in. I think there's opportunities turn that into more the product or that feature. It's kind of like an agent itself and it kind of tries to make decisions based on the input it creates and then it can still have maybe ask a certain amount of input, but it could run automatically. It's like hey, I see these patterns and these patterns point into this solution and this solution seems to be potentially something that works for people. And I built a, made a build, I sent it to some customers and they say the feedback is good. So it's kind of like it gives you. It does things on its own based on some kind of context and a rule based system or some kind of guidance. And then I do think the thing I'm still I think people should still think even in this world where agents do some of the thinking and does run automatically to some degree. I do think people have to be a lot more explicit like what do they want or what is worth doing and what are the areas we should be doing. So there I think a lot of this still humans having meetings or discussions or writing issues or writing documents. I think it's reading documents. There's still going to be a place where humans need to understand this stuff to. You can't just outsource the thinking purely to the AI or agents. But the more you can clarify your own thinking and the strategy or something, the better it's for your team but also the better it is for the agents too because then you can codify some of those strategies or thinking into actual these autonomous things. So I think I personally don't see the future in a way that we are replacing humans and I don't quite believe in it. Maybe I don't want to believe in it, but I think things will change, the roles will change. Maybe there's some movement around exactly what does engineering do, how many engineers we will need, and what is the job in the future. But I still don't see how the agents, how the AI actually does all the thinking and the choices or decisions. I think product building is still kind of like a craft or an art. A lot of times we talk about intuition. We just decide things based on how we understand the problem. We hardly use any data as part of decision making. Sometimes we use it to look at something, but it's more like a signal. So I never personally believed in this A B testing and data driven product development, which I think could work well for agents, but I think it doesn't work for all kinds of products. And I also think the best products are not necessarily being built that way. You still need the human kind of touch of what is interesting or what, what would make this good.
- [51:51]
Dan Shipper
I love it. Kari, thanks so much for joining.
- [51:55]
Kari
Yeah, thanks dad, for having me. And this was great. Oh my gosh, folks, you absolutely, positively have to smash that like, button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure, unadulterated knowledge bombs. About Chat GPT Every episode is a roller coaster of emotions, insights and laughter that will leave you on the edge of your seat craving for more. It's not just a show, it's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor, hit like Smash, subscribe and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely, hopelessly in love with you.