AI Automation For Your Code Reviews & Improvements

Welcome to The Did You Know Podcast by Varisource, where we interview founders, executives and experts at amazing technology companies that can help your business save a lot of time, money and grow faster. Especially bring awareness to smarter, better, faster solutions that can transform your business and give you a competitive advantage----https://www.varisource.com

Welcome to the did you know Podcast by Varisource, where we interview founders and executives at amazing technology companies that can help your business save time and money and grow. Especially bring awareness to smarter, better, faster solutions that can transform your business. 1.5s Hello, everyone. This is Victor with Varisource. Welcome to another episode of the Did You Know Podcast. Today I'm very excited to have Tim Gilboy, who is the founder of Sorcery, with us. Sorcery is an AI platform that reviews your code anywhere you work and automatically suggest improvements. Welcome to the show,

Tim. Thanks for having me, Victor. Really excited to be on.

Yeah, super excited to have you, honestly, because you're solving first of all, I'm not a developer, as I mentioned to you before. But obviously, being a founder, co founder, building a software platform, I've learned so much about software development. All the good and the bad and the challenge. And sometimes it doesn't make a lot of common sense, but it's such a necessary thing to change the world. Right? When you talk about building software. And So, super excited to have tons of questions for you on how you guys solve this problem. But to kind of kick off, why don't you give the audience a little bit about your background and your founder story?

Yeah, definitely. So I guess it's interesting because I'm actually personally not a developer myself either, by trade, but my two co founders, Brendan and Nick, very much are. And their story is really the origin story of Sorcery, I would say. So the two of them have been working together for about 20 years, and they started their career at a financial software firm that had its code base written primarily in the late eighty s and early ninety s. And so they started working on it when it was 1520 year old legacy code base. And it came with all of those pains of dealing with kind of a really old complex code base. Things were buggy, things were written by people who were no longer at the company and nobody really knew how it worked. And just as a result, everything was a constant battle to try and improve the code, refactor the code, and just everything kind of took longer than they would have liked it to. I think that really sparked the seed for a few years down the line for them to really start building. Sorcery with this goal of how could we make it so that any company around the world could continuously be improving their code and never kind of fall into that trap of having to deal with a big complex legacy system. And we've gone through a couple of iterations over the years, but we're really excited what we have today and kind of how we're able to, in real time, actually review someone's code, give you suggestions and fixes for how can you make it better and better and better and not fall into those traps around technical debt. 1.4s

Yeah, when you say that, you obviously make it sound so natural and easy. It's like, sure, of course, that's what you do. Right. But then in reality, this is something which really is kind of mind blowing. When you start building software and really get into this space, right, this department, can you maybe spend a minute or two kind of giving the audience some high level who may not be familiar with I mean, they know developers. They know they're in high demand, they know these developers are important. But you would imagine if you're a developer, they hire you. You should just do the work and the work should just be pristine, right? Like you should just do what you're hired to do and everything is great. Why do you need when you talk about all these terminologies like code reviews and refactoring and all of these things, it just sounds like, well, you can't do 1.4s the right thing the first time around. And that sounds counterproductive when you think about any other department. Right. So can you kind of maybe give one or two minute kind of overview on that flow, on why that is for people that may not be familiar with kind of the DevOps?

Definitely. And I think it's a funny one because when you compare it to any other department or kind of business function, software development is really unique. Because when you think about it, all of the work that you're doing as a developer or kind of all of the code that you're building, you're not just building or you're very rarely building. It for kind of a one time usage. Everything you do is building on top of itself. And so over time, it's not just the work you're doing today, but it's the work you did last week, last month, last year, and not just the work you did, but that your colleagues and kind of other folks did. So you're really building this complex 1.2s system that you're building up on over time, but at the same time you're trying to move really quickly. I think we're all, especially in the startup world, always under pressure to get things done faster. And so you're faced with this dilemma within software development of how do you get things done quick and how do you get things out to users so that we can test, we can learn, we can improve our products. But at the same time, how are you building code that's really resilient and high quality and can be easily extended upon in the future? 1.2s And there's always a little bit of a trade off there between that speed and kind of that perfection of quality. And oftentimes we wind up having to sacrifice a little bit of that quality for a little bit of that speed, or a lot of that quality for a lot of that speed in certain instances. And it's not because the developers are being sloppy or they're struggling to do their job, it's just because they're under this intense time pressure. So then over time, things are going to build and you're going to have cases where suddenly that kind of complex system that you've built up, over time, it's becoming brittle, it's becoming hard to work with. And you then need to go back and invest some time in improving and kind of reviewing that code and seeing how can you refactor it or improve it. And kind of our goal with Sorcery is how can we make that a continuous process? So instead of having to make that trade off between speed and quality, we can help you instantly improve the quality while still moving at speed so you don't fall behind, if that makes sense.

