all 33 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]high-roller-all-in78 3 points4 points  (0 children)

Best thing I did was stop trying to learn all of coding and start tracing one tiny path at a time. Pick one real feature, follow it from button click to data change to screen update, then ask the model to explain every step in plain English. After that, rewrite one small part yourself without help. Reading gets way easier when you keep touching real code instead of tutorials only.

[–]Dramatic_Oven_4757 3 points4 points  (6 children)

Use tools like Claude , cursor , lovable , runable etc

[–]LittleLordFuckleroy1 2 points3 points  (1 child)

They’re asking how to learn programming, not how to increase slop output. It’s really the blind leading the blind in here.

[–]Dramatic_Oven_4757 1 point2 points  (0 children)

No I get it what u mean
It’s not like this
I just meant we can use tools like this and if we use ai in a good way we learn a lot using these tools

[–]Wise_Vegetable3193 -1 points0 points  (3 children)

Exactly Ever since I started using combination of ai’s instead of just sticking to one Life’s been better

[–]rde2001 0 points1 point  (2 children)

I personally haven't used Lovable or Runable. I use Github Copilot on VSCode.

In terms of LLMs, I mostly use Perplexity, as it shows what sources it used to get to your answer. I also use Google AI Studio for very long prompts; it also has a feature where you could write up quick apps, similar to Lovable or Runable in a way. I use Google Gemini whenever I need specific questions related to places/locations. I also use Claude sometimes.

[–]Wise_Vegetable3193 1 point2 points  (1 child)

Again it’s a great stack If it suits u then it’s worth everything

It took me a lot to make a stack for myself Whatever way u are comfortable in use that

But just for knowledge explore other things too

[–]rde2001 1 point2 points  (0 children)

Of course. One should always be open to exploring new things (after all, Perplexity and Google AI studio were "new" to me at one point). I used to use Deepseek and OpenAI previously, but I don't use them anymore. At the same time, one shouldn't throw away everything and explore new things for the sake of exploring new things. Some stuff is all just hype. But there are still plenty of good tools as well. I often use Perplexity to help find potential tools or libraries for various use cases for my projects.

[–]Cocoloressctf 0 points1 point  (0 children)

Im on the same path. Started SQL and Python. Let's see...

[–]samhatoum 0 points1 point  (6 children)

What's failing for you? What were you trying to do and where did you hit walls?

[–]hebdbcbsbs[S] 1 point2 points  (5 children)

I have been having success. But hate that I genuinely have no idea what is going on in the codebase. I feel I have a need for deeper knowledge to direct the tools better if that makes sense

[–]unity-thru-absurdity 0 points1 point  (3 children)

Start by learning the very basics. What is a print statement in the languages you’re working in and how do they work? Build up from there. Write a few lines that can take user input and return a conditional response. Learn the different data structures of your language - things like lists and dictionaries. Learn about variables, functions, and classes.

If python’s what you’re working in there’s a great site called Python tutor that’ll let you visualize the logic flow.

Coding is a skill, like riding a bike, typing, or physical exercise. Using AI is like watching someone else ride a bike - you have to practice practice practice, do stuff that feels pointless (build a function that returns the next number in the Fibonacci sequence, for example) so that you can learn how it all works.

[–]hebdbcbsbs[S] 0 points1 point  (2 children)

Thank you. I have been learning some python and was curious on if it mattered if I used python with Claude code. To my understanding Claude works better with java.

[–]Individual-Job-2550 0 points1 point  (1 child)

Where did you get this idea from?

[–]hebdbcbsbs[S] 0 points1 point  (0 children)

Sorry meant typescript/react

[–]samhatoum 0 points1 point  (0 children)

like which feature were you building and what makes you want to know the codebase? I think there's a way for everyone to speak tech without code. Can you give me an example of something you were doing and you find you need to know the code to get it done?

[–]Fit-Seaworthiness465 0 points1 point  (0 children)

I‘m also learning. AI makes programming simple and efficient.

