Photo by Arnold Francisca on Unsplash
Coding with AI: what we gain and what we quietly unlearn
Yesterday I wrote a date normalisation function in twelve seconds. The assistant suggested it, I skimmed it, I accepted it, and it was right. That evening, in another project without an assistant, it took me four minutes to remember how to handle a timezone offset by hand. Four minutes on something I could do with my eyes closed two years ago.
The gain is real, and it’s immediate
Let’s say it straight away: I’m not switching the tool off. On repetitive code, obvious unit tests, converting from one format to another, translating a piece of logic from one language to another, it’s a clear gain. It removes friction from tasks where the friction taught nobody anything.
It’s also good for exploring an unfamiliar library. Not because it tells the truth, it gets things wrong regularly, but because it gives you a named starting point. Searching documentation when you don’t know the field’s vocabulary is the worst moment of learning something.
The difficulty we removed was doing something
Learning research has a name for this: desirable difficulties. An effort to retrieve something from memory, an error you correct yourself, a detour that costs ten minutes, these things stick. The shortcut sticks nothing. You get the result without the journey, and the journey was what built the map.
In practice, what I feel eroding isn’t syntax. It’s reading. Reading code you didn’t write, at the speed of a suggestion, in a validation state rather than a design state. An experimental study of assisted developers found that they produced less secure code while reporting more confidence in its security. The gap between those two things is the part that interests me.
Who benefits from the speed-up
There’s a question we rarely ask at the same time as the technical one: where does the time saved go? In my personal projects, it goes to me, and that’s very pleasant. In a company, it doesn’t end up as days off. It ends up as a wider scope with the same headcount.
These tools are trained on public code written for free, for years, by people who never billed for it. They are then rented back, month by month, to those same people. The model is elegant from the point of view of whoever collects the money. I pay my subscription like everyone else, so I’m inside it, not above it.
How I organise myself since
I’ve kept two separate modes. In everyday production code, the assistant is active, and I review it the way I’d review a hurried colleague’s pull request. In anything I really want to understand, a network protocol, an algorithm, a binary format, I switch the suggestions off and struggle.
The second mode costs time nobody reimburses me for. It’s also the only one where I still improve.
Skill doesn’t vanish in one go. It quietly wastes away, and you only notice on the day the tool gets something wrong that you’re no longer able to check.
Related articles
Technical debt is a decision someone made, not an accident
We talk about technical debt as if it were a developer's fault. Most of the time it's an economic trade-off made well above the keyboard, by someone else.
Lire l'article →
Serverless, and the bill you find at the end of the month
Paying per execution looks honest until the day a loop, a bot or a broken cache turns an elegant architecture into a meter that runs on its own.
Lire l'article →Sources
What I read, watched or checked while writing this article.
- Perry, N. et al. (2022). Do Users Write More Insecure Code with AI Assistants? Experimental study of code assistants and security arxiv.org (opens in a new tab)
- Wikipedia (fr). GitHub Copilot: how it works, the underlying model and the controversies fr.wikipedia.org (opens in a new tab)
- Wikipedia (en). Desirable difficulty: the effect of learning difficulties on long-term retention en.wikipedia.org (opens in a new tab)