I stopped coding around 2016-2017. I can’t recall exactly when.

That marked roughly 15 years of programming, developing smart algorithms (before I became mainstream), and managing R&D teams.

It was fun, but until recently I didn’t truly miss it.

Whenever a thought came to mind that I should use my skills to develop an app or a service I immediately recalled all the hassles involved with coding. I mean, coding itself is fun, but everything around it – like setting up a development environment – introduced overhead I didn’t want to deal with.

So what’s changed?

The AI revolution.

That’s what changed.

By now I guess all of you have seen all these LinkedIn posts from random people who share how they built something by themselves, using one of the new AI no-code platforms, and now they are all making tons of money out of their creation. That made me think it might be time to reevaluate my decision to stay away from programming.

And then an opportunity came. One of my customers was in need of a standalone app, but all of their developers were fully occupied. Reading all these posts, I thought to myself – why don’t I try to build it myself?

After all, I have a strong engineering background, and if even just some of the hype is true, I should be able to build something workable quite fast.

And without promising anything to my customer, I started playing with all these platforms and I actually managed to build my fully functional AI app.

In this post I’m going to share what I tried and what I found to be working the best. But don’t be confused – this is not a post for programmers. This is a post for product managers, and I will share my takeaways for PMs towards the end of this post.

Additionally, as with any AI-related post, remember this content is the exact opposite of my usual evergreen material. All the advice I will share here will probably have a short timespan of a few months, as the AI advancements are announced at such a rapid pace, that any ‘how-tos’ are becoming obsolete quite fast.

With that in mind – let’s go.

My mission

I won’t get into the very small details of what I needed to build since I want to protect the confidential aspects of it for my customer.

I will therefore just say that the app I needed to build had to process a given CSV which contained a lot of data, and apply cleaning & other transformations on it, provided by a free form text. For example, the user could ask it to ‘transform all ‘AB’ strings to ‘ab’’, ‘remove rows where the value of the cell under column M is below 0’, etc..

This is a high-level generalization of what I needed to build (there were other, important, small details, but again – I won’t share them here).

When I worked directly with Claude, I uploaded to it some sample CSVs, I gave it instructions and it did it quite easily. I also know from past experience that Claude can create workable frontend interfaces amazingly well. Because of that, I concluded that such an app should be quite straightforward to build. 

In reality, that wasn’t the case. Not that it was hard, it’s just that it wasn’t trivial as I originally thought.

Platforms I tried

When looking at today’s AI-driven development platforms, we can roughly divide them into three groups:

1. LLMs – meaning, working directly with the chat interfaces of the big language models such as ‘Chat-GPT’, ‘Claude’, ‘Gemini’, ‘Grok’, etc..
2. No code platforms – such as ‘Loveable’, ‘Bolt’, ‘Base44’, and ‘Replit’
3. AI driven IDEs (Integrated development environments) – such as ‘Windsurf’ and ‘Cursor’

LLMs

LLMs are great if you need code samples, analyzing a given piece of code, or even quickly prototyping a workable user interface. They can also help come up with proper design and recommended tech-stack when needed.

However, they are not great where you want to build a full stack app, since they will just generate you a bunch of files which are lacking the environment to work together.
Claude is somewhat of an exception since they recently released ‘Claude Coder,’ an extension for VS Code. Still, it doesn’t have a lot of adoption as far as I know.

Thus, LLMs are super powerful, but I wouldn’t use them for full app development.

No code platforms

No code platforms are aimed at people who have zero or quite little programming experience. The promise they introduce to the world is that even non-developers can create great things.

Behind the scenes, most of these platforms are using Claude Sonnet, as it’s considered (currently) the best in coding. They just provide the missing layer of gluing anything together in a closed internal dev environment, which is not exposed to you.

My original attempt was to try one of those. I went with ‘Base44’ since it was the ‘new kid on the block’ and received tons of praise on LinkedIn.

The interface is quite straightforward, and I managed to build a running app relatively fast. Problem is, the app was running, but didn’t work well. Parsing the file took forever, and when I needed to get more control over how it leverages the Claude API from within (when trying to apply the free for text instructions on the CSV), things were starting to get really messy. At some point the chat of this platform even told me that ‘it’s limited only to writing frontend code’. When I asked what it meant (because I knew it’s untrue), it corrected itself and admitted that it is capable of building full stack apps, and it’ll make another attempt. Well… thank you for that.

Long story short, I ran out of credits quite fast, and I decided to try another platform – Replit.

Replit’s main attraction is handling deployment for you. Meaning, once your app finally makes it to production, they will host it (on an internal domain, or a custom domain you will provide), so people can easily access it from any browser.

Their pricing seems reasonable, but quite fast I discovered that there are hidden fees. Each time the platform saves a ‘checkpoint’ for you, which happens practically for almost any change you make – it costs you about 0.2$. Your monthly package covers you for about 25$ (if I properly recall) and after that you’ll be overcharged.

I quickly calculated that I would exceed my quota within a day and a half, so I abandoned this platform as well.

AI Driven IDEs

AI driven IDEs can look quite complex to anyone who is lacking programming experience. A lot of small windows, terminals, logs, debuggers and tons of other views. This can be definitely intimidating.

But if you’re willing to learn a bit about these environments (there are numerous beginner tutorials on YouTube), you’ll quickly find they’re not as intimidating as they initially appear.

You don’t need most of these views, at least not at the beginning, and later you will discover that they can really help to gain more granular control over your app.

Coming from programming myself, the overall environment looked quite familiar, though things have definitely progressed since my time, so I viewed a few tutorials myself before ‘settling in’ the cockpit seat.

In the end, you start your project similarly to how you’d start on no-code platforms – by describing exactly what you want to build in the AI chat window (yes, that’s one of the new features). 

