The cornerstone of coding is the function. Study functions.
Ask HN: What would you recommend a vibe coder learn about how all this works?
41–44 of 44 posts
Re: Ask HN: What would you recommend a vibe coder learn about how all this works?
#42I'm a CS professor at an undergraduate college. I'm currently teaching a class on AI coding for non-programmers and also using Claude Code for all the projects in my upper level courses. I'm also planning to update our first course in the fall to include an intro to agentic programming. Here are some practical suggestions based on what I've seen with my students. To summarize: AI programming de-emphasizes the specifi…
This seems like the most helpful response for someone like OP. Is the curriculum or syllabus of your class public?
All of my course materials are on GitHub: https://github.com/dansmyers
The Programming with AI class is here:
https://github.com/dansmyers/ProgrammingWithAI
We're building it out as the semester goes on. Right now, it's mostly the in-class practice activities we're working through each day. This is the first time I've taught this version of the class so it's pretty experimental.
Here's the complete version of my intro class with notes, labs, and projects:
Re: Ask HN: What would you recommend a vibe coder learn about how all this works?
#43do an online cs50 course
Re: Ask HN: What would you recommend a vibe coder learn about how all this works?
#44If you are enjoying vibe coding, the biggest "aha" for me is realizing that software is mostly about managing state, data flow, and failure, not syntax. Once you get how data moves, where state lives, and what happens when things break, a lot of the "magic" disappears. Learning basic debugging and reading stack traces also compounds forever, even with AI. One thing that helped me: think a bit like a PM. Spend time cr…
This is exactly right. The mental model gap is the real risk for AI-first builders. The code works until it doesn't, and when it breaks you have no framework for understanding why.
One thing that helped us: externalize the structure that experienced developers carry in their heads. Things like test driven development or wheel-and-spoke based file size limitations etc. are the distilled judgment of decades of software engineering. But if you've never written code traditionally, you don't know they exist.
We formalized these into enforced workflows. What I found pretty exciting about it, from an educational tool standpoint, is that the side effect was that new team members and vibe coders working within those constraints started absorbing the patterns themselves. They learn why tests matter because the system won't let them skip them and learn why file size matters because the system blocks them and forces decomposition etc.