DEV Community: orelzion

I tried vibe coding, and survived to tell (well kinda) - Part 1

orelzion — Sun, 10 Aug 2025 09:38:26 +0000

TL;DR I'm still in the early stages of the project; vibe coding is fine and all — until you need to do something that's slightly customized. Then, a developer's eye is needed.

📖 The Why

Ok, ok, let me start the story like it should—from the beginning.

So, I'm writing a book (it's about being moral, but you never asked, so I won't tell), and when I was searching for ways to properly edit and design it, I came across several options but didn't like any of them.

They were either too complicated or cost more than I wished to afford.

I spent hours researching and asking ChatGPT for brilliant ways to overcome this, but to no avail.

But then myself told me: "Orel! You're a programmer, right?"

"Well, yes," I replied, as I am quite polite.

"Then why," myself continued, "don't you develop an app tailored to your needs by yourself?!"

I must admit that myself posed a good question, but I didn't want to admit it — so I came up with an even better idea:

"You know what?" I told myself, "why write an app when you clearly don't know enough JS, when you can vibe code it?"

Oh, did I not mention? I'm a mobile developer; I barely know the basics of web development. So I went to ask the smartest person I know.

No, not me, I'm not that pretentious.

I meant ChatGPT.

So I asked him, and he agreed with myself. Now they were two against one, so I had to do the democratic thing and agree.

And thus began the crazy journey of a mobile developer vibe coding his first desktop app. Stay tuned—there will be bears 🐻.

🛠️ The Plan

I started by asking ChatGPT to come up with a plan. We discussed my needs, technologies, and features until I thought it was enough.

Then, I asked it to craft a PRD and created a new directory on my computer.

I ran Claude Code from the VSCode terminal and asked it to read the PRD first and explain what its plan was to develop it.

Claude Code is my favorite AI code assistant. I like that it's a CLI tool and that it seems to really understand the requirements of the project.

It gave me a comprehensive plan, broken down into steps and divided into MVP and future implementation milestones. After some back and forth with it, I agreed to the plan.

Then I asked it to write that plan down into a development_plan.md file so we would have a reference.

We decided to use react for the frontend, built on top of Tauri.

I saved my project and was ready to start coding—or, actually, vibe coding.

🚩 The Struggle

The first struggle came when I asked Claude to start with installation. To its credit, it did try — but it kept failing. Eventually, I told it to just give me instructions and I'd handle the heavy lifting myself.

I reverted all generated code and went through the installation process on my own: the Tauri CLI, the NPM packages, everything I needed. At last, everything was ready, and I did my first commit.

Then I asked it to save our progress to a development_log.md file so we could track progress. I ran /clear to reset the context and save money.

Next, I asked what our next step was, and it went ahead and started developing. I approved everything without reading the code. I mean, I could’ve, but this is vibe coding we’re doing—and like I said, I’m not a web developer.

Anyway, it tried to run the app but had a hard time doing it from the CLI. So I told it I'd run it from the terminal myself. A good choice, and you’ll see why later.

The first iteration was great: the editor was usable, I could write text, emphasize it, and do text-editor-y stuff. Excited, I asked it to add a chapters menu—and it did!

I asked for more steps, but then my session was stopped. You see, my Claude subscription is the $20/month one, and I have a limit on tokens. So after a while, I got blocked. Kindly, it showed me when I could return to vibe — so I waited.

😍 The Honeymoon

Waiting can teach you patience. And patience is everything, or something — I don’t know, I’m not great at Buddhism. Anyway, after my detention time ended, I returned to programming.

We reviewed the structure of the saved files and agreed on how to store the markdown content. But something kept breaking. No matter how hard Claude tried to get the saving feature working, it wouldn’t cooperate.

Then I realized a permission was probably missing. I mentioned this, and we searched together. Turns out, it did request the permission—but the Tauri package was missing, so I installed it manually. Once I did that, saving worked smoothly.

