AI Features in WeWeb: More Harm Than Help?

Ask us anything
1

Hi everyone,

This has been on my mind for a few weeks, so I wanted to share it and hear what others think.

In my experience, AI in WeWeb hasn’t been helpful—it’s been unreliable. And to be fair, I don’t think this is just a WeWeb issue. I think “vibe coding” in general tends to create fragile, unpredictable results. I’ve seen people try to build apps this way and end up with something that looks good on the surface but isn’t stable enough to support real users.

I’ve personally tried to use WeWeb AI for small tasks. For example, I recently asked it to add a minimum character requirement to a password input. Instead of helping, it broke the logic—the button stopped working entirely, and I had to delete everything and rebuild it from scratch. I imagine others have run into similar issues.

My concern is focus. WeWeb is already a powerful no-code platform, and I think its biggest strength is giving users control and clarity over what they’re building. I’d much rather see continued investment in making the core no-code experience more robust, predictable, and refined—rather than putting energy into AI features that, at least today, feel unstable.

For context, I’m not a traditional developer. I’ve been learning by building—using WeWeb and Xano—and avoiding AI has actually forced me to understand how things work. That’s been valuable. It’s slower, but much more solid.

Even in cases where AI does produce something usable, there’s a deeper issue: if you don’t understand what’s happening under the hood, it’s very hard to sell, maintain, or troubleshoot what you’ve built. And problems will come up. If you don’t truly own the logic, you can’t confidently support it.

To be clear—I really like WeWeb. That’s exactly why I’m sharing this. I just think the platform’s strength is in empowering builders, not abstracting things away too aggressively with AI (at least not yet).

Curious to hear if others have had similar experiences or different ones.

2

Yes, I’ve experienced this myself. I’ve been working with WeWeb for a while now, and I’ve also been using the AI, which, like any other, doesn’t always deliver what you expect. But I’ve realised that this isn’t the case if you limit its scope and interpretation. For example, I’ve learnt that I can’t ask it to handle a complete workflow because, in some cases, it takes unnecessary steps and doesn’t adhere to the principle of ‘the simpler, the better’, so that it can be understood over time. So I use it more for key points that require JavaScript code, and that’s where you can really harness its full potential or its ability to create custom components.

In my opinion, giving it too broad a context causes it to fail, which is why, from my point of view, narrowing the scope is essential.

3

The best feature for me was the AI Formulas…

4

Agree with you wholeheartedly. Of the few times that I have used it, I get exactly the same results - it breaks something and it is the same with other app builders that I have tried.

As as you said, how do you support something if you don’t know how it works.

There are so many things that are requested by builders that are seemingly ignored all in the pursuit of building out AI agents. It is very frustrating.

5

Same here. The AI formulas where hugely helpfull and I used it a lot. After that diseappeared I havent been able to use the AI to anything helpfull even once.

6

Agree!!! After AI formulas disappearing is a torture to make each simple formula work..

7

I’ve been a WeWeb supporter since the early days, and I was genuinely excited to come back recently and see how much the platform has evolved.

What surprised me wasn’t that the AI has limitations. Every AI builder has limitations. The issue is that WeWeb’s AI often seems disconnected from WeWeb itself.

For example, I tried building a simple toast notification system using native WeWeb functionality. Instead of leveraging existing platform features, global formulas, reusable workflows, or other native abstractions, the AI immediately started generating custom JavaScript, creating unnecessary complexity, and referencing workflows through UUIDs that are difficult for humans to understand or debug.

That’s the opposite of what I expected from an AI built into a low-code platform.

The biggest advantage of low-code is structure. The biggest advantage of AI-assisted low-code should be that the AI understands and reinforces that structure. It should prefer native platform capabilities before introducing custom code. It should generate solutions that remain visually understandable and maintainable by humans.

Today, it often feels like the AI behaves similarly to every other vibe-coding tool on the market. Sometimes it works. Sometimes it doesn’t. Sometimes it confidently creates solutions that aren’t aligned with platform best practices. The result is burned tokens, repeated fixes, and a lot of manual cleanup.

What makes this disappointing is that WeWeb had an opportunity to differentiate itself.

Tools like Lovable, Bolt, and others are fundamentally code generators. WeWeb could have been the platform where AI generated applications that remained structured, transparent, and maintainable because the AI deeply understood the platform’s architecture and conventions.

I don’t think the AI is worse than other AI builders. In many ways, it’s comparable. But that’s exactly my concern.

WeWeb wasn’t supposed to be just another vibe-coding platform. Its value was always in providing a stable, scalable, and understandable application layer. If AI is going to be a core part of the future, I’d love to see it become much more opinionated about using native WeWeb capabilities first and custom code only when absolutely necessary.

That’s where I think the real opportunity still exists.

8

I’ve had some success with the AI. But generally this is scaffolding the front end for a new pop up and with that I pretty much give it the exact html equivalent design I want. Even then it will change static text that’s in the design I give it. It also added in some shadow box design that literally I couldn’t find in the actual editor. When I clicked any border or shadow stuff to see where it was the design it made went away and it wasn’t in custom css either. I have no idea how that’s even possible but I had to actually just redo that part myself cause it’d created a some design that was invisible to me in the editor.

I refuse to let it do any formulas, workflows or anything that requires actual data cause it 100% doesn’t do what I want.

9

Thanks for the thoughtful feedback @EvilHIdden, the way you describe how you would like WeWeb AI to be is exactly where we want to bring it.

