How to Approach Vibe Coding Challenges

My biggest takeaways from Lazar Jovanovic (a full-time vibe-coder at Lovable): 1. Vibe coding is now a full-time professional career. Lazar Jovanovic gets paid to build internal tools and public-facing products using AI. His work ranges from Shopify integrations and merch stores to complex internal dashboards tracking feature adoption. Companies across the S&P 500 are actively hiring people with these skills. 2. Not having a technical background can be an advantage when vibe coding. People without engineering experience don’t know what’s “supposedly impossible,” so they try things that technical people might dismiss. Lazar built Chrome extensions and desktop apps with Lovable because he didn’t know the technical reasons why those shouldn’t work. The willingness to try anything until proven wrong unlocks capabilities others overlook. 3. Coding is no longer the bottleneck—clarity is. Lazar spends 80% of his time planning and chatting with AI agents and only 20% building. The ceiling on AI output isn’t model intelligence; it’s what the model is told and shown before it acts. Your job is to provide clear context and instructions, not to write code. 4. AI tools have a limited context window that you must manage deliberately. Think of it like a genie granting you three wishes. Every request consumes tokens for reading, thinking, and executing. If you dump vague requests, the AI spends the most tokens figuring out what you want and has little left for quality output. 5. Start five parallel builds to find clarity your thinking faster. Instead of overthinking one design, brain dump into the first project, get more specific in the second, add visual references in the third, attach actual code snippets in the fourth, and compare all five. This costs more up front but saves hundreds of credits and days of iteration later. 6. When you get stuck, follow this four-step debugging sequence. First, let the tool try to fix it. Second, add console logs to track what’s happening and paste the output back to the agent. Third, bring in an external tool like Codex for deeper diagnosis. Fourth, revert a few steps and try a cleaner prompt. 7. Use rules files to make your findings permanent. After solving a problem, ask the AI how to prompt it better next time, and then add that guidance to your rules.md file. 8. Design and taste are becoming increasingly valuable in the AI era. When everyone can produce good-enough output instantly, the people who stand out are those who understand emotional design decisions—fonts, spacing, micro-interactions—that AI can’t yet replicate well. Invest time in studying elite design work. 9. Build in public to land vibe-coding jobs. Lazar got hired at Lovable because he was already shipping projects, teaching on YouTube, and sharing knowledge on LinkedIn. Hires at Lovable submitted Lovable apps instead of resumes. The fastest path to a professional vibe-coding role is doing the job before anyone pays you for it.

I’ve been working on a massive prompt that extracts structured data from unstructured text. It's effectively a program, developed over the course of weeks, in plain English. Each instruction is precise. The output format is strict. The logic flows. It should Just Work™. And the model? Ignores large swaths of it. Not randomly, but consistently and stubbornly. This isn't a "program," it's a probability engine with auto-complete. This is because LLMs don’t "read" like we do, or execute prompts like a program does. They run everything through the "attention mechanism," which mathematically weighs which tokens matter in relation to others. Technically speaking: Each token is transformed into a query, key, and value vector. The model calculates dot products between the query vector and all key vectors to assign weights. Basically: "How relevant is this other token to what I’m doing right now?" Then it averages the values using those weights and moves on. No state. No memory. Just a rolling calculation over a sliding window of opaquely-chosen context. It's kind of tragic, honestly. You build this beautifully precise setup, but because your detailed instructions are buried in the middle of a long prompt -- or phrased too much like background noise -- they get low scores. The model literally pays less attention to them. We thought we were vibe coding, but the real vibe coder was the LLM all along! So how to fix it? Don’t just write accurate instructions. Write ATTENTION-WORTHY ones. - 🔁 Repeat key patterns. Repetition increases token relevance, especially when you're relying on specific phrasing to guide the model's output. - 🔝 Push constraints to the top. Instructions buried deep in the prompt get lower attention scores. Front-load critical rules so they have a better chance of sticking. - 🗂️ Use structure to force salience. Consistent headers, delimiters, and formatting cues help key sections stand out. Markdown, line breaks, and even ALL CAPS (sparingly) can help direct the model's focus to what actually matters. - ✂️ Cut irrelevant context. The less junk in the prompt, the more likely your real instructions are to be noticed and followed. You're not teaching a model. You're gaming a scoring function.

