Catch the Bugs Your Code Review Misses - Killian Carlsen-Phelan & Taylor Luttrell-Williams, Sonar

AI Engineer · 38 min · 362 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:01[music]
00:12My name is Taylor Luttrell and I'm joined here by Kilian Carlson.
00:17Together we make developer content at Sonar, the maker of SonarQube.
00:22But today, in particular, we are jazzed, dare I say, to get you all up and running with Git Guardian so that you can both find and critically fix issues
00:34in your AI-generated code before they ever emerge.
00:39Now, before we dive into the hands-on demo itself, if you would please direct your attention to one of the screens on either side of this room, we've provided for you a QR code
00:51and also a link there below which, once followed, you can use to set up a free, I should note free, 14-day pro trial for Git Guardian.
01:02So, this is going to be really important if you want to follow along step-by-step and play-by-play with this workshop, you're going to need Git Guardian.
01:10So, we'll give you all a minute to get that set up, should you like.
01:15And just in the meantime, while you do configure that, if I could get a quick show of hands from the audience, who amongst you is already using an AI code reviewer
01:27as part of your CI process?
01:31Okay, so that's a fair number of you all and that's what we like to see.
01:35And whether you are or you're not, we hope that you will be able to derive some utility from today's session.
01:42We'll give you all just another minute as you sign in to Git Guardian and set up that trial.
01:54Next I have for you another QR code and I promise this presentation is not exclusively QR codes, but this one is in fact very important as this will take you to
02:05the dedicated GitHub workshop repo that we have created so that you can get up and running with Guitar.
02:11This project is going to help exercise some of Guitar's incredible capabilities and Mr. Killian here is going to walk you all through that in a minute, but as you get set up, I do want to note that
02:24everything we do in this session is going to occur in the browser.
02:28So, you're not going to need to set up any local tools, install any local environments.
02:33All you need is a GitHub account and access to Guitar to follow along play by play.
02:38Uh just a couple of housekeeping notes as y'all are getting signed in and set up.
02:43Uh in this workshop, we're going to guide you through a few different things, namely installing Guitar as a GitHub app.
02:50Going to need access to GitHub for that.
02:52And then critically utilizing Guitar across a few different pull request scenarios.
02:58We have three prepared for you in this demonstration that are going to demonstrate how verification with Guitar goes beyond simply code review.
03:09And don't worry, this is very beginner-friendly if you're not especially technical.
03:13We're going to start slow with Guitar's out-of-the-box verification and then we're slowly going to ramp and build into some of the more advanced features.
03:22We're actually going to create a project-specific configuration that teaches Guitar your project's conventions.
03:29And then lastly, we're going to round things out with a CI uh failure diagnosis and you're going to watch some automated fixes occur directly on your PRs.
03:39So, if you follow along with Guitar and with this repository, then by the end of this workshop, you're going to walk away with Guitar installed, three verified pull requests,
03:51as well as a practical understanding of a number of things such as, but not limited to, verification instructions, rules for your repositories, as well as CI failure analysis.
04:05I hope by now you're all set up with guitar.
04:08You've logged into GitHub.
04:09Go ahead and refrain from forking the repository right now, as Killian's going to walk you through the steps uh specific for our configuration.
04:19I want to start instead with a scenario that I'm sure many, if not most of us are intimately and also frustratingly familiar with, which is we all know that AI coding agents are wildly effective
04:35at writing code, both at speed and also at volume, but while these agents are supercharging our teams to write more code and much more quickly, we ought to pause
04:49and ask ourselves who or what is actually verifying the code that our agents ship.
04:57And whether consequently the code that our agents ship is not only secure, of course, and maintainable and reliable, but also whether it is practically and not just functionally or technically
05:10correct.
05:11As we know, agents, as they're generating more code and they're doing so faster than anyone can realistically inspect, a couple serious issues have begun to arise.
05:25The first is an obvious review bottleneck.
05:30We have teams with a fixed number of members, but which are now facing an increasing number of changes uh via their AI agents.
05:39They're being inundated with code to review, and as a result, queues are growing, merges are sitting waiting and unattended to, and reviewing is essentially becoming uh a job, a chore, if you will, that nobody
05:52wants to handle and simply doesn't have the time or the resources to tackle.
05:57Number two is we're noticing an increase in the number of production incidents.
06:04As incidents scale with the rate of change given that coding agents do not always respect the project architectures that you spend so much time devising your team or your company or organizations
06:18coding standards or any of the guidelines that you've established.
06:21They're unaware of those things.
06:22They lack the proper context.
06:25And with these issues threatening to undo the very progress that coding agents promise, the answer has to be faster than um anything that humans can perform and also better than human review
06:40in order to keep up with the rate of changes that are being introduced by these agents.
06:45And so, what we have for you is Guitar, which is the code change verification agent.
06:54And it stands out apart from and above the rest in a number of ways, namely it functions with a high signal to noise ratio and effectively minimizing the false positives,
07:08the number of false positives in order to improve the fix rate and reduce token expenses as well.
07:14It diagnoses CI failures.
07:17This is really unique.
07:19And it separates real breakages from flaky noise or infrastructure noise.
07:23And it also, crucially, fixes these issues accordingly.
07:28And it fixes autonomously also.
07:32So, that you can move forward as quickly and as freely as possible.
07:37Effectively, you choose your level of automation and you also choose your level of involvement.
07:43We're giving you the reins.
07:44Guitar also iterates until all of your changes pass CI to be absolutely certain that you can ship the code that your agents are generating.
07:55And lastly, it provides a high degree of transparency into the review process and your CI through a number of dedicated analytics dashboards so that you can continuously improve the speed,
08:08quality, and effectiveness of your code delivery.
08:12So, in essence, and and just to recap, Git Tarr is designed for platform and engineering teams uh who need to ship code with confidence at agentic volume and also agentic velocity.
08:25And it complements SonarQube with an understanding of each code changes context and intent.
08:35And Git Tarr leverages a variety and a a wide body of context sources to accomplish this.
08:43Suggesting educated and informed fixes from such things as PR diffs and details and comments and whatnot um from the CI uh CI logs as well, the the very logs that I personally hate to to have to sift through.
08:59Um from project-specific instructions as well.
09:03Um configurations that you can write yourself in the repository rules and and much much more.
09:08And we're going to dive into some of those during the session uh today.
09:11And I should note that for anybody who is worried about noise, as I mentioned uh Git Tarr is tuned for signal uh because we understand that every false positive is a token spent
09:23and a fix attempt that risks an unintended change.
09:28Um and rather than adding more noise and burdensome decisions to an already complicated review process, Git Tarr does do the work of getting the change through and in the process
09:39verifying and fixing everything so that you don't have to yourself.
09:45At a high level Git Tarr's review engine is triggered when a PR is opened and it calls upon that wide body of context that we just spoke about to produce findings
09:57and also fixes posted directly to your pull requests as actionable guidance that you can interact with with comments or if enabled, automatically fixed and merged.
10:12And to demonstrate just that, I'm going to pass things off to Kilian, who's going to walk you through the hands-on component of this workshop.
10:20Should you have any questions, if you get blocked, feel free to raise your hand or call on me.
10:25I'm going to be walking around the room and I'm happy to assist should you all need any help.
10:29Thank you.
10:30Cool.
10:31Thank you very much, Taylor.
10:32Um hey everybody, I am Kilian.
10:34I am a developer content engineer at Sonar.
10:37And um we're going to hop into the hands-on section of this workshop.
10:43And before we do that, uh the first thing, like Taylor mentioned earlier, is we're going to want to have the Guitar app already installed.
10:52So, if you haven't done that yet, please go to app.guitar.ai and sign in from there and then start the GitHub install.
11:01And the second thing is right here, I have the workshop repo.
11:05It's at github.com/sonarsamples/aie-new-york-workshop-guitar, but you can find it under the repos tab.
11:15And the first thing that we're what going to want to do is just go ahead and fork the repo.
11:24And make sure that the owner is the organization that you've installed the Guitar app to.
11:31And you can name it anything.
11:33You can keep the name.
11:34You can name, you know, test run, whatever works for you.
11:38But the most important thing is that this right here, copy the main branch only is unchecked.
11:47There are multiple branches for different exercises I'm going to walk through, and if you only copy over the main branch, you're not going to get those different exercises.
11:57So, we're going to go ahead and click create fork.
12:03And once that's done, the next thing that we're going to want to do is hop into actions.
12:10Right, by default, GitHub disables workflows from forks.
12:15And in order to set up some of the things that we're going to do, like automated merging and approvals, you're going to want to enable that.
12:23And then the last thing is that if you want to make sure that Guitar is able to read this fork, you can go into the Guitar dashboard.
12:33Um go to settings.
12:36Go to configurations and repositories, and you should see your repo pop up there.
12:43But okay, just to hop into this exercise.
12:48I have here Box Office, which is a fake sample ticketing API for a small concert venue.
12:56[snorts]
12:56And it's it's a pretty simple Python project.
13:01We have orders.py here, where somebody is able to purchase a ticket or cancel it and get refunded.
13:10We also um have this uh checkin.py, and what this does it just handles the logic for somebody to hypothetically be able to scan a QR code and get someone into a concert.
13:21And this is a pretty basic uh example application, but there is a test suite here um that cover all of the existing uh functionality.
13:31And every time a PR is opened, uh the test will run.
13:37And so, what we're going to do right now is actually open pull requests for each of the three branches that are in there.
13:46And the reason for that is because Guitar can take a few minutes to run, and instead of having to wait for each review to happen sequentially, we're going to open them all up and then go through them step-by-step.
13:59One thing to note is make sure that you set your base repository to um what you are trying to do.
14:08Uh set your set your base repository to the fork that you have made.
14:15So, I accidentally hopped back to the base repository, but yep, right here.
14:21So, I'm going to open new pull request.
14:26Oops, I kept on checking it.
14:31[snorts]
14:39Yep, so you're going to set that to your um run right here, and then click sequentially stage one, stage two, stage three.
14:50So, yep, create pull request here.
15:00Going to set up another one.
15:06Pick stage two.
15:11Create pull request.
15:17And then open up the third one.
15:26Again, make sure that this is opening against your fork and not the upstream repository.
15:36All right, so all three should be running.
15:39Guitar should be running its review um while we wait.
15:43And so, let's hop into the first PR right here.
15:47Um this is just going to be Guitar's out of the box review.
15:51We haven't done anything, we haven't configured anything.
15:54This is just when it looks at a PR, what it suggests.
15:58And what this change does is we are adding the functionality for someone to order a ticket, and then transfer it to a friend.
16:07So, if I buy two tickets, and I send one to my friend, we should both be able to go to a concert hypothetically.
16:13Now, I have included in some pretty basic validation here that just makes sure like, "Hey, the ticket's not found."
16:21If you don't have a valid email address or it's a voided ticket, it's not going to let you transfer those tickets.
16:27And uh some tests for that as well.
16:30And the tests for this uh PR pass.
16:34The workflow is green.
16:36The CI is green.
16:38Um and one thing that I want to point out here as well while we wait for the review to land is that while Guitar is is reading this, it's analyzing
16:50in a different way than more traditional static analysis tools or other tools might be doing.
16:56Where static analysis like SonarQube is incredibly important and it catches security issues like SQL injections to where, you know, traveling through 20 different files and functions, it's able to identify
17:11um you know, SQL injections before they land in your database.
17:15What it can't do is infer intent, right?
17:19By looking at your descriptions, your titles, at your existing code base compared to the features that you're adding, it cannot infer that, "Hey, the business logic that is being attempted
17:32uh to create here um doesn't add up in the way that it should."
17:37That's why we need both layers on top of each other.
17:40They cover different capabilities and both of them are complementary towards having a fully verified application.
17:48We need to be making sure that our code is completely verified as it scales in volume and speed.
17:55Otherwise, um outages and and breaks are almost guaranteed.
18:00So, um I'm going to hop back into the main conversations here and we see that Guitar has added a finding.
18:09So, anytime Guitar finds an issue, it'll add a comment um at the line that it finds an issue and it also posts a code review that has all of its findings,
18:21as well as descriptions and suggested fixes, and provides a nice summary at a high level.
18:29If we read this here, it says buyer can refund and void a ticket after giving it away.
18:35So, when adding this PR, right?
18:39When you buy a ticket and then send it to someone else, if you go ahead and cancel your original order, it gets canceled for your friend.
18:47Right?
18:47This is an edge case that wasn't accounted for, and there wasn't even a test that almost caught this.
18:54There was a test that said, if you have a voided ticket, it won't let you send it, but not the reverse.
18:59Um and it also identifies, right here, that the issue is in the original ordering file, orders.py.
19:09So, the the if you were just a reviewer looking at the diff, you wouldn't necessarily see in the code that you're adding that there's anything wrong.
19:19You would have to have working knowledge of how cancellations already work in your application in order to understand what's being broken.
19:29Now, this issue only multiplies as as we do more and more agentic coding.
19:36The surface area of applications gets more and more complex, um and in order to maintain an understanding of how every last function works is almost impossible at the rate at which we're coding.
19:51That's why reviewers like Guitar are absolutely necessary because it compares all of your features against existing functionality even when it's not readily apparent in the PR diff.
20:04And so, awesome.
20:06Guitar has posted its review.
20:08Now, what do we do?
20:09It's very simple.
20:10You can either click this apply fix right here, or you can just comment Guitar fix, right?
20:19Comment that.
20:20What Guitar is then going to do is add a new commit to the PR.
20:25It will continue to iterate and re-verify the new commit blindly.
20:31So, if any side effects in the workflows happen to occur, Guitar will keep working, will keep iterating at no extra cost per PR to make sure that it gets fully green
20:43by the end.
20:47So, Guitar is working on that extra fix.
20:50And what it will end up doing is just fixing in that orders.py um file and adding extra validation for this.
21:02Just takes a couple minutes and it automates this entire process of diagnosing a break, re-pushing, and then fixing and verifying your commits every time.
21:14I am I am really passionate about the fact that we not cannot be shipping unverified code.
21:21This is absolutely essential and we need to be verifying every PR with context, with verification, with both deterministic and um a logical understanding of what's being done here.
21:37So, while this fix lands, it'll just update uh the commit here.
21:45We'll see it pop up in the files change diff.
21:49Um it will analyze and make sure that the workflow goes green, and um it should be ready to merge.
21:58But, I'm going to move on real quick into the second pull request, where we're going to cover context.
22:07So, every repo or every team has extra rules and uh business logic that doesn't necessarily get represented in the code.
22:17So, that could be something that lives in your senior engineer's head or in a wiki or in a confluence page or something like that.
22:24And these business rules don't necessarily have anything to do with code correctness.
22:30So, for this PR right here, we are adding in a $3.50 service fee for every ticket that's that's purchased.
22:38So, if you buy a $50 ticket to a concert, at the end you're going to be paying $53.50.
22:45But, for this hypothetical company right here, they have a rule that says every price we show a customer is the all-in price.
22:56I don't know about you, but it is the biggest pet peeve in the world for me when I go and buy a ticket for something and it's like $30
23:03and then with fees and everything like that, it's like $70 by the end of it.
23:07Um this hypothetical company cares about user experience.
23:11They care about you.
23:12So, they have a business rule that says every price we show is the all-in price.
23:18But, how do we enforce it?
23:19How do we enforce that this is going to get reviewed by a code review agent.
23:24Well, there's a couple different ways.
23:26One is this uh review directory.gitar/reviewdirectory and another one is this .gitar/rulesdirectory.
23:35So, what a review directory does is you can add all the context you want, as many MD files, as much of your business logic as you want to add and Gitar
23:46will steer its own reviews according to this.
23:51And this is super powerful, by the way.
23:53Like, I encourage you on your own, just throw as much context as you want at it.
23:58Uh Gitar is incredibly efficient and powerful at ingesting this and applying it.
24:04Uh for the rule section right here, rules are awesome.
24:08I set these up all the time.
24:10Rules are if a certain uh criteria are met by a PR, then a rule will fire and take an action.
24:18So, for this one, is every time an some of the pricing files are edited or updated, it will check and present to a reviewer a list of hey, these are all the customer facing fields
24:30that are edited and it'll let you know these are all in or otherwise.
24:35But you can do a ton with rules.
24:37Um one that you can do is if let's say you and another engineer are talking about uh a new capability or feature in a Slack thread.
24:46You can set a rule that says, "Hey, every time I paste a Slack link in my PR description, go into Slack, look at the conversation, and check my code against the discussion that we were having."
24:59And it'll just fire every time that you do that.
25:02It's super cool.
25:03I love this capability.
25:06Um and if we scroll down, oops, a little sneak peek of what Gittar found there.
25:11But we can see that um there's this, you know, service fee that gets added and some tests.
25:18If I hop back into the main conversation, we can see that Gittar posted his code review.
25:25It posted the rule, right?
25:27It sees all of these pricing fields and it lets you know, "Oh, this is is or is not an all-in price."
25:34It finds the bug.
25:36Now again, guys, this is not an engineering bug per se, right?
25:42If you're just the world's best programmer in a vacuum, it's it's not like this is incorrect, but according to your business and your use case, this may or may not be what you want to do.
25:54So Gittar is able to check against this.
25:57It is so powerful.
25:59We're not going to go ahead and merge this one in.
26:02Um we're just going to leave it before hopping into the third exercise.
26:09Oh, and just um the Gittar fix uh and then I'm going through and it's been fully verified from the previous exercise that we did.
26:20Um Gittar uh approved it, fixed it, and we can see that um Let me look at the diff.
26:30Then I went ahead and fixed this orders.py and added in this extra check.
26:36But moving on to the third exercise.
26:39And what we're going to do here is we are going to enable full automation and merging complete pipeline verification from the moment you open your PR to the moment that it gets merged in.
26:53And there's going to be a little bit of settings that we have to adjust here.
26:55So if you want to follow along, I highly encourage you to.
26:58If you just want to watch and set this up later, the read me for this repo has all of the instructions available for you.
27:05Um so the first thing that we're going to want to do is hop into rules, scroll down, and click allow auto merge.
27:13That sets up the GitHub setting that allows for GitHub's auto merging.
27:18Next thing is to go to rule sets.
27:21Hit new rule set, new branch rule set.
27:27And for rule set name, you can just say, you know, workshop rule or whatever you want it to be.
27:35Make sure it's active.
27:38And make sure that you target default branch.
27:42And the rule that we want to set here, the check we want to set is require status checks to pass.
27:48And what that will do is if you type in test here, is that we are going to require our CI to go green, our test to pass before we say, "Hey, this is good to go ahead and auto merge."
28:04Again, if, you know, you missed any of those steps, this is in the read me with all of those different requirements listed there for you.
28:14So go ahead and create that.
28:16And if your company has secure off set up like mine does, it may enforce a code, which I have right here.
28:29Awesome.
28:30Cool.
28:30So we've created a new rule set.
28:37So, you may see already for this PR, it's just been blocked.
28:41A test has failed.
28:43But, what this is doing is it is essentially refactoring the way that tickets are scanned.
28:49Um what it's saying is that, "Hey, we're going to update tickets now at the point to the ticket page URL and refactoring a little bit of the logic that already existed
28:59within the application."
29:01Um but the the the test failed.
29:05And if you go into that and you look at what failed, it says, "Test ticket cannot be scanned twice."
29:11So, it caught a check that was missed in the refactor.
29:16Um if I scan my ticket, I should be one and done.
29:21I don't want to continue scanning over and over and let all my friends use my same ticket behind me.
29:27It's pretty basic, but it's easy to miss logically.
29:32In Guitar's uh review, it is able to inspect CI.
29:38It says CI failed.
29:39It says, "One test fails at the gate check-in.
29:41Scanning an already used ticket a second time returns 200."
29:45So, if you have any failures in your pipeline, Guitar is able to inspect the logs and fix.
29:53One of the I guess biggest annoyances in my engineering career is like the test log inspection loop, where you have to go in and see what failed and then try and diagnose and then, you know, fix it locally and then push it
30:08and then wait for the pipeline to rerun.
30:09And some of these pipelines can get really long.
30:12And then you're just waiting and then it fails again and it's just this time-consuming, money-burning process.
30:18And you may even need to like keep pinging another engineer about reviewing.
30:23And I'm getting a headache just thinking about it.
30:26Guitar just solves all of that for you.
30:29It is able to automate that process and keep going.
30:33So, it's very simple.
30:36All you have to do is type guitar, sorry I'm doing this with one hand, is guitar auto apply on and then guitar auto merge on.
30:51And what auto apply is going to do is just allow guitar to keep pushing fixes without needing you to to click yes on it every time.
31:01And then what auto merge is going to do is whenever it doesn't detect any more issues and whenever your pipeline finally passes fully, it's just going to go ahead and merge that in for you.
31:10Um cool.
31:14I'll add that.
31:15[snorts]
31:18Guitar auto apply on, guitar auto merge on.
31:21If I refresh it, guitar Oh, it already did it.
31:24Hit it with a nice thumbs up.
31:25Thanks, guitar.
31:27Um And so, guitar will iterate, push a fix, validate it, verify it, and then eventually merge it in.
31:36And this will happen within a couple minutes.
31:39This is beyond powerful, right?
31:43To be to be able to set up your application.
31:47And by the way, adding the comment like we did is just for the sake of this workshop because I didn't want to auto merge in the other PRs.
31:55You are able to go into the guitar dashboard and turn on auto approve and auto merge for any of your repos that you want.
32:03You can be selective.
32:05You can choose the level of automation and approval that you set up for each repository.
32:10If you have an incredibly agentic workflow with tons of guard rails and tests and a sophisticated pipeline, um and then you add guitar on top of that, you're just able to let these rock and roll right off the bat.
32:24So, I'll refresh this.
32:28Guitar still working, um but it will continue to go and push until everything is fully merged.
32:41The repo as well.
32:44Uh I encourage you to continue working on it on your own at home.
32:48There are some extra things at the end um that that
32:51[snorts]
32:51are more advanced capabilities for you to check out.
32:54Uh Taylor's going to talk about a few of them, but you have a 14-day pro trial that I encourage you to use on this repo, that I encourage you to use on your own repositories.
33:04Um I think you're going to get a lot out of it.
33:08Um so instead of uh holding y'all hostage to watch Guitar add its uh auto merge in as it's iterating and applying those fixes, I'm going to pass it over to Taylor to talk about a few more
33:23features.
33:24Well, thank you Killian for the insightful demo.
33:26I hope that we were able to help y'all get a rocking and rolling with Guitar.
33:31Just want to pop back up to discuss a couple more advanced features that Killian has just mentioned, uh which he touched on, but whose walk-through would go beyond the scope of this short and simple workshop.
33:44So, first note that at the bottom of the read me in the repo is a take it further section, as he just mentioned.
33:52I would encourage y'all to follow that after this workshop.
33:55Follow it at your own pace, take it home.
33:58Um but to quickly highlight, Guitar does enable some additional features including but not limited to number one, functional validation.
34:09As Killian mentioned, it checks each PR against the ticket in the case of Jira that it implements.
34:16And this is really powerful because it ensures that the change is correct and complete and not just clean.
34:23All right?
34:24So, it works with Jira currently, linear.
34:26It works with Slack as well, which you can can connect through the Guitar dashboard at settings and integrations.
34:35For example, you can reference a Slack message or a Jira ticket to better inform and structure your reviews with Guitar.
34:45Guitar also takes advantage of a feature that we're calling knowledge, which learns conventions and also references false positives from the feedback that it receives and the feedback that you provide
34:57to it.
34:57And it's weighted by reviewer seniority, actually, which is pretty neat.
35:01Um and this shows essentially the rules behind every review, where they come from, and why they're coming into play.
35:11There's two that I would like to show you all today.
35:13The first is cross repo, and the other is cross PR analysis.
35:18Cross repo analysis finds PRs that may very well merge cleanly independently, but um but break code in another repo.
35:30Right?
35:30And there's actually no limit on how many repos it analyzes.
35:34Just food for thought.
35:35Um and then there's cross PR analysis as well, which checks in-flight PRs against each other.
35:43As you probably know, or may very well have experienced, I certainly have, two PRs can each pass alone and yet still break production together, and that's just a risk
35:55that grows with every agent you add into the stack.
36:00So, Killian's walking you through the dashboard.
36:03Um just to quickly touch on each of those features.
36:06Um if you would, perhaps we could click into a single one of these findings.
36:10Note that it points you to the fix, shows you where this is occurring, and importantly, why it actually matters, right?
36:16Why you want to defer to a uh to Guitar to go about uh fixing it.
36:24And that is Guitar in a nutshell.
36:29We hope that y'all have found some utility from this.
36:32Um again, feel free to take this home should you like to better familiarize yourself with the tool.
36:39Play around with all of the context that you can throw at it to get better and more informed reviews.
36:45Um there are a couple that come with the um enterprise feature.
36:49All of this is going to to ship with with Pro.
36:52And so we'll open the floor now to any questions.
36:54Should y'all have any questions for us, we'd be happy to answer those.
36:58Thank you very much.
37:01Yes, so Git Tower has MCP connectivity.
37:03It's able to ingest um context like that in a variety of ways.
37:08Um
37:08Configure your own integrations.
37:10Yeah.
37:11That that sounds a little bit different from the knowledge capability that we have.
37:14That sounds more like the context capabilities where it'll review, you know, code against, you know, like architecture guidelines and things like that.
37:22The knowledge tab that we have is um steering Git Tower specific reviews.
37:27So if Git Tower posts a review and suggests a fix in a certain way, you can say, "Hey, we actually tend to fix stuff in, you know, this type of way or or XYZ manner."
37:39And Git Tower can save that for its own fixes in the future.
37:44That's a great question.
37:44I'd have to follow up on you about how exactly knowledge ingestion works.
37:50Um but I I I believe I actually I actually know for a fact that there are ways to get that connected, whether that's in the knowledge feature itself.
37:58I would have to follow up with you about that.