We went back and forth on other features and made great progress. We implemented themes, I18N, tons of text features, chapters, and subchapters — I really felt like I didn’t need to do anything. An entire app was being built by a computer. Amazing.

I got so excited I told anyone reckless enough to ask how it was going.

And then I read the code...

I discovered it didn’t always implement I18N and had hardcoded strings scattered throughout. It also didn’t consistently follow the theme approach and used inline styling in random places.

So I read more about it and realized I needed to add a CLAUDE.md file with proper instructions. I used Claude’s code to generate it, naturally.

In this file, I stated some rules, like so:

## Important Rules
- **NEVER run the Tauri app** – always tell the user what to test and let them test manually
- **ALWAYS use i18n text** – never hard code strings, use translation keys from i18n config
- **Structure components in folders** – organize components into logical folder structures
- **No automatic tests** – we don’t run automated tests, manual testing only
- **ONLY use react-icons** – never use SVGs, always use icons from react-icons/fa6 package

It also explained the project purpose, the technologies, and basically everything Claude needed to know. Now it mostly complies with my preferences — and if not, I just mention it broke the rules, and it apologizes and fixes things immediately.

I mean, I’d prefer it didn’t break the rules in the first place, but you know what they say: “You can’t have it all.”

💻 The Debug

Debugging with Claude is surprisingly pleasant. No, I really mean it.

After some trial and error, I discovered the best way to actually fix problems: tell it to add logs.

Yes, plain old logs.

I just review the logs, paste them into Claude, and suddenly it understands exactly where the problem stems from.

This feels a lot like pair programming to me.

Of course, sometimes — or should I say too many times — Claude claims it figured out the problem and fixed it, only for you to test the app and discover it's gotten worse.

But let's be honest: how many times has that happened to you? Don’t answer me.

Still, this isn't quite the same. Like I said, I’m not a web developer, so I can't really verify that Claude isn't writing complete nonsense. But sometimes you just sense something's off.

You know what I mean? Like you can't read TypeScript code, but you recognize a code smell when you see one.

You notice how it sprinkles setTimeout calls throughout the code and you're not sure why, but you're pretty sure that's not how things should work.

So you ask why, and Claude responds with something like "You're right, let's completely change that." Then it rewrites everything and the app stops working entirely.

Moments like this lead to great frustration. Honestly, there were times when I thought this whole thing was a big mistake, and I just couldn't fight with it anymore.

Over time, I learned how to question it properly.

If it tries to fix some problem in a way that looks odd to you, just stop and ask why — like why did it choose this particular solution?

Sometimes you need to tell it to go look up the problem on the internet. Hell, sometimes I did it myself, came up with a solution, told Claude about it, and it implemented it perfectly.

So yes, don’t automatically accept every one of its fixes. Question it.

For example, if there's an error with a library it's using, Claude might just completely change it and use another library. You need to stop it from doing so and tell it to show pros and cons of that library — or to search for the issue online first. Just so you know, Claude can search the internet—it just won’t do it unless you specifically ask for it.

🐻 The Bears

Ok, ok, so there were no bears, I’m sorry for that. But we did reach the end of this post, and that's something, isn't it?

If you followed along, you saw that I have my moments with Claude's code. Sometimes I'm like “God, this is genius - I love you!” and other times I'm like “How can you be so stupid?”

But this isn't really the end. I'm only at the beginning of the project, so other posts will surely follow.

Maybe there weren’t any bears — yet. But give it time. Claude might generate one.

First impressions on Maestro - The simplest mobile testing framework

orelzion — Sat, 17 Sep 2022 19:13:51 +0000

Photo by Mark Williams on Unsplash

Last week I participated in Droidcon NYC and outside the main conference room was a stand of mobile.dev. I usually don't stop at stands (unless I see some great t-shirts or socks 😄) but something caught my eyes.

It was this demo
// Detect dark theme var iframe = document.getElementById('tweet-1565004345355079680-189'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1565004345355079680&theme=dark" }

