Vibecoding scouthappy.com

Teju Adeyinka
6 min readMar 1, 2025

--

Somewhere between the Replit Agent announcement and the Cursor-to-MRR craze, I, like many others, caught the bug to try building my own software. I had used low-code tools like Glide and Webflow in the past to create simple personal apps, but this felt wildly different — I wasn’t constrained to what the platform could do.

I started with a simple UI to demo an API my team was building, then a slack bot to fetch insights from customer data within Slack. Emboldened by the Twitter threads that told me I could ship the next Instagram in one hour, I started tinkering with creating a fullstack app. It took far longer than an hour, but I eventually made scouthappy.com, a board for helping talent in Africa discover global jobs and opportunities open to them. Scouthappy finds active opportunities online, filters them for accessibility to African applicants and serves them up through the website.

In many ways, creating software through prompts (aka vibecoding, h/t Andrej Karpathy) feels eerily similar to working with a very knowledgeable but inexperienced engineer. The agent is eager to build stuff and has a ton of technical knowledge but doesn’t always know how to direct it. This means that it jumps into solutions confidently without fully understanding the context or taking time to understand what has already been done. In particular, Claude-sonnet in Cursor seems to always begin responding to debugging prompts with “I see the issue…”. The first few times I encountered this, I was very excited because I thought there was a solution in sight. Eventually, I realized it was a ploy and stopped getting my hopes up.

Me, when Claude *clearly* doesn’t see the issue.
Claude after the umpteenth time of me telling it to check if something already exists. (If you have good tips for making this stop, please share with me)

The process is equal parts frustrating and exhilarating, but the end result — building something I’d been procrastinating for months — is deeply satisfying. For one, it taught me to appreciate the hundreds of tiny technical decisions that developers encounter after the big product trade-offs are decided — what and how much to log, when to optimize for reusability, when to just hard code something, database choices — the topics that software engineers passionately fight about on Twitter. It also made it clear to me that my favorite part of creating products is designing the end-to-end experience across different disciplines. It’s what I love about being a product manager, and coding agents make that easier.

There’s an abundance of ‘how to’ content for vibecoding, so it’s only right that I add my tips to the growing pile. Most of this should be intuitive to product managers — it’s what you already do for work!

  • Just like working with a human developer, the instructions you provide and how you provide them matter. In my case, I’ve landed on being very specific about the outcomes and the end result. Even when prompting for a narrow feature, I’ll provide context about how it fits into everything else and how it will be used both by the user and in other parts of the system. For example, when working on a method for categorizing jobs stored in the database, I’ll mention that it eventually will be used in the UI via a search bar and a category filter dropdown.
  • It turns out a picture IS worth a thousand words. A developer I once worked with always stressed the importance of showing over telling in PRDs and it turns out it works pretty well for coding agents also. I used screenshots from Figma & Canva to describe UI changes and Excalidraw to create simple workflow diagrams to explain logic. I would ask the agent to describe the visual it was seeing to make sure it understood before going ahead. Working in this way had the added benefit of helping me see through the logic and comparing it to the implementation and tests. I still think that the ideal UX for vibecoding includes an interactive system diagram that both the agent & human collaborate on.
Sample workflow on Excalidraw
  • Have a list of prompts for helping your agent think deeply about the problem. Unlike with a human, telling the agent to ‘think critically’ is not passive-aggressive and is surprisingly effective. Whenever I was stuck in a loop, I would ask Claude to “Think critically about the problem to get potential reasons and check {{name of specific folder}} folders to get full context.” 8 out of 10 times, it was able to break out of the loop of trying the same things over and again. Here’s another pretty handy one that someone shared with me.
  • Focus on one thing at a time. This is similar to creating focus around single milestones when working with humans. For projects with different moving parts, breaking up the work and only working on one thing at a time made a huge difference. In addition to getting better answers, it also made change management easier as I could focus on testing scoped changes at a time. To help with coordinating these pieces of work within the larger project, I maintained a ‘current_progress’ markdown file and often asked the agent to update it with changes as we moved along.
  • Use the agent to track changes in code before pushing to production. I always asked the agent to describe the difference between my local and remote files to make sure I hadn’t accidentally accepted some changes that the agent had made.
  • This goes against the etymology of vibecoding, but trying to understand what’s actually happening makes things easier and faster. While reading every single response probably isn’t a great use of time, having a working understanding will help with unblocking the agent. Ask “why” the agent is choosing to do something, ask for more details about the bugs you’re encountering. Sometimes, a bug is caused by something super silly and you can short-circuit it and tell it what to do e.g., “stop assuming the structure of that site and actually check the HTML.”
  • The final 20% really does take 80% of the time. In the case of this project, it took me a few hours to get the UI right and the basic backend setup, so I thought I only had a ‘little bit’ to go. It turns out that catching edge cases, adding tests, and making sure the logic works correctly across different cases is a ton of work. In my experience, the agent needed a lot of human collaboration here.
  • Breathe in, breathe out. You’ll need lots of it as you oscillate between thinking (and maybe screaming) “why are you doing this to me?!” and “wow, this is magical!”

Finally, massive props to products like Render & Vercel and all the open-source software creators that made deployments, handling databases, etc. a breeze.

And a special thank you to Cursor — the team at Cursor SHIPS! I joked with my friend that it felt like I used several different versions of Cursor throughout the project, each one better than the last. My favorite updates are the larger context window that lets the agent grep large blocks of the codebase and the new agent UX! I have a laundry list of feature requests, but for now, I’ll leave it at thank you.

All said, this was a fun excercise and I hope to build some more stuff!

And, if you live in or know folks who live in Africa, tell them to check out scouthappy.com & subscribe to get weekly updates.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Responses (1)

Write a response