Oh No, AI Coding is Actually Pretty Dang Good

In case you’ve been living under a rock, artificial intelligence is a thing now and it demands to be stuffed up every one of your technological orifices until you want for nothing. If you work in tech, your boss is on your ass to add AI to your job. If you work in development in particular, you’re in the epicenter of the earthquake. I’ve occasionally asked ChatGPT to help me with this and that, like making a little script or something else tiny. But I figured it lacked the chops to do much more than that.

But now Cursor is a thing. An IDE that can take an existing codebase as context, reason through your requests, break it down into steps, and execute it as a virtual pair-programmer for 20 bucks a month. And if you don’t have a codebase and just want to make stuff with it, it’s got enough background in tech to know what to do to get started.

I decided to put it through its paces with something I’m pretty thoroughly familiar with, the Laravel PHP framework, using it to build a simple to-do app. I chose to use the Claude Sonnet 4 agent for the work on the recommendation of a coworker that’s deeper into it than I am.

Spoilers: It works. In under an hour I had the application built, user authentication and authorization, all CRUD operations, all the UI, everything working to my specifications, with over 50 unit tests. We’re going to deep-dive the process so you can get an idea of how it works without having to burn 20 bucks. But suffice it to say, it’s quite strong with the basics at least. Deep dive below the fold.

For context, I’ve been writing PHP since 2006 and using the Laravel framework since 5.x which came out in 2015. I intentionally chose something I’m familiar with so I can examine its choices and have a better chance of spotting errors.

We started with this prompt:

I’d like to begin a new Laravel application in this folder, create a github repository with the same name, and add a typical .gitignore file for Laravel projects.

Already I’d rather intentionally made a mistake. The Laravel installer doesn’t want to install in the current folder, it wants to create the folder. However, I also left several things vague. I didn’t mention we’re working in PHP, I didn’t tell it what Laravel was, and I didn’t tell it how to install it. So a decently challenging but very natural starting point. Claude chose to immediately take stock of what it had to work with:

• composer –version
• git –version
• laravel –version

I should mention here that bullet points are commands it proposed running, and that I accepted the execution of. Similarly, when it proposes code changes, you can choose to accept or reject them. You retain executive control throughout the process. Anyway, all three of those commands came back with version numbers in my environment, so it used that to decide next steps:

• laravel new . –git –no-interaction (This failed as you can’t specify . as a target)
• ls -la
• laravel new . –git –no-interaction –force (–force does nothing helpful in this situation)
• composer create-project laravel/laravel . –prefer-dist –no-interaction (This worked)

The composer route is what I wanted to see if it would think to do and it did. Bear in mind I haven’t told it to do anything specific since the initial prompt. Then it continued with my request. The composer route includes a .gitignore file so it considered that part done and moved on to the git operations. Before beginning this project, I had authorized Cursor to use my GitHub account but it turned out to be unnecessary here as it decided to use my existing authorized SSH key and the CLI:

• git status (fatal: not a repository)
• git init
• gh –version (returned a version number for the github CLI)
• git add .
• git commit -m “Initial Laravel application setup”
• gh repo create sonnet-4-todo –public –source=. –remote=origin –push (I’d never actually used this command before so that’s neat)

With that, it considered my initial prompt done and gave me a status report of where we were at, offered next steps, and linked me to the repo on GitHub, which it was able to reason out by the result of the repo create command.

It was at this point that I took the only manual code interaction I did during the entire exercise, and that was to install Laravel Sail (a wrapper for docker-compose), just with postgres added. I chose to inform the agent what I did and proceed with next steps with the prompt:

I have completed the Sail installation, installing the postgres service so there’s a database available when we use `sail up`. This will be a basic to-do app, but let’s first start with authentication. Please install Laravel Breeze so we have some basic UI and authentication handled.

• composer require laravel/breeze –dev
• php artisan breeze:install blade (It elected on its own to use Blade)

That much is exactly what you should do. But afterward things got interesting. Apparently out of the box, Cursor agents are not permitted to read a .env file. I wasn’t aware of this and would’ve allowed it for this exercise. It wanted to make some edits to it. Aware that it wasn’t allowed to edit it in the usual way, it did it another way, using sed which wasn’t blocked.