What caught my eye was the simplicity of this framework. I have some experience with Espresso and I know how hard it is to write the same test in it.

So I promised myself to go and check it out when I return, and so I did.

In this post I'll share my first impressions and maybe this article will actually become a series 😄

Installation

Installation was actually a breeze, I head over to the guide and everything is explained there.

I decided to first install it locally, and since I want to test both Android and iOS I didn't install it into gradle but via homebrew.

Android

Running my first test on Android was easy.

I created a new file simple_login_test.yml that looks like this

appId: "ai.viz.notifier"
---
- launchApp:
    clearState: true

Then, I headed over to Android Studio to open an emulator.

And then I run this line from my terminal
maestro test simple_login_flow.yml

And that was it!
The app has launched!

iOS

For iOS though things have been a little bit harder.

I first needed to add another installation from homebrew

brew tap facebook/fb
brew install idb-companion

This is a library from Facebook that will allow us to connect to an iOS simulator.

After installing run this command in your terminal

idb_companion --list 1

it will list all of the available simluators, find one that you like (for me it was iPhone 13 mini) and copy its udid.

Then you will launch it with this command

idb_companion --boot 85921D77-E655-4FA4-B202-D705E66E0D8A

After it's launch you'll need to connect to it with this command

idb_companion --udid 85921D77-E655-4FA4-B202-D705E66E0D8A

Now you should be able to start your test.

So I created another file simple_login_flow-ios.yml with the same code just replacing the android's appId with a iOS' bundle id.

appId: "viz.ai.VizAINotifier"
---
- launchApp:
    clearState: true

But it didn't launch 😥

Apparently I had to shut down the Android emulator first, and only then it launched.

I guess they first try to find if there's an Android emulator and if there is they will try to launch on it. Then, it didn't find any app with that appId, so it just quite the test.

Running a simple flow

So the first flow we're going to run is a simple login flow. I want to launch the app, enter wrong credentials, see an error, fix the credentials and login successfully.

Simple, right?

