This reminds me of the UML/RUP era from the early 2000s....
Is that an attempt to revive or even resurrect UML diagrams and Rational Unified Process blending it with AI? I would bet it's all dead forever. I'm skeptical about diagram-driven development making a comeback. In my experience, developers today prefer more agile, code-first approaches because requirements change rapidly and maintaining diagram-code synchronization is an unbearable challenge.
I've found you can already paste an architecture diagram into Cursor and use that to guide code[1]. I make mine in Xmind because there's no need for special, rigid formatting.
I believe in UML usefulness as a whiteboard/blackboard language. A fun way to explain what you need or what you imagine to be a good architecture, but that's all, it's a drafting tool.
But then, why not using it as a communication tool ? You would draft something on the board, the LLM would generate the program. Sometimes it is simpler to draw 5 rectangles, name then and show their relationships in UML class modeling than to explain it textually.
UML class diagrams in mermaid syntax require less code than just defining actual classes with stubbed attrs and methods in some programming languages.
Years ago I tried ArgoUML for generating plone classes/models, but there was a limit to how much custom code could be round-tripped and/or stuffed into UML XML IIRC.
Similarly, no-code tools are all leaky abstractions: they model with UI metaphors only a subset of patterns possible in the target programming language, and so round-trip isn't possible after adding code to the initial or periodic code-generation from the synced abstract class diagram.
Instead, it's possible to generate [UML class] diagrams from minimal actual code. For example, the graph_models management command in Django-extensions generates GraphViz diagrams from subclasses of django.models.Model. With code to diagram workflow (instead of the reverse), you don't need to try and stuff code in the extra_code attr of a modeling syntax so that the generated code can be patched and/or transformed after every code generation from a diagram.
I wrote something similar to generate (IDEF1X) diagrams from models for the specified waterfall process for an MIS degree capstone course.
It may be easier to prototype object-oriented code with UML class diagrams in mermaid syntax, but actual code shouldn't be that tough to generate diagrams from.
IIRC certain journals like ACM have their own preferred algorithmic pseudocode and LaTeX macros.
This is a way to give developers and semi-technical people a way to generate and run code-first workflows using a visual language, be it UML or otherwise. We will be expanding support for text prompts in the future
Code-first is kinda moving towards prompt-first. A diagram is just another way to prompt, so I can see this making a comeback, esp. with AI taking over more and more code.
Even worse, you have to download a .zip containing the output.
I'm probably a bit too trusting, but holy hell does that still give a terrible first impression when we have in-browser solutions available to show code demos.
This is really cool as far as the application goes, but I do have a question on how you plan to compete/differentiate, if at all. I fed the same image to one of the flagship LLMs and was able to generate, more or less, the same dapr scaffold. You might probably be able to fine tune towards dapr use case better, but if one of the flagship models that people already use is going to come close, then it becomes a hard sell.
I suppose it's also a general question about the many new AI applications in the market, because these flagship models are getting really good by the day, and seem to be eating up into each and every of those use cases.
Hi thanks for your question. You wrote "more or less" and that's very accurate - the generated code by just feeding it to any LLM provider usually doesn't work out of the box, includes many hallucinations and also doesn't provide a solution that can be immediately downloaded and run in your IDE
Intead of "Step 1: Upload Your Diagram", if you could say "describe your diagram", that would take it to the next level. So you would generate a workflow from the description using an llm which the user could then edit. This takes out the painful part of diagram creation and makes it fun for the user. For example, for infra automation a description could be: "first download this from this url. then, run this command, then take the output and feed it to this, then reboot, email me if there is any problem".
To make it less ambiguous, you could let the user describe the diagram with what the software is supposed to do in some sort of more rigid unambiguous reduced English /s
This is cool. I remember not too long ago I had a professor telling me that this was essentially the future of software engineering and that soon we won't be writing code as we know it today. I believed him, I just didn't think we'd be seeing it here so soon.
Any plans to create systems that allow this to be embedded in existing code bases? It'd be neat to be able to sketch out new systems that your tool could generate code for that seamlessly hooks into an existing system's architecture, especially if it could have a UX similar to how copilot or cursor behave in how they're directly inline with the code.
Thanks for the response! What you're saying about embedding and enriching existing code based is definitely next level and I'll bring it back to the team to explore
I’m all in for diagrams in discussing software! When there is no whiteboard, I literally draw in the air to explain my point.
However, doing real, orthodox UML/BPMN requires everyone to understand the official notation, the difference e.g. between an „association“ and a „message flow“ (and then the differences between UML 1.4 and 2.0) etc. Do people really work in environments where all stakeholders have that kind of knowledge? Big corps I could imagine, probably where heavy machinery is involved. Aside from those „we build a cruise ship“ megaprojects I have the impression that people say UML and mean the much more approachable „squares connected by diamonds and labeled arrows“-diagrams.
Wondering how no-code tools like this handle those discrepancies between the super-detailed specs and the real world diagrams
Interesting. A future to consider, like it tries to understand our existing code(from GitHub or anyway) and generate new code that fits in well with what we already have?
Dapr is a code-first workflow engine that doesn't require a DSL language and includes many other integration points like pub/sub, service discovery and more. It also runs and deploys natively on K8s
So for workflows it's like Airflow, Brigade or hatchet or ...? How do workflows integrate with k8s (ressources, ...)? Camunda can also deploy natively on k8s. However you still develop apps for Camunda and it seems like dapr is no different there? Why is it in CNCF if it doesn't provide a way to build a workflow out of k8s-native artifacts (PVs, Deployments, Jobs, ...)?
1. yeah this is nice, making it easier to generate workflows is always good. i think the challenge is always versioning and proper error handling - if the diagram the user sends in doesnt properly model the work done, then you're SOL.
2. (sorry to bring it up but have to ask) how does Diagrid/Dapr compare to Temporal? i browsed your docs but there wasn't much that came up. is Dapr strictly dag based?
1. A user can always go into the generated code and make changes to it. The code generated includes explanations for what each step in the workflow does
2. Dapr has 9 APIs, one of which is Workflows which indeed competes with Temporal. Dapr Workflows isn't DAG based, it's code-first. This tool allows you to start with an external representation
This reminds me of the UML/RUP era from the early 2000s.... Is that an attempt to revive or even resurrect UML diagrams and Rational Unified Process blending it with AI? I would bet it's all dead forever. I'm skeptical about diagram-driven development making a comeback. In my experience, developers today prefer more agile, code-first approaches because requirements change rapidly and maintaining diagram-code synchronization is an unbearable challenge.
Yes. It's CASE[0] all over again.
I've found you can already paste an architecture diagram into Cursor and use that to guide code[1]. I make mine in Xmind because there's no need for special, rigid formatting.
[0] https://en.m.wikipedia.org/wiki/Computer-aided_software_engi...
[1] Diagram as code example from my dev blog: https://davidbethune.com/blog/watsonDevBlog28
I believe in UML usefulness as a whiteboard/blackboard language. A fun way to explain what you need or what you imagine to be a good architecture, but that's all, it's a drafting tool. But then, why not using it as a communication tool ? You would draft something on the board, the LLM would generate the program. Sometimes it is simpler to draw 5 rectangles, name then and show their relationships in UML class modeling than to explain it textually.
UML class diagrams in mermaid syntax require less code than just defining actual classes with stubbed attrs and methods in some programming languages.
Years ago I tried ArgoUML for generating plone classes/models, but there was a limit to how much custom code could be round-tripped and/or stuffed into UML XML IIRC.
Similarly, no-code tools are all leaky abstractions: they model with UI metaphors only a subset of patterns possible in the target programming language, and so round-trip isn't possible after adding code to the initial or periodic code-generation from the synced abstract class diagram.
Instead, it's possible to generate [UML class] diagrams from minimal actual code. For example, the graph_models management command in Django-extensions generates GraphViz diagrams from subclasses of django.models.Model. With code to diagram workflow (instead of the reverse), you don't need to try and stuff code in the extra_code attr of a modeling syntax so that the generated code can be patched and/or transformed after every code generation from a diagram.
https://django-extensions.readthedocs.io/en/latest/graph_mod...
I wrote something similar to generate (IDEF1X) diagrams from models for the specified waterfall process for an MIS degree capstone course.
It may be easier to prototype object-oriented code with UML class diagrams in mermaid syntax, but actual code shouldn't be that tough to generate diagrams from.
IIRC certain journals like ACM have their own preferred algorithmic pseudocode and LaTeX macros.
This is a way to give developers and semi-technical people a way to generate and run code-first workflows using a visual language, be it UML or otherwise. We will be expanding support for text prompts in the future
Code-first is kinda moving towards prompt-first. A diagram is just another way to prompt, so I can see this making a comeback, esp. with AI taking over more and more code.
If it weren't for the ambiguity of prompts and nondeterministic nature of the model.
Set the seed.
Reply to post: "any"?
[0] I accept large checks for allowing setting seeds on-prem.
not setting a seed is a feature - not a bug, otherwise lots of people with similar prompts will generate an exactly the same source code
Very much so, and in next iterations we will be expanding the scope both in what the generated code does as well as the ways to prompt
Some feedback: show example input & output without requiring me to create an account.
Looks interesting, best of luck!
This. There's a few example diagrams but I need an account to see the output of those example diagrams? No thanks.
Even worse, you have to download a .zip containing the output.
I'm probably a bit too trusting, but holy hell does that still give a terrible first impression when we have in-browser solutions available to show code demos.
Definitely fair feedback, we will look into it
To me that homepage feels like when you start a new 8-part TV show by accidentally watching episode 6.
I see some thing I recognize, diagrams, but nothing else makes sense.
This is really cool as far as the application goes, but I do have a question on how you plan to compete/differentiate, if at all. I fed the same image to one of the flagship LLMs and was able to generate, more or less, the same dapr scaffold. You might probably be able to fine tune towards dapr use case better, but if one of the flagship models that people already use is going to come close, then it becomes a hard sell.
I suppose it's also a general question about the many new AI applications in the market, because these flagship models are getting really good by the day, and seem to be eating up into each and every of those use cases.
Hi thanks for your question. You wrote "more or less" and that's very accurate - the generated code by just feeding it to any LLM provider usually doesn't work out of the box, includes many hallucinations and also doesn't provide a solution that can be immediately downloaded and run in your IDE
Intead of "Step 1: Upload Your Diagram", if you could say "describe your diagram", that would take it to the next level. So you would generate a workflow from the description using an llm which the user could then edit. This takes out the painful part of diagram creation and makes it fun for the user. For example, for infra automation a description could be: "first download this from this url. then, run this command, then take the output and feed it to this, then reboot, email me if there is any problem".
Great idea and a work in progress :)
To make it less ambiguous, you could let the user describe the diagram with what the software is supposed to do in some sort of more rigid unambiguous reduced English /s
This would have the added benefit of being able to describe to the computer exactly what you want to happen and how.
Feels like we're onto something here.
And them we can just use some process to turn those words into machine language. Maybe we can call it a compiler or an intepreter?
This is cool. I remember not too long ago I had a professor telling me that this was essentially the future of software engineering and that soon we won't be writing code as we know it today. I believed him, I just didn't think we'd be seeing it here so soon.
Any plans to create systems that allow this to be embedded in existing code bases? It'd be neat to be able to sketch out new systems that your tool could generate code for that seamlessly hooks into an existing system's architecture, especially if it could have a UX similar to how copilot or cursor behave in how they're directly inline with the code.
Thanks for the response! What you're saying about embedding and enriching existing code based is definitely next level and I'll bring it back to the team to explore
I’m all in for diagrams in discussing software! When there is no whiteboard, I literally draw in the air to explain my point. However, doing real, orthodox UML/BPMN requires everyone to understand the official notation, the difference e.g. between an „association“ and a „message flow“ (and then the differences between UML 1.4 and 2.0) etc. Do people really work in environments where all stakeholders have that kind of knowledge? Big corps I could imagine, probably where heavy machinery is involved. Aside from those „we build a cruise ship“ megaprojects I have the impression that people say UML and mean the much more approachable „squares connected by diamonds and labeled arrows“-diagrams.
Wondering how no-code tools like this handle those discrepancies between the super-detailed specs and the real world diagrams
Great point. Our tool does UML/BPMN as well as regular drawn diagrams without a specific notation, and will soon expand into regular prompts
Interesting. A future to consider, like it tries to understand our existing code(from GitHub or anyway) and generate new code that fits in well with what we already have?
What is the difference with tools like Camunda (for BPMN) for example ?
Dapr is a code-first workflow engine that doesn't require a DSL language and includes many other integration points like pub/sub, service discovery and more. It also runs and deploys natively on K8s
So for workflows it's like Airflow, Brigade or hatchet or ...? How do workflows integrate with k8s (ressources, ...)? Camunda can also deploy natively on k8s. However you still develop apps for Camunda and it seems like dapr is no different there? Why is it in CNCF if it doesn't provide a way to build a workflow out of k8s-native artifacts (PVs, Deployments, Jobs, ...)?
1. yeah this is nice, making it easier to generate workflows is always good. i think the challenge is always versioning and proper error handling - if the diagram the user sends in doesnt properly model the work done, then you're SOL.
2. (sorry to bring it up but have to ask) how does Diagrid/Dapr compare to Temporal? i browsed your docs but there wasn't much that came up. is Dapr strictly dag based?
1. A user can always go into the generated code and make changes to it. The code generated includes explanations for what each step in the workflow does
2. Dapr has 9 APIs, one of which is Workflows which indeed competes with Temporal. Dapr Workflows isn't DAG based, it's code-first. This tool allows you to start with an external representation
Why generating code ?
[dead]