Before we begin…

Let me tell you a little bit about myself.
I’ve been writing code for a long time now—almost two decades. I was still a student when I started coding and even began making money from it early on. Over the years, I’ve worked with a wide range of technologies, including C, C++, Visual Basic, Embedded C, PHP, Java, Python, data engineering, and jQuery. But not once have I worked with any frontend technology. Even today, the thought of learning a frontend framework (like React) scares me and keeps me up at night.

I don’t know what it is about that world, but I’ve never been able to wrap my head around it. I want to learn it—I really do—but I guess I lack the energy or patience. Or maybe it’s the fact that it changes so quickly, that whatever I learned a couple of weeks ago is already deprecated.

That fear has held me back from building many of the apps I want for myself.
I often resort to asking friends to build the frontend, while I handle the backend—APIs, database interfaces, and so on. But friends can only help so much. They’ve moved on and aren’t really interested in writing frontends for me anymore.

Still, I can’t stop myself from building tools for my own use. I want to make my life easier—and collect data about it so I can reflect, plan, and execute better. One of the apps I use the most is a personal expense tracker that I built for myself nearly seven years ago.

When I first started,
I wrote a pretty horrible-looking but functional frontend in AngularJS. A couple of years later, during the lockdown, one of my friends got interested and offered to build a new UI in React. He finished it in about a month, and it was a hundred times better than what I had before. It included new features, looked sleeker, and was much more user-friendly. I was thrilled.

And then

Come 2025, I wanted to build another app—this time to track my health and fitness.
I know there are already a plethora of apps out there for this. But most of them are either locked behind a paywall or don’t offer the exact features I want. That’s primarily why I build my own apps: so I can include all the features I want—and only the features I want.

So, I started exploring which technologies I could use to build a brand-new app for myself. It was exciting.

But as soon as I started narrowing down frontend libraries and frameworks, the nightmares came back.
Back in the day, I used to build Android apps instead of web apps. I even have a Google Play Developer account and have built Android apps professionally. But now I don’t use an Android device anymore—I’ve switched to an iPhone.

And here’s the kicker: I had never even looked at a single line of Objective-C or Swift. Writing iOS apps felt completely out of reach. But I had no other choice. So I started watching some YouTube videos on how to write Swift code, hoping that within a year or so, I’d be able to get a decent grasp of it.

To my surprise, Swift turned out to be much simpler than I expected. I never imagined it would be this approachable. It quickly became one of the easiest languages and frameworks I’ve ever worked with. So I dove in and began writing basic apps and games to get my hands dirty.

Within a couple of weeks, I had the basics down.
I learned how to build UIs with SwiftUI, handle on-device data, use biometrics and location services, call APIs, implement Apple and Google authentication, and even plot charts.

Then I thought: instead of jumping straight into the new fitness tracker, why not revamp my existing personal finance tracker? That way, I’d solidify my Swift knowledge while working on something that already has a stable production release. It would also give me room to experiment freely with all aspects of the app.

And that kicked off a five-month-long journey with Swift.

In those five months, Swift became my go-to language for personal projects.
I gained a deeper understanding of it, and a new appreciation for Apple’s dev community—for making it surprisingly easy to build apps for the entire Apple ecosystem.

The best part? I write code once, and it runs seamlessly on my iPhone, iPad, and Mac—all as native apps. I now have three Swift apps I use almost daily. A couple of others use them too.

With my essential apps running smoothly, it was time for the next experiment:
Build a new ReactJS web app for the same features—without writing any ReactJS code. Naturally, I turned to AI.

While working on the Swift apps, I was already using AI tools alongside Stack Overflow and Google. Mostly ChatGPT and Claude. But I kept seeing people use tools like Cursor and Windsurf to generate entire SaaS applications. I was curious but didn’t have time to explore them back then.

Now, I finally do.

And that’s how it started

I downloaded Cursor and started playing around with it.
At first, I asked it to perform some very generic tasks. I kicked off a few POCs, just like I always do when I’m learning a new language or tool—small projects that solve one specific problem. Once that’s done, I move on to the next one. I assumed this would follow the same pattern.

But I kept forgetting that these AI models have already done all that grunt work. I could skip ahead and go straight to the good stuff.

So I began building a new version of my personal expense tracker—
the same one I’d just rewritten in Swift after five years of using the React-based web version. I started with the basics: creating a dashboard-style interface, adding a nav bar with expandable menu items, placing a circular user photo at the top-right corner, integrating Google login, and so on.

Surprisingly, it all came together pretty fast.

Before I knew it, the two-week Pro trial ended.
But by that point, I had already made solid progress. A lot of the app was working, though it wasn’t fully ready yet. Still, the itch in my brain was too loud to ignore.