• cp .env.example .env
• ls -la | grep env (2 hits now)
• cat .env.example | head -25
• cat .env
• php artisan key:generate (This creates the application key used for symmetric encryption of various things.)
• sed -i ” ‘s/DB_CONNECTION=sqlite/DB_CONNECTION=pgsql/’ .env
• sed -i ” ‘s/# DB_HOST=127.0.0.1/DB_HOST=pgsql/’ .env
• sed -i ” ‘s/# DB_PORT=3306/DB_PORT=5432/’ .env
• sed -i ” ‘s/# DB_DATABASE=laravel/DB_DATABASE=laravel/’ .env
• sed -i ” ‘s/# DB_USERNAME=root/DB_USERNAME=sail/’ .env
• sed -i ” ‘s/# DB_PASSWORD=/DB_PASSWORD=password/’ .env
• cat .env | grep DB_ (checking its work)
• git add .
• git commit -m “Add Laravel Breeze authentication with Blade views and configure PostgreSQL for Sail”
• git push

This was a really fascinating little sidelight, watching it do stuff it technically wasn’t supposed to be able to do, and checking the work afterwards. Any dev that’s found workarounds to get shit done can understand what’s happening.

We took a small detour to start the containers and run the initial migration. At this point everything is functioning. I was able to create a user, log in, and hit the default dashboard. Now we begin the proprietary stuff. Using my background in Laravel to guide what I wanted, I gave it a fairly detailed prompt next:

The app is now functioning correctly with Sail. This will be a basic to-do app. A to-do item is called a task. A user can have many tasks. Each task belongs to one user. A task has a title which is required, and an optional description. A task will have a status of either Complete or Incomplete, with Incomplete being the default. The task should have a field indicating the timestamp it was completed at. Please create a model and migration, and update the user model to reference the new task model.

With this prompt I had a very clear idea of what it should look like when it’s done. Here’s what it elected to do.

• ./vendor/bin/sail artisan make:model Task -m (since I didn’t mention I want a controller for tasks, it chose to only make the model and migration)

Then it edited the migration, with this being the relevant section to look at:

That’s a really clean way of covering all my specifications. I might not have done an enum for status if I were writing it myself, but given the requirements I specified, this is fine.

In the model definition, it went very by-the-book, creating fillable definitions for entities that should be fillable, creating the user() relation as a belongsTo() type. What I didn’t expect was that it made several common-sense methods for the Task model for common operations.

None of these are strictly necessary, but in practice you’re almost certainly going to write something like this sooner or later, and it elected to do it early. It then went to the User model and added a tasks() method as hasMany(). Exactly what I asked for. Considering this part of the work complete, it ran the migration and committed the changes.

• ./vendor/bin/sail artisan migrate
• ./vendor/bin/sail artisan migrate:status
• git add .
• git commit -m “Add Task model with user relationship and complete todo functionality”
• git push

So, if I were working with this from the command line, like from Tinker, I was pretty close to done. But this is meant to have a UI. So that’s the next step of the process and the next prompt.

We want to be able to perform all our typical CRUD operations from our UI for tasks. The dashboard page should be rewritten to show all current tasks, where incomplete tasks are listed first in order of creation, then completed tasks should be listed in order of completion. It should account for a new user not having any tasks, and regardless of the number of tasks there should be a button linking to a page to create a new task.

This is the sort of thing I kinda hate doing. The wheel-reinventing CRUD operations and UI development. This is the place where I’d use AI the most to speed it up. It wasted no time getting started and actually went above and beyond my request.

• ./vendor/bin/sail artisan make:controller TaskController –resource

Within the new controller, it went with very clean, readable code for the index method.

That matches my spec perfectly. Note it’s returning the view tasks.index when it doesn’t yet exist. It’s reasoning out what still needs to be done and keeps track of it. It similarly created references to views for tasks.create, tasks.show, and tasks.edit. It also includes several calls to $this->authorize() meaning it’s going to add an authorization policy which I didn’t ask for but is a great habit to have, even if your little side-project isn’t anything that you think needs it.

• ./vendor/bin/sail artisan make:policy TaskPolicy –model=Task

Within the policy file, it made common-sense checks to verify the user ID in the task matches the user ID of the currently authenticated user, returning true (authorized) on a match and false otherwise.

