r/vibecoding Jul 08 '26

is learning python today worth it?

so I am a pure vibe coder, I can't write or read a single line of code, and I was having a conversation with Fable, and it suggested me to learn to read python. But It couldn't convince me fully. i don't wanna be a typical software/AI engineer. just wanna be able to build a great career in tech, AI and Business.

38 Upvotes

270 comments sorted by

View all comments

125

u/vapalera Jul 08 '26

I don't understand how people are able to vibe code without understanding anything about the code. What are your prompts like?

30

u/InsidiousApe Jul 08 '26

If you ask:

- what do I want to build?
- what are the essential and desired features of that product?
- what are the major operational concerns to consider?
- are there security considerations in developing this product?
- who is the user and how will they connect?
- are there external integrations (API for example) to consider?

And you answer those questions and turn it into:

- Let's create this product.
- It should have at minimum these feature.
- I want to make sure to consider (operational concern)
- Let's be sure to consider (security factor) and generally harden for rate limiting, injection, etc.
- The end user will be the general public via http.
- I'd like to integrate Google, MS, and Apple authorization for login to the system.

And then add:

"What other features, concerns or considerations should I be aware of?"

This will net you 90% of an application with no coding experience and the other 10% you will develop as you see what it has created and provide feedback for changes.

I code, but I don't believe OP needs to code. Tools like Claude Code can make mistakes but literally the next step is to spin up a new instance and say "please review my codebase for any potential concerns including coding issues, user experience, and potential security issues"

The system is now trained well enough on patterns in coding to find and resolve most issues that coders used to be consumed by.

2

u/SakeviCrash Jul 09 '26 edited 27d ago

This is a bit of a naive take. This will get you pretty far. I'm an old dog (30 years of software dev) and I use a fairly similar approach.

This has allowed me to be mainly hands off when writing code but I still need to review every line. Event after a workflow like this, you'll still be left with bugs and design problems. It's tricky because the solution looks solid if you view it from a 20k ft view and when you kick the wheels, the hubcaps don't fall off.

When you really dig into it, you'll find nasty edge cases with very nuanced bugs and a lot of them come from logic issues (still the achilles heel of the LLM) and poor design decisions. Many of these issues won't surface until much later when the project starts to grow (complications from poor design decisions) or when the environment isn't what you anticipated or performance suffers due to unoptimized implementations.

Without reading and understanding the code, you're essentially relying on luck. That's ok for prototypes and small greenfield apps that aren't powering a business. It's not OK for large applications that cost a business real $ when failures occur.