Vibe-code with confidence!

Note: This appeared as an X article in March: https://x.com/Bingeljell/status/2031771990940692903

The headline is a little bit of a lie - it’s more about being an ‘Agentic Engineer’ with confidence. The key difference being that vibe coders just want to 1 shot stuff. There’s no desire to learn and actually build. An Agentic Engineer may not be a comp-sci student or a programmer by trade, but is happy to get their hands dirty and learn as they build.

This article is primarily meant for those who are new to building, may or may not have a strong background with programming, or are coming back to it after very long and need a confidence boost. I fall into the last category: I started writing (very basic) code in the early 2000s when I built basic WordPress sites and did a lot of html/css work. If you can even call this programming. I last wrote code in the late 2000s - and wasn’t very good at it. But came back to wanting to build, with a vengeance in early-mid 2025. These are the things I’ve picked up along the way that have served me well.

In no particular order

Plan with a pro: Talk to your LLM (said pro) of choice in a completely separate thread and plan out what you want to build. Discuss your objective, the user experience you want and the technology stack. It doesn’t matter if you’re not familiar with the tech. When you ask it for different ways to build, it’ll also give you the pros and cons. Once done, ask it to give you a spec or a detailed product doc.

Note: I don’t mean that you need a pro plan to plan, but you will need one to build (tokens be expensive!). 😅

Get a 2nd Opinion: The great thing about foundational labs is that they give away a tonne of usage for free. So even if you’re subbed to one, you can get a lot of value from the others without paying. If you plan with ChatGPT, ask Gemini or Claude for a 2nd opinion on your product doc.

RTFM: This cannot be overstated. Reading the documentation is one of the best ways to get familiar with technology as a whole. I don’t understand half the stuff I read. I read it anyway. Months later, something will click. LLMs are great at explaining documentation too. I always prompt it to give me real world use-cases or examples. For complex abstract stuff, ELI5 style prompts are a great way to understand the concepts.

Know your repo: Step 1 is planning with an LLM. Step 2 is knowing how your repo is being built out. As part of your plan, understand the folder and file structure. When new features are being added, ensure your LLM tells you what it’s adding, and where. This will keep you sane when you hit some major bug or the feature you want isn’t working as intended, and everything seems stuck. Use this knowledge to prompt your LLM to work in specific areas of your repo when debugging or building out features.

Get familiar with the terminal: This was a big unlock for me. While many tools today don’t require you to be familiar — and this may not be a requirement in the future — getting comfy with the terminal will definitely be a useful skill. This will be true at least for another 12 months. Almost anything meaningful you do will boil down to doing something in the terminal.

Know your deps: I started ‘vibe-coding’ before TUI Agents were a thing. So I spent a lot of my time copy pasting, running and debugging code manually.

“Hey Grok I did what you told me to, now my laptop is on fire”…

I had to build out entire repos manually and that was a blessing in disguise. I got comfortable with IDEs, file systems, dependencies, etc… This meant that I knew what my app was built on and if something didn’t work, it was easy for me to go back to an LLM and tell it. Basically my prompts got more intelligent.

Read the Error logs: This is one of the best ways to learn. About 80% of the time it’s a syntax or formatting issue. About 15% of the time it’ll be a dependency issue. Only about 5% of the time is the issue really something that I have no clue about. Regardless, this also helped in making my prompting more intelligent. This may not be required in the future as LLMs will just do everything, but if your goal is also to learn, this is a good way to do that.

Git gud (kek): Use github or an equivalent and get comfortable with it. I’ve made tonnes of mistakes and a simple restore to a previous commit has saved me much pain. It’s also helped me collab with my Senior dev from the office. Github for vibers should be an entire article in itself, but suffice to say, git gud.

Commit frequently: See point 8. This bears repeating. I boldly test new tools, TUIs and models because I can just restore to a previous commit in Codex and restart dev from there.

Document everything: Have a robust docs/ folder. Since you’re not doing a lot of the typing, let the LLM be thorough in documenting stuff for you. Before I begin large feature implementations, I’ll have a detailed scope and plan doc. Whenever my agents are writing code, with each pass they have to update the change log and a progress doc. This allows me to review code (see below) as well as go back the timeline in case I want to undo any changes. My Agents.md file has explicit instructions on updating the change log and other necessary docs for each repo. This also allows me to be model provider agnostic. Session memory is good, but not a deal breaker anymore.

Play psyche games on the LLMs: Use one LLM to review the work of another, but gamify it. Incentivise good reviews and play the LLMs off each other. This is just a ‘deeper’ way to leverage point 2. I’ll have GeminiCLI review Codex work and vice-versa.

PS: Claude is the most opinionated of the lot.

Review popular repos: Whenever I come across an interesting github repo, I fork it, download it and then open up Gemini/Codex inside the repo and ask questions. There’s always interesting things to learn from popular repos. Eg: I copy @steipete’s script committer and took pieces of his AGENTS.md file which I now use across my other projects.

Deploy and deploy again: The easy way and the hard way. But deploy.

The easy way: Deploy to cloudflare, vercel, netlify, whatever else. You’ll understand how the internet works.
The hard way: spin up a VPS/droplet/instance and configure it yourself. Ask the LLM to guide you. You’ll really learn how the internet works.

I learned to deploy a python app in a docker container on a vps, a Laravel app on a bare server and multiple apps on Cloudflare / Netlify. I learned about github actions, cloudflare workers, wrangler… so many things. I’m now aware of how much I don’t know and need to learn. But also now aware of how I can think about doing things.

Use your LLMs to pen-test: When writing the LLM may frequently skip security best practices. But you can always ask it to review and do a security pass. Once done, ask it to give you curl commands to pen-test your own apps (see point 15). I do this regularly on public facing apps (we have 1 live and 1 about to launch for my company and 1 personal saas biz thedecentproposal.com — all tested and secured.)

Get comfy with Dev tools in Chrome: This was another really big unlock for me. Debugging can be annoying — esp when doing frontend stuff. Learning how to use dev tools was a life saver. Not just front-end, but inspecting your network and seeing what your app is sending and receiving is a good way to look under the hood. It also helps with security hardening.

Flex: Open up terminal in front of friends, family or in the office and leave it open as Codex/Gemini-CLI are building. Your dream of becoming a h4xX0r have now come true!

h4xX0r mode: engaged.

I’m definitely just starting out and barely skimming the surface, so it goes without saying that there’s a lot that I don’t know. Actually the more I build stuff the more I realise that I don’t know anything. I’m sure I’ll find new bugs, security issues and other bad practices as I continue to build and ship. But that’s the fun part. Most of X is happy to see you ship. Just be honest with yourself and you’ll actually learn a lot.

Obviously a lot of folks have helped me along so far, so a shoutout to some handles that have been especially helpful/useful:

@LLMJunky : some great articles and is probably the best community manager for Codex that @OpenAI could have asked for. Is also very encouraging!
@steipete has the best repos: github.com/steipete — Single handedly responsible for oss being super active and also for a lot of the AI slop out there (OpenClaw is amazing and scary lol)
@PaulSolt has some great tips that’ll make reflect from time to time
@shantanugoel has many cool projects and interesting tips, but I used his Oxydra repo for some deep learning too (github.com/shantanugoel/oxydra)
@fareesh (is a friend who keeps me safe and I owe him much)