The Exchanges

Q When the cost of copying is quicker than ever, does that change how you think about product? You're in a very competitive space, but many people can copy you very quickly. Does that change how you think about product?

A No, not really. I think the important thing for us is that we're building something that our clients get a lot of value out of, and we build that as fast as we can, but we don't build it faster than that. Um, there's like, there are, there are tons of people that are, um, vibe coding. You know, there's people that are vibe coding Legora. There's people that are vibe coding Salesforce and, and, and DocuSign and other companies. Um, it's very quick to get to the 90% where it looks the same, and in, like, 80% of the cases it works similarly. It's the, it's the other 90% that are difficult. You know, it's like ensuring all the edge cases work, and all the unhappy paths, and all the, um, audit locking, and all the RBAC, and all the, um, weird scenarios that you end up at, at a certain scale. That's what's difficult. Um, so no, we just, we keep focused on how do we create the most value for our clients, And sprint towards that as fast as humanly possible.

AI assessment note: “No, not really. I think the important thing for us is that we're building”

Q What have you been able to vibe code away?

A Let's see. We've primarily, well, we've added a bunch of things that are additional, or additions to vibe coding, so a great, really stupid example is Um, Ryan, who joined from Canada, we have a team of people joining from Canada, they're all moving to Sweden, and he vibe coded an app to help everyone migrate. So like very specifically, if you're Canadian, these are like all the laws and all the steps you take, and there's like, it's interactive, and you can see how far you've made it, and it's awesome, and it took, I don't know, a day to vibe code, and it saves so much time for an entire team. So it's like, you can build the big systems, but even just all the small ones that you can build really add up.

AI assessment note: “Ryan... vibe coded an app to help everyone migrate”

Q Okay, and so we have, like, efficiency against that, and so we just ship more?

A We ship more, we ship faster, um, we debug things faster, we iterate faster, everything is faster now, and each engineer can produce much more than they could previously, um, and that just has a ton of ripple on effects throughout the org, basically, and how you structure it, because, um, I mean, I think, a way I like to think about it is, you know, When you build software, there's kind of like three phases. There's phase one, which is The product work. You know, what, what are we building? Um, translate user pain, user dreams, nightmares into something tangible that we can try and we can iterate on and we can figure out if it works. And once you have that, you know sort of what you want to build, then you built it, you write the code, and then you review the code and you merge it and you get it going. And number two was the primary bottleneck for the past hundred years, almost. Um, so like the rate limiter was how quickly can you write code? That is now super cheap. So that's sort of been compressed. And so the, the bottleneck now is like the, the two other ends, which is, uh, review. How can we do that much more efficiently? Um, and then it's, how can we actually do the product piece much more efficiently? Because, you know, if you believe that code is cheaper to write, then naturally the two other things are bottlenecks. And that means, you know, one of the focus areas is ho…

AI assessment note: “We ship more, we ship faster, um, we debug things faster, we iterate faster”

Q Do you worry that we will see a next generation of security threat with the amount of AI generated code that bluntly opens vulnerabilities we didn't know we had?

A Yes. Absolutely. This is a very top of mind for me. And that's why we still at Legora and probably in a bunch of other enterprise software, we, we still review human PRs, every single one. Just because we have to be sure. Um, I think that's inefficient. I want to, you know, get some risk scores in there and change that so that we can run really fast, but, um, fundamentally I think you're right. I think threat actors, um, are extremely efficient now, which means like they can try so many different things and they can keep running at it. Um, and so we need just as, um, good defense and I'm not sure If we're there yet.

AI assessment note: “Yes. Absolutely. This is a very top of mind for me.”

Q company CEO the other day, and he was like, you know, my chief of staff took three weeks off and basically vibe coded Cooper, and we replaced Cooper, um, and it works and it's brilliant. What do you say to people who are like, that's ridiculous. Why would you ever bother vibe coding and taking months to do an HR system when you could just buy it off the shelf?

A It's really depends on the system. There are certain, I think basically there are like, let's say there are systems that are, um, let's say there's two axes to systems. There's, there's the, the horizontal one, which is like, how big is your product surface area? And there's the, the, the vertical one, like how complex is it? So if you're Deep. You're essentially your surface area. It looks quite simple. It's a simple app, but it does a lot of complex stuff. It hides away a lot of complexity to the user. And there's the other one, which is your very, very shallow app, which is like tons of things you can do, but there's not that much complexity. If it's a shallow app, and it requires a lot of customization from you, maybe you just build it. That's probably actually the right thing to do. If it's a very deep one, there's, there's just too much stuff for you to build, and it's not viable for you to do. That's kind of how, you know, I think about it.

