Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I like the idea. This is where software is going.

    The future of this is having a API (with CLI, MCP) and then a SKILL.md file for other system to integrate with it.

    Basically like yourapp.com/api/openapi.json and yourapp.com/api/skill.md.

    This is the universal integration interface. Any app that wants to expose itself to be used by others to build things on top can do this. AI is the integration layer, avoids the integration hell.

    I have tried similar things before. It works.

  • How does your VM handle local state and performance, when the user attempts to fetch, join and render data from multiple endpoints?

    We use Dart and Go (front/backend) to allow users to render widgets/mini-apps on Maxint (Finsight). And hence, the speed (virtually instant) and overall quality of the output mostly depends on the LLM/inference endpoint that they choose.

    In general, most users are happy with the existing features, however more advanced users have a playground to ship enhancements on-the-fly.

  • Interesting - but how do you ensure the generated UI's are high enough quality that I as a company would be happy showing them to my users. A lot of users are pretty tech-literate and would definitely critique anything that is wrong in the UI
  • Consider tightening up the pricing page. Paying $49/month for "$49 of usage a month" doesn't tell me what I'm getting. How many is "a few hundred", 200?

      Pro $49/month
      - Includes $49 of usage a month
      - ≈ a few hundred active end-user sessions
    
    An LLM safety judge concerns me.

      "You are Vendo Auto, a safety judge for tool calls.",
      "Choose run only when the call is appropriate for the user and context.",
      "Choose ask when user confirmation is warranted, and block when the call must not proceed.",
      "Return a concise rationale grounded in the supplied call, context, directions, and recent activity.",
    
    https://github.com/runvendo/vendo/blob/9e9782f653366793a769c...
  • > Deterministic beats model wherever you can get away with it.

    Both Apple and Google appeared to be making the contrary bet: define an MCP-like API layer (AppIntents and Appfunctions) that apps can implement so that the platform's agent, or in some cases maybe third-party agents, can manipulate those apps.

    That's going to be very attractive by making automations on demand. I like to say agents automate automation. An automatic on demand saw sharpener.

    I'm working on a project in which I have created an AppFunctions layer and tested it with the test agent Google provides. It's really pretty magical, weaving together information extracted from the app I'm creating with travel time estimates and information about nearby businesses, for example. Generating that non-trivial example was a piece of cake. The agent got it right on the first try.

    The consequence is that there is a whole class of features that would've depended on bespoke integrations, protocols, APIs, inter-app communication, etc. that, not only do I not have to implement, but I should refrain from implementing because the usage patterns are going to rely on agents.

  • What benefit does this provide over an excellent API + MCP access?

    I often find my users want to throw their Claude at it and have everything handled. Users have even developed their own local UIs using Claude Design. As long as they are within the bounds of the MCP I already provide access to, no problem. This also has the added benefit of using the AI subscription the org already pays for (or using the customers).

    Edit: Congrats on the launch and thanks for open sourcing!

  • I’ll say it: this sounds like it would be absolute hell for customer support. “Special” clients are already tough to manage with weird little workarounds and random business requirements. If you let them start making changes themselves, they will inevitably break it and then come to support freaking out because some “business critical” feature they made isn’t working how they want it to, or isn’t working at all. And how is customer support to know what the AI generated feature is, or how to fix it? Now make that possible for every customer, not just those paying enough money to throw their weight around, and you’ve got a recipe for a pissed off, burnt out help desk. And probably some stressed out account managers who have to smooth things over to try and retain the client. Does not surprise me the founders don’t appear to have much experience in customer-facing roles.
  • Not sure if this is productizable as-is, but I think it's absolutely the right direction. A lot of software has to become WAY more malleable directly in the hands of users.

    Software vendors should be providing the platform, including any hard-to-build widgets, and "stock" look-and-feel so that the software is usable out of the box, but then the customers should be able to send their product feature requests directly to a chatbot, whether it is embedded into the platform (i.e. same vendor) or rides on top (i.e. different vendor).

    This is the new form of UGC. The vendor can turn it into a marketplace within that platform, promote popular 3rd party features in that marketplace, etc.

Explore Birbla archives