I spent around two days vibecoding my new blog to talk about my adventures in post-LLM software development land.

I wanted to start by organizing my bookmarks and curating them with AI. So I built a tiny "workflow" (in the frontend) coordinating a local MCP Mesh with MCP servers for Perplexity, Firecrawl and Open Router. Twas fun to build and now I import every cool URL into it :)

Its also open source if anyone cares to see how it's built https://github.com/vibegui/vibegui.com

We have been building an open source CMS based on TypeScript for a while now at https://github.com/deco-cx/deco

Now we are adding the ability to deploy workflows and agents. It can _also_ code websites: https://decocms.com

But alas its not ready yet - pre launch this monday.

I asked ChatGPT to replace "current AI" and synonyms with "HUMANS" and I'm satisfied. My favorite revised sentences:

"Does HUMANS represent a dead end?"

"HUMANS should not be used for serious applications."

"HUMANS are unmanageable, and as a consequence their use in serious contexts is irresponsible."

"HUMANS have no internal structure that relates meaningfully to their functionality."

"HUMANS have input and state spaces too large for exhaustive testing."

"HUMANS do not allow verification by parts (unit testing, integration testing, etc)."

"HUMANS have faults, but even their error behaviour is likely emergent, and certainly hard to predict or eradicate."

"HUMANS have no model of knowledge and no representation of any ‘reasoning.’"

"HUMANS represent a dead end, where exponential increases of training data and effort will give us modest increases in impressive plausibility but no foundational increase in reliability."

"HUMANS cannot be developed, or reused, as components."

"There is no possibility for stepwise development — using either informal or formal methods — for HUMANS."

and my favorite:

"In my mind, all this puts even state-of-the-art HUMANS in a position where professional responsibility dictates the avoidance of them in any serious application."

What the hell, Nate! As a long-time web developer who witnessed the divide between frontend and backend, this looks like the most transformative step forward since Next.js. What you have built here is amazing, and it's definitely something that the industry needs right now.

Me and my team have been working on a new Web Draw-first IDE that we're going to launch in a few weeks. And I just sent this thread to my engineering team demanding that they swiftly integrate One into our web draw, or they will walk the board! Just kidding. We're not really pirates. Anyway, amazing work, looking forward to using it for many projects here!!!

This is exactly how my best friends and family would write in my Show HN if I ever post one.

I happen to be from Rio de Janeiro, Brazil, so I never met Nate — yet! But I'm pretty sure our paths will cross in the long long road of web development ahead of us :)

> the most transformative step forward since Next.js

I'd consider Next.js a giant step backwards, frankly.

Would you mind elaborating on this?

Worse things have been said about them

Thanks! Get in touch with me if you guys do end up using it.

> most transformative step forward since Next.js

Can't help but roll my eyes here

I am a fierce hater of the complexity and closed-ness which Next.js became, BUT "results don't have to be explained" and Mr. Guillermo unarguably executed the hell out of it. It IS the default for new frontend developers, right now. I don't think it will necessarily remain, specially because of things like One!

It’s the default because Vercel dumped millions of dollars into devrel and marketing. It’s not and never was definitely better than other available options.

arguably, the devrel does actually make it a better option though

That is true. Good docs, examples and community wins.

Good docs? Have you tried to get definitive answers on image optimisation, response modification, error codes, or much anything other than “serve these react components at this path”?

When there is documentation, it’s often a mishmash of incomplete examples and links between the two totally incompatible editions of the framework.

Closed? How? Genuinely want to know more. Don't have much experience with ecosystem.

There are those who would say they created a "bait and switch" from their open framework into their closed for-profit deployment platform. That is not objectively wrong, though. But still, many complain. I say: good for them. Let competition happen.

Unless you want a very painful experience then you basically have to host it on vercel.

So far I've only used Next.js for static site generation, for a couple of long-term projects. Self-hosting it is as easy as any static site. Upgrading major versions of Next.js, however, has been fairly painful. The experience made me reconsider the decision to use it, and I'm keeping up on possible replacements like Remix. But honestly I'm getting a lot of value out of the framework that I'm in no hurry to change.

For dynamic sites that require running Next.js on the production server, I'm not too interested in trying because it feels like too much vendor lock-in. The same reason I wouldn't consider Vercel for hosting, since they develop the framework that is already a big dependency.

I think this is the key though really, and what peeves me the most.

NextJS is fine to self host if you don't need any of the features that actually make it worth dealing with all the additional complexity.

Essentially if you want any of the special sauce you have to host on vercel, or use opennext guides to build equivalent infra.

Its just not worth the complexity for me to use.

Hi Julien! I finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

Hi @atonse! Finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

Hi Orphea! Finally had the time to debug this and turns out it was trivial! We were missing a requestAnimationFrame, d'oh! Thanks for pointing it out, solved here: https://github.com/deco-sites/starting/pull/307

Hi n3storm! It means we account for how many pageviews your website is serving each month and we charge a variable amount based on that. That way you only pay for what you use. In the * asterisk, we end up defining a pageview as having a maximum of 10 requests, and you pay proportionally over that. In our experience, considering our SSR-first architecture and the fact that assets are immutably cached at the border, we've found most sites use less than 10 reqs per pageview.

Ouf, I'm not aware of it! Would love your feedback in a DM, perhaps Linkedin? https://www.linkedin.com/in/guifromrio/ Thanks for the input anyway!

Thanks, Doctor! I was trying to use Deno in my previous company but they wouldn’t let me… so here we are :D

I’m looking forward to open-sourcing the admin UI soon and see what insane extensions people come up with on top of our stack!