How do I figure out what my app is actually doing?

Same here. I think vibe-coding is super fun and effective for a non-coder when the codes are really working. And it is frustrating when my AI can't help me modify the bugs and I just feel helpless by the fact that I don't know what is going on with my codes, either. But I think so far, vibe coding definitely brought more opportunities than challenges for me.

As a PM for 10 years, this is a very dangerous yet familiar situation.

Usually PMs own requirements but don't know what tech guys are doing in the codebase. To mitigate this, a typical PM can:

• ask the tech lead to take care of it

• ask the developers and receive a barrage of tech terms which most PMs don't understand

• ask the team to write documentation (but it all starts with the requirements and use case scenarios you should write)

Use case scenarios will lead to almost no white spots. E.g. you might write in the vibe coding prompt something like:

Create a payment form that will collect payments

It represents only 1 scenario - the ideal one. But what happens when the card fails? What happens when the user enters the payment but closes the page accidentally? What happens when the user gets an error?

For example, users might try to pay, but it errors out. And your support@yourdomain email suddenly gets blocked. How do you find out that your users can't pay (e.g. do you have logs, metrics and alerts?)? This is a 1st priority for the business covered by the mist.

So a pro-move for vibe coding would be this:

1. before coding, start asking questions. E.g. "I want to create a payment form that will collect payments. Write use case scenarios so that my users will always be able to pay, adjust for all possible errors on the codebase/server side and human mistakes on the user side"

2. after the use case scenarios are done (you can edit them out as you want), copy/paste them into the prompt and tell "Based off these use case scenarios create a payment form via Stripe that will collect payments"

3. a good practice would also be to tell it about what modules are already installed (e.g. my codebase uses Python+ReactJS+AlpineJS, here are my requirements.txt from pip freeze)

4. ask it to write automatic tests! Use your IDE to check if those tests are valid based of your use case scenarios

5. ask it to check vulnerabilities as well. It's important because hackers can sometimes bypass your system and, for example, get your product for $0.01 instead of $1000, for example. They can also do it multiple times, then fire chargebacks and just ruin your Stripe account this way. A lot of dangerous stuff can happen

6. ask it to create logs of successful or unsuccessful attempts of payments (with the error, IP, etc.)

7. ask it to create metrics based off those logs and alerts to your Slack/Telegram/email so that you could see if there's something wrong with your app

8. then based off those prompts and the codebase that it created, ask to write a documentation of this payment form module. If your project isn't big, let it throw down in README.md. If it's already big, use another document like payment-form.md

This should be a good start. Happy coding!

My POV:
I have only a vague idea of what’s happening in the code. I haven’t trained my brain the way old-school programmers did. They had to dedicate a lot of time and effort, and we often get results instantly, which means we tend to put less effort into the actual building process. And brain creates strong neural networks from struggle and repetition. What kind of struggle do we have when the code is written for us? :D

Shipping that booking system was a fluke I’ll admit it. Still, it taught me I needed better structure.

Not gonna lie, I vibe code to think through ideas. But I always rebuild once it makes sense.

I'm not against non-technical people building apps. In fact, I support it. But I'm strongly against the current vibe coding trend, not because of who is building, but because of how and why.

There's a lot of misleading information going around. People are making apps with the wrong intentions, and AI is being portrayed as if it can replace software engineers entirely. That’s not true.

Most people following this trend aren’t really learning how things work under the hood. They're just prompting AI tools, copying and pasting code, and building based on instructions given to them. They often assume tools like Next.js, Supabase, and Firebase are the best choice for every app because that’s what the AI keeps suggesting.

Take encryption for example. AI might give you one line of code and call it a day. But encryption is a deep topic. It takes time to understand and there are many important considerations when building secure apps.

I won’t go too deep into the technical side right now. But here are a few things I’d recommend:

1. Talk to a developer friend and ask about key software terms and concepts. It will help you write better prompts and make smarter decisions.

2. Before building anything, design the simplest version of your app on tools like Figma, Framer, or Bubble. Be clear about why you’re making it. Define every action and feature in detail like error messages, empty states, warnings, loading screens, etc.

3. Learn basic security principles on YouTube. After you build your app, ask the AI to help with writing unit tests, finding memory leaks, and suggesting code improvements.

4. Try writing pseudocode or flowcharts first. Use tools like tldraw, Figma, or even paper. This helps you break down features and understand the flow of each component before coding.

5. Write user stories and define tasks using the SMART method. It might feel slow at first, but it’s a good habit. It also helps later when writing documentation or release notes. If you want to see a great example, watch Jeffrey Way’s videos on Vue or HTML/CSS where he explains actions before writing a single line of code.

6. Also, if you haven’t already, watch the Silicon Valley TV show. It’s entertaining but also full of real-world tech lessons.

At the end of the day, it’s not about whether you can code. It’s about building a problem-solving mindset. Start small, build quiz apps, calculators, or directories. Then move on to more complex things like working with databases, APIs, and media files.

I fell into this when I first started, then quickly caught myself. I think first you have to decide what level of knowledge you want. Do you want to just know high level what each file does and the general ways to make a function? Or do you want to be able to understand every single line and be able to write code yourself.

Once you kinda have a goal I recommend:

• Choose a simple project and decide on a language (I did HTML, CS, and JS first then Swift for MacOS)

• Build SIMPLE so you can see, read, and understand. For the HTML example create a really simple landing page. For the Mac App, choose something like a button that triggers a notification.

• Read documentation and use ChatGPT to summarize and digest it.

• Google/Perplexity/ChatGPT the questions your thinking outloud and use Cursors Chat function to help explain the code to you.

All of the above helped me get a better grasp of what each file and portions of the code were doing which in turn made me prompt, build, and debug better.