Vibe coding (AI) is destroying junior developers. Junior developers/students are barely typing the code manually, it’s just copy-pasting the code. Prompting LLMs in plain English to build a feature/project until it does it right for you is the scenario. Be it hackathons, projects, or anywhere code is being generated. Developers are barely understanding what’s written by LLMs because the pleasure of software/output/feature being built and working smoothly makes you lazy enough to look upon the code. As a new developer, the biggest mistake would be keeping the original learning aside for just the pleasure of things built by LLMs. Been using LLMs way consistently and here’s how I am making sure I am not just another vibe coder. Eg: If I want to build a feature which allows you to synchronously scroll on multiple iframes I would go to Google, Stack Overflow, Reddit and understand how other folks have implemented this feature. Someone would have used method (scroll top, left position), someone would have used a completely different approach. Now, as you got some context on how to implement them, I would try searching the code on GitHub (if it’s open source). After thorough knowledge research, I would then brainstorm with LLMs about “I am going to build sync scroll feature and these are the methods. Can you explain which one is the most efficient and why?” I would communicate with LLMs to get full knowledge about the implementation, and then after I have some code snippets or basic flow of the feature, I would ask LLM to build it for me the exact way which I desire. Doing this would give me understanding of each and every line of code. I would be in the driving seat and not LLMs. I would be feeling confident about how the code is working. LLMs giving you output is cheap dopamine: don’t let it hamper your initial learning years of programming :)

Teaching my 13-year-old son to code never quite piqued his interest—until we tried “vibe coding”. We’re now building a full stack application together. If you don’t know what vibe coding is, it’s a term coined by Andrej Karpathy which basically means telling an AI what to build, without writing (or even looking at) any of the code yourself. Why it clicked for him: – He realized he could start making immediate progress on building his app idea without learning everything required to build a full stack application – The AI doubles as teacher and pair-programmer, so learning happens along the way. – It turns “I wonder if…” into a working product in hours, not months—entrepreneurial rocket fuel. Our 5-step flow: 1. Product spec: We dictated the entire feature set to O3 using Superwhisper. O3 generated product_spec.md. 2. Technical design: O3 recommended stack options and trade-offs (React + TypeScript, Firebase DB + auth, Vercel hosting, GitHub) as well as how to structure the data and logic. After some back and forth discussion we landed on an approach and O3 generated a technical_design.md file. 3. Task breakdown: O3 split the work into bite-sized tasks including test cases and generated feature_implementation.md with the detailed task breakdown 4. Cursor: We dropped the docs into Cursor Compose (agent mode). We asked Cursor to implement each task one at a time including testing, running, fixing and to let us know when it thought it was done with a task so we could test it in the application. Each task often worked on the first shot, sometimes we had to tell it what wasn’t quite right and we kept iterating with it until it was working the way we wanted. We then check in our progress to github. 5. Human checkpoints: When a manual step popped up (e.g., creating a Firebase project), Cursor told us exactly what to do step by step, we did it, and the agent continued. 6. At the end of each working session, we tell Cursor to update a progress_report.md file with everything accomplished in that session and what’s next. This way we don’t forget where we left off. Why this is powerful: – Real progress in one-hour windows because we’re able to move so fast and because we don’t lose track of where we left off – He is now learning how all the architectural pieces fit together: frontend, database, hosting, and auth connect—without having to have learned all of those before even getting started. – The barrier to shipping is gone; if he can imagine it, he can launch a first version tonight. AI isn’t replacing learning; it’s accelerating it and removing the barrier to starting. These are immensely empowering tools for young entrepreneurs. Hand kids these tools and watch what they build. #AI #Coding #Parenting #Entrepreneurship