Well, with other frameworks (Espresso ☕️ I'm looking at you 👀), this would take one class to set all the views to their IDs, another to launch the app and dozen functions or so to interact and assert it.

If you have to wait between actions, you'd have to also implement a timer to keep checking if your view is already displayed.

Not with maestro!

In here, to start the app all I need is this

appId: "ai.viz.notifier"
---
- launchApp:
    clearState: true

To tap a button to continue to the login screen, all I need is

# Welcome screen (yes, this is a comment)
- tapOn: GET STARTED

To do some assertions on views, to check that the views that suppose to be there are actually there, I needed

- assertVisible: "Email"
- assertNotVisible: "Password"
- assertNotVisible: "Reset Password"

The way that this works is that instead of looking for a view id, it looks for the text, the same way as your QA engineer will do it.

But what if you don't have a text? I wanted to assert if some icon was showing.

Fortunately, you can use IDs as well.

- assertVisible:
    id: "ai.viz.notifier:id/fingerPrintButton"

Maestro hierarchy

How did I get this id? Do I need yo open Android Studio and try to find it there? Hell no!

We want simplicity and simplicity will shall get 😄

To get all the views from a current screen, just run maestro hierarchy in your command line. The output will be all your view tree, with texts and IDs.

This is how I knew what ID to use here.

Other assertions

I did have one more thing I wanted to test.

In our app we disable the next button if you don't have text, this is part of the QA process and I wanted Maestro to do the same, but I didn't find any option to assert whether or not a view is clickable.

So I asked in their Slack channel whether they plan on having more assertions types.

And this is how they answered

Make sense!

So what I did was to tap on the button and check that the screen hasn't changed.

- assertVisible: "Email"
# Test next button is disable when no text entered
- tapOn: "Next"
- assertVisible: "Email"

iOS

I have other assertions in my file but I won't bore you with details 😄.

I now wanted to have the same test with iOS.

I started with the same test

appId: "viz.ai.VizAINotifier"
---
- launchApp:
    clearState: true
- assertVisible: "Enter your email"
- assertNotVisible: "Password"

But my first assertion failed. Although the text was there as a hint in the edit text, Maestro didn't find it.

So I posted another question in the slack channel.

Just 3 days after reporting, the issue got fixed!

This is an amazing pace for a library, and I think that this shows how hard they work to improve it and this is indeed a good sign.

But to test the icon that was there, I didn't test by its ID, in iOS it actually use the image id as the text, so I was able to test it like this,

- assertVisible: "sfIcon60"

Problems?

But then I got stuck, after the initial login flow, we have a view pager for a walkthrough. But no matter what I tried I wasn't able to test it.

Running maestro hierarchy on this screen gave me absolutely nothing.

orelzion@N9QFJYD6GW maestro % maestro hierarchy
{
  "attributes" : { },
  "children" : [ {
    "attributes" : {
      "text" : "VizDebug",
      "bounds" : "[0,0][375,812]"
    },
    "children" : [ ],
    "clickable" : null
  }, {
    "attributes" : {
      "resource-id" : "screen.onboarding.container",
      "bounds" : "[0,0][375,812]"
    },
    "children" : [ ],
    "clickable" : null
  } ],
  "clickable" : null
}

I was also trying to ask in the Slack channel, but this time, although they did try to help me, it just didn't work.

I'm guessing I'm gonna need to investigate that some more to understand what is so special about this screen 😄.

Wrap up

This post will probably have a follow up, the maestro framework is great! Super simple and intuitive, and I liked the philosophy of it.

This is defiantly a library that I will continue to investigate, and I look forward to integrate that into our projects.

Stay tuned!

Optimising markers performance on Google Maps using RxJava

orelzion — Sun, 14 Oct 2018 17:22:30 +0000

So today I ran into an interesting problem. I needed to display a large amount of markers on Google Map, and we decided that too many markers will just not look good, and so we are eliminating markers that intersect by over 70 percent, and display just one of them instead.

And so I wrote this little function that takes two Rect objects to see if they intersect.

But how do you get a rect object if all you have is a Lat/Lng of where you want to position your marker?
Well, luckily for us Google Maps already has a utility function, that converts a lat/lng on map into a Point object.

mGoogleMap.getProjection().toScreenLocation(latLng)

And so, I was able to create a Rect object based on that point plus the icon width and height.

Now we need to iterate over all lat/lngs and check which of them are intersecting.

Since this can be heavy (iterating over each object and check it against all other object in the list), I decided to run it inside an RxJava observable.

Seems legit, right?

Well, I thought, let's give it a run. Oh boy, that sucked terribly. I ran the app on a Google Pixel 2 device, and whenever I moved the screen and the markers needed redrawing, the app just stuck for a second.

So I looked at my code again, and although the method 'getPoiForVisibleRegion' is running in the background, the map operation that comes next is not! This is so because I only added the subscribeOn and observeOn methods inside 'getPoiForVisibleRegion' so the map operation that was called later was not included.

Ok, so I just need to include the subscribe method after the map declaration, right?

Not so fast, my friend.
Here's the catch. Google Maps can't get you the screen point while in background, so that means that I was able to run every other parts of my algorithm in RxJava but the intersection filter.

Back to the drawing table then.

Now I thought, what if I could get all the points for the currently visible markers before the filter, and make the actual filter run in background when it already has all the points?

And so I did just that. I created a HashMap that updates every time the map bounds changes (so that means zoom level has changed, or the map moves). I get the currently visible region of the map while still on the UI thread

mGoogleMap.getProjection().getVisibleRegion().latLngBounds;

Then I go and filter out only the markers that I should draw now. And I save a mapping between those locations to their point on screen

Viola!

The result was very satisfying! The map moves smoothly and the markers are getting removed or appeared on screen with a nice animation (not described in this post), without the user has to wait more than a fraction of a second, and more importantly without the screen ever gets stuck