XII.AI at work · August 2026
The more I fix with Claude Code, the more I want to fix without it.
The first few wins are thrilling. Then the credits start running out — and you realise the people who don't get addicted are the ones who learn what's behind the screen.
By Gisella Famà · 5 min read · AI at work
There is a particular rush that comes from typing a sentence into Claude Code and watching a real UI fix appear in your actual product. It is not quite confidence, because you didn't write it. It is closer to the feeling a slot machine gives you on a lucky pull: something worked, and you want to pull again.
I have been pulling the lever a lot lately. Small fixes on real products, UI tidy-ups, layout nudges, the kind of things that used to live in a Jira ticket waiting for an engineer. Each time it works, I feel the same small jolt. Each time it works, I also notice a second feeling growing underneath it.
"The real question isn't whether AI can fix it. The question is whether you know what it fixed."
The rush, then the bill
The first few weeks were pure upside. I could describe a problem, watch Claude locate it, and have a running change before my coffee got cold. It made me feel like a front-end developer in a way that I hadn't before — faster, more capable, more plugged into the product.
But the meter is always running. Subscription credits, token usage, the quiet arithmetic of 'how much of this fix did I actually pay for?' The small fixes add up. Not just in money, but in dependency. Every time I reach for Claude instead of reading the file, I am buying the answer instead of learning the place.
What I started doing instead
I now read the diff before I apply it. Not skim it — read it, line by line, like a translation of what I was about to ask for.
I run the commands myself. If Claude suggests a git branch or a terminal command, I type it. The muscle is worth more than the shortcut.
I spend longer in the error. Instead of pasting the failure straight back, I sit with it and try to understand whose code is talking to whose.
I ask smaller questions. Not 'fix this screen' but 'what is this prop doing' — because the smaller the answer, the more likely I am to recognise it next time.
The slot machine theory
I have been thinking about why AI coding feels so addictive at first. It is not just speed. It is the random reward schedule. Sometimes you get exactly what you wanted. Sometimes you get something close but subtly wrong. Sometimes you get a confident answer that breaks something else. The uncertainty is part of the dopamine.
Slot machines work because people chase the win. The people who stop are not always the ones with more willpower. Sometimes they are the people who look at the machine and decide they would rather understand the game. Or start a new game.
Why I am not the gambler type
I don't like not knowing why something worked. I don't like the feeling of a win that belongs to the machine more than it belongs to me. And I don't like the idea that my ability to improve a product is gated by a subscription and a credit balance.
So I am learning the boring parts. The terminal commands. The file structure. The way the state flows through components. The things that don't give an immediate reward but slowly move the dependency from Claude to me.
What I'm actually trying to become
Not an engineer. That would take years and it would be a different job. What I want is to be a designer who can make the small fix herself, who knows enough to spot the obvious problem and the obvious fix, and who only brings in AI when the problem is genuinely fuzzy.
Claude Code is still in my workflow. It is excellent for exploration, for scaffolding, for the first pass when I don't know what I don't know. But the goal is to need it less — not because I am rejecting it, but because I am becoming less dependent on it.
"The best win is not another pull of the lever. It is the moment you open a file and already know what to change."
I suspect this is the healthier arc. Use AI to get started, then learn the parts it teaches you by accident. Let the first pass be fast, but make the second pass yours. The product gets better, the bill gets smaller, and you stop feeling like a tourist in your own codebase.
Disagree? That's the point. Tell me why.
← Back to all thoughts