Skip to content
← All writing

Introduction to Cursor — DAL Health Datathon

DAL Health Datathon 2025 — CODE, Riyadh Event recap
On this page

An invited talk in the DAL Health Datathon 2025 programme, to a room of people about to spend a weekend building against the clock.

Three parts: where these tools sit relative to each other, how Cursor works underneath, and the thing most people don’t try — using it for work that isn’t code.

The landscape, briefly

It’s worth seeing how wide this got in 2025 before narrowing to the coding tools:

AI tooling in late 2025
Writing & chatChatGPT, Claude, Gemini, Perplexity
Design & imagesMidjourney, DALL·E 3, Canva AI, Leonardo
CodingCursor, GitHub Copilot, Windsurf, Cline
Video & audioRunway, Veo 3, Synthesia, Suno
ContentJasper, Copy.ai, Writesonic, Notion AI
AutomationZapier AI, n8n, Microsoft Copilot

Narrowing to coding assistants, the honest comparison is that they’re closer than the marketing suggests. Copilot has the broadest IDE support and the deepest GitHub integration. Windsurf is agent-first with strong multi-file reasoning. Cline is open source and fully customisable, with your own API keys. Cursor is the one I use daily, for the context handling and the Tab-plus-Chat-plus-Agent combination rather than any single feature.

How it works

The same mental model I use in every one of these talks, because it’s the thing that makes everything else make sense:

The loop
01InputYour prompt, plus whatever context the editor assembles around it.
02ModelPredicts the next tokens. Has no memory of you between sessions.
03OutputCode, in your files, that you are responsible for reading.
Cursor's actual product is step one — deciding what to send. Better context, better results.

Then the four chat modes — Agent to build a feature, Plan to think through an approach before committing to it, Ask to understand code you didn’t write, Custom for your own workflows — and the features that make a real difference over a weekend: rules files so you stop repeating your conventions, docs indexing so the model isn’t working from a stale training cutoff, checkpoints so a bad direction costs you seconds, and @ mentions so you can be precise about context.

Using it for everything

The part that surprises people. It’s an editor with an agent and good context handling, and none of that is specific to code. I use it for technical writing, architecture documents, code review, and learning unfamiliar systems by asking it to explain them.

For a datathon that matters, because the deliverable is rarely just code — there’s a write-up, a presentation, and an explanation of your approach, all of which are text.

The pitfalls, which are all the same pitfall

Vague requests. Not including the error message. No project rules. Too much irrelevant context. Expecting the first attempt to be right. Never trying a different model.

Every one of those is a context problem. Get context right and the rest mostly follows.

Thanks to DAL for the invitation.

Mazen Alotaibi (@ma7dev)