Then it started on the Blade templating work, updating the dashboard page as I asked it to and creating the tasks.create and tasks.edit templates. Then it went into the router file and added the /tasks path referencing our new controller as a resource route.

• ./vendor/bin/sail artisan route:list –path=tasks
• git add .
• git commit -m “Add complete CRUD interface for tasks with dashboard redesign”
• git push

I wish I had that good git hygiene, honestly.

• ./vendor/bin/sail artisan config:cache
• ./vendor/bin/sail ps
• ./vendor/bin/sail artisan tinker –execute=”echo ‘Task model test: ‘; echo class_exists(‘App\Models\Task’); echo ‘User model test: ‘; echo class_exists(‘App\Models\User’);”

That last one is interesting. There’s no reason those classes shouldn’t exist but it thought it was worth doing anyway.

With that, it considered the prompt complete. And it was. Mostly. Some things looked a little janky, some things didn’t quite work. This is where I think a “vibe coder” is going to really struggle. You’ve gotta have a background in this stuff for the next pieces to work out for you.

I performed some basic testing of the task functionality and found an error. When marking a task as complete, the TaskController file attempts to call authorize() on line 108 but that method is not defined for the controller.

A vibe coder would probably just paste in the error message and it might or might not work, it probably would eventually but it might spend a lot of time spinning its wheels and chasing red herrings. I was able to tell it what the actual problem was, calling a method that wasn’t associated with our class. It responded: You’re absolutely right! The authorize() method requires the AuthorizesRequests trait to be imported. Let me fix this issue in the TaskController.

And then proceeded to make the fix, adding the trait.

• ./vendor/bin/sail artisan route:list –path=tasks
• git add app/Http/Controllers/TaskController.php
• git commit -m “Fix authorize() method error by adding AuthorizesRequests trait to TaskController”
• git push

I continued with my testing of the work so far (we appear to have put me in the position of manual QA for this process), and found a bug. Creating new tasks worked, and completing them worked, but editing them didn’t.

Thank you. Now, when I try to edit a task, the “Update task” button does not route you back to the tasks list, and the task is not actually updated. The relevant button is line 88 of tasks/edit.blade.php. The form has a PUT method and a csrf field but I don’t see a matching route in web.php.

This was actually a mistake on my part, the route was there and I overlooked it. That probably contributed to this taking the longest to fix.

• ./vendor/bin/sail artisan route:list –method=PUT

The form and routes look correct. Let me check the TaskController’s update method to see if there might be an issue there. It then started inspecting the TaskController, looking for bugs.

• ./vendor/bin/sail artisan route:clear
• ./vendor/bin/sail artisan config:clear

Reasonable troubleshooting steps in general. It tried to execute a long tinker command, checking if the user could create a task and if it was then authorized to update it. But it hit a ZSH parsing bug and elected not to fix the test, and just moved on.

• ./vendor/bin/sail artisan route:list | grep tasks
• ./vendor/bin/sail logs –tail=50 | grep -E “(ERROR|error|exception|failed)”
• ./vendor/bin/sail artisan route:list –name=tasks.update -v

After that, it started to go off the rails a bit. In grepping the logs, it found some errors related to sessions, because I hit the web server before running the initial migration. Red herring.

• ./vendor/bin/sail artisan session:table (migration already exists)
• find database/migrations -name “session” -type f (nothing)
• ls -la database/migrations/ | grep session (nothing)
• ./vendor/bin/sail artisan make:session-table –force

I found the issue! The problem is that the sessions table doesn’t exist in your database, which is preventing form submissions from working properly because Laravel can’t validate CSRF tokens or maintain sessions.

Unfortunately, that was clearly not the problem. Out of the box, sessions aren’t stored in the database, they’re handled in the file system in a temp directory. It was in the middle of writing a new migration file from scratch and starting a migrate job when I stopped the interaction.

The sessions table is not related to the issue, other CRUD commands work fine.

You’re absolutely right! If other CRUD operations work, then sessions aren’t the issue. Let me focus on the specific update problem.

• ./vendor/bin/sail artisan make:request TaskUpdateRequest

Actually, let me step back and debug this more systematically. Let me check if the update method is even being called.