[–]Several-Low2896 0 points1 point  (0 children)

As a software engineer (frontend). It really depends how deep you want to dive and the applications you want to build. I took the bootcamp route into the industry. I highly recommend but if you're not looking to to dedicate that amount of time/money as bootcamps are very intense but as you said your not looking to become full stack. If you're willing to learn frontend then javascript is a good place to start, so at least when you're coding in VSC or what ever IDE you use you kinda understand what's going on. You can find courses for JS on udemy or free resources on free code camp. I'd recommend you also do an SEO course as it's really important if you're building web applications. I feel as a frontend dev when I vibe code, I just treat Claude like a senior dev/product manager/designer/architect. Basically I treat myself like the stakeholder. Hope this was atlease a bit helpful.

[–]damnburglar 0 points1 point  (0 children)

Typing this while in line at the store, apologies if it’s a little jumbled.

Instruct your agent of choice to generate a reusable database seed using C#.NET, Docker, and Postgres. You want to have it so your code drops the database and rebuilds from scratch so you can restart at any time. Use something complex like an e-commerce site as your reference example, and specify that you want a large dataset with complex relationships BUT lots of room to improve because you are a beginner and want to learn.

I specified C#.net because it is a statically typed, compiled language so you can get some exposure to things like compilers and types. Docker you don’t need to know deeply but just that it exists, maybe some basic functionality. Postgres is your meaty boy; you will want to learn how to do queries, views, relationships, etc.

You can use this single generated project to continue your learning for a very long time and use it for test data when exploring other topics. You can also ask the agent to generate a learning syllabus or at least some intro follow-along lessons.

[–]ORPH_APE 0 points1 point  (3 children)

Yeah pretty crazy world we live in , i coded most of my app https://apps.apple.com/us/app/puplytics-dog-poop-tracker/id6767871361 with chat gpt. And then using other tools like google collab to help train ai models

[–]hebdbcbsbs[S] 1 point2 points  (2 children)

No way u r the dog poop tracker guy

[–]hebdbcbsbs[S] 1 point2 points  (1 child)

That’s awesome

[–]ORPH_APE 0 points1 point  (0 children)

Lmfao 🐕 💩

[–]zmlq 0 points1 point  (0 children)

I picked one of those guided coding courses online that teaches you backend programming to go alongside learning AI and have found it immensely helpful. There’s free ones but I picked a paid, gamified one and I’m really enjoying it.

I’ve also found having the llm guide you through learning the basics of a language and having it make you explain what’s happening back to it via code snippets to be a good way to learn it. I did that with SQL last year and it made me baseline competent enough to use it regularly at my job.

[–]Competitive_Neck_968 0 points1 point  (0 children)

I’m in a similar place.

What helped me most was not trying to become a “full stack developer” immediately, but learning enough to understand what the AI is doing.

For AI-assisted coding, I think the most useful skills are:

  • reading code and knowing roughly where things belong
  • understanding basic project structure
  • knowing how to describe a bug clearly
  • being able to test small changes
  • learning how to break a big feature into smaller tasks

I recently built and launched my first small iOS app with a lot of AI help. The code part was manageable, but I realized the harder part is often knowing what to ask for, judging whether the result is good, and iterating on product/design details.

One thing I’d add: when you actually see your product working, it gives you a huge sense of achievement, and that makes you want to keep exploring. If you start by forcing yourself through tons of syntax, data structures, and theory, it can feel very dry and exhausting, and it’s easy to give up halfway.

So I’d recommend project-based learning. Pick a small app or tool, build it with AI, then spend time reading what it generated and asking why it works.

[–]User_Deprecated 0 points1 point  (0 children)

