So I’ve become a blogger. Or rather, I’m becoming one - it’s too early to say whether this turns into anything lasting. But let’s give it a shot.

Where did the idea come from? I started writing yet another version of my toy programming language, and this time I decided to document it. First, to leave myself a trail of what I was trying to achieve - projects like this have a way of pulling me back months later, when I no longer remember why I did something one way and not another. Second, because someone might find a different take on how to approach it useful. Programming languages can feel like a subject reserved for academia and a handful of initiates, and they really aren’t. I want to show the practical side: what works, what breaks, and why.

But I don’t want to stop there. My day job is backend and systems architecture, and that’s the second thread I plan to follow here. What interests me is the seam where theory meets reality - how elegant assumptions collide with the fact that systems fail, data drifts apart, and the “guarantees” we promise ourselves turn out to be thinner than we thought. I also like coming back to the patterns I reach for when designing something, and asking myself why some hold up better than others. And I’m curious how habits picked up in one language reshape the way I write in a completely different one.

I won’t promise specific titles here - I have a few in mind, but not all of them will happen, and some will probably change shape along the way. I’d rather treat this blog as a place to jot down whatever I’m working on at the moment than as a list of commitments. We’ll see how it goes.

Reading the occasional article - technical and otherwise - it’s hard not to wonder: how much of this was written by a person, and how much was polished, or outright generated, by AI. Fairness to the reader means saying plainly how it works on my end. Yes, I use AI. It helps me gather material, checks my reasoning for consistency, catches language mistakes, and translates - English isn’t my first language, and putting it out into the world still feels a little uncomfortable. But the idea and the content are mine. AI is my editorial team, the reason the whole thing simply reads better.

And the code and the solutions I present? It’s much the same. I use AI at work. We discuss new functionality as a team and run it past the model too - which doesn’t mean we take the first thing it hands us. At the end of every decision there’s a person, in this case me. When I write code, I lean on AI; sometimes it generates most of it. But that doesn’t excuse me from reading it, understanding what it actually does - not what it was supposed to do in my head - and checking that it holds up.

That’s why I break tasks into smaller pieces and generate code against specific assumptions, keeping an eye on quality and staying on topic. Handing AI an entire task from start to finish doesn’t convince me at all. After a few iterations I feel lost enough in that kind of code that I’m left with two options: a laborious refactor, or handing it back to the AI. And the refactor would probably take longer than writing the whole thing myself from scratch. So much for the introduction - now to the point.