Behind the scenes they have their own AI engine, but I recommend that you instruct these IDEs to simply use Claude Sonnet (they let you pick the engine). It will use more credits per use, but eventually you’ll need less credits because it will do a better job.

As for ‘Windsurf’ versus ‘Cursor’ – I’ve chosen Cursor. The reason for my decision is based on their pricing. More transparent and no hidden fees.

Windsurf pricing model (as of writing this post) is a bit shady, and your true fees are going to be much higher than you probably planned. 

Cursor is more transparent, and you won’t be overcharged. If you are out of quota, the AI requests will simply slow down as your priority will be lowered.

[Originally I shared at this point my engineering challenges but it’s quite technical, so I moved it to an appendix at the end of the post, in case you’re interested]

My final configuration

I ended up with the following configuration which I found to work best:

1. Perplexity & Claude – for researching the best programming languages to use, tech stack and defining project ‘rules’ (so the AI within Cursor will stick to best practices, languages and the tech stack chosen). In the end, they chose languages I had no experience with, yet it turned out fine.
2. Claude LLM (via its chat interface) for designing the app, defining algorithms and the more complex logic. 
3. Cursor AI, with Claude Sonnet 3.7 as the internal agent. I used this agent for applying all complex logic, algorithms and designs determined by the LLM, and also for fixing compilation errors, runtime errors and doing more trivial stuff.

With this configuration I managed to save a lot of credits.

Main takeaways for product managers

Here is what my experience taught me:

1. We’re currently at the golden age for solopreneurs with technical backgrounds. It means that if you’ve previously coded, now is your time to shine. There are quite a few apps that you can probably build yourself, release to the world, and make some extra bucks if it provides a true value to some audience.
2. As product managers, you should expect your developers to increase their velocity in a significant manner. In the app I just described Claude wrote roughly 98% of the code. I just had to stir it in the right direction, do the QA and tell it what is still not working. I also had to serve as the ‘architect’ and instruct it what approach it needs to take. It did all the rest. Your dev team has no excuses. They must adopt a ‘pair development with their AI buddy’ mindset. To my great surprise, quite a few developers that I met recently, didn’t want to work with AI. They didn’t trust it. If this is happening in your team, have a serious conversation with the team leader to emphasize that the world is changing. A revolution is happening, and we are not going back to how things were before. They must adjust or become irrelevant. 3 developers can now build a billion dollar company.
3. The ‘no code’ platforms are cute, but not there yet. They’re great for prototyping, but I wouldn’t rely on them beyond that. With enough persistence you can make them build a real full stack app, but it will cost you (or your company) a fortune. Hence, as a product manager, you can and you should use them to express your vision and better explain what you want to build. You can also use them with customers to test ideas, or even build product demos.
4. If you are a product manager with an engineering background, and you have some spare time on your hands – You can easily build standalone apps and tools to benefit your organization.
5. The business risk, which I mentioned several times in the past, is real. Just because something works well directly via chat with an LLM doesn’t mean it’ll scale effectively through the LLM’s API. As a product manager it means you must test with your developers the very basic assumptions when it comes to ‘tokens management’. Otherwise, things may work, but they will either cost you a fortune, be extremely slow or… both.
6. Just an observation, and not directly related to this post – someone has to wonder about the future of product designers. UX guidelines and best design practices were already fed into the main LLMs and they follow these rules to build impressive designs. After all, AI shines where there are clear guidelines and rules. The UI (branding, styling and eye candy stuff) is a creative process, and hence brilliant designers with artistic talent will still be needed, but I’m not sure about the rest. And this is why I believe the day of replacing product designers with AI is relatively close (again, my personal observation).

Summary

Look, the AI revolution is upon us and it’s progressing at the fastest pace I have ever seen technology advances. This can be both scary and overwhelming. Personally, I think we are now in dire need of some responsible adults to frame and agree where we should take it, but this is a discussion for some other time.

In the meantime, you can and you should leverage one of the 20$/mo no code platforms to accelerate your work and be more productive by creating workable prototypes you can test with your teams and customers, and maybe even build full apps or internal tools if you have more technical background.

Additionally, if your dev team is reluctant to use AI, show them what you build and inspire them to do much better with their programming skills. Your goal is to make sure they all switch to one of the AI driven IDEs and get into the state of mind of ‘AI coding’.

If your team won’t do it, your competition will do it for you.

Good luck!

— Appendix to follow below —

If you enjoyed this post – please ‘like it’ and also share with your friends using the links below.

Appendix – My engineering challenges

Other than trying to figure out the true pricing of each of the platforms, my real challenges were engineering challenges.

Remember I said that in order to assess the difficulty of this project I first made a direct attempt with Claude and the CSV?

Well, Claude’s success with processing and ‘cleaning’ the CSV was indeed very encouraging. However, when I tried to do the same with Claude’s APIs (e.g. sending the same CSV to Claude programmatic interface together with the same cleaning instructions), I ran into serious issues.

Just for context – I run all my tests with a 80kb CSV. We can all agree that this is a relatively small file, and real life data files are usually much bigger.

So first – merely sending this file as it is to the API resulted in an ‘out of tokens’ error. Claude API translates the file contents to tokens, and those 80 kilobytes were too much for it.

My next attempt was to naturally send the file in batches. That worked, but it took about 6 minutes to process this file. That worked but took about six minutes for a small file, implying real-life files might take roughly an hour. That was unacceptable.

Then I tried to ask it to send only the ‘diffs’. Meaning – I’d send the full file to Claude and it will return only the rows that were changed. But that was too slow either.

At the end, I had to acknowledge that Claude API wasn’t designed to receive files. I used the API only to do what it does best – to translate the free text instructions to structured instructions and do the processing on my own backend.