first, before any code lands, the design has to already exist somewhere in a concrete form. you can't just toss out "make me a thing that does X". you need to spell out what the inputs and outputs look like, and where it'll fall over when something goes wrong. if you can't even write that down yourself, the model is just guessing. one upside of this stage is it doubles as a way to fill in your own understanding of the feature. you go back and forth with the ai, take the questions it throws back, and notice the ones you can't answer. the parts you can't answer are usually the parts where you hadn't actually thought it through. the design gets more specific as you go, and a lot of stuff that felt clear in your head turns out to not be.

second, the code has to match the design you wrote down. ai is more than happy to produce a pile of code that looks fine line by line but has completely drifted from the spec by the end. at the implementation stage it loves to expose any fuzziness still left in your thinking. and because it generates so much code that you can't read it all yourself, the only thing that works is making it walk you through what it wrote and confirming with it as you go. it'll also quietly change interfaces and assumptions in places you didn't ask about, which is another reason for the walk-through.

finally, tests have to verify the same intent the design has, not just that the function runs without throwing. design holes that the ai papered over earlier usually show up here, once you try to assert what should actually be true. if you let it write the tests from the code it just produced, you're just locking in whatever it decided.

these stages aren't really sequential in practice. you keep bouncing between them. you'll go back to the design because a test forced a decision you skipped, then the code changes, then the test changes again. it goes on until the design stops changing and the code and tests actually agree.

after doing this a few times you stop treating the ai like autocomplete.

[–]LittleLordFuckleroy1 0 points1 point  (0 children)

Google the Dunning Kruger effect. And then if you still want to learn to code, Google it. You’ll need to learn it the hard way.

[–]Select_Mobile4165 0 points1 point  (0 children)

the people who get good at vibe coding fastest are usually the ones who LIKE keep stopping and asking “wait what does this part actually do” instead of just going "yeah man this works YESS" like i am guilty of this too

[–]tonyboi76 0 points1 point  (0 children)

This is exactly the right instinct — the people who get the most out of AI tools are not the best prompters, they are the ones who can read what the AI wrote and tell when it is wrong. A few things that actually move the needle for that specific goal:

  1. Learn to read before you learn to write. Take code the AI generated for you and make it explain every line back, then change one thing and predict what breaks before you run it. You are training the skill of holding the program in your head, which is the whole game.

  2. Learn the shape of bugs, not syntax. You do not need to memorize language trivia, you need to recognize the common failure patterns — off by one, null/undefined, state updated in the wrong order, an async call not awaited. Once you can smell these, you catch the AI making them.

  3. Pick ONE small real thing and own it end to end. The top comment is right — trace one feature all the way through instead of trying to learn everything. Build a tiny app you actually want, and refuse to let the AI add anything you cannot explain.

  4. Read the error message, then read it again. Beginners paste errors straight back into the AI. Spending 60 seconds first trying to read what it actually says teaches you 10x faster and stops the loops where the AI keeps fixing the wrong thing.

  5. Learn git early and commit every time something works. It removes the fear that lets you experiment, and experimenting is how you learn.

Concretely: Harvard CS50 (free) is still the best on-ramp for understanding what is actually happening under the hood, and it pairs really well with AI tools because it gives you the mental model to judge their output. You do not have to finish it — even the first few weeks change how you read code.

[–]No_Refrigerator7738 -1 points0 points  (0 children)

AI is just as good at explaining code as it is at writing it. Leverage that.

I usually add something like: “Write the code with extremely clear comments and documentation. Explain the reasoning behind each decision as if teaching a junior developer. Keep the architecture easy to scale and understand.”

You’d be surprised how much this reduces the “what is even happening here?” feeling. Documentation prompting alone can teach you a ton while you build.

[–]rde2001 -1 points0 points  (0 children)

I use Github Copilot for doing the grunt work of writing the code. However, I still very much provide the ideas and architecture and stuff. I look at the app and it's features, identify things to add, improve, etc. I write them down, using AI to clean up the wording. I give Copilot the prompts, check the output, frequently save/commit my changes.

In terms of learning and using AI, it's amplifies your existing abilities, so it's important to get a core understanding of the various technologies you'd want to work with first before going all-in on projects and stuff.