since this topic was closed in a rush in just about 48 hours, and it feels like there is more that can be said about it, I am going to be the annoying person reopening the discourse.
to weweb team: feel free to close/delete this if you think it’s not appropriate.
Providing proper types for components, wwLib, config, would be very much helpful to humans (documentation hurray!) and machines (actually meaningful context yeah!).
Local testing would add soo much value for a standard feedback loop time when developing.
Right now this 2 things would save so much more time to power users than any ai.
I personally recreated a local mockup environment and type inference just to speed up development of custom code components.
weweb makes it very easy to add custom code compared to other visual platforms, but it’s still not comparable to the dx you have in you own editor.
Hey Mariano 
,
Totally appreciate you reopening the conversation, no need to worry about being “that annoying person.” Starting a new thread like this is actually the right move.
We closed the original topic not to shut down the discussion, but because it was starting to derail the intent of the original post, which was someone simply sharing something they were proud of.
This kind of open, constructive feedback absolutely has its place in the community, and creating a dedicated space for it helps keep conversations respectful and focused for everyone involved.
So thank you for doing it this way, much appreciated.
great! love the platform too much, I needed to reply with my feedback. Hope it is helpful 
Funnily enough, Documentation for Custom Code was promised to be by the end of 2024. As for developing components, I simply do them in a Vue local env first, because the editor is unbearable.
100%!!
Give us this and enough proper documentation here and some of us might get tired of waiting for an MCP and we build it for the community as an open source project.
AMEN.
I’m sure the WeWeb team rolls their eyes at some posts from @Broberto and myself - but we would not kick and scream if we didn’t care. Team WeWeb should be happy we care.
And this was kinda the point I wanted to make re: MCP for wrapping into WeWeb components. There just isn’t a point IMO for WeWeb to put a lot of energy here where they don’t need to - because they just won’t ever IMO match the leading editors.
There is NO WORLD where advanced WeWeb users are not using leading editors IN ADDITION TO WEWEB.
So … if you accept that fact - then you focus AI efforts on what gives User most velocity excluding custom components.
This allows you to double down on ways to improve AI / prompt based requests by users to modify core components because - as you are well aware - if you create your own documentation of examples as context for the LLM specific to your actual core components - you will get better responses.
Where WeWeb CAN leverage AI best IMO - is laser focus AI efforts on the following:
A) First Draft layout using only core components from a prompt OR from a Figma file.
(Figma literally has a “First Draft” mode in their AI now - this is EXACTLY what WeWeb focus do)
B) Edit / update existing core components. Create “over documented” examples of modifying core components to feed as context to LLM(s).
Just LIMIT the scope of what you want to do with AI. Many of us learned the hard way that models are moving so fast now - that even tuning a model is now a complete waste of time.
The temptation is always there to try to “do ANYTHING” from a NL prompt … but that is a fools errand. If you understand what MOST of the prompts from your users are (and OBVIOUSLY you have that data - if you aren’t analyzing that you are insane) - you just focus on getting those results right. Because … the models will get better - even if you don’t.
If WeWeb literally sub-contracted a technical writer - or just a highly technical WeWeb user to create MORE documentation with many examples as context … the needle would move quickly IMO.
If you are waiting for your lead devs to “find a window” to create documentation … you are not being realistic. Sub contract a rock star technical writer to create your documentation - and then have your lead devs proof it.
Hey guys, I think these are very good feedback, thanks for sharing it with us.
There is no plan to work on the “internal” code editor for custom components for now, and making it easy to build & import them from another IDE is good.
It’s not a prio for now, but I’ve heard it 
Short term prios for the tech team: improve the AI (making it work with the design system, making it work as it used to with formulas), improve the onboarding experience, improve the documentation, improve the figma plugin, improve the datagrid, the new icons system and the new popups system, ship the new elements and fix bugs.
Awesomeness.
To be the “super squeekly wheel” here - " improve the documentation" is FAST and SIGNIFICANT ROI -not just for new users - but to support your AI in BOTH the Intercom support chat + your AI in the editor.
EVERY start up in the world underestimates how meaningful quality documentation can move the needle. Easiest thing in the world to supplement resources to (sub-contract technical writer, etc.) - most everyone throws it together at the last moments before release.
Just my 2 cents on the lowest hanging fruit.
and I just want to re-enforce Mariano’s post before leaving you alone (for a short while :)) -
yes 100%! + Mariano’s input are definitely good and taken into account - not a top prio but I logged them.
@Matthew_S is doing an amazing work improving the doc and it’s just the beginning.
Thanks again all for the feedback, good stuff!