AI assessment note: “If it's a shallow app, and it requires a lot of customization... build it.”

Q I mean by that is like, you know, one of my dear friends, Jason and I came from Statue, he's like, anyone on LinkedIn who talks about their team, fire them. Fire them straight away. We don't want managers who manage other managers who manage other managers. If you can't do full stack, get out, pick up your severance and go away. Like, do we still want, like, senior managers?

A It, it really depends. You can build a company of super senior engineers that can do everything, and, and you probably don't need to manage them at all. You have, uh, especially if there's, like, really strong, uh, if, if they know what they're trying to achieve, the codex team, for example, like, they all know what they're building, they can just, like, run at it, and they don't need anyone to tell them that they're doing well. But if you have a more complex product that can go in many directions, and you have to do constant prioritization, and you have, Um, a, a suite of engineers and a team of engineers, so the way that we have engineering teams is relatively small teams, let's say six people, a PM and an, and an engineering manager. The engineering manager is super technical, you know, spends most of their time coding. They're not like a, people hold each other's hands and like sing songs. But, uh, but it's still important that I have someone that's accountable to the team health. Are people, you know, doing good jobs? Are people having fun? I can't walk around and judge everyone. You know, are they, are they doing well? And so I think it's important to have someone who's accountable, um, and that's how we run it, right? They decide their own roadmap, they're their own little startup, um, but someone is, one person is accountable.

AI assessment note: “it's still important that I have someone that's accountable to the team health”

Q Is that the future of engineering, being systems design, systems architecture, and then bluntly code creation, code maintenance, is actually completely done by AI?

A Yeah, I think so. I think so. I think that's right. The job of assist, of a, of an engineer is changing from typing a bunch of code to sort of one layer above it, which is, um, what does the system look like? And then you can have AI running around inside each of the pieces of the system, but you sort of have Engineers thinking about the higher, um, level one abstraction above, which is like, what does the system look like? What are the bets we're making in different places? Do we want to invest into doing something here that we can reuse a bunch of places over here and it's going to make everything much more stable? That's one of them. I think the other thing that engineers are doing more and more, which is an explicit role with us soon, which is like kind of the meta engineering of making agents really effective. So you know how you have Developer experience teams that, you know, whatever they might help write custom linting or custom developer setups to make developers efficient. We kind of need to have the same team for agents. Like how do we make agents really, really effective? How do we make sure that we can enable agents to Sort of, um, independently self-improve the system. Can we, can we gather data in a really good way so that we can just unleash agents and say, hey, you know, increase conversion rate on my e-commerce store. And it can just like go and run experiment…

AI assessment note: “Yeah, I think so. I think so. I think that's right.”

Q they, they both told me that fundamentally, you know, in a world where agents are the pickers of software, the API quality that we have is the core determinant of what agents will choose software based upon. How do you think about how we make agents more effective? Is it a simple question there of data and making sure we're the best at that? How do you think about that?

A We have to set up the guardrails really effectively. This is actually something that I'm thinking about right now. So our code base is starting to get large. Happens. It's a good problem to have. Um, we're starting to be a lot of engineers. We're also starting to be a lot of agents that are working on this together. And so, um, you start to think about how can I mechanistically enforce the system to behave a certain way. And, and so I'll try to give an example here, which is, um, you can have custom rules, for example, which is like, The agent tries to do something, and we tell it, no, you can't do that. You know, there's like, for whatever reason, you can't do that, because we want the system to be in this way. And I think that type of, um, guardrail setting will see everywhere. And so, if you're a big enterprise, and you're rolling out AI tooling, and you have agents that build your own internal software, you know, you have AI tools that build your, um, HRAS system, and your, You know, ATS system, and whatever else, you probably have some engineers that are just setting up the, like, this is where you get the data, this is what you can do, this is what you can't do, and then you can just let agents run amok inside of that system, basically.

AI assessment note: “We have to set up the guardrails really effectively.”

