Currently playing around with @bolt.new after being inspired by @gabe and building a bunch of mini apps, mainly for fun. Haven't pushed any to production yet but so far I'm enjoying it bar the odd hiccup where I have to roll back a few times to fix a stubborn error.

I've also looked into @Lovable and it seems pretty cool but wanted to see what people had to say about it. Is there any reason to pick one over the other and which one have you settled on?

I've been having a lot of fun exploring AI and using tools like @Cursor, @bolt.new, @Lovable, and @Warp to learn how to build and make some apps for myself! I'm also noticing a tremendous amount of growth in folks creating their own apps using these same tools which has me wondering... if a company wanted to acquire someone's app or tool that was built via vibe coding, would it matter how it was built? Does the method of how it was built impact the valuation?
In my idealistic eyes, I'd like to think it doesn't. As an acquisition is often much more than just the tech but also the user base, brand, and even team behind the product. If anything I think that acquiring a product that has been "vibe coded" and putting them into capable engineering hands would only enhance the product...or a least make the code base cleaner.
I also believe that talent that is able to create stunning products with AI is currently a small percentage of folks, and that companies should be investing in acquiring that talent (either independently or via product acquisition) so that they can stay ahead in innovation while learning how to implement AI tools more efficiently in their orgs.
Very curious to hear what you all think!

if i use claude or codex, i constantly am screen capping to show bad padding / alignment / whatever. is there a defacto way to let claude or codex tool call to see the browser or render a page for themselves?

Been meaning to do this properly instead of just going off gut feeling every time my usage bar turns orange. Pulled together what I could find from benchmarks and my own week of switching between tools, and a few things genuinely surprised me.

The efficiency numbers aren't close, and not in the direction I expected. One widely cited test had Claude Code completing an identical multi-file feature task using around 33,000 tokens with zero errors, while Cursor Agent burned roughly 188,000 tokens on the same task and hit several errors along the way, a 5.5x gap for the same deliverable. Separately, other community head-to-heads put Claude Code at roughly 3-4x the token use of Codex on comparable work, so depending which pair you're comparing, the "efficient" tool flips.

Zero-shot capability and token frugality don't always come from the same tool. On raw benchmark performance, Claude Opus 4.6 sits around 80.8% and GPT-5.5 powering Codex around 88.7% on the metrics one source tracked, but Claude Code holds an 88.6% SWE-bench Verified score by another measure. The benchmarks genuinely don't agree with each other depending on methodology, which is its own lesson.

Price-per-output tells a different story than raw capability. Cursor's Composer 2.5 lands in the top three on capability index while running roughly 10-60x cheaper than the leaders, so if you're optimizing purely for $/task rather than fewest tokens per task, the ranking flips entirely.

In my case, the first app I vibe-coded, I learned that it is important for you to research market to see whether demand exists or not. Any app without demand and no low to no budget while starting will not work.

The lessons from second app was that in an extremely competitive market, if you don't have a differentiator, the idea simply will not work. Especially if you are creating a saas which many devs have already made and distributed before also.

One small change has made my AI coding sessions much easier to control.

Before asking the agent to implement a non-trivial feature, I now ask it to write a short implementation plan first.

I am building Rewire, a trading-psychology drill app, and the build is one person plus a set of AI agents with defined roles: a frontend one, a backend one, a QA one that walks the whole user journey, a perf one, and a few for marketing research and drafting.

What I spend my time on: writing the trading logic, designing the scenarios, and making the judgement calls about what a disciplined trader actually does in a given spot. The agents turn that into working code, tests, and a changelog, usually by the afternoon. I review every scenario and every deploy.

What changed for me: a build day used to end with a plan for tomorrow. Now it ends with something shipped. The tradeoff is that the agents are literal, so the specs have to be tight or you get exactly the wrong thing built well.

Two things I am still working out:

Do you ask the agent to write unit test, or any integration/e2e tests to cover the app regression? Or do you just test it manually?

Hey guys,

Quick question for those of you dealing with AI architecture and scaling.

Right now, we rely pretty heavily on n8n at our startup. It s been amazing for moving fast, tying APIs together, and automating workflows. But looking ahead, I'm trying to figure out the long-term play.

At what exact point does it make sense to move away from n8n (and paying for third-party LLM APIs) to actually build out a specialized, local RAG on physical hardware?

Claude Code is amazing. Agentic workflows just... work - at least better than last years options for vibe coding.
Things I've learned:
- .md files are a must
- architecture and context
- log history after every pass
- Short passes with initial creation, full pass with design is fine
- Fable is a hog.
- use ChatGPT or Gemini for UI/UX and design prompting, but not before you get Claude to chop down your architecture first to hand off.
- /clear
What other things do you use to ensure Claude is productive and doesn't break with a long term project?