Between
Rounds

A year ago I sat down to learn Swift. I had a small app in my head and the old confidence that I would have it running by the weekend.

I taught myself to code at fifteen and was shipping PHP for paying clients before I was twenty, so how hard could one more language be. By midnight on the second day I was stuck on a type error I could not even read properly, cursing myself for letting the muscle go. The syntax was the smaller problem. What I had lost was the patience to sit inside a problem that does not care how busy you are.

My respect for working developers went up several notches that week and it has stayed there. Knowing the language is the entry fee. The real cost is diligence, hour after hour, when nothing works and nobody is watching.

That is how programming used to feel, even when I was good at it. A long night with the output in mind and a hundred small bottlenecks between you and it. Two modules that refuse to talk to each other. A whole evening lost to one missing semicolon. You patch, you run, you patch again, and at some hour you pull it off and go to bed feeling like you earned it.

Now the machine pulls it off. I describe what I want, and a few seconds later there is working code where there was nothing. The long nights are gone.

What surprised me is that the work did not get smaller. It moved.

The closest picture I have is a boxing match. Every prompt is a round. The round itself is fast and mostly out of my hands; the model does what it does and I watch. The real work happens between rounds, on the stool, in the sixty seconds where I look at what just happened and decide what to change before the bell. Did that land. Is the project drifting. Do I keep the plan or throw it out. Then the bell, and another round.

And here is the round I keep losing.

The model will do something impressive, far better than what I asked for, and in a direction I never intended. It is hard not to be charmed. The thing works, it looks good, and some part of me wants to follow it and see where it goes.

But I am the only one in the room who knows why we are building this. The model knows the last prompt. I know the customer, the deadline, and what this has to become in three months. So I sit on the stool and decide: ride the new direction, or pull it back onto the track. Most of the time pulling it back is right. Most of the time I hesitate anyway, because it feels like throwing away a gift.

That hesitation is the new skill, and I did not see it coming. Writing code needed patience with the machine. Directing it needs patience with yourself: the discipline to say no to a good thing because it is not the thing. Whoever knows the why has to hold it, out loud, round after round, against something that is faster and more fluent and does not care.

Which is why I am careful about the word easy.

No-code tools, and now vibe coding, have let a lot of people try product development who would never have sat through a Swift tutorial. I think that is a good thing. But I have been on both sides of it now, and the hard part was never the part that got automated.

A year ago I could not get a single screen to compile. Today I can get a working app in an afternoon, and I still lose rounds. Knowing what to build, holding the why against a model that keeps offering something shinier, deciding on the stool with the clock running: none of that is syntax. Development was always more than code and knowing the language. The tools just made that visible to everyone at once.

The fight is the same.

The gloves got lighter, that is all.