Yeah, no, absolutely. I live in it every day and again, learned a lot and have a great appreciation for developers and the DevOps team for any company building amazing software. 1.1s It's one of the hardest things for sure. It's a constant challenge and battle, but the result can be a fantastic game changing value. Right? But the next couple of questions are really going to focus around kind of talk about the problem a little bit more. Can you kind of give audience a couple of minute insights into why is co quality and co review so difficult? And just based on what you said earlier. Because it's kind of like a Lego piece or you're building a house and you keep layering on these floors, but maybe you didn't finish this first you build a foundation and then you build a second floor. But the second floor you didn't maybe build it the best. Maybe you didn't finish the drywall and some of these things, but you got to build that third floor already. So then you go move on to the third floor. And so again, you're just under this time crunch to finish this project. But then the more layers or floors that you build, it's much harder to go back and figure out what drywall did you forget? Is that kind of the concept? If you can kind of make it into more of an everyday people kind of language, what I describe, is that correct?

Yeah, I quite like that kind of home building analogy there or constructing a building analogy there. I would say it's rarely though it certainly happens. It's rarely that people are dealing with things that are so incomplete as saying, hey, we've got the floor here, or something like that. Oftentimes you're building things so that they'll work, but maybe it's a you started building that house and you didn't realize you needed to build an extension onto the back and so you don't have the structures in the wall in place to make it easy to extend. Or it's just certain situations where you didn't finish painting that one corner and now you have to go back a little bit later. It's usually not these catastrophic issues, but they're those small issues that are just going to keep building up and building up and building up over time. 1.5s But when you were asking about kind of why is code review generally difficult? 1s Yeah. So code review winds up being tricky because it's really a multifaceted process. It's not just about the code itself. But you're also having to start by checking, is this code actually even doing what we need it to do? Is it serving the purpose that we as a business needs to do? Is that maybe that's you have a bug you need to fix? Or maybe that's a, we're trying to build this new payment processing system and you need to know how is that supposed to interface with the rest of your product suite? And so you need to come into that code review with that understanding of what is the actual context for what we're building and then check the code to see does it do that? But then at the same time, you also need to understand kind of all the things about your system design and architecture and how is this code correctly fitting in within that code framework as well. And then finally, from a technical perspective, was this the best way we could do this? Are we using kind of the best features and structures of the programming language we're working in? Is it going to be performant? Is it going to be secure? Is it going to be maintainable? Is it going to be readable for somebody who's coming in later? And so you have all of these different components of the code review process that typically we're asking individual developers to go back in and review someone else's code and they have to keep all of these things in mind as they're looking through it. And that just can become a tricky process because you're asking one person to be doing three, four, five different jobs at once while they're doing that code review.

Yeah. No, I think this is starting to give people kind of a visual of how it's kind of like you have people working on different rooms, kind of back to that housing example. You have people working on different rooms. They are focused on their room. Obviously they're building towards the entire floor together, but a lot of times they don't have visibility into the rest of the rooms, what other people are doing. And so when you then you need somebody to also put all the rooms together into the floor and there are just so many areas that can be overlooked and create challenges in the future. So that's kind of the challenge that developers face. 1.7s Obviously you've talked about clean code 1.9s from a developer perspective when you go into a company, 1.2s maybe your code style or maybe obviously there's best practices, but everybody comes from different skill levels. So typically when a developer gets new developer gets high, it 1s what are the challenges that they face to make sure they're coding to the quality or 2.5s the requirement of the company? And then how do you guys solve that? There for the company. 1.6s