You actually described our thesis: an AI that uses native platform capabilities first, stays visually understandable, and only goes to custom code when there is no native way to do it. That is exactly what we are aiming for.

As I mentioned elsewhere, this is a very challenging technical problem, but we made a lot of progress towards solving it and I believe that by the end of the summer we should be good.

The AI we are building is guardrailed by a deterministic JSON abstraction, and this is precisely what will allow us to offer “AI generated applications that remained structured, transparent, and maintainable”.

Although it might not feel like it today, we will get there, and at this point it is just a question of when and not if.

Thanks a lot for your patience and understanding. It’s a long transition, but it will be worth it! The product that will come out of it will be the best web-app building platform for non-coders and I’m very much looking forward to it!

10

thanks for the feedback @Yaj, we are working hard to improve AI’s reliability. Another month or two and it will be much better. It’s improving weekly. Thanks for your patience, I know it’s been too long already, but we are getting there!

11

I have to be brutally honest about this - I don’t think weweb will get there in time. And I say this as a fan of weweb - I’ve been using it for about 1,5 years now - only finally getting towards launching my first project, and already I know I’ll be completely rebuilding it with claude code once I manage to start getting users.

Personally, I think the company that has actually cracked it now is Xano. I connect to the MCP, I now use claude code, and claude generates the api functions in Xanoscript - and then I can use the ‘visual’ mode to see and edit what claude has generated for me. Meanwhile it has all the guardrails you need, I can have an api branch just for claude and merging allows me to revise everything first, versioning is built in - I have a seperate test data source, etc.

Personally, I only see survival of a no-code tool like weweb if we can have a fully mature tool like claude or codex to generate the front-end, and weweb to allow us to visually make changes to what the ai created. I have my personal doubts that the weweb team will manage to pull it off with an internal AI tool (whatever tech it runs on). Also because that AI tool will only be able to work with weweb’s own database workflows/api tools. Correct me if I’m wrong, but that means we’re headed to a situation where the weweb AI will either be fully functional if you use weweb unify / full stack - and if you use a different backend like xano or supabase, the weweb ai will only be useful for front-end. And I think that choice/trade-off be the biggest pain point for (potential) users.

For my platform, I’ve already chosen not to build the ‘backend’ (admin panel / content management) in weweb but claude code (astro/js/html) with the existing xano backend, and development has literally been at least 50x faster. Combine it with Cursor’s visual editing to quickly fix some layout and styling and you’re done…

I’m sorry but the tools around weweb are just moving at warp speed right now and it pains me to say it because I love the team behind weweb, their support and availability, but I don’t see it catching up and I do see myself moving away from it sooner than later.

12

Thanks for the response @Raphael, and honestly, I appreciate the transparency. The vision you’re describing is exactly why I was excited to come back and take another serious look at WeWeb.

I completely understand that this is a difficult technical problem to solve. Building an AI that truly understands platform abstractions, prefers native capabilities, and produces maintainable applications is significantly harder than simply generating code.

My concern isn’t really about the vision. It’s about the timing.

What I’m experiencing today is very similar to what another commenter described. While WeWeb is working toward that future, platforms like Xano have already found a workflow that is dramatically accelerating development for me right now.

With XanoScript, MCP integration, versioning, branching, testing environments, and the ability to inspect and validate what AI generated, my backend development cycle has become exponentially faster. I can use Claude Code, Codex, or other tools to generate functionality, then immediately audit, review, and refine it within a structured system.

That’s the part I think is important.

The real value isn’t necessarily AI generating the application. The value is being able to audit what the AI generated.

As developers, we’re ultimately responsible for the outcome. We need to understand the logic, validate security, review edge cases, and maintain these applications long-term. If AI creates something, there needs to be a clean, human-readable representation that allows us to inspect and modify it without reverse-engineering AI spaghetti.

That’s why I think WeWeb has a huge opportunity.

I don’t personally think the answer is trying to compete directly with every new vibe-coding platform. There will always be another model and another code generator. Those products are moving at incredible speed.

Instead, I think WeWeb’s advantage is the same advantage it has always had: structure.

If WeWeb becomes the platform where I can use Claude, Codex, MCP, CLI workflows, or whatever the best model is next year, while still maintaining a visual, auditable, enterprise-friendly frontend architecture, that becomes extremely compelling.

In my ideal world, I would be using AI-assisted development across both Xano and WeWeb, with complete visibility into what was generated on both sides.

We’re actively building a project on WeWeb today, and I’m genuinely rooting for the team because I think the vision is correct. I’m excited to see the continued MCP and CLI work, and I’m looking forward to seeing where things are by the end of the year.

I don’t think the challenge is whether AI can generate applications anymore. Plenty of tools can do that.

The challenge is whether AI-generated applications remain understandable, auditable, and maintainable by humans after they’re generated.

If WeWeb can solve that problem on the frontend the same way Xano is increasingly solving it on the backend, I think that’s where the platform becomes truly differentiated.

13

As developers, we’re ultimately responsible for the outcome. We need to understand the logic, validate security, review edge cases, and maintain these applications long-term. If AI creates something, there needs to be a clean, human-readable representation that allows us to inspect and modify it without reverse-engineering AI spaghetti.

This here!

14

What I love about the new Xano AI Agent for example is the review function before pushing to draft. This allows me to check and iterate before anything happens to my function stack. Even after that I always have the opportunity to revert the changes made After testing. This gives me the chance to try things out and never have to worry about AI breaking anything.

Would love to see something like that in weweb.

15

Sadly, we don’t even have branching