My laraveldaily-structure-audit AI Skill: Review of the AI Code Review

Hello guys. In this video, I will show you how to add AI skill to your Laravel repository based on my own example, Laravel daily structure audit AI skill, which I added to the updated course about Laravel 13 structure of the project. And it actually became a new tradition whenever I update the course, I'm trying to add a bonus AI skill which would do something like this. And I will show you that in action in Cloud Code and Codex. Based on that, you would be able to create your own AI skills if you want or use my own and by the way, there's a 40% off yearly or lifetime membership this week for premium membership of Laravel daily. But also, this video is not about AI skill only. I'll actually show the report result and we will go through those findings and discuss various Laravel structure cases. For those of you who are following this channel for quite a while, you remember my series of junior code reviews. So, in this case, it's AI code review of ironically AI generated code. But in the same fashion as humans, we will look at the code and see the actual structure problems or potential refactorings. So, this is my Laravel project vibe coded by the way by Cloud Code a month ago roughly and I decided to run the structure audit on that vibe coded code. That was one of my AI coding experiments and in the skills, you see some skills from official Laravel provided by Laravel Boost like recent Laravel best practices, which are reviewed recently on my channel. If you haven't watched that video, I will link that in the description below. But here we go, Laravel daily structure audit. This skill is just skill MD file with some minimal structure on top. The name of the skill and the description when it should be called by AI prompt. So, this description is important. This defines when that skill would be called even if you don't prompt for that directly. So, keywords here. But in case of Cloud Code, we can run that skill automatically. And then a lot of checks what to check for based on my course, I decided to kind of package the course into that skill with a dozen of checks with small details, a few hundred lines of code. And you put that if you want to use that only in that project in that project.cloud/skills and then the folder with skill MD file. Similar for Codex, it's just using .agents folder, but then inside, everything is the same. Skills, then folder and then skill MD. Now, let me show you what those skills actually do. And before that, let's check the usage and I will show you how much it cost in terms of tokens. So, current session 4% used for Cloud Code. And here I have Codex opened in another terminal and current status is 95% left of current limit. And we will check both after the audit is done. So, in Cloud Code, you can use those skills as just / commands. So, I can type in Laravel daily structure audit or just structure and then choose it from the list. And I just hit enter and it will audit all of my code. In Codex, it's a bit different. So, in Codex, if you run / it will not find that skill and if you even run skills, the skills list the skills globally from your user folder and not the project folder. So, to enable the skill, you just need to type or ask for it, which I will do in my whisper flow with dictation. Review that project code using the skill Laravel daily-structure-audit. And my whisper flow wasn't fully correct. That's Laravel daily like this. And let's let it run. And meanwhile, Cloud Code is using sub-agents to explore. And yeah, they are both on their way and I will wait for them to finish and see what they find. In my previous experiments, such skill takes like 5 minutes or less. But of course, it depends on the size of the project. This was pretty small, relatively small demo project. But you may see here what is searching for and also with sub-agents, Cloud Code optimizes the run to have separate context and check separate things in parallel. So, the result of Cloud Code for that reason may be faster. And as you can see, each of sub-agents have their own tokens and their own tool uses. So, we're waiting for last one. And it's done in roughly 3 minutes. And now we will have the report summary. And meanwhile, in fact, Codex is also done with the review. So, it wasn't slower at all. It's roughly the same pace or actually, I launched Codex later. So, Codex is actually faster, but we'll see how much it found, both of them. So, let's start with Cloud Code. It cooked for 3 minutes and 48 seconds in total and let's see what it found. 21 findings across nine categories and by category. This is the audit of structure, remember? And personally, for structure, I do prefer form requests whenever possible. So, in controllers, all controllers do use form request, but for Livewire component, in Livewire, you cannot directly use form request, but the audit suggests to have validate attributes or form object for validation. All of those audit findings are just recommendations because in Laravel, as you may know, you can structure project almost however you want. And I even have the cap to answer all of the questions like should I structure this or that? It depends and it's always a personal preference or preference of your team. So, this audit is just suggestions. Next, we have export dashboard controller, which was flagged as kind of fat too long. Let's take a look at that. Okay, so this is the controller with invocable method with variables in blade. I wouldn't say it's fat, so I would say it's a false positive. But that's why probably the severity is low. And another similar finding for another controller, export profile page controller, which looks like this. So, it's not a fat controller. Maybe I should tweak that AI skill a bit. It actually says that controllers are generally lean. So, it's not flagging the length of the controller, but rather the logic. So, business logic in controllers, sometimes it's fine, but generally, it's better to have that logic somewhere else in services or actions or something like that instead of longer controller. In this case, like 30 lines of code or 50 lines of code, it's not a big deal, especially since it's not reusable and probably logical only for that controller. But again, this is a general recommendation, so you would maybe even think about some things in your other projects for the future. Let's move on with other findings. So, medium status strings in Filament in this case. So, this is another thing that this structure audit would try to find is candidates for enums like this. This is, I think, a good candidate for subscription status enum for refactoring. And a few more candidates, but actually not that strong and this is why this is severity medium because it's probably going to be reused in multiple places. And since it's about payments, it's more crucial to have no errors here. For these enums, it's kind of low priority, low severity. But also, that structure audit emphasizes good things in your code base. So, project already uses some enums well. Next, duplicate logic across controllers. So, in multiple controllers, this code is present resolving the expert ID from slug, the parameter. So, one controller is this in invoking the very beginning from slug parameter from the URL in this case. Booking page controller also identical slug to expert ID. And in the review controller, it's happening in the method, which is actually reused in create slug and then store slug as well. So, that's why it's a separate method, but also uses the same string slug to expert ID. So, the suggestion for reusable code is extraction to a function, for example, in the user model. Also, similar thing for the same controllers is identical URL validation. So, same logic. And then another duplicated method in two controllers and then that service already exists and this is actually the suggestion where to move that to. Then a few things, a few checks that are not applicable or no issues. Then route model binding, which could be used. And again, we see string after last expert ID from slug. So, maybe route model binding could be used here instead of some helper. Of course, for some custom route model binding, you should use something like get route key name or something totally custom with route bind. This is again a suggestion if you're a fan of route model binding by default. Then also, I'm a big fan of policies in Laravel. So, whenever I see abort unless or abort if with 403 in controllers, I don't know. It looks okay and it works and it's also a personal preference, but if you can offload that logic to policy, I think, for example, a new developer comes to the team and if there's one place for all the authorizations in the policies, for example, that new developer would know where to look for. Especially if the logic for that authorization check is the same. So, this is not just about not using policies, but about repeating logic that could be offloaded to some gate policy or even middleware because it's identical everywhere. Again, this thing called three times. So, the suggestion is to use policy. Also interesting, another example, this is validation for slug and it uses abort unless, but this is not actually authorization. This is URL check and you should return 404 if it's not found. So, this is not a policy candidate. This is kind of additional information. So, if you try to refactor abort unless to policies, you can find abort unless here and you may think that it's also a policy thing, but no. In this case, it's 404, not 403. So, this is not a policy candidate. The next thing, route file organization is cool. So, not a big routes web, so it doesn't make sense to refactor anything. And then business logic in blade templates, this is kind of debatable recently because with livewire and with other kind of non-strictly MVC patterns, I'm not that strict on PHP block in blade. I used to hate it a lot, but sometimes it makes sense because it's the structure only for that blade file, not really reusable anywhere. That's why the severity for those is low, but let me show it. So, here PHP on top, resources views expert show, and I would hate it in 2024 or something, but after I saw livewire 4 with single file components, I saw that quite a lot of people prefer the logic in blade in one file, so to not switch between controller and blade for checking the logic in a few files. I'm not sure, but again, that structure audit would flag those things. And a few more things that Cloud Code found. So, the model booted is kind of too big. I'm using Zap package for scheduling. So, if we take a look at the model, this booted with static creating, saved, and deleted, it is flagged as kind of scattered. So, it's a candidate to have observer with separate methods, but I would call it false positive and severity is low. I'm pretty fine for that to be in booted method in this case. And also structure audit is flagging for over-engineering. Nothing found. In fact, the opposite, it's under-extraction in a few places. So, for example, DB transaction with 54 lines is a candidate to separate in separate services or actions. And I'm pretty sure that Cloud Code is right here. Let's take a look. So, lines from 134, this one. DB transaction with quite a big logic here inside. Yep, that could be a candidate to some service called or something like that. But also, it's your personal preference where to extract to. Even Cloud Code says service/action or in another use case, render method could be extracted to query scope or builder class. So, this is that example, render method of livewire component. So, this thing probably could be eloquent scope. I'm not actually sure because it's probably already using scopes and queries here. I'm pretty fine with this in livewire component, to be honest. Because again, with Laravel structure and general with code structure, it's always a question whether it makes sense to have it all in one piece, in one file, readable at once or separated via different layers to be reusable in other files or other structures. So, you need to click around here and there in your IDE and navigate to see the scope or other methods what's inside. Now, let's take a look at Codex review, what it found. And in case of Codex, we have only five findings, so it didn't provide the structure. I will actually even ask it, "Did you use skill Laravel daily structure audit?" And yes, it's confirming that it used the skill. It's just that the presentation of that findings list is in Codex way, not by category like Cloud Code did. Anyway, findings, public expert resolution is duplicated. The same thing, extract when it appears three times. This is kind of the rule, but it doesn't actually show the code. It's just showing the links to that slug to ID. Also, same thing flagged, booking flow concentrated in one large livewire component. This is the same finding that we just discussed with Cloud Code with big database transaction piece of code. Another finding is related to using policies as well. This is workable now, but again, centralized logic in policies is better. And interestingly, Codex flagged those two as high and then medium, are using policies. Also, using route model binding is another suggestion. And low suggestion, presentation of views contain transformation logic. So, again, logic in blade is kind of a flag for refactoring. And also interestingly, how Codex presents the information. So, this sentence, "I did not flag those because they are in good shape." So, Cloud Code is more verbose to have the list of this is good, this is good, this is good, and Codex just summarized it to one sentence at the end. And brief positives also are one sentence at the end. So, yeah, this is the result of such audit. To have that audit, it's a pretty again, pretty big skill. Let me open that again from Cloud Skills. So, this is how you define the skill and then this is kind of free-form markdown, so you can place whatever you want here in the text. So, points to check for, what to flag, and what to suggest, stuff like that. So, this is my personal list that I used in the course of Laravel daily here, but also in other projects that I'm creating in 2026. And finally, I checked the usage, how much it used in terms of tokens. So, on Cloud Code, it's from 4% to 8% used of my current session, and I'm on $100 max plan on Cloud Code Anthropic. And for Codex, it's 91% left from 95%. So, it's also 4% of current session of 5-hour limit. I would say it's reasonable for pretty detailed review. So, what do you guys think about my structure audit and about the things that I pointed out or AI pointed out in this video with my comment, we can discuss all of that in the comments below. And again, a reminder, this week there's 40% off yearly or lifetime membership, which include the courses with AI skills. So, Laravel daily structure audit, API audit, queues audit, eloquent audit, and whatever I find in the future to be useful. That's it for this time, and see you guys in other videos.