Thanks. That's a great question and it's something I've actually been looking quite a bit into recently is this idea of coding standards within companies. Because when you're coming into a brand new company, there's a couple of challenges you're going to face. One is you need to understand kind of the domain the company is working in. You need to understand the existing code base, you need to read through documentation and just figure out what is going on, what information lives there. But then, as you said, every company has their own standards, best practices, styles. And for some companies they do a really good job of actually codifying these standards. They'll have either style guides, they'll have contribution guidelines, they'll have very specific code review checklists or things that they're looking at. And that can be really helpful for somebody coming in because they can go in and they can explicitly look at this. They can say as they're working, is my code fitting in here? And that's all great, but that's only probably true for 20% to 30% of companies I speak with, for the other 70, 80% of folks out there. We tend to see that while these kind of code standards exist, they're not codified in a concrete way. They're kind of more an internal collected knowledge that's shared amongst the team over time, but it's never been put down on paper. And so for a new person coming in, that can be really tricky. They'll start to learn it over time as they get that feedback from a code review, but they don't necessarily have something that they can go learn from directly. So where sorcery where we try and fit in there is we try and help push teams to codify these coding standards, not just on paper and kind of a written document that says do X this way, but actually embed it within your code and within your software development process so that you tell sourcery, here are our coding standards. And then we as a service, we're kind of reviewing the code while a developer is working and we're pointing out those moments to them saying, hey, you wrote this function in this way or you imported this library into this piece or this part of the code base and we don't allow that here. And that then not only helps streamline that code review process because the reviewer doesn't need to check for these types of issues, but it also winds up actually helping reinforce that kind of new developer on the team as to here's the way that we approach things within this company and they can learn that much, much faster.

Yeah. No, I love it. I think it's a game changing technology for sure. And that's why we're so excited to partner with you guys. In my mind there's a tool called grammarly, and I'm sure a lot of people may be familiar with it. It checks your writing. When you're writing something, it tells you if your grammar and spelling and the style and all of these things it helps you with improvement of your writing. And they have a term for it. Obviously. It's a popular term, maybe by Microsoft as a copilot or your virtual assistant or your AI assistant, whatever you want to call it. It's this AI that has so much more knowledge than you may have in specific areas by indexing certain data sets. And it's able to assist you in telling you where you can improve what are the best practices. Because I may not be a writing expert, right? And so things like grammarly are super useful and popular, but I think do you guys maybe think of yourself as the grammarly of coding, where you're really providing that same value, which is that AI assistant or Copilot to help coders standardize their code across the company by helping them with best practices. And you also mentioned suggestion of improvements. So is that kind of a good comparison, you think?

Yeah, I really like that parallel that you're drawing there to grammarly, because I think they approach things for the written word very much. How we like to think about approaching things for code, because with grammarly it's not going to help you write that next line of your essay or your email, but it's going to look at what you've written and say, hey, here's a better way to do it. And help, first of all, give you an improvement, but also help you learn so that the next time you're writing that email, you can write it a little bit better. And that's exactly what we're trying to do. We're trying to say, hey, let's look at that function, let's look at that class you've just written. Here's a couple of improvements you can have for it. You can quickly accept those, just like you could for grammarly when you're writing an email. And then you also are getting that feedback of kind of, how can you do it better? But just like grammarly, we're also not focused on creating new code from scratch for you. There's a lot of great tools out there for that, but we're focused on that moment that code has been written. How can we help you improve it, and how can we keep helping you improve it over that code's

lifecycle? Yeah, I think that's a great actually differentiator because obviously a lot of people are aware of Copilot from GitHub and OpenAI and obviously all of these tools that are helping you write code. And so a lot of people might put you guys in that bucket, right? But in fact, you complement those tools by providing kind of these suggestions. So obviously, 1.4s every company is thinking about ROI today. If they buy anything, if they implement anything, what is this ROI? They very much care about that. 1.3s Can you give us a couple of examples or kind of data points on what kind of ROI have you seen? And I'm assuming a lot of it is time savings, which time equals money. Right? But give us a couple of examples how you save developers or companies time, and what are some of the big pack ROIs that you've seen? 1.7s

