I'm a big fan of voice dictation apps. In fact, I'm using one right now to write this very post (you'll have to wait till the end to see which one I'm using )

The two main products I've used in this space are @Aqua Voice and @Wispr Flow. From talking to others, these are the two that I typically hear people mention using. In general, I hear a lot more people talk about using Wispr Flow.

Stack settled into this after breaking it a few times:

Cursor for IDE work. Claude Code for longer agentic runs when I trust the spec. Codex for boring tickets while I'm in meetings. v0 when a client needs a UI mock in 10 minutes.

The thing that actually changed how I use all of it: stopped treating them as interchangeable and just routing by task type. Refactors go to Cursor. Full feature from a spec goes to Claude Code. Tedious backlog stuff goes to Codex.

Hey Maker community!

I ve been experimenting with the "vibe coding" workflow lately, and there s something incredibly satisfying about building useful micro-tools using nothing but a single `index.html` file in VS Code and a web browser. No npm install, no complex frameworks, no heavy configurations.

To prove the concept, I just built a quick "SVG to React Component Converter" completely client-side in vanilla JS. It handles the drag-and-drop, cleans Figma metadata, fixes camelCase attributes, and even displays a real-time preview of the icon.

It reminded me that sometimes we overengineer things when a simple script is all we need to solve a micro-pain.

Vibe coding with LLMs feels like having superpowers until you realize you're just swimming in a sea of digital spaghetti with a fried brain.

The tools are magic, but moving at 10x speed is a psychological trap. If you don't build a systemized framework around how you use them, you're not an engineer anymore-you're just an easily stressed middleman for an AI's hallucinations.

The real skill isn't prompt engineering; it's engineering management.

You have to treat the LLM like a hyper-fast, slightly chaotic junior dev. That means aggressively wiping your chat context clean the second a sub-feature works, forcing strict modular architecture so it doesn't vomit out a 600-line monolith, and stepping in the exact moment you hit a "3-prompt death loop" instead of blindly hitting generate.

Hands up who's worried with token costs? Yep, me too.

We were actually paying ~$5/year to keep track of our LLM costs for @Helicone AI. After the @Mintlify acquisition it wasn't the same .

I'm a veteran and solo founder with no formal coding background. Spent the last few weeks directing Replit's AI agent (with Claude as a strategic/QA partner) to build a real production app, entirely from my phone.

The part that surprised me: the "vibe" is the easy 20%. The other 80% was the same discipline any build needs catching bugs by hand (missing auto-capitalization, a timezone off-by-one, a file upload limit rejecting real phone photos), refusing to accept "it's fixed" without proof, running full walkthroughs section by section, chasing root causes instead of patching symptoms.

That's made me rethink what "vibe coding" even means. It's not skipping the engineering discipline it's relocating it. Instead of writing code, you're writing precise instructions, reviewing output critically, and doing QA like a hawk. If anything it demands more discipline, not less, because you can't rely on catching mistakes by reading your own code you have to actually test everything.

For others who've directed an AI agent instead of hand-coding: has your experience matched that, or did you find a different bottleneck? What ended up being the hardest part for you the instructing, the reviewing, or something else entirely?

Generating an MVP with AI agents feels like magic until you hit day 3, when components start drifting out of sync.

When you're prompting full-stack features, agents are great at adding code, but notoriously bad at cleaning up after themselves. A few patterns I keep running into:

1. Redundant state loops: An agent creates three different local state hooks to track the exact same data across siblings, causing weird hydration mismatches and flickering UI.

Hey makers

I ve been building an AI productivity platform over the past few months, and one of the biggest challenges has been deciding what users actually need versus what simply sounds like a good feature.

I started with focused tools for everyday tasks like writing, business planning, marketing, SEO, and productivity. As the product grew, I realized that adding more tools doesn t automatically make the experience better.

Now I m focusing more on making the overall workflow simpler and understanding which features people actually return for.

I was inspired by @chrismessina to build my own Raycast extensions after he released his own! I have been using Raycast a lot more thanks to a gentle nudge from @jakecrump (and @Raycast's latest AI releases), so I knew I wanted to build my own Raycast extension at some point.

There was a lot of news about Cyberpunk for Mac released and I wanted to search if there was a deal for it on PC. I instinctively went to search Raycast .but it wasn t there. So my extension idea was born!

My goal was simple: make it easier to hunt for video game deals right from the Raycast command bar. What followed was a rapid journey of prototyping, debugging, and learning. I m excited to share what I learned and hope it will encourage more makers to ship their ideas.
You can view my IsThereAnyDeal (ITAD) Extension on GitHub here! I will launch it when it's approved on the Raycast store :) I'll publish a more in-depth, nerdy guide later. But for now...here's my experience building a Raycast Extension!

I've been vibe coding for a few months as a non-coder and I'm still annoyed with the fact that I can't understand what's happening under the hood.

I've got a decent understanding of code but I can't actually write it and I don't know the best practices for stuff like architecture and security which apparently aren't baked into most vibe coding tools. So my question is...