AI is the future of coding

They say you always remember your first kiss. Well, I remember my first time using an IDE.

At first, I was using Notepad++, which worked fine. I wrote HTML, CSS, JavaScript, and a little PHP. The white background was jarring, but I got used to it.

It wasn’t until I noticed what my coworker was using to code that I doubted myself. He was using this fancy editor with a slick, all-black background and a nice UI, and I thought, “I need to learn how to use that.” It had so many cool plugins and features that I didn’t know existed.

This IDE was Sublime Text.

The only downside was that a single engineer developed it, and updates were slow to non-existent.

After a while, because of the lack of updates, I got the itch to try something new and stumbled upon VS Code. It was a breeze to pick up, mainly because you could set your keybindings to simulate Sublime Text’s keybindings.

I used it when coding Angular, React, and even VueJS. When doing the backend, I used backend-specific IDEs like PHPStorm or GoLand. And everything was fine, everything worked. Developers were happy.

Until the AI revolution started.

Introducing CoPilot

When OpenAI took the world by storm with ChatGPT, the narrative for programmers was straightforward. We were all doomed.

In partnership with GitHub, OpenAI and Microsoft released CoPilot, an AI-powered coding assistant that uses the same LLM that powers ChatGPT.

People were a little skeptical at first. Some companies were concerned about allowing LLM models access to proprietary code.

For me, it was nothing mind-blowing. It could autocomplete some basic code if you named the function correctly; you can ask it to write some unit tests for you in later versions, but mostly, it was lost when changing from file to file.

It was excellent in goLand, where the code syntax is very rigid, and the autocomplete was spot on. It improved my output 5x, but in VsCode, it was barely okay.

When they introduced the Chat feature, I wasn’t impressed. It was complicated to use, and the output was often plain wrong.

So, I continued using Copilot for the autocomplete and chatted with the AI using chatGPT or Claude in their respective apps.

Enter Cursor

Cursor is the fastest-growing SaaS in history. It went from 1 to 100 million dollars in ARR in just 12 months—faster than Wiz (18 months), Deel (20 months), and Ramp (24 months). And honestly, it’s not hard to see why.

When it came out, it marketed itself as the first AI-powered coding IDE. It was a fork of VS Code, already a great IDE, so it benefited from a great foundation. It also kept the same look and feel as VS Code, plus it allowed you to install all your VS Code extensions, so it was easy to pick up, solving the Cold Start Problem of having to customize it again.

But the real game changer for me was the integrated AI chat. By pressing cmd+L, you will open a side panel to chat with the AI.

At first glance, it looked like a normal AI Chat, but once it provided code suggestions, the interface changed to a simulation of how Git Merge Conflicts works.

You can see the changes, line by line, and accept or reject them.

It was a game-changer.

When I used Claude to provide code examples, I had to ask him for the entire code to copy and paste it. It was a pain to check where it made modifications and where it didn’t.

Another cool thing about the Chat is that I can copy and paste specific lines of code, which will add them to the chat context. Even more impressive is that I can do the same with the terminal and its output.

For example, I had it write me test cases for an entire file; it created the file and filled it with tests. First, only three passed out of 15; after copying the latest output, it could fix the tests and get 15/15.

But wait, there’s more.

Cursor Agent mode

The main benefit of Cursor is its ability to choose which AI model it uses. You can choose between 6 models and select whether you want a thinking model.

If it’s a thinking model, it will take some time to digest the requirements, create internal steps, and think about different solutions before suggesting code changes. It’s perfect when working on significant changes or complex tasks.

Cursor has three modes:

• Ask: Where you can ask any question about code, architecture, or design best practices. It might suggest improvements but won’t apply them to your project.
• Manual: Keep control of the context. Cursor would not be able to check the entire codebase, only what you give it.
• Agent aka Vibe coding. Please give it a task, context, or image, and sit back while Cursor changes your code to accommodate your request. You can then move between files and code suggestions and either accept them one by one or accept all the files. The Agent can also run terminal commands, create new files and folders, and wreak havoc on your codebase*.

• Please follow best coding practices and commit often to avoid losing yourself in vibe coding.

Cursor Rules

You want Cursor to follow best practices and your codebase coding style and not just write you the first solution it finds. At first, it used Tailwind CSS when I didn’t even have it installed in the project.

