Next steps as non-tech vibe coder

I joined a DX team a few months ago at a mid-sized transportation and logistics company based in Japan despite having no experience in tech.

Luckily, I found Replit early on and was able to design some internal tools using coding languages that are outside of the technical specialties of the current IT department (which is mostly tasked with the maintenance of various outdated and convoluted systems) at a fraction of outsourced costs.

The small scale tools that I’ve developed with replit are having real impacts and a positive ROI so far, but I’m beginning to encouter some problems since starting more ambitious projects.

My theory is that I am lacking the following key aspects of vibe coding in order to get the most out of Replit.

  1. system architecture basics
  2. an understanding of unit tests in order to produce meaningful data
  3. basic understanding of various terms and ideas to be able to interact with the agent on a more technical level (and perhaps more importantly to STOP the agent when we are not aligned)

There are a few vibe coding “courses” but they only cover the very basics concepts that I was able to pick up after a month or so of daily tinkering with Replit.

I would really appreciate if anyone with experience in the field could point me in the right direction on how I can overcome the current plateau that I feel a bit stuck on. Seems like I made a small step forward since experimenting with coderabbit.ai that Steve mentioned on an another topic but the overall progress has been unremarkable the last few weeks.

I read that perceiving a loss of momentum after the initial bump is common when learning how to code and I imagine its similar with vibe coding as well.

Please let me know if there is any other info that would give more context.

Thanks for your time!

1 Like

I think the courses only cover the basics because so much of it is get rich quick stuff by people who pump out “educational” content.

  1. Check out books from the library, or sign up for things like ByteByteGo - they have an initial book they’ll send out that is like 350 pages of architecture frameworks and guides depending on the type of product you’re trying to deploy.
  2. I use npm for unit tests. If you’ve implemented this or similar, work with Assistant and Agent to implement unit tests for all your pages. Then probe them on if they’re comprehensive enough. Once they’re implemented the data is super helpful, you can run npm test in Shell and it will show you where all the errors are. Work with Agent to fix them. Don’t forget to also run User Acceptance Tests to make sure that it all works on the front-end, too.
  3. Just keep learning. APIs and Databases are typically your best bet in prioritized learning. CI/CD and development pipelines are probably next. How to read and interpret errors, and how to find them (you’ve already identified testing as a gap, so you’re already a step ahead in teaching yourself how to identify knowledge gaps and what you need to close).

I’m big on be very careful the content you consume. There are too many get rich quick people on YouTube, so go to forums and see who people trend towards being real thought leaders. Follow https://www.youtube.com/@mattpalmer/ his videos have sped up ramping on Replit quite a bit for me.

I also really liked this video for teeing up how to talk with AI to improve your outcomes - https://www.youtube.com/watch?v=EWFFaKxsz_s

Finally, come back to here and see if you can help with the issues other people are facing. Teaching helps solidify what you’re learning, so even if they’re suggestions are based on what you’ve experienced, you’re putting learning into practice.

Similar issue here.

The advice I’ve received when I’ve asked is “just stick with it,” “keep learning,” “ask LLMs to explain/educate,” which are all insufficient advice.

It’s a doubling down on the autodidact approach.

What we really need in this vibe coding age is weekend bootcamps (or series) that are focused on addressing just the issues you mentioned, the key of which is a basic fund of knowledge of the appropriate framework/architecture for each case type.

  • So you’re building a marketplace, here’s what you need to know (essential toolkit).
  • So you’re building a multi-tenancy PaaS with RBAC and payment integration, here’s what you need to know.
  • So your AI Agent reassures you that you have built the perfect app with complete functionality and no critical bugs, yet the app fails in the real world. Here’s why and how to troubleshoot.
  • So your app is launched, but the run cost is exorbitant. Here’s how to optimize your code architecture and cache strategy.

Sign up for our 2-day crash course and learn the fundamentals. Network with peers and join our peer-driven community for continued post-seminar support and guidance.

1 Like

@rajharrykissoon ha! I tried setting something up - an online forum, £99/Yr introductory fee. It fell flat on its face when I spoke to people about joining. People are tight!:joy:

So instead I am now doing full app builds using replit. Complete done-for-you production-ready apps from £1500. And have a queue of people!!

So from my experience it seems there are fewer people wanting to learn the hard stuff than we all perhaps believe. And we are still in a “just do it for me” world.

1 Like

Yeah, I get it. And, the “just do it for me” wagon is what vibe coding is all about.

But, it’s not mature yet for non-tech vibers. And, considering myself, when I factor in the inefficiency and cost due to my knowledge and skill deficit, I’ve probably easily spent 4 months trying to debug one project with the attendant cost of those failed and frustrated efforts.

After all, there are essentially only two states for software development:

  • You are either building; or
  • You are debugging

The building is actually easy and cost efficient.

The debugging is the costly and time consuming bit. This is where 80% of projects get abandoned.

From a cost analysis for a non-tech viber, I image the analysis may be: spend $$$ for DIY debugging or $$ for human-in-loop professional service.

1 Like

Hi Shawn, thanks for the detailed response.

I’m waiting for the book now and the unit tests were surprisingly easy to implement by bouncing ideas off of both coderabbit and replit agent.
I’ll also check out mattpalmer when I have a bit more time.

You’re right about sharing my experience as well.
There are definately some simple tips that wouldve been very useful to know back when I was starting out a few months ago. I’ll share them below.

I might have found a short-term solution for non-tech vibe coders.

Ill explain below.

A quick update for my fellow non-tech replit users.

Use coderabbitai! (thanks Steve)

It seems to be able to take a more hollistic view of my entire repo compared to replit agent.
It identified some major problems with my build despite checking in with the replit agent several times throughout the build to ensure a stable and scalable system-architecture.

Here is the flow that I’ve been using:

  1. Have coderabbitai take a look at your repo and ask it to list any concerns it has regarding the system/code architecture by priority.
  2. Ask it to give a detailed plan on how to address the highest priority issue (one at a time)
  3. Feed that info to replit agent and ask it to consider the plan (I have a feeling the agent has much better context)
  4. Feed back any suggested changes to the plan back to coderabbitai
  5. Once cleared, copy paste the updated plan to replit agent and ask it to make a verbatim .md file.
  6. Begin the fixes by telling agent to follow the plan on the markdown file. Ensure that all phases and tasks are complete (the agent often ends up on a tangent unless you check in with the .md file yourself and ask it to refer to it often)
  7. Rerun a coderabbit analysis by asking it to check that phase X has been completed properly.
  8. If yes, go back to 2. If not, go back to 3.

Been feeling as though my apps have been held together by tape and hotglue but having a third-party app take a more hollistic look has been a huge confidence boost.

1 Like

That’s just how I plan to use coderabbit, so it is great to see you’re having luck with it. I will follow soon.

Btw, was your app held together with tape, or was it more solid than you thought?

It was more like a jenga tower. It looked fine at the moment, but trying to adjust a single block and putting it back it to make it whole again probably would’ve toppled it.

1 Like

yes, it can be scary fixing architectural stuff. But that process of asking the agent/coderabbit to prepare a series of prompts to do fixes one by one (and in a carefully thought out order) is key. Don’t try to fix it all in one big prompt - or the tower will definitely fall!