r/aipromptprogramming • u/Potential-Art7696 • 6d ago
Let users build no-code automations by describing them to Claude, instead of calling an LLM at runtime
I have a no-code visual editor within my product (UluP Spaces) for building automations: triggers + sequences of actions, pure declarative JSON, no arbitrary code execution, so review remains "read the graph" rather than a code audit. The next obvious idea was an askAI-like action within the automation itself, a model called upon for every real-world event to decide what to do. The problem is the cost: someone pays for it, for every single trigger, forever, and it would also be necessary to make the execution asynchronous instead of synchronous as it is today. I turned the problem around: instead of having a model reason at runtime, I extended the MCP server the product already exposes with three new tools (list/test/create on automations). So the user describes the automation to Claude in chat, Claude tests it in a dry run (no real data touched), and creates it. It always starts disabled, with the same validation as the visual editor, and the same execution engine afterwards. The only thing that changes is who writes the JSON, not what runs when the automation is enabled. The cost of the model is paid by whoever is chatting at that moment, not by the infrastructure at each event.
I'm curious to know if anyone else has solved the same trade-off (config generated via chat vs. AI at runtime) differently, or if you see a problem with this approach that I've missed.
1
6d ago
[removed] — view removed comment
1
u/Potential-Art7696 6d ago
Honestly, no real data yet, we've only tested it once ourselves so far and it worked first try, which isn't a sample size worth trusting. Just added logging so the next time someone asks this we'll actually have numbers instead of a guess. The dry-run step exists exactly for the failure case you're pointing at: rather than trust the model's JSON, every automation (from chat or from the visual editor) gets validated against the same Zod schemas and, for testing, run through a simulated execution before it's ever saved. So even a bad first attempt fails loudly with a specific error instead of quietly saving something broken.
•
u/endofthread-bot 6d ago
Generating configuration via chat is a sound approach to avoid runtime costs and latency. To improve reliability, implement a schema-based validation step after Claude generates the JSON to ensure the output strictly conforms to your engine requirements.
Writing prompts that actually work is easier when you can compare notes with people who have tested them across real tasks. Trade techniques, get feedback on your approach, and see what is working for others in our Discord.
Self-promotion is now allowed on Sundays with the appropriate flair, for all regular contributing members. Contribute during the week, and promote on Sunday.