It? Yeah, that's a great question. It's one we get asked a lot by engineering leads and teams is kind of how can you think about ROI with something like Sorcery? And it is predominantly time saving. And it comes down to two things. One is it saves time directly in the code review process. I was talking with a team earlier this week who was saying that they probably spend between 20 and 40% of their time in a given week on code reviews, and we're able to cut down maybe a quarter of that pretty easily right away. And so that can be a pretty significant cost saving right there just in terms of senior developer time. But then it starts to actually build on that as well. Because one of the interesting things is only about a quarter of a developer's time or even less than that, is actually spent writing new code. The vast majority of a developer's time and you'll see this typically set it in the 60% to 70% range is spent trying to read and understand existing code. And when that existing code is hard to understand, it's low quality, it's poorly maintained. That means every task across the board is going to take a lot longer. And so with Sorcery, one of the big ways you start to see team productivity dramatically increase is we improve the quality of code across the board. So all of that time spent reading and understanding code is made so much more efficient. So we typically see somewhere on the order of magnitude of five to 10 hours per developer per month that people say they're saving just by using Sorcery today. And obviously we're continuing to try and improve that. But when you think about what kind of a typical developer's salary or kind of like hourly rate would be, that ROI comes in pretty quickly.

No, that's amazing. Yeah, time is money. And also, I think just the happiness of your developers, right. I think that cannot go unnoticed as well. So you mentioned something about because a lot of solutions today where they face challenges is in AI world is very point solution, meaning they can only help you with those specific instances. They're not able to look at your entire code base to give you 1.5s kind of suggestions based on the entire code base. It's kind of like any tool today can give you suggestions to help you write code or suggestions on your specific room, but can they give you a suggestion based on how your room is connected to every other room in that floor and how it all works together? And that is one of the utopias I haven't seen or heard available yet from a lot of tools and technology you today from developers. I know that's something you guys are striving for. Can you give us a little bit of insight on the importance of suggestions and improvements based on understanding the entire code base versus just that individual developer's Code Base. 2.3s

Yeah, it's a really important aspect of how we think about improving sorcery as we move forward, because when you're looking at kind of localized changes, let's say within a single file, there's only so much impact you're going to be able to have on kind of the overall improvements to the project. Yes, you're going to see some time savings there. Yes, you're going to be able to improve code quality, but you're not really going to be able to start taking on larger improvements in terms of system architecture and design. It's going to be harder to find big performance wins or even things like potential security risks. In order to start to tackle those types of problems, you need to really be able to look across a project at a much deeper level and say not only what's going on in this file or this function, but what's going on several files away where something has been called through a number of different files. And we need to figure out what happened in that very first instance. And so we're starting to roll out a bit of functionality that will really help with that, starting with being able to find things like where are there uncaught exceptions across your entire code base and being able to trace those back and give warnings where those pop up. But then we can do things like start to determine where are really expensive functions being called from like a performance perspective or where are there potential areas where users could actually give input into a section of the project and where does that link up across the board and that could represent potential security risks. So all of those types of cross file analysis or full project analysis start to allow us to give much more powerful insights and therefore much more powerful improvements to developers

as a whole. Yeah, I don't think a lot of companies 1.1s comprehend and especially the ones that have built software or have the software can probably appreciate. But for the general public, I don't think most people fully understand 1s the complex layer and challenges that from a DevOps presents. Because you have people that do the coding, you have people that do the review, the code, and then you have people that do the QA, the testing of the code, and there's a whole supply chain just in that one department alone, and there's so much time that goes into it. And so what you guys are doing is really a huge impact. So obviously when you talk about providing suggestions, one of the questions I'm sure a lot of people are going to wonder is how can I trust your suggestions that it is going to be the best for me or my company or my specific code? 1.5s First of all, how do you build up that confidence, obviously, and how would you explain to these companies why are the suggestions you provide better than maybe their internal knowledge or 1s their developer managers what would you say? 1.7s