So I gave in and did the inevitable—I bought an annual subscription to Cursor. I told myself it wouldn’t go to waste. I write a lot of code anyway, and having an AI tool to generate most of it sounded like a pretty sweet deal. Sure, it’s expensive for a hobby, but hey—now it was time to build some awesome-looking web apps.

The early days were rough.
I’d ask Cursor to build something, and it would break something else. I was giving it vague, brief prompts—and, unsurprisingly, the output was never quite what I had in mind.

Then I had a lightbulb moment: I needed to be more specific. I started giving detailed prompts, complete with examples of how I wanted things to look or behave. The clearer the prompt, the closer the result was to my expectations.

At that point, I wasn’t writing code anymore—I was writing prompts. But within a month, I had the app working more or less the way I wanted.

The coolest thing about using AI to write code?
I can now build a lot of apps very quickly.

The most annoying thing?
The code isn’t always written the way I would write it. Especially with React—since I don’t fully understand it, I don’t really look at the code, so I can’t critique it much. But when I used Cursor for Java and Python, I did look—and it was kind of messy. Not necessarily bad, just… unorganized. Not thought through like I would do it.

But anyway, we’ll get into that later.

The add-ons

One thing I observed—like in the screenshot below—is that Cursor often gives me more than I ask for.
(The numbers here are obviously just for illustration—I’m not about to show you my actual expenses.)

For this particular page, I had only asked Cursor to plot a pie chart (not a donut chart) that would display my expense categories using data fetched from an API. But Cursor went the extra mile. It automatically added the four summary boxes at the top, highlighted the top three categories, and included a color-coded list next to the chart.

None of that was part of my original prompt. And yet, Cursor filled in those gaps on its own—and honestly, I was pleasantly surprised. It made the page look way better than what I had originally envisioned.

For comparison, here’s what the same chart looks like in the Swift app I built myself for the same data.

You can clearly see the difference. Now, to be fair, I know the credit here really goes to React, the charting library, and overall design principles—not just Cursor.

But from my perspective—someone who doesn’t know web design, doesn’t understand aesthetics deeply, and doesn’t code in React—this is incredible. It’s making my life noticeably easier.

But it’s not all green

While there are definitely benefits to using tools like Cursor—or any AI coding assistant, for that matter—I wouldn’t recommend letting them do all the work.
They’re great when you need help here and there, but I’d never rely on an AI tool to write entire codebases for me. I see it as an assistant, not an employee. It’s designed to assist me—not replace me.

And it’s far from perfect. That’s something we need to acknowledge.

There were times during my experiment when I was driven to the edge of frustration because Cursor couldn’t get something absurdly simple to work. For example: black text on a black background. Obviously unreadable, right?

Well, not to Cursor. It took me no less than three days to get it to understand this. And even after all that, it still refused to change the text color. I had to dig into the CSS myself and make the fix manually.

And it didn’t stop there. Every time it fixed something for the dark theme, it would break the light theme—and vice versa. Even now, after nearly two months of giving up on that app, the light mode still looks like I intentionally designed it to annoy users.

Also, while Cursor tries to follow clean coding principles and adheres to the language standards, the code it produces often doesn’t feel practical.
If a human wrote it, it definitely wouldn’t look like that. It’s too textbook—by the book, sure—but not pragmatic. Some might argue, “That’s how clean code should be written.” But real-world development isn’t an exam.

It’s not human. It lacks nuance. And honestly, I would never use an AI tool to write my code completely—not at this point in time.

Next

Now that I’ve built one and a half apps with Cursor, I can’t say I’m any better at writing frontend code—
but I am a lot better at prompting.

I’ve always been good at Googling, and now I’m pretty decent at talking to AI too. I can get things done faster than when I started, and more importantly, I can get the output closer to what I actually envisioned.

But lately, the charm and excitement of using AI has started to fade.
I know the power of AI is available whenever I need it—but I also know I can’t always rely on it. And that’s a crucial realization.

I’ve stopped using the web versions of the apps I built with Cursor.
I’ve gone back to using the Swift versions instead—mostly because they just work better. They’re snappier, feel more native, and don’t frustrate me as much.

Honestly, I don’t know if I’ll ever build another React app with Cursor. But I’m certain I’ll build many more apps in Swift.

They may not be the prettiest, but they’re reliable. And they get the job done.

And here’s the most important part:
With the apps I built myself—in Swift—I know exactly what’s going on under the hood. If something breaks or behaves weirdly, I know where to look. I know where to place a breakpoint.

That gives me confidence.

Confidence that I never had with apps generated by an AI tool. And as a developer, I can’t compromise on that.

I can’t trade away that confidence for the convenience of a no-code or low-code solution—no matter how magical it seems at first.