Additionally, our team has five Frontend Engineers and three other FullStack Engineers who contribute regularly to our codebase. As everyone uses Cursor (company mandate), we don’t want each Cursor IDE to write different code; therefore, we set up ground rules.

Cursor Rules are just .mdc files inside a .cursor folder in your project root. It’s extra prompting that tells the Agent how to code. In our project, we have:

• react.mdc
• test.mdc
• typescript.mdc
• style.mdc

Here is an example of rules in our style.mdc file:

# When writing SCSS

- Use CSS variables declared in the @index.css file for spacing, colors, and borders
- For typography, use SCSS mixins declared in @typography.scss; never write other font rules
- Use @utility.scss for helpful mixins like skeletons, sr-only mixins, and tablet screen mixins, which should always be used to write code for tablet and mobile version
- Always use BEM syntax without grandchildren when writing code.
- We are using Sass version 1.78, so ensure you are not nesting mixins between root properties. 

If you want, Cursor also has a directory of typical rules you can use at Cursor Rules Directory, where you can browse according to your programming language or needs.

But wait, there’s more! (Cursor MCP)

Meet the universal adapter for AI - Model Context Protocol (MCP)

Have you ever noticed how every software integration requires a custom solution? It’s like needing a different charger for each device. MCP solves this by creating a universal interface between AI and applications.

Your AI coding assistant can fetch data from databases, edit Figma designs, or control apps through natural language. No more context switching or learning different APIs - MCP acts as the translator between human language and software commands.

One AI can integrate with thousands of tools as long as they have an MCP interface. Instead of being locked in its own world, your AI can now reach out and “press buttons” in other applications.

Quick Setup

• Open Cursor Settings
• Navigate to Features
• Scroll to the MCP Servers section
• Click “Add New MCP Server”

Similarly, with rules, Cursor has a list of MCPs you can already add in its Cursor MCP Directory

Here are some of my favorite MCPs that I use and help me in my day-to-day life as a developer:

• Figma MCP to get access to Figma design files.
• JIRA MCP
• PostgreSQL MCP gives read-only access to Postgres DB.
• Github MCP
• Puppeteer MCP - Browser automation and web scraping
• Sentry MCP - Retrieving and analyzing issues from Sentry.io
• Sequential Thinking MCP - Dynamic and reflective problem-solving through thought sequences
• Slack MCP - Channel management and messaging capabilities

And here’s a typical workflow I usually use:

I use JIRA MCP to ask Cursor to get the three most recent bugs assigned to me, put them in Progress, and announce in #daily-updates in Slack that I am working on them.

Bugs have Sentry ID attached in the description, so we get more data from the Sentry MCP and try to replicate them using Puppeteer (Here, I also help by giving steps to reproduce, adding the correct files in the context, and more)

Once we identify a bug and how to reproduce it using Pupeteer, the Cursor Agent writes unit and e2e tests to ensure the bug does not happen anymore. It tries to fix the bug by running the test each time, seeing the output of Vitest and Pupeeter until the tests pass. With the issue resolved, the ticket will be marked as Ready for Testing and start to solve the next bug.

For more complex tasks, we connect to Figma to get the layout we need to build, start with some tests, and create the components. We use Storybook Visual testing to verify the image of the Figma File with the implementation.**

** Here, it rarely gets right it from the first try (or the tenth), but it does get the skeleton ready in a couple of seconds and saves up to 30 minutes of work

Conclusion

The future is here; we already have products like V0, Lovable, and Bolt that can build on their own React and NextJS projects from 0, while Cursor still struggles with this.

We have to embrace our new AI overloads and, like any craftsman, use the best tools that we have at our disposal. Our Jobs are not gone yet, but the age of the 10x developer is gone. Now, everybody is a 100x developer by using the right AI tools.

My recommendation is this: try it out. Step by step until you get comfortable using it daily, and never look back.

But be considerate, commit your code often, write tests first, and have strict rules in place so it follows your coding practice.

Before starting on a new feature, write a PRD (Product Requirements Document), give it access (using JIRA MCP), and break the feature into small testable steps.

Do not expect to give it two sentences, a Figma doc, and expect Pixel Perfect results; like before, building something great takes time, but now we spend more time guiding using English AI Agents than writing code ourselves.