Q Yeah, yeah, no, I totally get that. I interrupted you when we spoke about the efficiencies earlier that comes with AI. You mentioned the second was the processes that change. How do processes change, be it PRs, be it postmortems?

A Well, actually, postmortems is a great example. We run them really efficiently now. It's, it's great. And, you know, if you have an incident, now you just unleash an SRE agent, a sort of an incident agent, and it will just super quickly figure out what's going on, look at all the logs, look at all the metrics, metrics, sorry, Telemetry, and it's surprisingly good. It's really, really good. And so, like, instead of having a bunch of engineers wake up in the middle of the night, you still have some waking up in the middle of the night, but they are really well equipped, and the post-mortem basically almost writes itself as well. Um, so that's actually a great example of something that we can run really efficiently. Um, but I think more broader in sort of the software development life cycle with AI, um, PEMs can prototype super, super fast. Which is really, really great because that means you can front load a lot of the work. So like a PM can start hyper long before once he or she has the, you know, smallest inkling of an idea that we might want to do this. They can prototype it and they can just go to users. They can, they can test it and they can iterate themselves. They don't even need to bring in engineering until they have something that's like clearly super valuable. And then we can switch and we can say, okay, now we take this from prototype to something that's like, Actual…

AI assessment note: “Well, actually, postmortems is a great example. We run them really efficiently now.”

Q Do we skip the design stage in a world where prototyping and getting to V-one is so much easier?

A Probably some companies will skip the design phase. I think, I think we can skip the design phase on functionality. Uh, you don't need to necessarily have this long, you know, discussion, uh, where you said 10 people need to figure out where should the button be. I do think design still has a place. But it's maybe, you know, one level above the individual features, the individual stuff that we build. It's the design language that we choose to have. It's the taste. It's the, um, opinionated stance we have of who we are, and like, what does Legora look like? Um, what's the navigation? What's the hierarchy? Um, but it's more for consistency UX UI sake than, and for taste sake, rather than, uh, functionality, so.

AI assessment note: “Probably some companies will skip the design phase. I think, I think we can skip”

Q And just so we understand, like, what does that mean? Like, you, you build sites for Slaughter and May, so you can pitch to them, and Clifford Chance, so you can pitch to them.

A We, um, no, but it's, it's way broader than that. It's like, we have a, a team now that's internally at Enablement, which is just like, Reimagining, you know, again, from first principles, with all the stuff that we have today, if you're building the most efficient company to go from, let's say, 200 to a thousand employees, what does that look like? And that means, obviously, you know, Claude Cowork and similar things for everyone, but it's also like, can we just build a bunch of the tools that we need ourselves? Can we just vibe code a bunch of the tools? Can we vibe code our, um, HR system? Can we vibe code our, A talent acquisition system. Can we vibe code our payroll system? Like so many things where there exists, tools exist out there, but you always need to customize them so much, and they always basically never really work, and we just built them now because it's so cheap to build.

AI assessment note: “no, but it's, it's way broader than that.”

Q We mentioned PMs and like their proximity to customers, and then that delivery mechanism back to engineering, which is kind of always what PMs did and did best. Does the role of the PM change in the next few years?

A Yes and no. Um, I think there, there are certain people that are, or a lot of people are saying that product and engineering are converging. It's becoming one thing. It's like one person can, um, do the product work and build the engine, like build the system and ship it and everything. And I think for, for some companies, that's true. I think for companies where You really need PMs. It's not true. Or it can be true, but it's inefficient, and I'll tell you why. So we were talking about, um, product, you know, you do the product work, first the scoping, then you build it, and then you, you ship it, and you review it. In a company like Legora, we're always focused on the bottleneck, and the bottleneck's no longer coding, which means the bottleneck is the product work, and so you don't want your product people to do engineering. Cause like, the opportunity cost of that is really high, cause what you really want them to do is the product work. Like talking to customers, uh, figuring out, doing the synthesis, that's the bottleneck. So if your PMs are coding a lot, if they're spending 50% of their time coding, we're missing out on so much product work. So that's how I think about it right now. And for certain companies, if you're doing developer tooling or doing consumer where engineers intrinsically have a good sense for their own or their other own clients, you maybe don't need a P…

AI assessment note: “Yes and no. Um, I think there, there are certain people that are”

Q What do you advise a CEO In terms of intelligent usage of AI, and should we just be pushing tokens as much as fucking possible, or do we just need to pump the brakes a little bit here?

