With great power comes no responsibility

Once upon a time, in a Belgian city not too far from a waffle stand, we welcomed an eager intern to work on a standalone project for his bachelor’s thesis. Let’s call him Cursor. Any resemblance to actual people or tools is purely coincidental. Probably.

Cursor, the intern, was a hit. Likeable, competent, and more productive than most. The project shot out of the gates like a caffeinated squirrel. Setup scripts, CI pipelines, fancy UI's written by someone who actually knew what a volume mount was. Life was good.

At one point, it was 80 percent finished. It needed some fine-tuning, bug fixing, and implementing non-happy paths—you know, typical developer things. Cursor said no.

He announced a well-earned holiday, satisfied with a 16 out of 20 on his grade sheet and emotionally ready to let go. Apparently, the final polish was someone else’s problem. Like a Netflix series that ends on a cliffhanger, Cursor simply walked off into the sunset. It was like spending weeks training a pigeon to fly like a hawk. Agile. Sharp. Majestic. And just when it finally flaps high enough to do something useful, it veers off, declares itself a commercial airline, and disappears into the clouds. No passengers. No destination. And about five minutes from flying straight into a window.

There I was, with my 80 percent finished project. And then the worst part was I had to walk over to an engineer, gently smile their way, and bestow upon them the deeply cherished experience of fixing someone else’s code.

Fake it till you make it, literally

As someone knee-deep in data and AI, I cannot afford to ignore the shiny tools popping up every five minutes. So I installed Cursor, the tool. Yes, another Cursor. The multiverse is clearly trying to teach me something.

I gave it a flashy task. Build something from scratch in a language I barely know. That task was less about me and more about simulating our beloved business stakeholders who believe AI tools are perfect replacements for engineers. You know the ones. They “vibe code” their way through life and then panic when the production site crashes every hour.

At one point, it was 80 percent finished. It needed some fine-tuning, bug fixing, and implementing non-happy paths—you know, typical developer things. Cursor said no.

Cursor, the tool, got stuck in a Groundhog Day loop. Fixing one thing, breaking another. Point out the error, and it politely reverted to step one. Lather, rinse, repeat. Minute after minute, token after token. It was enthusiastic, just not useful. It felt like being stuck in a roundabout with an overconfident Uber driver who refuses to exit because “we’re making great time.”

There I was, with my 80 percent finished project. And then the worst part was now I was the engineer with the ungrateful job of fixing someone else’s code.

Offshore, on Time, and optimised for regret

During a recent technical due diligence, I stumbled upon a story so familiar I nearly offered them condolences instead of advice. The company in question had a good product, a solid team, and absolutely no time. They wanted to build something new, but could not spare the resources. So they did what many have done before. They outsourced it to a consultancy in India. Let’s call them Cursor. Might as well complete the trilogy.

Cursor, the company, was energetic, cheap, and endlessly agreeable. Every conversation ended with “yes mister” and that wonderful feeling that everyone was smiling and no one had a clue. The project was delivered on time, to spec, and came with that distinct smell of premature satisfaction.

At that point, it was 80 percent finished. It needed some fine-tuning, bug fixing, and implementing non-happy paths—you know, typical developer things. Cursor said no.

The contract was complete. The scope was closed. The product worked just well enough to be legally acceptable. Edge cases? No. Error handling? Please. Scalability? Only in the spiritual sense. It had more downtime than a 2003 modem. Cursor, the company, had delivered “as per spec” and promptly vanished into the night. It was like hiring a wedding band, getting exactly the playlist you asked for, and then realising they only play kazoo. Technically correct, socially catastrophic.

There they were, with their 80 percent finished project. And then the worst part was the engineering team received the ungrateful job of fixing someone else's code. Only this time, it was not even theirs to begin with, and rewriting it became a full-time job.

Conclusion: buckle your belt

The moral of the stories? Cursor is bad. All three of them.

Well, not quite. That would be lazy. Let’s try again.

Each Cursor had potential. Cursor, the intern, was fast and smart until he hit the boring parts. Cursor, the tool, was powerful but endlessly optimistic about its own usefulness. Cursor, the company, delivered exactly what was asked and nothing more. All of them got us to the same place: a shiny, exciting proof of concept. And then stopped.

Because these are not magic solutions. They are tools. That’s all. You should not hand them a half-baked spec and expect confetti, applause, and a LinkedIn post about innovation. You are supposed to use them, understand them, and most importantly, know where they fail.

Cursor, the intern, is not a replacement for a long-term developer. Cursor, the tool, is not an architect. Cursor, the company, is not your in-house team. They are helpers, accelerators, and starting points.

Use them for what they are. An extra tool in your belt. Not a substitute for the belt, the trousers, and the person actually holding the toolbox.

Know their strengths. Know their limitations. And for the love of all that is cleaned up by someone else, stop acting surprised when 80 percent done means 100 percent not finished.

Final thought?

That title wasn’t a metaphor:Three Cursors walk into a codebase...…none of them paid the tab, and someone else had to clean up the mess they made.