Techie Tinkering: Come vibe with me - Episode 2

 

Show these two characters holding hands and skipping towards the camera through a meadow

You asked for it, you've got it! Part 2 of my vibe coding series. Let's recap where we go to last time...

Where we left off 

We'd basically recreated my old excel graph and got it working pretty well: 

Pretty! 

...But I'd listed a bunch of stuff I'd still like to explore:

1. I'd like to press the "yes please" button to the database question and see how that works. 

2. I've not got as far as deploying the solution yet - keen to see what happens there. 

3. I've not really strayed from the happy path yet - what happens if you upload something weird? How does it handle exceptions?

4. For the sake of ease, I've been choosing the CSV file manually so far. I wonder if it's possible for it to go grab it from the raspberry pi. In my head I believe this is a step too far, but I wonder what replit will do when something is a step too far. 

5. I want to learn more about the UI implementation here - is it responsive? Can I get light mode? And what happens when we have months and months of data?

6. Can we make it bigger / more complicated? When does it start to struggle, both in terms of capability, and in terms of my needing to pay for it. Can I get to a stage where I have an opinion on whether this tech really does constitute a threat to software engineers? 

7. I've mentioned that I wanted feature parity with my original excel file. In retrospect I wonder - if I gave it that excel file to start with, would it have replicated the graph quicker? 

8. I realised that I tended to give my instructions to replit in a kinda technical way, referring to axes, series etc. I wonder if I'd talked in really plain English whether I'd have got the right result as quickly.

So, let's start exploring some of it! 

1. I'd like to press the "yes please" button to the database question and see how that works.

So, yeah, I asked it to create the database... 

It suggested that it go create a Postgres database behind the scenes and enable me to save info to that. Sounds good. 


Done. You can add stuff to the database, filter by dates. Just works! 

4. For the sake of ease, I've been choosing the CSV file manually so far. I wonder if it's possible for it to go grab it from the raspberry pi. In my head I believe this is a step too far, but I wonder what replit will do when something is a step too far. 

Given that it found adding the database so easy, I thought that this one was the most challenging thing to test it with. Would it be able to figure out how to access the raspberry pi? Only one way to find out... 

I have a raspberry pi pico that generates these activity CSV files and stores them locally on the device.

If I plug the raspberry pi into the computer, are you able to access the file there, without me having to manually download it and upload it into this program?
And, success...we've reached the edge of its abilities! 


The proposed solution is interesting though. Honestly, I'm not sure it's much use to me...but it will be fun to see how it does it. 

I'll stop doing step by step screenshots at this point and just add a few observations, as it all got a little scrappier. 

This was the first time replit seemed to struggle a little with the coding... we had to go through several iterations of it trying something out, me telling it there were errors, then it fixing those errors. 

It wasn't really difficult, or anything, but it lacked the "wow, it just works!" feeling that I've enjoyed with vibe coding up to this point...and felt a bit more like acutal coding and debugging. 

But, you know, it got there in the end. 

The page where it shows monitoring status.


It even added a nice configuration page.

You'll just have to trust that some of the data on this graph was uploaded using the file sync!

Is the honeymoon over?




Don't worry, we're not quite there yet...
I'm still having fun, but it does feel like I'm starting to bump up against limits. 

In order to really allow access to my file system (in order to drop the files in for syncing), I really need to deploy this thing locally - which I've not needed to do thusfar. For the purposes of testing this I uploaded the files into the hosted solution where it could see them. 

These meatier changes are also chewing through my free tier usage, too. 

As a rough guide, implementing the original solution to simply read the CSV files (and get into the state we started this post in) used about 27% of my allowance.

Implementing the database took this up to 44%.

And adding the sync folder took it up to 74%.

The last of these seems to deliver relatively poor ROI compared to the others and speaks to an issue - the more errors replit makes, the more you have to ask it to fix them.... and the more you ask it to fix them, the more of you allowance you use. 

So using 30% of my allowance isn't saying that I asked it to do something super-complicated. Just that it introduced a lot of errors in the process which it had to subsequently fix. 

I also feel like the solution isn't 100% how I'd do it. The way it's been implemented is fine. Maybe even better than how I'd do it. But there's something about it that feels one step removed. Like I've told someone else how to build their baby....rather than building mine. 

As an engineer I've always loved finding elegant solutions for problems...and this process lacks that joy, as I'm not the one providing the solution. On a professional basis, I also feel like I'd struggle to take ownership of this thing. I don't have any pride about having created it...and to try and prescribe the solution to the extent that I had that feeling would completely negate the productivity advantage I gain from building this way. 

Are there still positives?


Of course! Replit continues to go above and beyond in terms of the way it implements things.

Once I'd told it to implement the sync feature, I'd have anticipated it doing that in a fairly generic way - ignoring the context of where the file is coming from and just syncing the files from wherever they turn up from. And, to a large extent, that's true. You could drop files in there from wherever and it would work. 

But replit didn't forget the requirement I gave it - that I want to get these things from a Raspberry Pi - and whilst it told me it couldn't program the Raspberry Pi code itself, it did add a readme explaining what I should do to implement the other half of the sync logic:


As I said above, I implemented this solution not expecting it to be very valuable - as transferring a file to the sync folder is just as much effort as uploading it in  the UI. But if the above instructions work, replit has suggested a way of implementing this which is legit what I asked for. Impressive. 

Next steps

I think the next steps from here are pretty clear. I want to try implementing the above logic on the Pico and see if they work. And I'll need to deploy the solution to really test it out, which will tick another item off my todo list, anyway. 

Short but sweet 

I'll leave it there for now - I've ticked a couple of items off the list, but you should always keep your adoring readers wanting more. So I'll see you on the next one. Stay safe!