AboutAbout.

01How I work with AI

The systems on this site, Alex OS, Alex CMS and the Theme DNA layer, were built with Claude Code as a pair. I set the architecture, write the scope, review every change, and gate what ships with tests and an evaluation suite.

02What I like to build

The work I enjoy most is the hard kind: a problem that genuinely resists you, where getting to the answer means real debugging, reproducing it, tracing it, and staying with it until you've found the actual cause and fixed it. I like the challenge, and I like the moment it finally gives.

03What I think most people underrate

A lot of developers treat the frontend, speed, and UI/UX as things you bolt on at the end. I don't. How fast it feels, how it's laid out, and whether the code underneath is clean and well-structured aren't finishing touches. They're the product. Good structure is what lets a system keep growing without falling apart.

04How I work

I'm comfortable either way: inside a team or owning something end to end on my own. Both produce good work; what matters is the standard, not the setup. When an approach turns out to be the wrong one, I treat that as information and don't repeat it. The mistakes are part of how the next version gets better.

05What I leave behind for the next engineer

The test of a system isn't whether I can run it. It's whether someone else can change it next month without asking me. So the habits I bring to any team are about making the standard visible, not about being the person who holds it.

• Rules written down where the work happens. The design-token rule and the "no hardcoded copy" rule live in the repository itself, so every engineer (and every AI assistant) working on it follows the same standard without a meeting.
• Decisions recorded with their trade-offs. Every project here carries what I chose, what I gave up, what didn't work and what's still unresolved, because the next person needs the reasoning, not just the code.
• Gates instead of trust. A strict lint configuration, 169 tests on Alex OS and fixed evaluation sets mean a change is checked against the standard before a reviewer's attention is needed.
• Measured claims. When I say something got better, there's a number and a method behind it, like the evaluation report where my own default lost.
• Every diff read. AI-drafted or not, nothing ships that I haven't reviewed and understood.
• Knowledge shared outward: the workshops on this site teach the same lessons, written so another team can use them.

06What I won't do

One thing I won't do is ship something I already know isn't good. If a system doesn't meet the bar, it doesn't go out. I'd rather fix it, or say so plainly, than pretend it's finished.

07Where I've worked

I'm based in Skopje, North Macedonia.

08Teaching & mentoring

09Ask Alex OS about me

Alex OS is the assistant on this site, and it was built the way I describe above. It answers questions about my work from what I've actually published, with sources, so you can check anything it says.

10See the evidence

None of this is just claims. The work is here to inspect: projects with the problem, the decisions, and the outcome, and an evidence section with before-and-after results and the limits of each number.

11Workshops

I run hands-on workshops, which also work as talks, on building with AI without lowering the bar: owning AI-written code, RAG that knows when not to answer, and measuring AI systems honestly.

12Get in touch

If you want to talk about applied-AI product work, full-stack platforms, or how to build with AI without lowering the bar, I'd like to hear from you.