Skip to content
← All writing

The AI Dev Stack with Cursor

Cursor Saudi — Mozn Office, Riyadh Event recap
On this page

I gave this talk at the Mozn office in Riyadh in January 2026. It was the longest one I’ve done for the community — around eighty slides — and the argument underneath all of it is short enough to say in one sentence: stop asking which AI tool is best, and start asking which one you reach for at which point.

The problem is that there are too many

Here is a partial list of tools that could reasonably claim to help you write code, as of early 2026: ChatGPT, Claude, Gemini, Perplexity, Cursor, Copilot, Windsurf, Replit, v0, Lovable, Cline, Codex, Claude Code, Devin, Bolt, Tabnine, Codeium, Aider, Continue, Base44, Antigravity, Gemini CLI.

That list is exhausting on purpose. Even Andrej Karpathy — who coined “vibe coding” in the first place — has said he finds the pace of change overwhelming. If he does, you’re allowed to.

The way out isn’t to evaluate twenty-two tools. It’s to notice they fall into four groups, and that the groups do genuinely different jobs.

The mental model — four categories, four jobs
01 Chatbots ChatGPT, Claude, Gemini, Perplexity. Research and ideation, before you write anything.
02 App builders Replit, Lovable, v0. Nothing to running prototype, fast.
03 Terminal agents Codex, Claude Code, Gemini CLI. Autonomous, batch, CI-shaped work.
04 IDE assistants Cursor, Windsurf, Cline. The daily driver, with real codebase context.
Pick one from each row and learn it properly. That beats sampling all twenty-two.

Once the categories are clear, the choice inside each one is mostly taste and budget. Chatbots differ on context window and how much they hallucinate. App builders differ on whether you want a beautiful UI (Lovable), a deployed full-stack app (Replit), or React components that match your design system (v0). Terminal agents differ on how much rope they give themselves. IDE assistants differ less than you’d think — pick one, get good at it.

Four terms worth actually understanding

Most confusion about these tools is really confusion about four ideas underneath them.

Tokens are the units a model reads and writes — roughly four characters each. "Hello world" is two. function getData() is about four. They matter because you’re billed per token, context windows are measured in tokens, and more tokens means slower and more expensive. That’s the whole story.

Context is everything the model can see when it answers. This is the one people get wrong. The model has no memory between sessions. Nothing carries over. If it isn’t in the context, it does not exist.

What the model actually sees
System prompt Instructions, rules, persona. Your .cursor/rules lives here.
Retrieved context Whatever the tool searched up: @codebase, @docs, @web.
Conversation Everything said so far in this chat.
Your prompt The thing you just typed — the smallest part of it.
Better context beats better prompting. But more context is not better context: irrelevant files dilute the signal and cost you money.

RAG — retrieval-augmented generation — is the fix for the fact that the model doesn’t know your codebase. Instead of hoping it guesses, you search for the relevant parts and put them in the context before it answers. In Cursor that’s what the @ symbols do: @codebase to search semantically when you don’t know where something lives, @file when you do, @docs for library documentation, @web for anything current.

MCP — the Model Context Protocol — is the plug standard. Before it, every AI tool needed a bespoke integration for every external system. Anthropic built MCP and then donated it to the Agentic AI Foundation for open governance. It’s past 97 million monthly SDK downloads with 10,000+ servers, and OpenAI, Google, Microsoft and AWS have all adopted it. Think USB, but for connecting a model to your database, your GitHub, your Slack, your browser.

Vibe coding, and where it breaks

Karpathy’s original line was: “You fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

For a weekend prototype that’s correct, and I’d recommend it. For anything that has to survive contact with other engineers it produces exactly what you’d expect — no architecture, inconsistent patterns between files, bugs nobody caught because nobody read the diff, and a pile of debt that arrives all at once about three weeks in.

The fix isn’t worse tools or slower work. It’s putting a process around the same tools.

The distinction the whole talk is built on
Vibe coding
  • Prompt → code → hope
  • "Just make it work"
  • Accept whatever comes back
  • No plan, no review
  • Fine for prototypes. Breaks in production.
Vibe engineering
  • Research → plan → build → review
  • Understand the problem first
  • Agree the architecture before generating
  • Read every line that lands
  • Same speed. Ships to production.

The four stages aren’t ceremony. Each one has a tool that’s genuinely better at it than the others, which is the entire reason to have a stack rather than a favourite.

My workflow, and what I use at each stage
01 Research ChatGPT to think out loud, Perplexity to find docs and check what's current.
02 Plan Cursor chat. Architecture, file layout, API shape — argued before any code exists.
03 Implement Cursor Composer for multi-file work, Codex for large mechanical refactors.
04 Review Cursor Agent for a first pass, then me. Always me.

Three objections, answered

“AI makes developers worse.” In 1986, teachers in South Carolina picketed to keep calculators out of classrooms until the upper grades, on the grounds that students wouldn’t learn real maths. Calculators went on to enable space programmes and most of modern engineering. What actually happened is that attention moved from calculation to understanding. I think this is the same shape of change, and the same shape of panic.

“You’ll stop learning.” The opposite has been true for me. Working this way means I read far more code than I write, and reading is how anyone gets better. The failure mode isn’t using the tool — it’s accepting output you don’t understand. If you couldn’t have written it yourself, don’t ship it.

“It’ll replace engineers.” There’s an MIT result worth sitting with: experienced developers expected AI to make them 24% faster, and were measured as 19% slower at first. Not because the tools are bad, but because new tools have a learning curve, and confidence arrives before competence does. These tools amplify what’s already there. A strong engineer with a 3× multiplier is worth far more than a mediocre one with the same multiplier, because your expertise is the thing being multiplied. Invest there.

Karpathy again, and this is the line I’d keep: AI is an Iron Man suit. It augments. It doesn’t replace.

Where it genuinely changed my life

Debugging. It used to be: hit the bug, search the error, fall into a Stack Overflow thread from 2017, search GitHub issues, try things for two to eight hours. Now it’s paste the error with the surrounding code, have a conversation, understand the answer, verify it. Fifteen minutes, most of the time — and faster still with full codebase context in the editor.

That single change has been worth more to me than all the code generation put together.

What to take away

Define your stack, so you know which tool does which job. Build templates and rules files so you’re not re-explaining your conventions every session. Review everything, because the model is a junior engineer and you’re the senior one. And measure what actually ships faster rather than what feels faster, because those two diverge more than people admit.

The best engineers I know don’t just use AI tools. They build a system around them.


One thing I mentioned at the end and will repeat here: this entire eighty-slide presentation was built in Cursor, in about three hours, using Agent mode with the Perplexity MCP doing live research. The medium was the message.

Mazen Alotaibi (@ma7dev)