Vibe but Validate: Part II Last week, I spoke of the security responsibility gap in vibe coding—where developers, vibe coders, and AI platforms all lack the full context to catch vulnerabilities before they ship. This week: how to operationalize security for vibe-coded apps—without slowing down. Start by defining your security model upfront. Before you vibe a single line of code, ask: What data needs protection? Who should access what? What are the trust boundaries between frontend, backend, and database? Document this ‘blueprint’ and reference it in every prompt so the AI generates code that is secure by default rather than vulnerable by design. Engineer security into your prompts. Instead of “Create a login function,” be explicit: “Create a secure login using bcrypt with salt rounds of 12, implement rate limiting to prevent brute force attacks, add protection against timing attacks, enforce OWASP authentication best practices, and load all secrets from kms”. You can do this manually—OR better still automate it by embedding the above security ‘blueprint’ into every AI prompt via a pre-prompt template, system instruction, or configuration file, so secure-by-default logic is injected automatically across all generations. Apply Recursive Criticism and Improvement: prompt the AI with “What security vulnerabilities exist in this code? How can we improve error handling to prevent information leakage?” This recursive technique significantly reduces AI-generated code weaknesses. Leverage your existing Secure CI/CD pipeline for seamless validation. One of the major benefits of vibe coding is that once your AI‑generated code is committed to a code repository, it automatically moves through the same trusted security gates and automated checks as your traditional code—thereby inheriting the strength of your established CI/CD security best practices. The future of vibe coding isn’t just faster—it can also be safer. Automating security blueprints and validation ensures every line of AI‑generated code inherits your organization’s best practices from day one. #VibeCoding #AICodeGeneration #SecureByDesign #DevSecOps #VibeCoding #OWASP AIBound

This Reddit user made $0 with five vibe-coded apps before hitting $7K+ MRR with the sixth — and the difference had nothing to do with the code. Apps one through five all worked. They were functional, sometimes even decent-looking. But they sat in the app store with no users. No downloads. Nothing. The problem was the assumption: build it, and they will come. They did not come. For the sixth app, he stopped coding first. He spent two weeks on distribution before writing a single line. He researched what content formats were already working in his niche using a tool called Peerwatch to find viral hooks and video templates. Then he made his own versions — short-form content about the problem his app would solve. He posted consistently. He engaged with communities. By the time the app launched, people were already waiting for it. Early users became advocates. The growth compounded. He's now hired creators to post for him. The lesson he came away with is one most vibe coding tutorials skip entirely: the technical barriers to building apps have collapsed. Claude, Cursor, Bolt — you can ship a working app in a weekend. That part is solved. The new bottleneck is attention. If you're stuck on an app that isn't getting traction: stop building the next version. Spend a month on nothing but distribution. Find out where your users already hang out. Create content around the problem your app solves. Become a genuine part of those communities before you ever mention what you built. Distribution isn't the step after you ship. It's the step before you start. Have you cracked distribution for a side project? What actually moved the needle for you? #IndieHacker #VibeCoding #AI #BuildInPublic #LLM #ClaudeCode #AICoding

"Should I be vibe coding or doing AI engineering?" Wrong question. That's like asking whether you should Uber or learn to drive. The person who only Ubers is stuck when there's no service. The person who only drives misses productive commute time. The real skill? Knowing which mode to use—and being good at both. Here's the difference: Vibe coding = You describe what you want. The AI builds it. You evaluate by running it. AI engineering = You work alongside the AI. You understand every decision. You can explain any line. Same AI. Completely different relationship with it. Before I start any project, I run a 30-second test: 1. Who's using it? Just me/team = vibe code. Paying customers = engineer it. 2. How long will it exist? Days to months = vibe code. Years = engineer it. 3. What if it breaks? Minor inconvenience = vibe code. Real consequences = engineer it. 4. Do I need to understand the code? No = vibe code. Yes = engineer it. 5. Business logic complexity? Standard patterns = vibe code. Intricate rules = engineer it. If you answered "engineer it" to even ONE of these: engineer it. 5 patterns that make vibe coding work: 1. Describe the vibe, not just features. "Minimal and calm, like Apple Notes meets Things 3" beats "has a sidebar." 2. Build in phases. Navigation first. Then one screen. Then the next. Never ask for everything at once. 3. Be explicit about constraints. Tell it what NOT to change. These tools love to "fix" things you didn't ask about. 4. Use reference points. "Design this like a Stripe landing page" is more precise than describing aesthetics from scratch. 5. Accept 80%. Don't chase perfection in the tool. Graduate to engineering when you need more. 5 patterns that make AI engineering work: 1. Plan before prompting. Write down what "done" looks like before you touch the keyboard. 2. One task at a time. "Build me an auth system" produces mess. "Create the login endpoint that validates credentials and returns a JWT" produces code you can actually review. 3. Always review. One study found devs who felt 20% faster were actually 19% slower after debugging. The speed is in writing. The cost is in fixing. 4. Use linter feedback loops. Paste errors back to the AI. It knows exactly what to do with structured error output. 5. Test-driven prompting. Write the test first. Ask the AI to make it pass. Now you have verification built in. The golden rule: Don't commit code you can't explain. If you can explain it, the tool that helped write it doesn't matter. If you can't explain it, don't ship it. A year from now, the developers winning won't be the ones who picked the "right" tool. They'll be the ones who learned when to use each.

