framer's 2026 report just exposed the real problem with vibe-coding

according to the state of sites ’26 report by Framer,

70% of website projects get deprioritised because they're too slow or difficult to ship.

with the rise of ai and consequently vibe-coding, you might assume both challenges would be taken care of.

as someone who has used ai to get surprisingly far, surprisingly fast on simple and complex projects alike, some requiring api calls, types, complex logic, and more, i think vibe-coding has real use cases, but solving those issues is not one of them, at least, not yet.

while you can technically vibe-code an entire website or product, ship it, and have real users use it, it doesn’t mean you should. why? because vibe-coding often worsens the aforementioned issues in the long run.

in this piece, i’ll be exploring the dilemma of vibe-coding no one tells you, so you don’t invest hours and your all-too-precious creative juice into creating something that looks amazing, functions effectively, but still leaves everyone feeling remorseful, frustrated, and pissed after a few months.

why you probably shouldn’t vibe-code that website or product

i used to think vibe-coding was the future, and maybe it still is.

you know, with ai, you can write entire lines of code without having to worry about syntax, logic, or the codebase. and this often translates to greater ease and speed in coming up with working prototypes and version ones. but this ease and speed is not always sustainable for real products.

for the past couple of months, my workflow has been: open up a github repository, fire up codex or claude code (or both), and then start tossing rough ideas and screenshots into it. i used to take pride in this. feeling like a creative god, yeah?

after a few back-and-forths, i usually give it the go-ahead as i lie back and watch full screens of mesmerising designs materialise within minutes. it felt good… until i had to edit something some weeks later.

you see, ai makes it stupidly easy to get to “it looks amazing and works.” but the cost of that is that you may never really understand what the hell is going on under the hood.

now, you might wonder, “what do i care about what goes on under the hood? isn’t the whole point of vibe-coding to not bother with that?” and you’d be right.

but the issue is, websites and products need maintenance, and sometimes transfer. there will be things that need to be modified, added, removed, relocated, or integrated. and if you don’t understand how the puzzle was put together, how do you rearrange it?

and no, you can’t always easily vibe-code the modifications.

and that is where the fun ends, and misery begins.

the hidden cost of vibe-coding

in the past, if you had an idea, you’d simply go on a no-code platform like figma and manhandle pixels and elements until you got something that looked like your vision, though not functional.

but today, when you have an idea, you simply go to your preferred ai and describe it in plain english, and that gets translated into functional elements.

while this shift is great, as ai reduces the burden of dragging and dropping pixels, i think many designers skip a step by taking these ai-generated prototypes to be actual products worth shipping.

they are not.

i know, because for a while, that was exactly how i built and shipped things.

it didn’t take long to notice that whenever i tried to make structural changes to these vibe-coded projects, it quickly turned into a nightmare... one that lasted for weeks.

for instance, i recently took on a merch project. all i wanted was to build something that could get custom art onto a 3d, interactive mockup in a way that actually looked good and updated correctly. ai was amazing at getting me to a nice-looking first version with smooth interactions.

but when i came back to tweak it, i quickly realised that, unlike the usual visual editors — where i could click, drag, and interact with specific elements i see, with vibe-coded projects, you ask the ai to fix something… it says it’s fixed… and it clearly isn’t.

then you ask again… and it starts spiraling.

at some point, you realise you actually have to step in and figure out what’s going on yourself.

and because you didn’t write any of it, you end up digging through layers of generated logic, trying to make sense of decisions you didn’t make.

that’s when you turn into an archaeologist on your own project.

each time i needed to make a specific change, i ended up scrolling through long chat logs in claude or codex.

even when you explicitly tell the ai to prioritise existing components and props, it will acknowledge your instructions, and even generate a modified ui that looks consistent across pages, but underneath, every page with a “similar” component has a totally different class structure or slightly tweaked code.

instances get duplicated, detached, or silently forked for no clear reason, and your “system” starts to feel fucked.

after burning hours of token, you realise that the difficulty and time you were trying to circumvent have, in fact, not been circumvented. and, who do you blame? chatgpt?

according to the report by Framer,

30% of professionals say that ‘clear ownership and accountability’ would make it easier to work on website projects.

ai helps us ideate faster, explore quickly, and iterate without burning out. but when systems and structures matter — when you need to maintain, extend, and trust the thing — you need more than vibe-coding.

you need someone who understands what is under the hood, and a system that gives you control and ownership.

the right way to vibe-code

framer is a powerful platform that gives you real control over your website. my portfolio website (jameschimdindu.framer.website) is built entirely using framer.

once you open the site, aside from the pretty interface that comes in both light and dark mode, along with state management, you’ll immediately notice it has a working puzzle, a background music player, and multiple page routes that all seamlessly wrap into the homepage. during halloween, i even had a 3d pumpkin animation on the site.

it is a complex site, yet easy to maintain.

even if i decide to add more features tomorrow, it won’t break the website or overwhelm me.

so how am i able to do all that on a no-code platform?

well, i vibe-code the features.

i still use tools like codex or claude to generate the code.

but, framer gives me a structured place to put that code, through its code components (and workshop). instead of raw, scattered output, i plug in functional codes into a system that can actually hold it together, in a structured manner.

so, i basically “vibe-code” each feature and add it into framer as a code component. but i also expose those component properties to framer, which enables me to actually manage the vibe-coded features.

this way, i trust that components behave as they should. and when i update something at the source, i know where it will ripple and where it won’t.

i can name, document, and structure the design.

and that structure matters more as complexity grows.

because if there is no clear way to iterate and ship updates without ruining everything, then the project either stalls or resets every time something needs to be modified.

and this tracks with findings from the aforementioned Framer report which states:

a website is never done. 53% of website work is general edits and fixes.

and:

69% of respondents say design flexibility matters most when choosing their tool.

in other words, by giving you greater flexibility and maintainability, framer helps you truly build easier and faster.

conclusion: a good design scales and is transferable

i am not asking you not to use ai for your design projects.

god knows i hit my claude code and codex limits four, maybe five times some days, across three chatgpt business accounts and one claude pro account.

i use ai obsessively.

but i’ve also learned how not to use it.

humans used to be responsible for all the changes in projects. now, because “ai can do it better,” we’ve mostly handed those changes over to ai.

but as we’ve seen, that creates more issues than it solves.

that’s why i no longer try to vibe-code everything.

some things shouldn’t be vibe-coded.

if you’re exploring ideas, prototyping in private, or just having fun pushing ai to its limits, vibecoding is amazing.

but do that knowing those outputs are better seen as sketches, not systems.

to build a system, you need structure.

if it’s a site or product your business will live in, or something you intend to hand off to others, you need a real system behind it.

and for me, when it comes to websites, that system is Framer.

if there is something the rise of vibe-coding has exposed, it is that good design scales and is transferable.

which is why i obsess over layer naming as i perfect my pixels, but that’s a topic for another day.

if you found this insightful, consider subscribing… or not.

thank you for reading my stuff.

keep shipping!