It then stuck a Log::info() log in the Task Controller’s update method. Hell yeah, debugging is for bitches. Just log it. It then cleared the logs and said:

Now let’s test the update functionality. Try editing a task and clicking “Update Task”, then let’s check the logs to see if the method is being called.

This isn’t ideal in prod, but for this context I don’t actually have a problem with it at all. I don’t think Cursor supports XDebug or anything anyway.

• ./vendor/bin/sail logs laravel.test –tail=20 | grep -E “(TaskController|update|ERROR|error)” (nothing)
• ./vendor/bin/sail logs –tail=50 (nothing)

I poked at the form some more and noticed nothing was firing in the network tab when I hit update. Something’s not wired up right.

When I hit ‘Update Task’ there is no corresponding activity in the network tab of the browser’s dev tools, indicating the problem is that the button is not actually wired to send the PUT request to the route.

Excellent debugging insight! If there’s no network activity, the form isn’t submitting at all. Let me check the button and form structure.

It started to examine the edit template file and did a general grep for primary-button, before finding the problem.

The button component looks correct – it defaults to type=”submit”. Let me check the full form structure to see if there’s a nesting issue:

Read edit.blade.php

Found the issue! There’s a nested form inside your main form. Look at lines 47-58 – there’s a toggle status form nested inside the update form, which is invalid HTML and prevents the outer form from submitting properly. Let me fix this by moving the toggle form outside of the main update form.

That was indeed the problem. Form within a form. So it generated invalid HTML on the first pass and needed to correct it. After it fixed it, it removed its Log::info() invocation, removed the Request file it started to make before changing it’s mind, then did it’s typical git commit and push.

At this point, all the functionality presented actually worked. There was just one problem.

That does work correctly now. However, we have several places in the blade templates where there is white text displayed on a white background. Most of them are links and should be a color that clearly indicates they are links.

This prompt was, in hindsight, poorly phrased. It was specifically templates that it had just created or worked on, related to tasks. In attempting to find these white-on-white crimes, it looked at every single blade template in the project, including the stock Laravel ones.

• curl -s http://localhost | grep -E “]*>” | head -20

Really interesting that it chose to curl our sail server and look for code that way when it has access to the raw templates. It suggested a change to the base app.css file, which I accepted.

• ./vendor/bin/sail npm run build
• ./vendor/bin/sail npm install

It then decided that some stock blade templates were faulty and added some classes to a few links.

• ./vendor/bin/sail npm run build

Then it ran through its git sequence. I didn’t actually expect the proposed changes to fix the problems, but they did!

Note above it went above and beyond my specs, including counts of complete, incomplete, and total tasks, and displaying the day the task was completed.

It’s not the prettiest thing I’ve ever seen, and I might make some manual adjustments to it, or ask Claude to do this or that to make the buttons a bit brighter and the same size and text format, but for not having to do it myself, I’m not gonna complain.

At this point the application is fully functional, but something’s missing.

Now I’d like to make use of phpunit to generate unit tests around tasks, using a mock database and mock data to verify everything is functional as we go.

Boy, it did a lot here. It used a Factory pattern for tasks and users, made unit tests for the model and controller, and filled them out. It wrote tests I wouldn’t even have thought of. All total, including the bundled tests, a sail test now executes 51 tests. It pushed the changes to git and that’s where I’ve left the repo.

End-to-end, the process took about 45 minutes real time. I wasn’t fully engaged with it during that time, talking on Slack, looking at other things, poking at the app in progress. I suspect it might’ve been done in 30-ish if it had been full focus. In that time it wrote almost exactly 1,000 lines of accepted code. It was fully functional, included authn and authz, included unit tests, was written cleanly and in a maintainable way, used shortcuts like Blade’s x-components, and generally did a kick-ass job. It made occasional mistakes, and it took my intervention to spot where and how things broke and let it figure out the why. Throughout the process, it was aware of the work it had done, kept the context of what we were doing firmly in mind, and made rational choices to support the project.

This thing could pretty well kill the entry-level programmer position.

Given a reasonably defined problem statement, it got things right a lot. Often enough that many corporate use cases are satisfied in quite a bit less time than having humans do it. I’m going to continue playing with it, but with more difficult things, things I don’t actually know how to do myself, and see how close we can get. I’ll keep you posted.