I keep seeing advice like use this model for the easy stuff and that one for complex problems. But it makes me wonder what really counts as a complex problem for an LLM?

For us, complex usually means lots of steps, deep reasoning, or tricky knowledge. But for AI, the definition might be different. Some things that feel easy for us can be surprisingly hard for models, while things that seem tough for us (like scanning huge datasets quickly) might be trivial for them.

Vibe coding makes it much easier for non-technical founders to build a first version, test an idea, and get real users without hiring a full engineering team.

But what happens when the product starts working?

You have users. Maybe even paying customers. People depend on it now. But the app starts slowing down, bugs become harder to fix, and adding new features feels risky because the codebase was built mainly to validate the idea.

At that point, the question is no longer: Can this be built?

I recently found a dataset on @Hugging Face that has a huge list of prompts. It's called awesome-chatgpt-prompts, but they point out that it's applicable to other models as well. There are some really useful ones in it along with some funny ones like Magician and Lunatic

I've found persona prompts like this to be really helpful, and I want to start trying out some of these now. I've even gotten my wife to start using some persona prompts in @ChatGPT by OpenAI and she's getting better results.

Recently I've worked with a group of non-corders trying to "vibe code" their apps with AI.
While knowing code is clearly not a must these days, it helps to get technical.
People who were familiar with basic software engineering concepts were 10x more likely to success and get better results.
So, with the hope of providing value to the non-coders people, I've created a quick roadmap for the basic terms and concepts you should be familiar with.

• Requirements: Building apps with AI is all about being able to clearly guide AI and express your app features and requirements.
  You need to be able to express those ideas and explain them as you d explain to a human developer. Think like a Technical Product Manager.

• Frontend: The face of your app.
  It's what your users see and interact with. It could be a website, a mobile app, or a desktop app. Most popular frontend libraries and frameworks are React, Next.js.

• UIs: They are the buttons, the forms, the modals, the tooltips, etc. In React, the UI is built with components. For design & styling, Tailwind CSS is the most popular library.
  For animations, Framer Motion is the most popular library.

• Packages & npm: Apps are not built from scratch.
  They are built on top of existing libraries and frameworks, like lego blocks.

  The most popular package manager is npm. For example, "react-hook-form" is a famous package that helps you build forms.

• Backend: The backend is the part of your app that runs on the server.

  It's where you store your data, your business logic.

  e.g: If you want to send an email, or process payments - this is where you'll do it.

  Vibe tip: Use minimal backends with serverless functions.

• Database: The database is where you store your data.

  It's where you store your users, your projects, your tasks, etc. Think of it as a big spreadsheet.

  I recommend using a database that is integrated with your frontend.

  For example: Fine, or Supabase.

• API: Real-life apps almost always need to integrate with other apps.

  For example: if you want to send email, or get weather data, or integrate with AI - it's all done through APIs.

• Hosting & Deployment: For your app to be accessible to the public, you need to host it.

  The code is usually hosted on GitHub, and deployed to platforms like Fine, Vercel, Netlify.

Finally, being comfortable with code is helpful - even if not a must.

AI often makes minor mistakes (like importing a wrong package), and if you re not afraid of reviewing code - you will get better results faster.

After rebuilding the same project three times because AI forgot my architecture, I got fed up and built @CodeRide (Beta) with my team.

The problem: AI code assistants lose track of your project between sessions. Every time I start coding with Cursor, Claude, or any AI assistant, I waste time re-explaining my codebase structure, architectural decisions, and coding patterns.

What we built: The project management tool for coding agents using MCP. Upload your project documentation or PRD, and CodeRide breaks it into optimized, fully contextual tasks ready for your AI agent.

I wanted to share a bit of my experience with vibe coding, because about a year and a half ago this project was basically just an idea.

I train regularly and use an Apple Watch, but I kept feeling that my fitness data was scattered everywhere. One place for workouts, another for recovery, another for fasting or hydration, and lots of metrics without much help deciding what I should actually do next.

So I started thinking about building my own workout planner.

At the beginning, I wasn't thinking about launching a company or even necessarily publishing an app. I just wanted to see whether I could turn the idea in my head into something I could actually use.

Today, traditional engineering interviews often revolve around DSA (Data Structures and Algorithms).
And while DSA tests analytical rigor, it also wires thinking into strict, logical frames.

Creativity lives outside those frames.
Problem-solving and creating experiences are two entirely different games.
And sometimes, forcing a purely analytical mindset can quietly erode creative instincts the very instincts vibe coders thrive on.

Which raises a bigger question:

Is the future of technology moving into the hands of more imaginative, creative builders rather than traditional analytical problem-solvers?

I ve been using a lot of AI-generated code lately, and while it definitely speeds things up, security feels like a weak spot.

I ve run into issues like missing auth, exposed endpoints, and weak configs stuff that AI doesn t really flag unless you explicitly ask.

Curious how others are handling this:

• Do you rely more on manual reviews or tools?

• Any workflows that consistently catch vulnerabilities?

• Have you faced any real incidents because of AI-generated code?

I spent most of my career doing non-technical work, and I now build our product, @HeyNews. I got there by talking to AI coding agents night after night. The catch: the agents are good company right up until 4am, when you're still hitting approve every thirty seconds and what you actually want is sleep.

So I built a loop I can walk away from and wrote up exactly how it works: https://blog.heynews.co/afk-codi...

Hey everyone

Like a lot of you, I use AI coding agents (Claude Code / Codex) daily, and token usage adds up fast especially on large codebases where the agent burns context just orienting itself.

I contribute to OpenObserve (open-source observability platform, large Rust + Vue codebase), and here's what's actually moved the needle for me:

1. CLAUDE.md / AGENTS.md files a short project map (architecture, conventions, key file paths) so the agent doesn't re-explore the repo every session. Biggest single win.

2. Scoped prompts over vague ones "fix the null check in parseQuery() in src/utils/query.ts" costs a fraction of "the query parser is broken, fix it."

3. Fresh sessions per task long conversations drag the entire history into every request. Clearing context between unrelated tasks cuts spend noticeably.

4. Plan first, execute second asking for a plan in plain text, approving it, then executing beats letting the agent trial-and-error its way through with expensive tool calls.

5. Right-sizing the model using cheaper/faster models for boilerplate and refactors, saving the big model for architecture and tricky debugging.