Thanks. It's a great question. I think it really comes down to two things. One is we take quite a conservative approach in terms of trying to analyze and understand a code base or a section of a code base to understand what suggestions can we actually make there? And we've built up kind of a corpus of best practices that we can then tap into to help improve that code. But we always want to take a conservative angle because the last thing we ever want to do is break somebody's code. And so we want to make it very clear from that analysis we do from the suggestions we give. This is going to improve your code, but you don't need to worry about it breaking. And that might mean sometimes there is an opportunity for us to make more suggestions, but we're going to hold back because we're only 90 95% confident that that suggestion would be accurate. We're going to hold back and make sure we're very, very accurate, close to 100% accurate across the board in those suggestions we make. To your second question about how can we make sure Sorcery is able to give better suggestions than somebody within a team? To be honest, we're not going to ever know your code base better than you as a team lead as an individual developer. But what we can do is we can allow you to tell Sorcery about your code base to tell Sorcery about your coding standards and build that knowledge into Sorcery so that it's constantly reviewing things and it's always having an eye for where can those standards be put in place? And always kind of take those suggestions that you as a team care about. And because Sorcery is constantly reviewing things and that's its sole focus, it's going to catch more of those kind of tiny cases that might slip under your radar otherwise. And we can make sure that you then, as a team, are going into code reviews with Sorcery already having checked the code for those types of improvements, already having given those suggestions. So then you as a team, really can just worry about during code reviews. Is this code doing what we need to have it do from a business logic perspective, and less so from a is this fitting in with the rest of our code base? Is this fitting in with our code standards perspective? Yeah. No, I love that kind of you guys taking that conservative approach. Like you said, a software is so critical to a lot of companies, right? And oftentimes it is the company if you're a software service. So it's very critical, meaning any risk, 1.4s any new tool sounds great, but then if there's a risk of anything breaking, that's just a huge concern for companies. So I love the approach that you guys take. So, a couple of last questions as we wrap up here. So. 1.6s You know when you look so what kind of size companies would you say are best fit to get the most impact immediately from a Sorcery? Is there a certain size of the development team? And how long does it take to implement something like Sorcery where customer can start getting ROI and value 2.2s So? In terms of company or teams eyes, we really see it run across the board. So we've worked with kind of early stage startups that are three, four, five developers just getting started and are really trying to implement best practices from day one to working with teams that have several hundred or several thousand developers across the organization. And there it's really about how can we start to improve the existing legacy code? How can we help those teams be more nimble, more agile, and then kind of help improve things in their day to day process? But I'd say typically the sweet spot is probably an organization with between 52 hundred developers in it, because at that point, you can usually get organizational buy in across the board. But they also have hit a critical mass where they've had to have those conversations about codifying those coding standards, codifying those best practices, and those you can then start to build into sourcery so you're getting the most value there. It's not just giving you general best practices, but it's giving general advice around best practices, but it's giving you specific advice as to how can you improve things based on what you want for your project and for your code base. In terms of getting started, it's actually incredibly quick and easy to get started. You can add Sorcery into your IDE, where a developer is typically writing their code in a matter of seconds and just right out of the box. Sorcery will start scanning your code and giving you suggestions. You can then take a little bit longer to get things set up. Maybe it'll take an hour to customize some of those rules that you want to build in your own best practices into Sorcery, but it's a very quick turnaround process from not having it all to starting to get that feedback and starting to get that code improvement.

Yeah, it's been a great conversation. And again, I think anybody who has developers or is building software needs to look at a solution like Sorcery. Again, we're super excited to partner with you guys to take over the world together. But the last question we always like to ask our guests is, you've seen a lot, you've done a lot. If you had to give people one advice, whether that's a personal advice or business advice, what's something you're really passionate about them? 3.6s

I really like that question. 1.3s I have to say. You can never talk to your customers too much. I think it's occasionally a trap we've run into at sorcery it's occasionally a trap I've run into in past roles of of assuming we know what's going to be be valuable to people, of assuming we know kind of what the underlying problem somebody is dealing with on a day to day basis is. But you can really never have too any of those conversations with current or potential customers to understand really what are their issues on a day to day and how can you build something that's valuable to them to help tackle those problems.

Yeah, I love that. Yeah. No, it's something we at Varisource also strive for as well. So no, thank you so much for your time and again, excited to partner with you guys. That was an amazing episode of the digital podcast with Varisource. Hope you enjoyed it and got some great insights from it. Make sure you follow us on social media for the next episode and if you want to get the best deals from the guest today, make sure to send us a message at sales@varisource.com.

Spend Advantage Podcast

AI Automation For Your Code Reviews & Improvements

Listen to this podcast on