Here's one thing that separates a junior learning professional from a senior one. It usually happens when leadership makes a decision you don't agree with. Your team has been vibe coding projects and leadership has just made a decision. Going forward, vibe coded projects need strong rationale before being approved as a solution. The team has too many projects with no consistency, different skill levels producing different results, and no standard for things like how brand is applied. Making it difficult to launch and update projects. A quick definition. Vibe coding is when you use AI to write code for you, usually by describing what you want in plain language and letting the AI build it. You don't agree with the decision. You know you can move faster by vibe coding. And you already have a project where you committed to a timeline you're not sure you can make it any other way. Junior ➡️ You tell yourself this one time won't hurt. You vibe code the project, deliver it on time, and head out on a two week vacation feeling good about it. ➡️ While you're gone, your stakeholder has an emergency update and your manager has to step in. They look at your project and don't know how you exported it for the learning management system. They ask the team. Nobody knows. The project is blocked from being updated, your learners and stakeholder are impacted, and you come back from vacation to find out you've lost trust with your team. Senior ➡️ You set up a separate conversation with your manager. Not to push back, but to understand the root cause. You ask questions. What's driving this? What are the specific incidents that got you here? You're trying to get a clear picture before you react. ➡️ You're transparent about your situation. You explain that you committed to a timeline and were planning to vibe code the project. Then you come to the conversation with a different approach, one that lets you meet the timeline and keeps the project easy for anyone on the team to update. ➡️ You propose that while no one should vibe code right now, if you take ownership of solving the business continuity problem, creating standards, upskilling teammates, and writing an exceptions guide, then it could be a future option done the right way. You ask your manager to align on that path. ➡️ By handling it this way you earn trust with your manager, deliver your project on time, and become the person who championed a solution the rest of the team was hoping someone would bring forward so you can move faster for your stakeholders and learners. If you work around a leadership decision because you think you know better, you become someone who needs to be managed more closely. Seniority ≠ tenure. It’s the level you operate at in your role. When leadership makes a decision you disagree with, what's a giveaway that you're working with someone junior versus someone senior? #eLearning #InstructionalDesign #LearningandDevelopment #AIinLearning #VibeCoding

"Vibe Coding !== Low Quality Work: a guide to responsible AI-assisted dev" ✍️ My latest free article: https://lnkd.in/gjMdjMWV The allure of "vibe coding" – using AI to "move faster and break even more things" – is strong. AI-assisted development is undeniably transformative, lowering barriers and boosting productivity. But speed without quality is a dangerous trap. Relying uncritically on AI-generated code can lead to brittle "house of cards" systems, amplify tech debt exponentially, and introduce subtle security flaws. Volume ≠ Quality. A helpful mental model I discuss (excellently illustrated by Forrest Brazeal) is treating AI like a "very eager junior developer." It needs guidance, review, and refinement from experienced hands. You wouldn't let a junior ship unreviewed code, right? So how do we harness AI's power responsibly? I've outlined a field guide with practical rules: ✅ Always review: Treat AI output like a PR from a new hire. ✅ Refactor & test: Inject engineering wisdom – clean up, handle edge cases, test thoroughly. ✅ Maintain standards: Ensure AI code meets your team's style, architecture, and quality bar. ✅ Human-led design: Use AI for implementation grunt work, not fundamental architecture decisions. The goal isn't to reject vibe coding, but to integrate it with discipline. Let's use AI to augment our craft, pairing machine speed with human judgment. #softwareengineering #programming #ai