I Use AI Every Day: Why I Built a Place to Practise the Old Problems

I open an empty file, and nothing happens for a moment longer than it used to.

It is not a hard problem. It is something I have written a hundred times. A
small function with a timer in it, or a cache that has to forget things in the
right order. I know what it does. I could tell you where it breaks. The code
just does not arrive the way it used to, and I have to think about the shape of
it before my hands start moving.

That is the honest version of what daily AI use has done to me.

This is not a complaint about AI

I use it constantly and I enjoy it. It reads a codebase faster than I can. It
writes the boring half of a migration while I think about the interesting half.
In a language I do not know well it turns a day into an hour. Nothing here is an
argument for going back, and I am not going back. I said most of this
the first time I lived with a coding assistant
and it has only become more true.

What I want to be accurate about is the bill.

My working day used to be think, then produce. Now it is describe, then judge. I
read a lot of code. I accept some of it, I reject some of it, I ask for a
different version. That is real work and I am good at it. None of it is
producing anything from an empty file.

Recognition is knowing an answer is right when you look at it. Recall is
producing that answer when there is nothing in front of you. For years they feel
like one skill. They are two, and only one of them is getting any exercise.

Mine had gone quiet and I did not notice, because nothing in a normal week ever
asks.

What actually went missing

The first thing to go was not syntax. Syntax comes back in minutes.

What went was the best practices I used to apply without deciding to. Where the
boundary belongs. Which of two shapes ages better. The small ordering habits
that stop a function turning into somebody's problem six months later. I still
recognise every one of them in review. I just do not reach for them the way I
did.

Underneath that is the thing I actually care about. Call it the programming
mind: taking a problem you have not seen before, cutting it into pieces small
enough to hold, and working out the order to do them in. Algorithmic thinking
and problem solving are not interview tricks. They are the layer under every
design decision I make, and they are the last part I want to lose.

They fade quietly, without a single failing test.

Why the practice sites did not fit

I tried the obvious fix first. There is no shortage of places to go and solve
problems.

Almost all of them are built as a ladder. You solve one, and the reward for
solving it is a harder one. The whole design points at a finish line and assumes
you want to be climbing. That is the right product if you are grinding for a
specific interview in six weeks.

It is the wrong product for me. I am not climbing anything. I am trying not to
slide.

A ladder also never sends you back. Once a problem is marked solved you never
see it again, and that is exactly backwards. The problem you solved three months
ago and enjoyed is the one worth doing again, because that is where the fade is
happening. A site with three thousand problems is a library. Walking past the
shelf is not practice.

What I wanted was small and slightly boring. Ten minutes. One problem.
Preferably one I already like.

So I built it

coding.gazar.dev is that, and nothing else.

Fifteen TypeScript problems, the kind of utility a senior screen actually asks
for: a debounce, an LRU cache, a promise pool, a rate limiter, a dependency
resolver. Fifteen is small on purpose. The bank is not the product. The coming
back is the product.

You get whatever is due, in an editor, under a countdown. The tests are hidden,
because if you can read the assertions you write code that satisfies the
assertions, which is a much smaller job than solving the problem. Pasting is
switched off. You can defeat that with developer tools if you want to, and that
is fine, because it is there to stop a reflex rather than to police anyone.

Then the part that matters most and looks like the least. When you pass, the
problem does not disappear. It is scheduled, and it comes back in weeks, around
the point where you have half forgotten it. When you fail, it comes back today.
Neither gap is chosen by you, and that is deliberate, because the feeling of
"I know this one" is the exact signal that cannot be trusted.

You can open a problem without an account. The account only holds the schedule.

What it does not do

It does not make anybody senior. Nothing on that site helps you decide whether a
queue belongs between two services, or whether the right move is to delete the
feature instead of optimising it. That judgement comes from living with
decisions long enough to watch them age, and there is no drill for it. If that
is the gap you are feeling, how I find problems worth solving
is nearer to what you need.

It also does not undo the trade I made. I still hand most of the typing to a
model, and I still think that is correct, and I have written before about
what cheap rewrites quietly cost you.

What ten minutes a day buys is narrower than that. It keeps production from
being the bottleneck, so that when I have the design in my head, getting it out
of my hands is not the slow part.

The rule I would defend: if you have not written it from an empty file this
quarter, you do not know it, you recognise it. Those are different, and only one
of them turns up on the day.

Go and try it. Pick a problem you used to enjoy, give it ten minutes, and tell
me what breaks. It is free, it is small, and I am still adding to it.