What If Your Code Could Explain Itself? Nested Graphs and AI Functions

Most development tools ask you to choose: simplicity or power. Visual tools are easy to understand but hit a ceiling. Code is powerful but demands expertise. We've been thinking about what happens when you refuse to choose. When a visual graph IS the code. When the abstraction and the implementation are the same thing.

Here are three ideas we're exploring that could change how people build software with Lexikl.

AI Writes the Functions, You Set the Constraints

Every function node in Lexikl knows its inputs and outputs. It knows the types, the names, and which pins connect where. That's a lot of context. Enough context, in fact, for an AI to write the function body.

Imagine clicking on a function node and seeing a prompt box instead of a code editor. You type: "Take the user's email, validate the format, and return a normalized lowercase version." The AI sees the input pin (a string called "email") and the output pin (a string called "normalizedEmail"), and it generates the function. Well-scoped. Testable. Correct.

The generated code isn't hidden. Click "View Code" and it's right there. Read it. Edit it. Replace it entirely if you want. The AI is an assistant, not a black box. If you're learning, the generated code teaches you. If you're experienced, it saves you time. Either way, you stay in control.

The key insight is that the node's pins act as a contract. The AI can't generate something that takes the wrong inputs or returns the wrong shape. The constraints make the generation reliable.

Double-Click to Go Deeper

What if a function node isn't just a function? What if it's an entire workflow?

Picture this: you're looking at a workflow with five nodes. One of them is labelled "Auth Middleware." You double-click it. The canvas transitions smoothly and you're inside a completely new graph. This one has nodes for token validation, permission checking, rate limiting, and session refresh. A breadcrumb trail at the top reads main > authMiddleware. Click "main" to go back up.

Each level is just another workflow. A function node at one level is a full graph at the next level down. The inputs and outputs of the inner graph map directly to the pins on the outer node. It's recursive. Fractals of logic.

This unlocks composition in a way that text-based code struggles with. Someone builds a "Stripe Payment Flow" as a graph with error handling, retry logic, and webhook verification. They publish it as a single node. You drag it into your workflow. It just works. If you're curious how, double-click and explore. If you're not, it's a single box that says "Stripe Payment Flow" and that's all you need to know.

The Reveal: It's Already Live

Here's the part that surprises people. While you're wiring up nodes and describing functions in natural language, you think you're building a prototype. A mockup. A diagram that represents what you'd like to build someday.

Then you hit deploy.

And it's a real API. A live endpoint you can curl from anywhere. Each function node maps to a Lambda. The edges define the invocation chain. The infrastructure deploys itself. The gap between "playing with boxes on a canvas" and "running in production" doesn't just shrink. It disappears.

During development, the functions run in the browser for instant feedback. Pure logic nodes (transform, validate, format) execute locally in a Web Worker sandbox. Nodes that need server resources (database queries, secrets, external APIs with credentials) run via a preview proxy. You see results immediately without deploying anything.

When you're ready, the same code moves to Lambda unchanged. Same function signatures. Same behavior. The only difference is where it runs.

Smart Change Propagation

When you edit a function node in the middle of a chain, you don't want to re-execute the entire graph. You want to re-run only what's affected.

The edges already encode the answer. Walk forward from the changed node through its output connections. Mark every downstream node as dirty. Everything upstream is untouched. If branches converge, the downstream node waits until all its inputs are resolved. Only dirty nodes re-execute.

During development, this means near-instant feedback. Edit a transformation in the middle of a ten-node chain, and only the nodes below it re-run. For deployment, the same logic tells you exactly which Lambdas need updating and which are unchanged. Minimal deploys. Fast iteration.

Import, Understand, Extend

One more idea we're exploring: what if you could point Lexikl at a GitHub repository and see it as a graph?

Parse the repo. Identify functions and modules. Map imports and call relationships as nodes and edges. The code is already structured this way. You're just making the relationships visible.

The interesting part isn't just visualization. It's that once the code is a graph, you can extend it with the same tools. Add a new function node. Describe what it should do in natural language. The AI generates the code. Connect it to the existing graph. Deploy. You go from reading someone else's code to extending it without ever opening a text editor.

Where This Is Going

None of this is science fiction. The canvas editor exists. Touch and mouse interactions work. Nodes connect with Bezier curves. The infrastructure deploys via CDK. The pieces are in place.

What we're building toward is a tool where the visual representation isn't a diagram of the code. It IS the code. Where understanding, creating, and deploying software are the same action performed on the same artifact. Where the barrier to building isn't "can you code?" but "can you describe what you want?"

We think that's worth building.

Try the current state of Lexikl at lexikl.com and follow our progress. The best is ahead.