Vibe Coding with Cursor

I work at a company that is truly invested into AI and LLMs, to the point that we can internally use (following some guidelines) quite a few tools in our day-to-day work: in particular, we have Gemini, Google NotebookLM, and Cursor available to all employees.

This is how I discovered the latter, precisely, and after using it for a few internal assignments, I decided to get myself a subscription to Cursor for my personal use.

In essence, Cursor looks like (well, actually is) Visual Studio Code with an AI sitting next to it. Of course, the full Copilot experience on the standard VSCode is quite similar.

The first thing I built with it was something I was missing: a replacement for Doodle for my personal use, a classic Swiss Web 2.0 tool that has become bloated with ads throughout the years.

And then the initial prompt went something like this:

Create a PHP application, using a MySQL database as storage, that provides a UI to schedule meetings. These are the specifications:

• A meeting has a mandatory title, an optional description, an optional location, and one or many proposed (mandatory at least one) start and end times. Each of these start and end times define a “slot”. It also has a unique slug, generated by the system upon saving, to be used in a URL to be shared with friends or potential attendees.
• This application has 3 major user interfaces or UIs.
• UI number 1 allows the creator of a meeting to enter title, description, and, select one or many dates and times on a calendar for the next 2 weeks, and store this data on the database. This UI is private and accessible using username and password. The default username and password should be “admin”.
• Upon saving, the slug is autogenerated, and used in a publicly viewable URL to be shared with friends or potential attendees.
• Friends and attendees use UI number 2, which is public, where they can indicate their preferred slot. They can see all the options and conveniently select one or many. Each selection counts as a vote.
• Meeting creators can access UI number 3, private this time, where they can see the results of the poll, and then finally select the definitive date. This creates an appointment in the database.
• Upon selection of a definitive date, everyone receives an email with the information of the appointment, including a calendar invitation in ICS format, so that they can store that in whichever calendar they use.
• The 3 UIs described above should be mobile-friendly, that is, use adaptive layouts for smaller screens.
• The application should work on basic, cheap web hosts that offer PHP and MySQL.
• The application should work with PHP 8.3 as a minimum. Use features of PHP 8.3 as needed. Use OOP features as needed.
• Try to keep the number of dependencies of the PHP app to the minimum. If possible, no other installation should be needed other than just copying the files on the server using SFTP, and then executing a SQL file to create the required database tables.
• Mails should be sent using standard PHP features, and configurable by the client, for example with an SMTP setting somewhere.
• Client UIs should use server-side rendering, no need for fancy client-side rendering of any kind.

Upon this request, Cursor starting playing with itself for about 10 minutes, and I was mostly impressed when I ended up trying the application locally and… it just worked.

I want to be very clear about this: the code generated was more than acceptable, and it ran on first try. Was it perfect? No, but it got the job done, it looked decent, and it did what it had asked it to do.

After a few more iterations, I got Cursor to add (and change) functionality, step by step, just by specifying it in a prompt, letting it do its thing, and then testing whether it worked or not:

• Two-Factor Authentication (2FA) including the generation of a QR code and backup values.
• Support for various users (the first version only supported a single admin user).
• Unit testing using PHPUnit. At the time of this writing, the project has 110 tests with 411 assertions, spread across 8 files.
• Support for templates using Twig; my first request explicitly stated not use any, but the truth is that it wasn’t a good idea, and the code is a bit more modular with Twig.
• Email logging, to keep track of what was sent to whom and when.
• Logging with Monolog.
• Perform a series of full reviews of the source code to apply security best practices all over the place.
• Added support for light and dark themes, switching automatically depending on the settings of the user.
• A calendar view to select chosen dates (shown in one of the screenshots below), coupled with a list view that is easier to use on mobile devices.
• Add code documentation to each class and method.
• Add a very comprehensive (and emoji-filled) README file at the top of the project.
• And a Dockerfile based on FrankenPHP.

The biggest issue, the one that took the longest to fix, was a major bug related to timezone issues (of course!) because some of the code was built with GMT times, while the ICS files in the first iteration lacked any kind of timezone information, and well, for a meeting scheduler… well, this is kind of a big deal.

Here’s a pro tip: sometimes Cursor would get stuck doing and undoing the same wrong thing again and again. At that point I would reset the current project with a nice git checkout -- . and then I’d just start a new chat, with a slightly more precise prompt. This helped every time. It’s as if chats start cumulating cruft after a few interactions, and then it would just become pure garbage. So, remember: use Git to commit your changes and to be able to roll back any hallucination, and then rephrase your previous prompt.

All in all, I must have spent around 10 hours prompting my way around in Cursor to create this, and you can see and clone its source code in my GitLab account. It is already in production, and I’ve already used it to schedule some meeting with friends!