AI has been part of Lubinik from the beginning, but not in the way the marketing version of that sentence usually sounds.
I did not want AI to be a magic button. I wanted it to be a collaborator I could use while still understanding the system myself. That distinction matters.
The first BnB theme was built while AI coding tools were becoming useful enough to experiment with. That made the project a learning lab: I could ask for help, compare approaches, debug generated code, read WordPress internals, and slowly decide which patterns were actually worth keeping.
Architecture as AI context
One thing became obvious quickly: AI works better when the codebase has strong boundaries.
Shorter files help. Consistent folders help. Repeated addon structures help. Metadata helps. A scaffolder helps. Clear separation between parent theme, core plugin, addon, child theme, and support plugin helps.
That does not make the AI correct. It makes its work easier to inspect. If a shortcode lives in a predictable place, has its own CSS, registers metadata consistently, and belongs to one addon, then reviewing changes becomes less exhausting.
This is why Lubinik is AI-friendly without being AI-blind. The point is not to let a model make all the architecture decisions. The point is to design a codebase where collaboration is less chaotic, where generated work has a place to land, and where mistakes are easier to catch.
AI made some parts faster. The architecture exists because faster is not enough if the system becomes impossible to reason about.
