taaron

Exactly - the amount of transparency provided by this commit history and diff is really cool. So many ways git features provide some interesting ideas e.g. could PRs be a way to track changes from different parties or even citizen groups? Could PR reviews/comments be a way to capture public discourse?

Was looking around for examples of git for complex document/policy management outside of software/code and found this repo where the Council of the District of Columbia stores its statues and code as code in a git repo with a full history of commit changes, diffs etc.

Not at the moment, though I am curious what the main benefit of a desktop app would be for you - running the code locally? more performant UI?

AI building the integrations is the approach we are taking at the moment, to the extent that you can store credentials like API keys and Oauth and then make the AI aware of these via a variable like ${googleAPI.SECRET}.

These credentials can then be use in the API node (where the AI can write a custom curl) or the run code component (where the AI can write custom python or js code to make an HTTP request).

We might be able to sort out a discount for individuals in exchange for some product feedback - send us an email at hello@workflow86.com

Interesting idea, I have it a go with this prompt: "Generate a workflow that uses code to scrape the content from a page, passes it to an AI assistant that then checks it for any types, and then outputs the typos and the correct spelling"

Here's the workflow that was generated: https://app.workflow86.com/template/2f8c5a73-af76-47bc-8757-...

We've heard this as well and also sometimes use it as explanation. Who knew "86" could make sense in so many ways.

We use react-flow which seems to be the go-to for any sort of node/canvas based UI at this point.

Working on it at the moment, would be interested in learning more about the actions/events you would need to make it useful.

Valid point. At its core, our AI is indeed a LLM that is prompted to provide an output. A lot of the work however is in (1) prompting it in a way that allows it to actually understand the user instructions and current state of the workflow and (2) allow it to reliably output a response that acts as a set of instructions on what needs to be done within the platform e.g. add this, remove this, change this question text to this, write this code etc.

One example of what we had to do to achieve this was to develop an "intermediary language" defines how the current state of the workflow is represented to the AI and how the AI responds back - this needed to capture enough detail about the workflow without overwhelming it with too much context. We also developed techniques for structuring the prompting, with the process of building a workflow actually split into 3 stages: a pre-build planning stage, a build stage where the overall structure of the workflow is set, and then a build node stage where each individual node its configured. There is a bunch of other techniques we developed to get LLMs to be able to do what they current do, but these are just some examples of how it's a bit more than just a "You're a business consultant" prompt.

One thing I'd encourage people to do is test these co-pilots head-to-head on the same prompt. If you were to ask Zapier or Make to "build me a process for triaging customer complaints", I'd expect them to not get very far, perhaps an outline of some apps you could connect together to achieve it. If you asked our AI this same request, it would be able to deliver a complete workflow with fully configured forms, tables, branching logic, tasks etc

Our AI goes much further than Zapier/Make in terms of how far it can get you towards a complete, ready-to-run workflow.

Make's copilot is pretty limited to generating an outline of the flow by selecting the right nodes but does not actually configure them. You still need to manually click into each one and set it up.

Zapier goes a bit further than Make, but it still leaves the workflow with a lot of configuration work that needs to be picked up by the user.

In both Make and Zapier, you really need to prompt the AI copilot in a very specific way to get good results. In our case, the AI is designed to use its business analyst/consultant mode to extract information so it can work from very general, unclear and ambiguous instructions to a clearly defined workflow/process to build.

The ability for our AI to edit the workflow at any time (including on top of your own manual changes) also means you can have a continuous iterative dialog/interaction with our AI copilot vs a once off interaction at the start. Both Make and Zapier's AI Copilots lack this or are very weak in being able to edit existing workflows reliably.

Partially inspired by WD-40 but more so the exorbitant price for anything workflow.com. The number did have some logic behind it: 8 letters in automate and 6 in no-code.

One factor in hindsight for doing this in-house was we did find out that AI can struggle with understanding and navigating existing workflow builders that were built and optimized for human usage and comprehension e.g. what nodes are available, the options that can set inside of those nodes and even how they are named had quite an impact on whether the AI could reliably form valid workflows on its own.

Very interesting will definitely check it out!

Because we started with a focus on orchestrating forms and tasks, I'd say we're more suited for complex, long-running workflows that involve a lot of stop/start steps assigned to different teams (e.g. review and approvals) mixed with automation in between.

We actually integrate with Zapier i.e. you can trigger a workflow from Zapier, and we can trigger a zap from within a workflow.

While Zapier has also done some great work in the AI space, I'd also say our Ai builder goes a lot further in being able to fully set up a workflow and then continue to help users edit, change and refine them at any point. We're able to do this because a lot more of the moving parts are internal to Workflow86 (forms, tables, tasks etc), so the AI has more context and control over what it can do.

Some new users are encountering issues with the AI during onboarding - if you do encounter an error, you can always try out the AI again by just click the glowing purple button on the right of any workflow canvas! This seems to be due to some rate limit issues from the uptick in self-serve sign-ups and hopefully should be resolved soon.

Integrations are definitely the toughest part of the implementation. That being said, I'm pretty optimistic on (1) AI getting better at writing the code/REST API calls or making it a lot easier or (2) the sort of browser agents we've seen with Open AI Operator, Claude Computer Use etc get good enough to integrate via the UI layer vs the API level.

Nope, we built the workflow builder entirely ourselves, but I guess most workflow builders do end up looking very similar!

Very cool - any interesting use cases you have seen from users so far?

> Much better to be in that position than a company with a beautiful codebase who didn't capture the market

For sure. But I wonder how many are prevented from capturing a larger segment of the market because of poor design decisions re more fundamental primitives of the product. I suppose the worst case scenario here is a complete rebuild and migration.

I think one downside is that because you are optimizing for sales in the short-term, it can lead to product design/architecture decisions which unknowingly constrain the direction or limits of future development/innovation (or at least make it very expensive to retrofit). I think Notion is potentially suffering from this now as users try to push its limits into more complex applications.

Interesting tool...how does this compare to other CSPM tools?

Very true...which is why every no-code chatbot builder I've seen ended up adding web forms about 12 months later.

Based on all the comments, we ended up disabling the chatbot on our landing page/website but keeping it on our web app.

This was one of the theories - given the HN traffic was likely more technical users meaning a chatbot was more hindrance than help.

Curious as to what is your go to place for finding help faster - DIY via the product docs?

I suspect a tonne of NLP, machine learning/AI. An intercom chatbot is at best just a bunch of very simple logic rules.

I actually think this was a big reason why we did a landing page chatbot - because everyone else had one.

The original scope was just a chatbot for support, but the logic was heck we were paying for it so why not use it in more places.

Interesting way to put it. I guess the funny thing is as a consumer, I do personally dislike chatbots beyond direct support (simply because it beats long-chain emails back and forth).

Random sales rep is a great analogy...and I suspect that was why so many people found our chatbot annoying.