What non-technical People Should Actually Learn About Vibe Coding

A Bit About Me

I didn't come from a technical background. My career has been in logistics and e-commerce, working as a customs broker before moving into product. I've been working as a product owner for about 5 years, learning on the job. I'd watch developers work and think 'one day when I grow up, I wish I could do that. I still feel like I don’t know what I am doing but for some reason things are getting done.

Recently I found myself sharing my experience with friends, family, even other developers - experimenting with projects that stretched beyond the office into personal hobby work. I started with AI app builders like Lovable and Bolt before moving to AI code editors like Cursor. A new approach to what felt possible. The conversations kept coming up: "How did you do that?" "What should I focus on?" "How can I do that too?"

So I thought I'd share wider what has been useful as a non-technical person dabbling in code.

The Point

You don't need to learn to code. You need to learn what matters when AI is doing the coding for you. Whether you're using AI app builders, code editors, or chat-based tools like Claude and ChatGPT - It’s the concepts that matter. It's about understanding enough to ask the right questions and avoid catastrophic mistakes.

GitHub: Your Collaboration Space

GitHub is how you work with other people, AI assistants, and with your future self. It's track changes for code.

The collaboration part:

You're pushing changes to a shared repository. Someone else can see what you changed, why you changed it, and pull your work into theirs. Your AI assistant can read the history and understand what you've been building.

What matters:

• Whether to make your repository public or private – protect your work or share it openly
• Understanding when to commit (save a checkpoint), when to push (share your work), when to pull (get others' changes)
• Branches let you try things without breaking what works
• .gitignore keeps secrets and junk out of your repository
• You can see what changed between versions, who changed it, and why

You don't need to memorise Git commands. You need to know when it's time to save your work, when to sync with others, and when to try something experimental on a branch. Your AI assistant handles the actual commands.

APIs & Integrations: Connecting Things Together

Most of what you'll build involves connecting services. The key is understanding direction and configuration.

Understanding direction:

• Your app pulls data (API): You request information from Stripe, Google Calendar, whatever – when you need it
• Your app pushes data (API): You send information to update something – create a calendar event, charge a card, post a message
• External service pushes to you (Webhook): Stripe notifies your app the moment a payment succeeds – they call you

Your job in integration setup:

1. Configure the third-party system: Create an app in their developer portal, set permissions, get credentials, configure webhook URLs
2. Recognise the auth method (see Security section below) so you know what credentials to provide
3. Feed context to your AI assistant: Point it to the API documentation and define what you're trying to achieve – the same way you'd brief a developer. Clear goals and good context matter whether you're working with humans or AI.

When Things Break (And They Will)

Error messages usually tell you exactly what's wrong, even if the language is technical.

Copy the full error message into your AI assistant – it's often more helpful than describing the problem in your own words.

When debugging:

• Screenshot the error if it's visual
• Copy the console output or logs
• Describe what you were trying to do when it broke
• Show your AI assistant the relevant code

Worst-case scenario this is why you work on branches in Github. You can always revert changes and try again.

Security & Credentials: The Non-Negotiables

The basic idea:

Some things can be public. Other things can't.

Secrets never go in your code repository. Ever.

You cannot rely on AI to catch everything. But you can ask it to conduct a security review of your project. It'll give you areas to focus on, often with recommendations. You'll still need to make decisions along the way.

What to learn:

• Secrets live in .env files on your computer and in environment variable settings on your hosting platform
• Your code references these secrets but never contains them. If you accidentally commit a secret, assume it's compromised and rotate it immediately. Ask AI to help if you're not sure how.
• The different types of authentication – you'll need to recognise them when configuring integrations:
  • API Keys: Simple string you include in requests (like a password for your app)
  • OAuth: When users "Sign in with Google" – you get a token to act on their behalf
  • JWT tokens: Time-limited credentials that expire and need refreshing
  • Basic Auth: Username and password sent with each request (less common now)
  • Webhooks signatures: How services verify the webhook actually came from them

You're not building these systems. But when setting up an integration, you'll need to configure which method they use and where to put the credentials. Reading their setup docs becomes much easier when you recognise what type of auth they're describing.

Deployment: Making Things Real

A prototype on your laptop isn't validating anything. Modern platforms (Vercel, Netlify, Railway) watch your GitHub repository and automatically deploy when you push changes.

What matters:

• Different environments: Development, staging, and production should be separate. Each gets its own secrets and databases. What you break while testing shouldn't affect what users see.
• Monitoring and logs: Know when things break before your users tell you. Logs help you investigate what went wrong, when, and for whom.
• Understand the difference between serving 10 people vs 10,000 – know your platform's limits

Where This Actually Works

Functional prototypes: Build something people can click through to validate product concepts. Real enough to learn from, quick enough to throw away if you're wrong. I built a speech-to-text-to-speech language learning app to test whether the interaction model actually worked before investing in proper development.

Proof of concepts: "Can we integrate with their API?" Stop theorising. Spend a few hours actually connecting to it and find out. I built a Gondola ↔ Xero integration prototype to validate whether we could sync invoicing and financial data – answered the feasibility question in 8 hours.

Modifying existing projects: Find something close to what you need. Clone it. Customise it. This is often faster than building from scratch. I took Stellarium (the astronomy app) and modified it to accept custom 3D models – a customisation I wouldn't have even thought possible before.

Internal tools: That dashboard your team wants but its just not a priority? Build it yourself. Dashboards are rarely about how to display metrics – they're about which metrics actually matter. As a product owner, you're often the best placed to answer that question. Build the customer dashboard that shows the metrics you need, and you'll unblock decisions that would otherwise rely on engineering capacity.

Where to Be Careful

Don't use this approach for:

• Production systems handling real customer data
• Anything involving payments or financial transactions
• Features that need to scale or handle load
• Anything with compliance requirements

These need proper engineering. Your job is to validate the concept before you brief engineering properly.

What You're Actually Learning

Not syntax. Not commands. Not "how to code."

You're learning:

• Enough security knowledge to not accidentally expose credentials
• Enough architecture understanding to know what's feasible
• Enough API literacy to read documentation and understand integrations
• Enough Git concepts to collaborate without chaos
• Enough deployment knowledge to make things real

Everything else – the actual code, the commands, the syntax – your AI assistant does that.

Practical Reality

Start with something small. Clone an open-source project similar to what you want. Ask your AI assistant to help you modify it. Break things. Fix things. Deploy it somewhere.

You'll learn what matters by hitting real problems, not by reading tutorials.

And here's the liberating part: you don't need to remember any of the commands. That's what AI assistants are for. You just need to understand the concepts well enough to know what to ask for.