Design-led. AI-assisted.
Some ideas deserve more than a polished mockup. I want to understand how they behave when the buttons work, the content changes, and someone actually tries to use them. Building gives me a way to explore those questions beyond the design file.
I use Codex to help turn my design direction into working products. My part is deciding what is worth building, shaping the experience, and questioning the result. The projects below show that relationship in practice: a design system, a review tool, and a small plugin that takes repetitive cleanup out of a designer’s day.
Built with AI assistance, not presented as AI-powered products.
Explore the builds antiflex/ui
Independent design system connecting shared tokens, components, documentation and a connected workspace demo.
- My role
- Created the system and design direction.
- AI contribution
- Codex helped translate my design direction into the working implementation.
Inspect the working example
antiflex/ui homepage.More than a component gallery
A design system becomes useful when people can build with it. I created antiflex/ui to connect the foundations with their application: shared tokens, reusable components, documentation, and a connected workspace that brings the pieces together. The goal is to make the relationship between design decisions and working interfaces easier to see.
Design decisions stay connected
My role goes beyond deciding how a button looks. I define the visual language and how the system should hold together across components and screens. The documentation and workspace offer two ways to inspect that thinking: one explains the parts, while the other shows them working as a whole.
Using Codex to make it tangible
Codex assists with implementation, while I direct the product and design. That distinction matters to me. Generating code is not the end of the work; the result still needs to be considered as an interface. You can explore the public documentation and workspace below rather than relying only on a presentation of the system.
What I bring to an AI-assisted build.
- Frame the problem
- Start with the friction, not the generated interface. I decide who the product is for, what it should help them do, and what can stay outside the scope. A clearer problem gives the build a more useful direction.
- Shape the experience
- I make the product and design decisions: the flow, the visual hierarchy, the interaction, and the relationship between components. Codex helps with implementation, but it does not decide what a good experience means for the product.
- Review the result
- Working code is a starting point for evaluation, not a reason to stop asking questions. I look at the result as an interface: what feels unclear, what happens beyond the happy path, and where the implementation needs to move closer to the design intent.