DiagramCraft · Source-Aware Code Generation
Most code generation starts with a model of reality: an OpenAPI document, a schema, a collection of variables, or a carefully maintained architecture description. That works—right up until the implementation and the model disagree.
Consider a Spring controller. Your generated client needs to know what happens when an order already exists. Is the response 409 CONFLICT? Does the method return 400 BAD_REQUEST? Does it throw an exception that eventually becomes a status through @ControllerAdvice? Maybe the API specification says one thing while the controller currently does another.
Traditionally, you have three choices: trust the documentation, duplicate the implementation detail into configuration, or teach a human to keep both synchronized. We wanted a fourth option.
Let the generator read the source.
DiagramCraft templates can access source files elsewhere in the diagram through it.src. The source does not have to become part of the generated artifact. It can simply become context for deciding what to generate.
<%
const controller = it.src.get("orders/OrderController.java");
const hasConflict = controller.includes("HttpStatus.CONFLICT");
%>Source code as an input, not an output
Include systems have existed forever. Reading another file just to paste it into this file is useful, but unremarkable. Reading another component's implementation so a generator can make decisions about the code it should produce is something different.
Imagine generating a TypeScript client for that Spring service. The template can inspect the controller that exists today, recognize the response paths it implements, and generate the appropriate handling. If an unfinished method later gains a new status path, the next generation pass can account for it.
Or consider two microservices evolving independently. A compatibility template can inspect the live implementation of the service it integrates with and generate an edge-case adapter only when that adapter is actually necessary. Tests can be generated against observed controller behavior. Migration code can react to implementation differences. Architecture becomes executable context.
Why this fits DiagramCraft
DiagramCraft already knows more than a conventional template engine does. It knows where source belongs in the architecture. It has scoped variables describing the system. It has relationships between components. It can hold runnable implementations, specifications, examples, and generated artifacts alongside the architecture that explains them.
it.src closes a small but important loop: templates can now use the implementation itself as another piece of architectural information.
Structured variables can describe what we intend. Source can reveal what we actually implemented. A generator can use both.
“What HTTP status does this Spring controller actually return in this case?”
That sounds like a question for a developer reading code. Now it can also be a question asked by the code generator.
Small primitive, strange possibilities
We did not set out to invent a new category of development tool. We added a way for a template to fetch source from its diagram. Then the use cases started appearing.
Some features arrive with a hundred obvious requirements. Others are tiny primitives that make you reconsider what the system around them can do.
This feels like the second kind.