[00:00:00] Tanya, how are you, I guess this afternoon your time? Yeah. Very good. Very good. Uh, things have been very busy, but all is well. How are things with you Ted? Uh, they're going great. They're going great. You and I got connected on LinkedIn. I had saw some things you posted about vibe coding. Which is all the rage right now in legal tech and, um, a very popular topic. And then we had a conversation and I found your current role and how you've approached the whole vibe, coding, prototyping process. Really a a bit unique from what we're seeing a lot today, which is where lawyers are just kind of jumping into like Claude Code banging out these prototypes and, you know, posting 'em in GitHub and Mm. That, that stuff is great, but that, that code will [00:01:00] very likely never be pushed into a production environment where it gets rolled out firm wide. Sure. And, um, you, it sounds like. You guys have maybe a little bit of a different process at your firm, um, which I thought was super interesting and mm-hmm. Probably the right path. But before we jump into that, um, why don't you just give us a quick introduction, who you are, what you do, and where you do it. Yeah, absolutely. Uh, really excited to have this conversation. Um, have been listening to your pod for a little while, so excited to be here as well. So, my name's Tanya Suge. Um, I am a lawyer by trade. I started working at my current firm, uh, link, which is a magic circle, uh, law firm based here in the uk. Um, about eight and a half years ago. And I did the very traditional, uh, legal route. I studied law at law school. Um, I qualified as a, a banking lawyer to be, uh, precise. Um, and then I just practiced, um, uh, as a banking lawyer for a number of years. And then at one [00:02:00] point, um, in my career, I basically, I. Done various secondments, I'd done a secondment to a bank. I had been on secondment to Tokyo for six months. And I got to that point where I wanted to do something a bit different to what I was doing in the day job. And I asked the partners in my firm to be sent on secondment to our then innovation team and one month into my secondment. And I had this grand plan of all of the kind of innovation things I was going to work on. Um, chat GT 3.5 came out and this was sort of around November. Um, you know, at that time. And it was 2022 and it was basically, I had started playing with the tool and I realized actually this is a bit of a game changer. So at that point, I kind of became one of the firm's, like unofficial AI lawyers. I had the space and the autonomy to really experiment with ai. And at that point I had already done a lot of um, workshops and one-to-one conversations with people in my practice to understand where those pain points were and suddenly. The [00:03:00] solutions that we had maybe mapped out for them, literally just a month ago changed overnight. Um, so that's sort of how I, I accidentally ended up in this space. So my current role now is I am the AI lead for the global banking practice. Um, I lead a team of AI lawyers in my practice. Um, but we are in this intersection basically between kind of being quite tech enabled, working very, uh, closely with our tech teams, but being embedded, um, in the practice. Your. Experience as a practicing attorney. You identified some pain around, I think, billing narratives and tell us a little bit about that and kind of what, what transpired. Yeah, sure. So during my time feening, um, there was, so I mentioned that at the start of my secondment, I basically sat down with all of the partners in my practice and actually all of the lawyers in my practice at some point to talk through where our main pain points were. And one pain point that came up repeatedly was the subject of [00:04:00] effective, repeatable. Consistent billing updates to clients. And the interesting thing about this pain point was I think it's felt by almost everybody in the process. So it was felt by our clients. And we have these sort of annual, um, surveys that we do. And, um, one of the top, uh, pieces of feedback we get is they would like more transparency, more regular updates because it helps them with their own internal processes. And if they need to get budget approvals, they, they really value that transparency. So that's definitely heard. Um, and we wanna be able to do that. But the process of. Providing these billing updates is very manual. So if you are literally just doing a, um, an update on a weekly basis saying this is the amount of, uh, you know, money, um, that has been incurred, whip on the matter. It's quite simple. But if you need a breakdown of where we are, what are the tasks that we've completed and what's left, that's when it gets a lot more, um, uh, cumbersome because. You are working on tight deadlines, a lot of things move very, very quickly. You're pushing things [00:05:00] very quickly, and so at any one point knowing what's happening on thematic, you have to basically manually go through the narratives and figure out what that is because there's many, many people working on that matter. So that was sort of the pain point in question. So we really, really wanted to solve this. And from the associate perspective, which was my perspective, I was usually the one preparing these narratives and each one was taking hours and hours a time. And it's non chargeable time and ideally you'd be able to do it more regularly for the client. So that was the pain point, um, kind of process. Then we were kind of looking towards how can we be solving these pain points? And one of the initial, uh, avenues we were going down was kind of traditional robotics, which was, you know, could we send a, um, a robotic automation, I mean not, you know, physical robotics, but could we send a, a WIP report, an Excels, uh, Excel spreadsheet to a email address, and then pass that and do various things with it? And basically create like a rule-based system. You know, if you have this content in the spreadsheet, do X, Y, Z. And we found very quickly that that was gonna [00:06:00] become extremely convoluted, very, very difficult to um, I guess. Really, truly implement because every single one of these spreadsheets looks different. Every single matter has different narratives. There's no consistency here at all. So we found that this was going to be more time consuming to try to automate it. And then chat. GPT came out and I was doing a lot of experimentation and I, I mentioned to you, Ted, the last time we spoke, um, I basically. I spent six months really and, and beyond that as well, but an initial six months. Really aggressively upskilling myself as quickly as I could on this new landscape because I didn't have any training in this area. So I basically, I did every AI course that was available at the time. Um, I delved really deeply into kind of AI before large languish models and machine learning algorithms. Built and I trained models and, you know, practically got my hands dirty. And then I did a number of coding courses as well. And Python was the main coding course that I looked into given it's the, kind of the, the simplest, um, to implement AI tools. [00:07:00] So I then at that point, you know, realized we couldn't do it through traditional automation built, uh, my first prototype in 2024, I think it was. And, um. Basically was able to create a tool that could do the thing that I said it was going to be able to do the thing that I wanted it to be able to do. Um, and that was kind of the, the light bulb moment where I realized actually we can solve for this problem. And I used, you know, publicly available information and completely, you know, fake data to basically prove that we could use, do this using a simple Python script and various API calls and actually create this kind of summary. So that was sort of where the prototype came about. A really good point the last time we spoke and one that really hadn't occurred to me in this, um. World is you were able to create a working prototype to generate buy-in within your [00:08:00] leadership as opposed to like a PowerPoint with with low fidelity wire frames that are static. Yeah. How big a dial mover was that aspect in generating buy-in and support? Yeah, so I remember that, um, conversation because I think, uh, and I've joked about this with, um, the, the dean of the law school at King's before, which is like when you hosted a hackathon in the legal space before, um, the output was always basically a number of screenshots and a PowerPoint presentation, and you just had to use your imagination to imagine the tool actually working. And now, and having actually just been involved with a, a, a. Legal hackathon, literally just a couple of days ago, organized by Jamie. So, um, it's just the landscape has completely changed. Like, the way that you're able to bring a solution to life, like in a matter of hours is just, actually just blows my mind. Um, uh, so. I think the, the vibe coding element of it was absolutely critical. So I [00:09:00] mentioned to you when we spoke kind of in 2024, uh, it was 20 23, 20 24, when I was, um, kind of building some of these prototypes and I built various prototypes. But this particular prototype, um, the AI assisted coding tools were not. Very good at the time. They're amazing now, and I'm using code, code all the time, um, in my personal life. But at the time they weren't very good. So I actually did have to understand like how Python worked, which was a real pain because like I'm not a, uh, you know, professionally develop, you know, software developer. I'm not professionally trained software developer. So it was very much what I'd managed to learn from these courses. And so it was really painful, but ultimately it was absolutely necessary because it's very difficult. I, I kind of explained to you the process for developing the prototype was, uh, kind of multiple stages. The first stage was building the prompts that would actually power the large language model to do the actual task itself. So I worked on that for a number of weeks. Managed to get them to basically output this output in a way which would kind of match the [00:10:00] style of the report. The updates we would typically give, it would be done in a link laters way. The language wasn't too archaic because if you told chat GT at the time to, you know, take on the persona of a lawyer, it would use extremely archaic language, and that was very unhelpful. So once I'd managed to get the prompts to work when I was then demoing what. I was able to do, it was a lot of copy this information from this Excel spreadsheet, paste it into here now iterate on the prompt, now go back and forth with the, um, AI chat bots. And at the time I was using, uh, Layla, which was our. You know, our kind of in-house, um, large language model wrapper, uh, tool, which was, uh, based on our Azure instance. So everything was, um, you know, secured and the data wasn't going anywhere. So we could use data, uh, without problem. And so yeah, the demo didn't look great because I'm just like copying and pasting stuff into the chat bot copying, paste things outside of the chat bot, and this whole process looks really convolute and everyone is like, what are you actually doing? I'm like, look, here are the bullet points At the end, it doesn't really have that same power. And [00:11:00] also I was a bit limited because in, if I was just using a large language model, um, I couldn't do the, um, cost estimates because as you, you know, as everyone knows, large language models, um, just by themselves are very, very bad at arithmetic. So I needed some kind of a script as well that would be able to do the calculations for me, and I just couldn't do all of that within a chat bot. So what I then had to do was basically code the application. Which would have the API calls to the LLM, but it would be done in a, you know, it would be packaged up as an app where I could press a button and all of these mechanisms would happen automatically without the end user having to see that this is being sent to this. And then now we're using a script to do the calculations, and then we're gonna finalize everything together, and then we're gonna run another script so that it pops up like an Outlook email, which is how the tool works. So. That is really, that changed the game completely because um, when I was able to create the prototype and show, uh, you know, the business and I was able to show our generative AI steering committee at the time, they could immediately see how this would slot [00:12:00] into what they were doing on a daily basis. And so that is when you get buy-in a lot more quickly. 'cause I'm not having to convince people anymore. The demo is doing all the talking. Interesting. Well, I wouldn't feel any insecurity about not being classically trained. Um, I, I have never been classically trained. I have an undergrad degree in math and an MBA. Neither one of which you could argue that mathematics and computer science are closely related. But, um, I used to work for Microsoft on the SQL team. Mm. I I, I was able to build SQL Solutions at a very high level and had no classical training other than maybe when I went to go study for a certification exam. But, but, um, and I've employed, uh, I don't know how many, but it's over a thousand for sure in, in the years. And I would say that actually. The less formal training IE um, no CS degree, the better in, in my experience, and I'll tell you why, [00:13:00] is uh, we have a core value at info dash called simplify and go. Mm-hmm. And my classically trained engineers have the hardest time with this core value. Hmm. And, uh, I equate them to sometimes their violin makers and the client wants a doghouse. And it's really hard to get a violin maker to build a doghouse sometimes. Mm-hmm. You know, they want, they want end levels of abstraction and dependency injection and all of these things, and it's like, wait a second. That, that makes sense if you're building, you know, an end tier enterprise scalable application, but sometimes you just gotta go with something quick and dirty because that's, that's what fits the need. Mm. So I wouldn't feel any, um. Deficit because my best engineers are the ones that were self-taught. Thanks for the reassurance. Sure. Um, so, uh, I, I would say that, um, in, in our, in [00:14:00] our conversation, you, you had talked about shadow it and the tension that. That can sometimes create, I actually might have brought it up when we spoke, but in my years in financial services I worked on, I never actually worked in it. I was mainly in risk management roles, but um, I was always one of those guys that would, um, kind of grab the bull by the horns and if, if there were some simple. Architecture that I could get, or I'm sorry, infrastructure that I could get access to. And the bank had met, had avenues for that, and I could build and stand up something to get things running. Like we built a sales incentive plan when I was in Global Treasury Services. We engaged our IT partners and said, Hey, can you build this app to calculate the compensation for our treasury salespeople? And they said, sure. It'll be two and a half years and $8 million. I, you know, we said, okay, we don't [00:15:00] have two and a half years. So we built, um, we got a shared instance, a SQL server built a, at the time, a Windows app using T net, and we were off to the races. And that created tension between our IT partners didn't like that because they have to follow all of these rules and all of this process and hear these little, you know, uh. Engineers in, in the business, were bypassing all of that and building something that ultimately benefited the business, but it creates tension between your IT people and you know, your fast movers that are, that have fewer constraints. How have you avoided that tension or have you, with internally, like how have you navigated that? Yeah. So I mean, for those listening, just, uh, um, if you haven't read the law.com article that talks a bit more about this, the tool that we're discussing, this was a tool that I [00:16:00] built a prototype for, but ultimately, um, we worked very collaboratively with many, many functions in the business, including our technology team, including our revenue, uh, cycle, uh, lifecycle team, um, and other AI lawyers as well. And then ultimately we have rolled it out. Globally, uh, to be used within the firm. So this is definitely an enterprise solution and I think that's where the, the distinction is, and I think you alluded to this earlier in the podcast head, which is to roll out a enterprise solution is a completely different ball game than to, you know, spend some time to create a prototype which works and gets that buy-in. I think that both processes need to be done. So the way that I managed to kind of, um, navigate this is really through just a huge amount of collaboration because. Ultimately I, what my job I feel in this process was to bring this pain point to life and to get people to be able to communicate with each [00:17:00] other and understand what it is that we're building. And I don't have time to, you know, spend three months making wire frames and mural, which is the old way of doing things, to be able to explain what it is that this pain point does. And a lot of the time I find in the legal sector as well. We do things in a very, like, mm, non straightforward way. Sometimes there is like, you know, there's a lot of conversations around process mapping, and there's only so far you can get with that because the nature of delivering legal work is messy and it's very human and there are a lot of inefficiencies that you just can't automate out of the process because that's just the, you know, the human nature of it. Sending emails back and forth and, and various other parts. So it can be very difficult to communicate to, uh, somebody who isn't a practicing lawyer. What the pain point really, truly is beyond like a conceptual level. So being able to build something as a prototype, you know, I'm like here, here is a HTML prototype of how this is going to work. It showed our technology team exactly what they needed to do. Um, and for them, you know, that's a form of requirements really. [00:18:00] Instead of just being like, I really hate billing and, you know, do something about it. So that was the first element, which is actually, um, going to our technology team. And once, you know, I got the business buy-in, the case was then how do we then take this forward? And of course we take it forward with the team who has rolled out every other enterprise solution within the technology function, which is the technology team. So, and I and I meet with our technology team regularly with the leadership as well and understand like, how can we do this in a way which is going to slot into your existing processes of doing things, which I think is the, the natural way of doing this. So the way that we agreed to do this was that I would work together. We actually hired a new AI lawyer into my team, um, Deb Naci, who, um, kind of ended up being a bit of a quasi lawyer, quasi product manager on the, on the project, which really helped. Um, and then we had our team of developers, testers, um, and we basically said, this is what we wanna build and. Ultimately we need this to work within the link latest environment. [00:19:00] So I had built it in a pre, it was a Python, um, uh, script that I had built that's not gonna run on our machines. It's not going to, uh, log, it's not gonna be able to be integrated with all of our template systems that interact with our billing to, with our billing reports. So I want something that's going to work in the existing environment. So what they did was they took why I had created and they completely rebuilt it and refactored it into C. So it's going to work in, in Excel. And, um, ensure that it would integrate with all of our various, you know, power BI and, and all the various other tools that we already have in the ecosystem. So, and that makes complete sense and, and the way to kind of ensure that the, you know, they would continue building what we expected and we were giving them the feedback that they needed. We had to work very, very closely together. And I mentioned to you, you know, we had, um, standups. Happening three times a week where they would say what they were working on and if they had roadblocks, we would talk it out live. And I think that kind of live iterative feedback is something that rarely happens in law firms. And we were very lucky that [00:20:00] we had the system in place to enable that so that we get to a point where we have a tool and everybody's got an involved and we had to have our billing tool involved as well to, you know, ensure that we're using the right template reports, you know, this for this bl able to be rolled out globally, has. To work within the existing systems, um, already in the firm who have, you know, developed various solutions before. I would say that's how we got around it. So I would say just like, just a lot of collaboration and a lot of iterative kind of development. And when we spoke last, I pointed out that to collaborate in that capacity, you have to have a, you have to have a high EQ and, and high empathy and be collaborative and. If you look at the work of Dr. Larry Richard, who's kind of the authority on lawyer personalities, lawyers are off the charts on autonomy high and they are off the charts, uh, low on empathy. Mm-hmm. Which is, which is a deadly combination when it comes to. [00:21:00] Um, embracing a collaborative mindset because you absolutely have to be empathetic To collaborate effectively, you have to put yourself in the other person's seat and negotiate, um, terms that are acceptable to both and consider everyone's constraints and, um, timelines and, and all those sorts of things. So, um. I know I've, I've had lawyers get defensive when I've brought up Dr. Richard's work before, and his data is so, um, he's, he's surveyed over 30,000 lawyers over 30 years, so it's, it's not a one off. Um, how, how important do you feel that, you know, empathy, eq, collaborative mindset are to being success in the model that you described? It's absolutely critical, um, because autonomy is really important. Um, but to be able to get a project [00:22:00] rolled out at an enterprise level, um, the number of people that you need to work with and collaborate with, of course it requires huge amounts of empathy and teamwork. And I think that it's, it's a really interesting point and I think that there are, there is a new breed I think of. I guess I think we've, I think we've coined the term AI lawyer at links and we may not have, but I think we have, um, where we've literally created these titles for people who are AI lawyers and. Function. Uh, Tom and Sarah kind of were looking to hire people. We were speaking about this a lot, and when I was interviewing, uh, various people who were joining my team, there's a very particular set of skills that you're looking for. So to take, uh, one example is, uh, dev, who is, um. A junior member in my team, an AI lawyer in my team who ended up acting, I mentioned as the product manager, basically quasi product manager on this, on this tool. When I was interviewing her, not only has she trained at Links, um, and, you know, [00:23:00] done the traditional training contract, but she had also done a secondment, um, in our, uh, tech startup create iq. And there she had, you know, done a product management course. She had done, um, various other courses and she'd worked with lots and lots of different people. And then there were various other elements of her, um, working style as well. When I worked with her, I instantly saw that it was just different to maybe a, uh, a trainee who hadn't been through that experience. So I think that what you need to be. Have the, and not everybody needs to have that, but if you are someone who is trying to work, uh, cross-functional, multidisciplinary teams, not every lawyer needs to do that. And that is absolutely fine. But in the, uh, the, the experience that we were going through, we did have to collab, collaborate with multidisciplinary teams, um, teams that. Spoken very, very different language to us, and I think that's really exciting because there is so much we can learn from each other. And you know, your horizon as a human being expands and that is going to make you, you [00:24:00] know, a better problem solver, a better collaborator on other, in other parts of your life as well. And not only did I work with the development team. On this project, on another project I worked on completely unrelated to this, um, when our, we built a tool called contract analysis, which recently won a number of awards, but also, um, was up for an award at the, uh, financial Times Awards and was, um, marked as a standout tool. I worked very, very closely with our data science function. I'd never. I ever worked with a data science team before that and the it was, and then that project was very challenging. We were trying to do something that no other firm had done before, but I can't tell you, Ted, how much I learned from that experience. And now any other project I do, I'm applying not only my learning as a fee Ning lawyer, but also my learning from working with a development team, working with a data science team. To everything I bring and I think the solutions I therefore work on are always going to be better and better and better. So I think that's the, the main distinction, realizing there is so much we can learn from [00:25:00] each other. And if you combine things that you learn from different industries, actually I think that's really powerful. Yeah. And, and to be, to be fair, Dr. Richard's work is, you know, if you think about the district, not, not all, all lawyers are high off the charts high in autonomy and low in empathy. It is a bell-shaped curve and there are long tails that where outliers exist. And I'm curious if, do you. Do you do any personality assessments for people in who come into this role? Or is it, is it more of a kind of a gut feel? It's a good question. I don't think we do any formal tests, but there are immediate telltale signs I find. And even if it's not like an in, you know, for outside of a formal interview context, if I meet somebody, um, and I'm thinking maybe they wanna do a second to my team, I think there are a couple of things that you, um, are [00:26:00] important to have innately, uh, within your personality traits. So one of them is, I guess, being very open-minded. So even if we have done things in a certain way next week. One of these AI houses is going to drop a new feature that completely changes every workflow that we have built until now. And I've had this happen to me where actually the best practice was to do this, and now the best practice is completely different because prompt engineering is not important anymore. Now we do context engineering. So you need to have that mindset where you are able to think outside the box and pivot very, very quickly. So I think that is one, uh, factor that you, you just, I look for that when I'm speaking to people. And you, and you get a sense of that by, you know, maybe working with them for a little bit on a project and just getting their immediate feedback when we have setbacks. So being able to pivot, being very curious. This is a space that is moving so quickly and you have to have an internal drive to want to kick. Stay up to date with all of the [00:27:00] latest updates. And the people on my team are constantly sending me LinkedIn posts and um, you know, messaging me all the time about new articles that come out. And they genuinely enjoy reading those articles. But that's another thing which is curiosity. And then I think linked to the first point is a kind of low ego mentality when it comes to work product. Are we here to solve the problem or are we here to say, you know, the way I said it is the right way. So we, you know, in my team. My own personal team. We have regular standups every week as well, and we constantly are assessing where we are on various KPIs and we need to have the humility to say, actually, I think we need to pivot. Or actually, I'm not sure that's the right way of approaching this. If we don't do that, we are gonna get nowhere. And as a team where you know, you are not fee earning anymore. You are delivering on value outcomes, you're delivering on outcomes. So we need to be able to constantly believe that what we are doing is the right thing to do. And if [00:28:00] you don't have that sense of, you know, low ego is fine. If we have to pivot and it's, you know, it's nobody's fault, you know, we need to cons constantly be, uh, evaluating ourselves. You're just going to go down the wrong path very, very slowly. And then you'll kind of figure out. Too late in the process of how did we end up here. So I think that's, that's the other thing as well. And um, it goes to your point, you know, being able to be empathetic so that when another team tells you actually we can't do X, Y, Z, you are able to see it from the perspective as to why they can't do X, Y, Z. So is it a security issue? Is it a resourcing issue? Is it actually integration issues? Uh, there are things. In the process that you won't understand as a lawyer necessarily from day one, but are you curious enough to understand things from their perspective so you can see how you fit into the bigger picture? So those are kind of the main things that come to mind, Ted. Yeah, and you know, um, to be fair, I don't know that I, it is. If you were to do a similar [00:29:00] personality assessment in the IT world, how, how well they would score on EQ and empathy, especially in certain disciplines. I think that's especially true within it. For example, you know, my experience, um, on with, you know. Information security, uh, InfoSec, they look for reasons to say no. And that's kind of their job, right? Is, is to, to, to say no, unless there's a compelling business reason to say yes, you know, to assume risk. So, you know, I, I have spoken on this and it's maybe an unpopular opinion, but I don't think that innovation should live in. Technology in, in the organiz, organizationally. And the reason is that if you think about the remit, um, and the KPIs with which it is judged, it's very, um, you know, defects and [00:30:00] mistakes are bad, potentially devastating, um, uptime, you know, security. Um. Uh, any, anything that, where mistakes are made is bad in innovation. You have to make mistakes. You intentionally fail. If you're not failing, you're not innovating, right? You're, you're maybe incrementally improving, but you have to take risks, taking risks. A technology environment can lead to disaster. Mm-hmm. Of course. So it is kind of a different mindset, you know, the move fast and break things versus the stability, the, um, predictability, all of those things in technology. So, um. Yeah. Did you have any challenges when you were working with your internal IT group and they like to do it their way? And, you know, I'm saying this as a technology person, like my years at Microsoft specifically were, [00:31:00] um, there were, there were a lot of egos, like, you wanna talk about egos like. There were people at Microsoft who were at the top of their game who you would walk into their office or their cube and they'd have a row of books that they wrote on the subject that you're gonna come debate them on. Right. And go, Hey, I got this idea. Or, and you know, they're like, yeah, look at the books buddy. Um, so I'm curious, did you have any challenges navigating where that, that you had to kind of work through? That's such an interesting point. So I would say internally I've been very lucky. I think the culture of the firm is, so we have a generative AI steering committee, but also, you know, we've had various leadership changes in, in the last few years as well. But ultimately I think that the, the firm has been very open-minded towards change, like even our firm wide managing partner. Who I speak to semi-regularly is always interested to hear how we can do things better. And so when on this particular project, you know, when we showed the demo, it was immediate what [00:32:00] the, um, benefit to the whole firm was Like, it wasn't like, look at this cool thing I've done. Look how cool I am. It was like, I can see that this is going to bring tangible impact to the business. Um, it's gonna help our clients, it's gonna help the partners and it's gonna help the poor trainees and associates who are having to do these, um, updates manually. So there's a clear win. Clear click prize here. And then from there, the collaboration was a case of, well, how do we bring this to life? And I think that was really exciting. And I, I've just really enjoyed that experience as well because we, you know, we built something and there was so many times where the tool broke and, you know, it was working just fine. And then an update came, or like one of the L LMS changed with, uh, Microsoft, um, you know, shifted resource from one of the LMS that we were using. And suddenly it stopped working. All hands were on deck until late in the evening. All of us on that project. On phone calls trying to sort it out. And that is, uh, a really precious experience, if I'm honest. Like being able to [00:33:00] collaboratively work on something and then push it out and see the impact and see the feedback that was coming in on the tool. And we would share it amongst ourselves. You know, this is what we've managed to collectively do something that's never been done before. You know, these billing, these billing updates have been done manually. Literally until this year. Um, so that's really amazing. And maybe I'm getting too excited about this, but I think that was incredible the point you made about, you know, uh, this is how we've always done things. It didn't strike, you know, it struck a kind of a bit of a thought in a slightly different way, which is gen ai. Because AI has been around for a really long time. And, um, you know, we go all the way back to rule-based ai, um, supervisor learning. Honestly, you know, it's, it's been a whole 60 year, you know, I'm kind of ballparking that, but around 60 years of history here. Yeah. And then Jenny, I have been around for a little while as well, but it really kind of came to the scene when, uh, that, uh, iteration of chat Chitty was released to the public. And so it's only, you know, people, [00:34:00] most of the population have only had about like, you know, three and a half years of experience, true experience of using large language models, most of the population. And so it's a really, really interesting dynamic because from my perspective, from the, you know, legal AI perspective, I've been working in this space literally from the beginning, um, in my own way. From the perspective of, you know, a bit of a, you know, people call it different things. Legal engineer, legal quant, AI lawyer, whatever you wanna call it. I've been doing it from the beginning, um, but. In the wider context of things. I'm still quite junior in my career. You know, I've been a, you know, I've been in the legal space for about eight and a half years, and I think that's a really interesting dynamic because some people maybe who have been in AI for a lot longer might kind of look at you and say, well, what do you know? And I'm like, well, I have, okay, yes, it's only been three and a half years, but I know what I'm talking about because I have built. This many tools. I have rolled out this many tools. I've rolled out training on all of this stuff, and I've, you know, done all of this experimentation in my own time. And so that dynamic is [00:35:00] really, really interesting. Yeah. It's, and, and, you know, I, uh, having confidence is, is really important in getting things done right, coming to the table, confident, like, you know, Hey, I, I understand this. I, I, you know, and it's a balancing out of, you know, confidence that doesn't. Become ego, right? Mm-hmm. For sure. Yeah. You know, balancing those two things out is important for any, certainly any leader, but even anyone in a individual contributor capacity. Um, people who balance that, those scales. Tend to, um, tend to excel. Well, we're almost outta time. I just, one, one final question for you. I'm gonna ask you to pull out your crystal ball here a little bit on vibe coding. Um mm-hmm. There's so much debate about like, what is, what does this mean? You, you know, I've heard everything from B2B SAS is dead, and, you know, which is complete nonsense in my [00:36:00] mind. Um mm-hmm. There's so much underneath. The, you know, presentation layer, which is really most of what people are vibe coding today is presentation layer. It's not the detailed, you know, uh, I always talk about the illities, you know, um, maintainability, scalability, um, supportability, um, all of the illities require real engineering. Um, focus and capability to make an enterprise solution, and those illities don't exist in vibe coating, at least today. Hmm. Um, if you look underneath the hood of most vibe coated apps, there is, um, you know, a hodgepodge of patterns, practices, syntax, naming conventions. Mm-hmm. Um, they're getting better and I think that eventually we may get to a place where. We will reduce our reliance on human engineers in the [00:37:00] loop. I think that's, that's inevitable. But I don't think that B2B SaaS is, is going anywhere. I don't know. What is your take on, like what do you see in a couple of years with Vibe coding and how it impacts the law and legal tech? It's a really interesting question, and I think that it ultimately comes down to what is the problem that we're trying to solve here. So being able to, you know, do various. AI enabled processes on a series of documents is one part of the puzzle. But there are many, many parts of the puzzle. And I think it goes to your, um, goes to your point Ted, which is if the tool breaks and I'm using this tool on a client matter, who can I call and how quickly are they going to be able to fix it? So if in the vibe coding world we're able to, you know, deal with that, that changes the environment quite significantly. But B2B, you know, one of the values of the B2B. One of the, [00:38:00] um, key, um, things that is currently brought to the table by a lot of vendors is that immediate problem solving facility. The scale of being able to throw a resource to a bug or an issue. That is what's going to matter to me in the, you know, when I'm actually trying to deliver my legal work, is, can I service the client in the best way possible? It's not just about being able to do something cool. So. I think that's critical. Um, it comes to, you know, you can look at it in, but it's not just like a legal, it's not a legal industry point. It's like, if I have an Etsy shop and I'm hand making clay charms, I can only service like, maybe, I don't know how many charms can I make a day? You know, that's, there's obvious limitation there. So I think it comes the exact same point to, to building an application. Whether you have vibe coded it, whether you've built it yourself as one person, are you able to service all of the other things that come with running a business, implementing that technology? So I think that's, that's, uh, that's my, my thought on vibe [00:39:00] coding. But I think vibe coding is incredible and I, I. Yeah, it's, it's a shame to take away from how incredible this switch has been by focusing too much on whether or not, you know, a, a vibe coded solution can be rolled out. Enterprise. I, I don't think it can, to be honest, at this stage in time, it can't, that doesn't mean that vibe coding is not amazing though because it's unlock something else. When I vibe coded my tool. I had no intention of rolling that out, enterprise level. My intention was to, uh, communicate a problem statement, use that as a vehicle to secure the resource, to be able to build it out an enterprise tool. And that is exactly what happened. And I'm really, I'm really grateful that that was able to happen. I completely agree. I think that the, the value, at least today, it's really, it is kind of hard to say where how fast the, the, the tech is going to evolve. But if you look at where the value is today, if you look at the software development lifecycle, you can compress the requirements gathering and business [00:40:00] case building phase of the SDLC dramatically, and you've got problem. Domain experts who are the ones that are building the workable prototypes, as opposed to you sitting down with a business analyst that translates what you're saying into words. It has to be interpreted by an architect and then a dev team, and by the time you get your eyes on it again, you've already gone down a path that you may have to pivot from Exactly. I think it's, it is extremely valuable and I, I think it's also just important to keep in balance. People get a little too enthused and be like, oh, you know, um, Jamie, so, um, vibe coded, uh, tabular review. Harvey and Lara are out of business. Like, no. Um, it's really cool what he did. I had him on the podcast. He's super sharp. It, but it's a great, it really opened people's eyes like, wow, you [00:41:00] can do that. With these tools. So, um, yeah, I'm, I'm a big fan. I think we're on the same page and it's been such a pleasure to, to have you on the show. I really appreciate you spending a little bit of time with us. No problem. Thank you so much for having me. It's been a lot of fun. Awesome. And then, uh, finally, where did people find out, you mentioned that there was a, a law.com article. How did people find out more about what the, the work that you and your team have done? Oh, um, I guess if you just search up my name, um, online, there are a couple of things I can't, so LinkedIn is probably where I'm most active in terms of, you know, showcasing what we're talking about. And there's a few other articles that, um, go into more depth about some of the projects I've worked on, if you search me up online. Okay. And we'll put some of those links in the show notes as well. Um, well great. I thank you again for the time and, um, I hope we get to meet in person sometime soon. For sure. Thanks so much, Ted. Alright. Take care. Thanks for listening to Legal Innovation [00:42:00] Spotlight. If you found value in this chat, hit the subscribe button to be notified when we release new episodes. We'd also really appreciate it if you could take a moment to rate us and leave us a review wherever you're listening right now. Your feedback helps us provide you with topnotch content.