 Hello, everyone. I told someone earlier today there was going to be five people in my talk. There's at least six of you. Which is a little disconcerting. I wouldn't have to say to ask you how many of you are here voluntarily, or how many of you your boss told you you had to come. If you do, I'm going to try and make it as interesting as possible if you're being forced to. I can also do it with a slide. So, today I want to talk to you about code reviews. Possibly the dullest subject on the board. But a really, really important one. And I want to start off with a cautionary tale, well, just a tale, just to set the scene. Many years ago there was a younger version of me. He wasn't as dashing. And he had a small dev agency. And we wrote a plug-in. This was a long time ago. This was at the point when if you were writing a commercial WordPress plug-in, you came to an event like this, you got booed. Some of you are so young, you don't actually remember these times. And we wrote this some code and it was for a membership plug-in. And we were writing some code to deal with refunds. Now, if you've ever had to write any code to do with anything to do with pricing, you can imagine where this is going to go. But with refunds, it's a particularly interesting problem. You have a membership site and let's say that you have refunds for you. If someone signs up for 12 months, they have three months and you want to prorata that refund. That doesn't sound too complicated. You start writing the code, you start finding the edge cases. Then someone says, yes, but we have groups because the plug-in allowed for you to have groups and you could have members and extra people could join the package. So halfway through, five new people came in and therefore the value changed. So now you have to refund based on that, but from this time point over here. Okay, we can do this. More code gets changed. Then somebody says, I'm still running on a 32-bit system and actually this whole process was set for 99 years. And so it doesn't matter about the refunds because all the expiry dates say something in 1970 and so when I refunded them, what I actually did was debited them for nearly 40 years. Okay, that's a new edge case when you write it in. By the end of an iterative cycle of what felt like decades, but was in fact only a few weeks, we had code. It was perfect. Well, I say perfect. If you looked at it, you would have said it is horrible. It is a mess. It doesn't make sense. It really doesn't make any sense. There are code comments in there, but they're basically talking about developers' pain, not necessarily about what it does. It got to the point where it's like, okay, it works, we're going to put it to one side. A few months later, a new developer comes on board. They look at that code. That code is horrible. It looks like this, it does this, it's not, it's all right. He starts to have a go at fixing it because in his mind it's broken. Needless to say he fails. He makes no progress whatsoever and he just admits defeat. In fact, some new comments have been added to the code with the levels of pain that he's affected. This happened for many years. We ran, this code was in a code base for about four, five years. By the end of it, it had a comment at the top that said, here be dragons. It was signed by each one of us that we would honestly never touch this code again because it was so bad that your head would blow up. The thing was, and the thing that young me never got, it worked. It always worked. It was ugly. It was horrible. It hurt your head, but it worked. We should never have touched that code again. We should have written some tests to make sure it constantly worked but then we should have left it alone but we couldn't because as developers we like pretty things and we like things to be our way. We like to feel like the things are working well and feelings are an odd thing for me to say about something that's so logical yet so much about code is about how we feel. The reason I started with that was because if only at some point we'd done some proper code reviews, some of this could have been solved. If only we'd really grasped the concepts behind a code review whether it's informal or formal, we might have got there. I think we then have to ask the question, what is a code review? Of course, what I did when I thought about this talk was I'll go to Wikipedia and they say something like that. A code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code and they do so after the implementation or an interruption of implementation. This is clearly been written by a project manager who likes to go on Wikipedia. No developer has ever said this. Let's think about probably a more accurate reflection of what most people think of a code review. I think it's more likely where we pick developers in a fight to the death over which hill they wish to stand on. I like to think it involves lions, but it doesn't have to. If your company is not comfortable with lions or maybe you're not a cat person, maybe you would like wolves. The thing is, a code review often comes across as an adversarial. We often think of them as, I'm being judged, I'm being tested. Of course, that's the last thing we want to do. We don't want to have people feeling like they're judged and tested. There are so many ways to do a code review and we can hide the fact that it's even a code review in the first place. In fact, lots of what you will be doing every single day whenever you talk to somebody about their job as they're writing code can be a code review. So maybe rather than asking what is a code review, let's think about why we might do a code review in some way. So why do we do code reviews? Well, the first one is because we might have to. Somebody might have said, hey, we have a specification and you must meet it. Whether that's PCI DSS, whether it's something to do with GDPR, whether that's something to do with like, if you're in the UK and you have to do anything with the NHS, with our medical services, they have a specific standard and they often say your code must be ordered to meet this. Somebody else is saying, you must do this. That's perfectly fine. By the way, you have every right to be grumpy about it because it's not your choice, it's somebody else and it's being set upon you. That's annoying. That's fine. You still have to do it. That's one reason we might have a code review. The second one is we might be required to meet some sort of standard internally and that could be a coding style. That could be we have a set of how we do certain things, how we have certain tests set up, what certain design patterns we might be using and those things are done from our internal perspective. The thing is, if you've got any of those and those are being picked up in a manual code review, you're doing it wrong. I don't want to say wrong because everything is different. But in this case, this is the one time I get to say, you're doing it wrong because you can automate all of that. If you're, if you as a company have a standard and it is not automated, it's not a standard. What you have is a set of guidelines and fidgetings that you can just use along with. Find bugs. I mean, I think it might actually ask you what does a code review do. I think most people would have assumed that was where we were going to be at the start. But actually code reviews aren't necessarily about finding direct bugs but finding where things work differently to what we're expecting, which is different because sometimes a bug is a feature after all. Again, we can test, heavily automate this with tests. This is where we find things like functional testing, acceptance testing and unit testing come really handy. The problem is that if we rely solely on testing as our way of finding bugs, we're going to miss stuff because we only test for what we test for and if we let the developer write the tests and they want to get home by five o'clock and some things aren't working, you quite often find at 4.59 when they really do need to get home that magically the tests are passing. It's a lot easier when you can go, well, there were 12 tests and now they're 11, but they're all green. And then we have make sure it does what we expect, which is does it actually work? It's not separate from bugs and bug fixes. Does it do the thing we actually asked for? Does it work? I imagine there's lots of people here who have given a code to review and you've looked through the code and it's looked beautiful. And it's been a thing of beauty and everything looks lovely. And then in the last second before you went to put that in push in, you went, hang on a minute, I'm just going to run that locally. It doesn't actually work. And then you look at it again and go, oh, chatty BT. OK. My final thing that I think why won't we do this is to share knowledge. And I think this is the most important one. And I think this is the thing that actually is the biggest benefit from code reviews, is that we can share knowledge in both directions with the person who's doing the review and with the reviewer. It's a really good way to help people understand code, help people understand what's going on within your code base. And it's a really, really useful place to help people who are perhaps your junior developers actually get into that feedback cycle and gain some knowledge through. And that doesn't mean that just doing code reviews against junior developers, but also allowing junior developers to see senior developers' code and reviewing that code. In many ways, that's more helpful for them. They also get to nitpick their boss, which, depending on your personality, is a positive or a negative thing. So, with the why, what does a code review look like? Well, it depends, because every organisation is different. So, and how we, where we put it in the cycle makes it important. So, let's go from what does it look like to when should we do it? And really there's three phases. The first phase is during development. And that's where we're busy writing in small chunks and we often will put that into, like, pool requests. Or maybe if it's less formal you might do something like pair programming. Cos I genuinely believe that pair programming is a really important and useful code review style. I can't really see you all, so I'm just going to assume everybody knows what pair programming is. Is there anybody in the audience who doesn't? It's okay if you don't. I can't see any hands, so I'm going to assume that's fine. If not, ask me in the questions or come and ask me afterwards and we'll talk through it. But I think pair programming is a really useful tool. But it's not something that you would traditionally call a code review, even though it is imparting all the things that we would do in a code review, it's just happening in that we have a real-time feedback attached to it. The other option is to do a code review when it's ready. So, we put it at the end and we sign it off. This is good code. Yay! And normally, whereas maybe when we were doing our iterative feedback loop, it would be more likely that any member of this team would be doing it. When it comes to the sign-off, it's probably going to be the person who's going to get shouted at, who's going to want to sign it off. And that review is normally a senior person. It might be subject specialists of some sort. And until they sign it off, nothing is going to happen. So, it's important to understand from their perspective what a code review should be. Because for this person, and this is probably the way the scenario most people think of as a generic code review, it's really important to understand at this point that the job of that reviewer is still to get code into production as quickly as possible, not to reject the code. And I've met too many reviewers who think it's important to nitpick the answers and send it back when your job as a reviewer is to get things into production. This caveat to that is it has to be good or work. Those are two separate things. And then the final phase is in the after and the postmortem. Hopefully not too many postmortems. Hopefully it's just permanently into production and everything is happy and rosy. This primary purpose is for knowledge sharing. This is where you come back and say, okay, we're going to look through the code, we're going to take what we can learn from this. And this is the time where the code review is generally positive or should be generally positive. You're not necessarily looking for the negatives because you know what the negatives were because we're at the postmortem stage. We know the bugs that failed and everything went wrong and it all burnt down. We can learn those lessons and learn them in production. So this is the phase where we go, oh, I know, I really like singletons. I don't know why, but I really like singletons. I like the way you implemented that. We should take that and that should become a standard across the board. I like the, you know, we as a company can learn these things out of this. We can share this information. We can share what went was good. We can share what's wrong as well in this stage, but it's primarily about sharing what is good. So if we've got the when's now under the who and who should do a code review and we've got gatekeeper, that is the senior member of staff who goes, I am very important and I push the button. You have passed and gone through. I deliberately use the term gatekeeping because immediately you're like, I don't like that person, but that's how most of our institutional setup is. You have the senior person who I am in charge. I will push it. It's a pro. If you've got lots of money on the line and your business is run on this, this is not a bad thing. It's not a terrible thing. And anybody who's been in that position will know that you have to do it this way sometimes. But without their sign off, we're back into this. We are not pushing code until they have signed off. We've got pair programming, which we mentioned before. That could be the colleague being a senior or a junior. It works really well if you pair different levels. Unless you're directly problem solving and you might want to have, say, two senior developers working because things are not going well. That is the standing over the shoulder look. I've got like, hey, shall we try this? Shall we try this? Shall we go for a coffee? Much better idea. And then everyone. By everyone, I mean literally everyone. And that can be not just be developers. That can be people who are coming from UX. It could be the design team. It could be people who are doing quality assurance. It can literally be your mum. Has anybody ever had their mum review their code? Oh, just me. OK. She's a very harsh lady. Oh, she was a very harsh lady. But everyone can get involved in a code review in one way or another. Ultimately, our technical stakeholders know when we make mistakes because somebody else tells them the email is down or the site is not working, et cetera. But anyone who has access to the code could theoretically be involved in some sort of code review. Can you have some of the specialists like me? I'm a WordPress security specialist. I do WordPress security code reviews. So I come along at any point inside your cycle and come along and say, ah, yes. Have you met these security helper functions? Yeah, OK. No, you haven't. We'll go and implement them here and here. But likewise you have accessibility specialists. You have legal specialists. You have people who are specialising in performance. They might come in and give their own reviews and they tend to come in at the end. So before the postmortem, but at the end of production or while it's in production, and come back with a list of bugs for you. And, you know, you're received like a lead balloon. Nobody likes it when you come back and say, by the way, you're now in production and everything's wrong. But having bring your specialists in early and going them through as part of your cycle all the way through is a really valuable thing. And having specialists looking at your code is really useful. I've separated out from everyone, junior developers, and I've already mentioned it once, but I want to mention it again. Your junior colleagues involved in the code review cycle from both sides, code reviews are much more about knowledge and education than they are about anything else. It's almost not about does it work, what bugs can we find, does it meet this standard, does it need this. It's about imparting knowledge across the board. We bring in our colleagues, we bring in people to look and do things because we want to learn, because we want to improve. And if we think about that for ourselves, then we immediately want that across the board. Otherwise we'd just do our own code reviews. Now, there are two types of people who do, if you do dry, you're doing your own code reviews. There's the type of person who says, I am brilliant. It's passed. And then there's the other person, the one who can't get out of bed this morning because they're crying because their code was so bad. It was the horribleest thing that they'd ever seen. It wasn't, of course, but we self-internalise and hate ourselves and say it's all roaring and it's all, and the harshest critic of those are all. And for those people, they need someone to come along and actually say, no, you did a good job. You might want to change this or this. For the person who says, I am amazing, well, you're never going to help them. You might as well just push it into production because clearly it's perfect code. So, where? I mean, we're now going to go into the gritty of what is the code review, where are we going to do code review, how are we going to do it. So, where? This one's a bit weird because I reckon this has changed dramatically in the last two, three years for some strange reason that I can't think of. But the first option is in person. And in many ways, having a really informal code review where you are either at the person's desk and you are staring at the screen with them and walking through it, that is probably really beneficial. And for a lot of people in the room, that's how you started doing development. If you work to the development agency as the junior who came in, this is how you learn, this is where you got that experience and we're sort of losing that now. Oops, backwards. You might take them off into a hustle into the small conference section. You might do a stand-up with no screens where you talk about, I've been there, it's weird. Imagine just being standing, literally standing up in a room with like six of you, talking about code you can't see. Had tried from memory having to remember what the thing was. It's a weird experience, but there are people that still do that. I mean, more likely now we're going to use online conferencing style tools, whether that's something like Zoom, whether that's Google Meet, etc. Slack, any way we can communicate. We can even use email and that gives us like threads and chains and stuff. There's also specific online tools aimed at doing code reviews and there's stuff like Dura and GitHub, issues for not going through. But also things like GitHub pull requests and then you have dedicated code review software. I find that if you have going to the dedicated code review software, some companies will insist that they use it. For me personally, I find that that's Stifon's communication and it makes it formalised in a way that doesn't necessarily work for everybody. But it does for some companies. This is a talk about the art of the code review. I used the word art very specifically. Often when we talk about computing and we talk about development, we don't necessarily talk about it being a creative thing. Code reviews are fairly creative. You need to have decisions, you need to be opinionated and you need to be able to express it well and communicate well on both sides as well. So the first thing to do with a code review is to automate. I'm not going to go and run across the screen. Yeah, automate, automate, automate. But if you can, any test, anything, any standard, any specification, anything we can do to automate will be better. I couldn't find a decent automation quote, so I made one up. But I believe this to be fairly true that if you can automate it and then the computing can do it faster, it's going to be more accurate than you and you can go outside and play or do more work whichever you prefer. So if we can automate as much as possible then we're left with the chunk that only we can do. And you can feel good about that and you have to do the things that can be automated. You should only be doing the things that you are good at. And we as humans are good at communicating and thinking outside of very structured things. And that's how we find and solve problems and bugs and things is because we can look and go we can take free jumps ahead to find out where we're going whereas computer system can't do that. A computer system can't ever completely do a code review. It can try but it can't yet I should probably say do a full code review. As a developer some things to keep very in mind if we're going through the iterative process keep your pieces that you want to be viewed as small as possible. Remember the goal is to get code into production. That is it. The code reviews are not a barrier to production. A code review is a blessing, a channel we're going to send to production and our goal is to get it there as quickly as possible. So if we keep up what we're reviewing small then it's going to get through quicker and out into the big wide world. Your reviewer, the person who's going to give you who's going to go, I almost said go and give you it's going to give your code a review do as much of the pre-work for them make sure that the automation tests are working make sure it's linted make sure it's going to do, it works if you're amazed people send code that doesn't work because they didn't test it don't be that person, test your code at least so you can say it works on my laptop and be open to like suggestions don't be afraid to say when the person comes back saying all of this is horrible and you've just done this wrong and you've done this and I don't like this but by the way you use tabs you don't be afraid to say you're wrong I won't use spaces or whatever it is that you're against it's okay to feedback and have a two-way conversation it should never be a one-way thing likewise if you're a reviewer be consistent so when you're doing reviews consistency is key if I keep changing my mind and keep moving the goalpost and keep deciding that hey this reviewer is about this now now all of a sudden we're about this if I keep changing what's going to be able to get through it's never going to work you need to leave any ego at the door that's a hard thing to do but you have to keep in your mind it's not about whether the code is even pretty it's not about if it does does it work, does it meet the specification yes then your job is done can I help them progress further with some bits that's a good addition can I beat on this person because I'm having a bad day or can I show them how wonderful I am because I would have done it ten times better you can't do that you need to leave it at the door you also need to be timely I know we all work in a really busy world but if you're not going to review that piece of code quickly it's sitting there and there's someone at the end of that who's sitting there now chances are they're on to another job that could be even worse because when you come back and when you have to start context switching it gets horribly messy very quickly but if you leave something just hanging there and hanging there and hanging there and hanging there it then gets dropped altogether or someone takes over and it just gets pushed through when you're providing feedback if your feedback cannot relate to an action that is going to be done it is not useful feedback if I cannot have if I sit there and say it's two and three paragraphs long we've all been there that you've got the reply back and it's massive a paragraph so you're going I'm not sure I see the question, the statement or even anything other than words it's of no use there's a direct analogy at conferences where at the end we ask questions and there's always that one person who will come to the microphone and then he starts talking and at the end of it the speaker is there going was there a question I think there might have been no there wasn't in the same way if we need to leave some sort of actionable feedback some feedback that they can take and do something with without that the review is pointless unless you're going to say it's blessed have a nice day but that is still an actionable feedback that is action that the code is going forward and above all as a reviewer your job, your number one job should be to be nice at least to use nice language we do not need to use horrible, nasty or negative language because language make it for man and it really really matters so there's few things that I've always when you hear when you're talking about language and one is don't take it personally there is that's the quickest way to make you go what do you mean don't take it personally what did I do and it immediately puts you on edge don't be that person whenever you're doing a review it's not about the person it's about the code don't be rude these are literally your friends your colleagues and more importantly next week the person is reviewing you just a thing as a Brit as a person who likes sarcasm and has a horrible tendency to use it myself don't use sarcasm in a code review especially in a larger team especially in a team that's an international team especially in a team where you are no longer directly person to person if you're going to use sarcasm and someone doesn't get it it's going to go horribly wrong never demand to ask questions and never say never because you're going to get find out you're going to be wrong and I want to leave you with one final thing and that is feedback is a loop and therefore every time that you say anything as a reviewer don't be surprised if the person coming back to you comes up with something better and gives you a better answer and tells you you are wrong if we can keep that loop going in a much better place everybody in this room does a code review every single day and everybody or everybody who writes code in this room does a code review every single day because if you're interacting with anybody else it doesn't have to be a formalised process but whatever you're doing be nice, be kind but make things very actionable so my name is Tim Lash I'm a WordPress security consultant if you want copies of the slides and there's extra resources like actually lists of tools and things bits you can go visit that QR code hey it worked, people are actually putting it up now the question is whether I actually published the page or not but if not go back to it later now you've got a picture of it, I did yay someone's put but what I'm going to do is put these slides up on there and put a bunch of other stuff on and thank you thank you thank you Tim so we have some time for questions just so you know there are two standing mics here where you can ask the questions so you can cue oh already either they're running away or they're asking questions I know he's asking the questions I'm used to this this is going to be a good question, I know Alex Alex so I think I've got two items I just need to find them so one question is if you ask everybody to do a review do you really want that and what if the review drifts off into like flame wars conversations you need to draw the line somewhere sorry so the question is how do you stop the as the person whose code is being submitted how do you stop the reviewer wandering off onto territories yeah you can kind of go too far by inviting everybody to review like too many opinions sometimes are counterproductive yes I think I wouldn't say that I would ever want a scenario where I had that it went out to review to everyone and I had to wait for feedback from everyone to come through when it's a one to one and the person is drifting off it's back to this oh no it's gone off the sky it's going back down to keeping this in a feedback loop having the confidence which is a really hard thing to do having a confidence to say no can we go back on to the subject certain reviewers will always behave in a certain way and the worst thing is if you didn't make it randomised if you did have it so that you could pick your reviewer certain people will always pick certain people and they will start because you know what they want what they're looking for so you'll go to them it's getting that balance because as you say you don't want the person who wanders off or worse wanders off for two weeks comes back with a half answer then changes the goalposts every five seconds and adds a bunch of stuff and the only way you can stop that is by feedback to them and saying please stop doing that which is a really hard thing to do this is normally where you hope you have some sort of management that will help you it doesn't always though so it's not a very helpful answer is it like well I think it it kind of is attached to my other question or like point is that you as the person who is requesting review you also need to do your homework and I think that's an important part especially about if you want to get timely reviews like as somebody who's also reviewing like doing the context switch and getting into your review what do I need to review how do you review so as a developer you can you actually have a really big part in how timely we'll get a review yes I mean I think we had the slide earlier talking about what developers can do and any pre-work you can do to make the reviewers life easier will lower that barrier to them coming in doing the review in a timely fashion as one of the ways of doing that is if you know the expectations upon what the review is going to be based then you should be able to already match to that this doesn't always work because code reviewers tend to have their own opinions on that same specification this is sort of why we do these in the first place though because if we if we could all manage to come up with exactly the same answers to the code review every time the code review if you had four people and they all retired with the same things you probably can automate that and it's no longer a code review with people and that's fine but yeah as a developer if you're writing code make it get making it small as the thing going to review make it as small as possible do as much work as you can ahead to make the reviewers life easier and don't be afraid to say hey have you had a chance to do that review now because I have to context switch and if I have to context switch this isn't going into production for the next two weeks that I think that's a perfectly valid thing to say to somebody on the other side be as a reviewer getting doing those reviews in a timely fashion is really important because otherwise you're holding up the system and I think quite a lot of reviewers think about the code review as extra burden and extra thing that they're doing and it's not it's part of your job you're there to do that review so it has to be factored in as well does that help yeah it's okay to re-request a review I think that's also an important point to make and I think it can be part of the culture of a project that you explicitly state that yeah I mean it helps I think if you're in a company especially if you're in a company rather than maybe in an open source environment we actually have really good contributor guidelines where we can talk about things like wow this is how we're going to review things it's weird actually most companies don't have exactly you'd think that they would have their own contributor type guidelines some do they have standard operating procedures but quite a lot done quite a lot are quite casual about how these things are done it might be good to have some sort of almost the contributor guidelines for the given project that you're working on which is separated from your standard operating procedures please next question hi and thanks for your speech it was brilliant experience I feel you need the microphone just lifted up for you I can hold it oh there we go hello how did so as I mentioned thanks for your speech it was really interesting you mentioned in your speech automatic reviews tools that you use for automatic reviews could you highlight some of them so I mean most of the so most when I talk about automated tools I'm talking about tools that we actually already probably is development for using for example if you've got a coding standard then having a code sniffer running before you go it should be running before you even start the code review process if you are if you have to set any form of testing those testing should be running you should be already using those things like unit test within code there are specialist code review software that will allow for creating a checklist that say have you done this have you done this and actually when you do like a pool request that you can create certain rules that say this must have been run this must have been run and I know I try to make talks agnostic of any individual software but if you're using something like github you already have the github actions that can be processed on a pool request a pool request is a form of a code review and we can have the github actions running and therefore you can have all those tests passing before we start the manual review in the process but I've got the page that I linked to earlier it's bare bones at the moment but I'll fill it with some software and bits in there for you as well thanks for that and I had another question but I forgot it so thanks in case you remember we will have time hello thank you for your presentation it was very interesting could you please tell us maybe a tool or something to ask colleagues to keep the pieces of code to be reviewed small because always getting those huge merge commits and how to fight them I mean if it's genuinely become a point where you need to have a tool to do it there's a wider conversation I mean you could automate that and actually have it come through just running a script on a pre-commit hook that says hey this is how many lines let's back are you sure you wish to send this to some poor soul but I think wow you can do that with code and you could come up with software to do that I think that's a process problem that's a change that's an expectation within a company that they're expecting to have larger bits and not smaller so I think it's more about talking to engineering managers or individual developers and say hey we need to do this in smaller chunks and that's a conversation to have rather than a formalised way I quite like the idea of having a pre-commit hook that just goes no you've written too much today goodbye thank you awesome awesome have you remembered the question? yes if you did and that is the last question okay so as we talk about tools have you tried any AI based tools on the and what are your feelings because I tried pair coding with chat, chibiti and it wasn't the best experience when you say who was doing the coding and who was doing the pairing obviously the future is clearly AI at the moment whether we like it or not if you went and looked at the sessions today you'd have thought we weren't at a WordPress conference just by the sheer amount of AI even content that's on the tracks you can make use of any tool an AI is just a tool I use chat, chibiti to write some code once it was fun and actually I do use chat, chibiti to write tests it's a really useful tool for writing acceptance tests because you can get it to write its tests and then you can get it to write some code and you can get it to test itself it's brilliant to have to be here at all I don't know why I'm a developer I need to be one anyway I've got an AI to do it for me ultimately though at the moment AI systems are not smart enough to be able to problem solve you've got to remember that in all of this they are incredibly clever or look incredibly clever but they are language processing models that are doing things in fact quite often they have no basis in logic they don't have imagination for all of its wishful thinking I know it appears to have imagination when it goes and says something that's completely random and off topic but it doesn't actually have the capabilities that you have as a developer and it doesn't have the capabilities to solve actually solve bugs and find things that you have so a useful set of tools but other than the standard dev tools things like co-pilot, codium on vs code and talking to things like barb and chat, chibiti I haven't seen anything specifically for code reviews it will be there it will be rubbish and it will tell you things like your code you should do this in your code and you'll look at it and go what? because that's the nature of how AI works at the moment 99% of the time it's good and the other 1% of the time it's what? OK thank you