Just to follow up on this: I asked it to give me a brief explanation on how to use laravel 11 blade fragments, which it did reasonably well.
I then offered 3 lines of code of a route I'm using in Laravel and I asked to tell me how to implement fragment usage where the parameter in the url determines the fragment returned.
Route::get('/vge-frags/{fragment}', function ($fragment) {
return view('vge-fragments');
});
It told me to make sure I have the right view created (which I did) and that was a good start. Then...
It recommended this?
Route::get('/vge-frags/{fragment}', function ($fragment) {
return fragment($fragment);
});
I immediately knew it was wrong (but somebody looking to learn might not know). So I had to ask it: "Wait, how does the code know which view to use"?
Then it gave me the right answer.
Route::get('/vge-frags/{fragment}', function ($fragment) {
return view('vge-fragments')->fragment($fragment);
});
I dunno. It's really easy to find edge cases with any of these models and you have to essentially question everything you receive. Other times it's very powerful and useful.
I mean, this is an unsolvable problem with chat interfaces, right?
If you use a plugin that is integrated with tooling that check generated code compiles / passes tests / whatever a lot of this kind of problem goes away.
Generally speaking these models are great at tiny self contained code fragments like what you posted.
It’s longer, more complex, logically difficult things with interconnected parts that they struggle with; mostly because the harder the task, the more constraints have to be simultaneously satisfied; and models don’t have the attention to fix things simultaneously, so it’s just endless fix one thing / break something else.
So… at least in my experience, yes, but honestly, for a trivial fragment like that most of the time is fine, especially for anything you can easily write a test for.
I then offered 3 lines of code of a route I'm using in Laravel and I asked to tell me how to implement fragment usage where the parameter in the url determines the fragment returned.
Route::get('/vge-frags/{fragment}', function ($fragment) { return view('vge-fragments'); });
It told me to make sure I have the right view created (which I did) and that was a good start. Then...
It recommended this?
Route::get('/vge-frags/{fragment}', function ($fragment) { return fragment($fragment); });
I immediately knew it was wrong (but somebody looking to learn might not know). So I had to ask it: "Wait, how does the code know which view to use"?
Then it gave me the right answer.
Route::get('/vge-frags/{fragment}', function ($fragment) { return view('vge-fragments')->fragment($fragment); });
I dunno. It's really easy to find edge cases with any of these models and you have to essentially question everything you receive. Other times it's very powerful and useful.