A Um, so a few different things on that. Um, I think one, having a leaderboard, a lot of people say this, get a leaderboard, um, and, and bring up token usage at performance reviews, And that leads to token maxing, which is people just burn tokens just to look good. Um, that's a really stupid way to do anything. Do hack days, do demos, um, have people show everyone else how efficient they are and like how much better they're doing and reward them for being, um, effective and efficient and having more output, not for necessarily using AI, but like AI will be the way there. Um, I think that's one of the points for enterprises. This is actually where I think cursor has Um, a reason to live, a reason to exist, which is, if your options are codex and clawed code, and a neutral third party, and you all pay, you know, you pay consumption based. Claw, sorry, cursor can help you optimize your token spend a lot, because they can optimize your usage, right? They can route them to the cheap open source model, or help you set limits for Whatever models you want to use for what thing.

AI assessment note: “reward them for being, um, effective and efficient and having more output”

Q Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now, I'd have in my mind, am I the CTO that takes this to public company?

A It's a very fair question. Do I, no, I don't buy that. I think It's, to me, it's a question of how quickly can I solve problems? Am I the person that can solve the problems that we have right now the fastest, or can someone else solve them faster than me? We have a great culture in Ligora in that no one has any ego. Um, I've told this to, I currently have two engineering directors, I've told both of them when I hired, if there comes a day when you, when I think you'll do better than I will, then we swap, or I do something else. Uh, I have very little, and they also have very little tied into their title or their role. We are here to build something huge, and that's the most important thing. And I continuously evaluate myself on my job performance. And if I don't do well, I try to rectify that really, really quickly. And I haven't been able to not rectify it yet, but maybe there comes a day.

AI assessment note: “Do I, no, I don't buy that.”

Q What have Harvey done better than you from a product perspective or an engineering perspective?

A I don't know. I think they've, um, they've been more aggressive with hiring, which I actually think, um, I have not been aggressive enough with hiring because I've, I've always tried to have a very, very small, very lean team, which I believed a lot in. Um, and I, I consistently underestimated how many people we need to be. I had this slide that I drew up, uh, maybe, you know, A year and a half ago that I showed the entire company, and it was, you know, the 300 Spartans versus the Persians, and it was like Legora and the 300 Spartans, and I said, I'm pretty sure I said, we will cap out at 20 engineers or something like that, which is like way undershooting it.

AI assessment note: “they've been more aggressive with hiring, which I actually think, um, I have not”

Q I'm your little brother coming out of CS at university. What would you advise me to be best placed in the next three to 10 years? So if I were to advise someone on social media marketing, I'd say, hey, you need to be full stack. You need to be able to create the image, get it out, and amplify.

A Yeah. Similar thing, I think, um, engineers, I think actually the most important thing is you need to learn how to learn. You need to, to, to figure out how you Constantly reinvent yourself and, and, and keep learning and improve because the things, things change all the time right now. You know, it's, it's, it's every week there's something new you should be doing. You need to change your way of working or whatever. And the most important thing that you can do for yourself is figure out how you keep at the forefront of what's happening all the time. Um, and if you can do that, if you're adaptable enough and you are ambitious enough, then the rest kind of works out. Because if you can just learn faster than everyone else, then, you know, over time, you win.

AI assessment note: “the most important thing is you need to learn how to learn.”

Q We mentioned the wonderful word earlier. It's like the word of the moment, which is taste. I don't know. Taste is what separates us. How do you, Think about the, don't worry, taste is what the differentiator will be. Is that true, or is that bluntly Silicon Valley and tech BS that's trying to protect us?

A Uh, I think taste is Important. There's different flavors to taste. Uh, pun intended. I, I, it depends on what you mean with taste. I think, you know, in tech, taste is like, we have an opinionated stance on something. I think if you don't have taste, then you let AI slop converge to sort of grayness, and everything looks the same, and everything's just like, I think you need to have taste to have sort of An opinion and it stands in the world. This is who we are. This is what we do. And we don't do these other things. And that's not for everyone. I think to me, that's what taste means. It's like, this is who I am. This is who we are. And, and some of you are going to hate it. And that's okay. Um, because you need to have some edges, you know, if you're just like letting, letting AI rip, you're going to look the same as everyone else.

AI assessment note: “if you don't have taste, then you let AI slop converge to sort of grayness”