I created Lucerna Media as the name for the independent path I wanted to follow. Almost immediately, I ran into walled gardens: Adobe’s subscription model, NVIDIA’s pricing and hardware ecosystem, cross-compatibility failures, privacy questions, security tradeoffs, and the constant feeling that every useful tool wanted another fee.

I felt overwhelmed, nickel-and-dimed, and tired of asking permission from software and hardware I was already paying to use.

I was tired of Python and the brittleness I experienced when projects grew beyond quick scripts. I turned to Rust, built a Tokio-based bus, and finally made my first applications. That was a breakthrough—but it still did not solve the larger problem.

So I stopped asking how software was normally assembled. I designed my first Atom application around a simpler question: what happens if a system is broken into its smallest useful mathematical parts, those parts stay visible, and everything else is composed upward?

I did not know how to write conventional code or explain the design in the language software engineers expected. The AI coders did not understand it either. They repeatedly pulled it back toward familiar patterns. More than once, I was told the complete idea sounded like decades of work for a team of a hundred engineers.

I wrote dozens of instruction skills. I turned architecture into analogies. The Spiderweb Bus gave the model roads, intersections, lanes, vibrations, and a spider that could manage traffic. Eventually, I got a rough prototype working, carried it into every new session as a reference, and refined it until the model could see the same architecture I saw.

Even then, drift was the real enemy. Keeping an AI focused on an unfamiliar design—instead of watching it snap back to pattern matching—was harder than imagining the application itself.

The Atom Vibe Coder harness came from that fight. It exists to keep the architecture, constraints, reference implementation, and user permission boundary present while an AI coder works.

I designed the Atom family in roughly two months. Most projects reached a functional first version in a day, then were tested, corrected, and polished over the following week. Speed was never the only priority. I wanted the results to be understandable, user-friendly, and visually appealing because powerful software should not have to be ugly or hostile.