Visual Programming + Literate Programming: A Better Way to Build Business Logic With AI
- Robert Werner
- Mar 16
- 7 min read
AI coding agents can generate working software from a few sentences of natural language. Building software got dramatically easier. But the output is still code. And code is still the interface.
When AI builds something visual - a UI, a dashboard - you can see the result and iterate. When AI generates business logic - a pricing rule, an eligibility check, a compliance calculation - the only way to verify it is to read the code.
AI changed who can start building software. It hasn't changed the hardest step: confirming that what was built is actually what you intended. That still means reading code - a format built for writing efficiency and machine execution, not for checking whether the AI understood you correctly.
Programs should explain themselves to people
In 1984, Donald Knuth proposed literate programming. It's the idea that programs should be written for humans first, computers second. "Let us concentrate rather on explaining to human beings what we want a computer to do." Weave the explanation of why directly into the what. Tools like Jupyter notebooks borrowed the idea, but literate programming never became the way most software gets built. Writing and maintaining prose alongside code was extra work, and if the prose drifted from the implementation, you had misleading documentation - worse than none at all.
Knuth was solving the right problem for the wrong era. Back then, programmers wrote their own code - they already understood it. Today, AI writes the code, and the humans who asked for it need a way to understand, shape, and trust what was generated. The overhead that killed literate programming in the 1980s is exactly what LLMs do well. The idea finally has the right collaborator.
Add visual programming, and something clicks
Literate programming captures intent in words. Visual programming captures structure as executable programs you can see. It also removes the syntax barrier - you don't need to know what curly braces mean or how to write an if-then-else. A visual representation of logic is something you can read on first contact and modify without learning a language first.
The old criticism was that editing diagrams is slower than editing text. That mattered when humans wrote everything by hand. It matters less when AI generates the logic from natural language.
Combine literate and visual, and you get software that people outside of engineering can build, understand, and own - both for verifying what AI generates and for changing it when the rules evolve.
The demand for this is already proven. Millions of people adopted tools like Zapier, n8n, Pega, and OutSystems (despite their limitations) because they wanted to build software without learning syntax. But those tools were all built before AI. They can't offer the workflow where you describe what you want in natural language and AI generates the visual logic for you, with literate intent built in rather than bolted on as manual comments nobody maintains.
A creative workspace for business logic
This isn't an audit tool for AI-generated code. It's a creative workspace where the person who knows the business rules builds them directly with AI assistance, in a format they can read and own.
At Leapter, we've been building visual programming languages for business logic for over twenty years, starting in enterprise banking. A blueprint is a visual program that compiles and runs. Not a picture of code, not documentation about code. What you see is what executes.
Think of the Specification view like a Jupyter notebook where the code cells are visual programs. But where a notebook is linear - top to bottom - the Specification view is hierarchical, organizing logic from high level to low level, the way Knuth originally proposed. Each blueprint breaks down into chapters. Every chapter starts with a plain-language explanation of intent - what this section does and why. Right next to the explanation sits the corresponding part of the visual program.
Here's a credit score calculation as an example. Instead of one monolithic program or a wall of code, the Specification view breaks the logic into named chapters you can navigate like a document. You see the full structure at a glance - what the calculation does, how many steps it has, and how they connect.
Each section can run independently. You can test one chapter's logic without executing the whole blueprint. You point at a section of the diagram, describe a change in natural language, and see it reflected immediately. Iterate until the logic matches what you actually need.
The Specification view also matters when you need to change existing logic and nobody remembers why it was built that way. Without literate context, you're staring at code trying to reverse-engineer the original intent. With the Specification view, the intent is already there. You read the chapters, understand why each section exists, and know what needs to change. AI benefits from the same context - it reads the same chapters you do and makes changes with that understanding.
A fair criticism of literate programming: prose alongside code can go stale, and stale documentation is worse than none. Leapter addresses this with a background sync - when the diagram changes, AI updates the prose to match and shows you what changed for approval. But visible intent also gives you something code alone never can - a way to spot implementation errors. If the chapter says "exclude values above the threshold" and the logic checks for below the threshold, you see the mismatch immediately. Without stated intent, you'd read the code, see the check, and have no way to know if that's right.
Where this works: built for business logic that has to be right
Visual programming isn't a better alternative for every type of coding. But for certain types of problems, it is and AI makes the case stronger than before.
Leapter blueprints are side-effect-free functions. They take inputs, apply logic, return outputs. No database access, no network calls, no UI rendering. This is deliberate. We scoped to the class of problems where business rules need to be deterministic and verifiable: data validation, calculations, pricing logic, eligibility checks, compliance rules.
Side-effect-free functions are easier to test and reason about. When they're represented visually, you can trust that what you see is the complete picture - nothing hidden changes behavior at runtime. You can run a blueprint with test inputs and step through the execution forward and backward, seeing which branches fired and the state of every variable at each step. AI can generate test suites automatically - different input permutations aimed at full coverage. Because the functions are side-effect-free, this is tractable: no mocking, no setup, just inputs and expected outputs.
The visual layout is structured automatically - every element is placed by the system, not dragged around by users. There are no messy diagrams. The editor prevents structural errors - you can only build logic that's structurally valid. When logic gets complex, it breaks into smaller, reusable blueprints - the same way a well-organized document uses sections and cross-references. And you can collapse sections to see the big picture or expand them for details.
On the tooling side, blueprints are stored in a text-based format - like Mermaid diagrams that live as code in your repo but render as visuals. Git-friendly, diffable, versionable. We've also built a visual diff: red for removals, green for additions, applied to the diagram itself.
Once a blueprint is ready, it's automatically deployed and callable via API or MCP - no separate deployment step. If you need the logic outside the platform entirely, blueprints export as JavaScript or Python.
Who gets to build software?
Consider the typical workflow today: a compliance lead writes a requirements document, hands it to engineering, waits for implementation, reviews code they can't fully read, and hopes the edge cases were handled. With a visual and literate interface, they build and verify the logic themselves.
Addy Osmani, Director at Google Cloud AI, calls it "The 70% Problem": AI tools accelerate development but struggle with the final 30% of quality, the part that requires someone who actually understands the domain. The actuary who knows the risk model, the compliance officer who knows the regulations, the logistics manager who designed the routing in the first place.
These are the people who should be building the logic. By 2026, business technologists will outnumber professional developers 4:1 according to Gartner. They don't lack ideas or domain knowledge. They lack an interface that lets them work with AI-generated logic without reading code.
When the interface is visual and literate, both creation and verification become possible for everyone. The business expert builds the logic in a format they understand. They verify it visually, test edge cases, and iterate with AI. And when the logic is right, they publish it as a deterministic tool that AI agents can call in production - same input, same output, every time.
That's a fundamentally different workflow than "prompt AI, get code, hope it works."
From black box to glass box
For teams in banking, insurance, and healthcare, this also solves a regulatory problem. When a regulator asks "why did the system make this decision?", you point to the exact chapter of the blueprint where the rule is defined, read the business rationale in plain language, and trace how the logic executes. No reverse-engineering. No guessing.
Max Tegmark at MIT is exploring what he calls "vericoding", formal verification approaches where AI generates provably correct code. That work is promising for the long term. But most teams right now need something more immediate - a way for the people who know the rules to build and verify the logic themselves, in a format that's transparent by default.
That's what visual and literate programming actually give you. A glass box instead of a black one.
The next interface for building software
Knuth had the right vision 40 years ago - programs should explain themselves to people. Visual programming had the right idea - make logic something you can see. AI gives them both a reason to exist together.
At Leapter, we're building that combination. A visual programming language with literate specifications built in. A platform where the people who know the business can build, verify, and own the logic - with AI, without code.
If your team owns business rules that need to be right, try the Specification view. The platform is early - we've rebuilt everything from scratch for an AI-native workflow, and some features are still in progress. But it's ready to use with real business logic. It's free, no sign-up required.