I think the author is a bit behind the "complexity prompting" state of things. He says learning vibe coding is easy and he did it in a couple of weeks, but he also hit a wall and now its bugs everywhere. So maybe... there is more to learn?
I also hit the complexity wall and worked through it. LLMs are genius with arms that can reach anything but eyes two inches from the screen. As a metaphor, think of when a code base gets too big for one person to manage everything, people start to "own" different parts of the code. Treat LLMs the same and build a different context for each owner.
The key is to not get to a point where you lose sight of the big picture. You are riding a bronco - try not to get thrown off! If you do, ask the LLM to describe the structure of things or restructure things to be more consistent, etc. Get to a place where YOU understand everything, at least in an architectural sense. Only then can you properly instruct the AI forward.
I'll accept this criticism. I've only done it for a month or so. That said, I do feel confident that, after reading plenty of online articles, I have learnt 80% of AI coding skills.
I configured Playwright and PostgreSQL MCP. Loads of unit and e2e tests for Claude to run after each change. Storybook for my components. I have multiple doc files in each folder.
I'm happy to learn though and would welcome any suggestions.What am I missing?
Right now, I have a bug with my message queue. I didn't spend enough time thinking about the proper way to implement and test it. I guess I also didn't pay enough attention to the PR. But then, if I did, is it really vibe coding or classic software engineering while getting Claude to write for me with the added burden of reviewing it thoroughly?
The issue is that if a user sends a message to someone, quickly switches to someone else and sends a message, both messages get sent to the first person.
I'll have to figure out why it happens. My guess is that it's somewhere in the React app. Claude can't figure it out. What can I do to help it?
I had to learn the hard way that you need to know at least the structure of what the code should be doing. Vibe coding doesn't work for long if you just YOLO repeatedly, you need breadcrumbs back to sanity. If you get lost in the weeds the LLM can refactor itself back to understandability but it won't get there itself (at least not yet).
I know what the code should be doing. But it's not doing it. Now I have to deep dive into a codebase that's far less familiar to me than if I'd written it.
This isn't usually such a frequent issue because systems typically have dedicated owners. We structure it this way precisely because debugging someone else code is just harder.
As for the broader responsibilities. Things like architecting systems, shaping their structure and behavior, planning their evolution and keeping everything clean with regular refactoring. These sound exactly like what I've been doing for the past 15 years. So what's actually different here?
I also hit the complexity wall and worked through it. LLMs are genius with arms that can reach anything but eyes two inches from the screen. As a metaphor, think of when a code base gets too big for one person to manage everything, people start to "own" different parts of the code. Treat LLMs the same and build a different context for each owner.
The key is to not get to a point where you lose sight of the big picture. You are riding a bronco - try not to get thrown off! If you do, ask the LLM to describe the structure of things or restructure things to be more consistent, etc. Get to a place where YOU understand everything, at least in an architectural sense. Only then can you properly instruct the AI forward.