The Design Philosophy of LensBench — Built for AI-Native Workflows
The biggest difference from other optical software is not an added chat box, but that, starting from the data model, it is designed for people and AI changing a design together.
LensBench's design philosophy, AI-native workflows, and news from the community.
The biggest difference from other optical software is not an added chat box, but that, starting from the data model, it is designed for people and AI changing a design together.
The entire state of a lens is a piece of .lens text. The AI can read it and write it, and every change is a visible diff.
The same command is, at once, an action in the desktop app, a subcommand of the command line, and a tool the AI calls. The AI has no hidden channel.
When you let an AI change a design, the worst fear is that it quietly changes something you didn't notice. So every change is dry-run first — which numbers changed and how the metrics move, and it is written only after you confirm.
When the AI reports a number, how do you know it isn't made up or out of date? The evidence id traces back to that real computation, and acceptance is recomputed independently with fixed standard sampling.
Open the Cooke triplet and say one sentence to the AI. It doesn't act right away — it first shows you which numbers would change and how the first-order quantities move, then waits for your nod.
Which model is better at Zemax reconciliation, which prompt saves an optimization from detours, at which step the AI often goes wrong — none of these has a ready-made answer yet.