I was deeply AI-skeptical for a long time. I still am, at least in some (many) ways, but after giving it a serious chance, I shelved away a lot of the doubts that made me skeptical in the context of my job, which is being a programmer for a video game company. And even if it took me some time to admit it, I can say now that adding AI to my projects has brought some invaluable advantages. So I’ll say it out loud:
AI actually helps me to produce better code.
I might be late to the hype (sigh…) train, I know, but that’s something I would never have imagined admitting a year ago. After spending proper time testing this tool and reading some articles, though, I think I’ve managed to come up with my ideal workflow for AI-assisted programming, one that seems to be working fine for me, and no, intensive code generation is not part of it.
With this setup, I’m actually managing to keep enjoying my craft while still feeling the benefits that come with using LLMs. It feels like the future, without the scary parts that are (legitimately) overwhelming so many fellow programmers out there.
1. Code reviews
AI is an excellent code reviewer: it’s methodical, it really does read every line of code, it never loses focus, and it’s not afraid of hurting your feelings (while also not willing to emotionally abuse you either).
That’s why, for each project I work on, I write what I call a precommit-review skill: something I want Claude to do before I commit a new change. I usually adapt it to the specific standards I want to enforce in the project, but I can summarize it as something like this:
git stashthe current changes without reverting them, so we have a recovery point.- Read the currently staged files and review them. Look for logical errors, memory leaks, excessive complexity, violations of best practices, duplicated code, dead code. Report everything to me without making any behavioral change.
- At this point, I decide whether to apply the fixes myself, tell the AI to apply them, or skip them entirely. Then I tell Claude to repeat the review from point 2, until I give the stop command.
- When the stop command is received, the stash is deleted, and a run of clang-format (or any other formatting tool, depending on the language) is done on the modified files.
This doesn’t just help me make sure I always deliver higher-quality work, even when I’m a bit too lazy or tired: being aware that I’m producing code with higher value is a boost of motivation that actually helps me stay in the flow.
What’s more: catching a bug before it actually shows up gives you an immediate feeling of saved time. You see the bug and think, “This would have wasted so much time debugging over the coming weeks.” And it’s just so satisfying — a free shot of dopamine.
I don’t care if it was an AI that spotted it. It could just as well have been a colleague doing a review, or me two months from now: who found it has zero importance in this situation. The only thing that matters is how much time the bug would have made you lose.
AI minimizes that amount of time. That’s the real deal-breaker, the actual gain: not the time you don’t spend typing code, but the time you don’t spend wracking your head against the wall trying to find the source of a memory leak.
2. Bug fixing
Well, not all bugs can be spotted in review, even by an AI. And when you find a bug, modern LLMs can be pretty good assistants: they can scan huge amounts of code in seconds, form their own hypotheses, test them, and if they still can’t find the solution, they’ll be happy to help you seed print statements here and there when needed (which I always hated doing…) and inspect the output you provide after reproducing the issue.
Basically, since I started using LLMs, hitting a bug doesn’t trigger the thought “Oh no, I’m going to lose my whole day to this” anymore.
3. Learning
That’s not a mystery to anyone at this point: LLMs have replaced (or are on their way to replace) Stack Overflow, and for many people they already act as the primary source of learning. The reasons aren’t hard to find: an LLM will produce exactly the information you need, at the level of detail you need, and won’t get annoyed if you ask a “stupid” question. Really, the ability to ask ANYTHING without fear of being judged by some seasoned Stack Overflow Arch user is priceless. The questions I usually ask:
- How do you do X in [language|library|OS]? Make an example.
- I wanted to do X and I did it like this. Does it reflect the [language|library]’s best practices?
- Is this the optimal method to achieve what I want?
- Could this be written with less lines of code?
What about code generation?
I’m extremely careful when I decide to have the AI write code for me, to the point that I’ve become almost reluctant to do it. There are various reasons.
1. Are we still allowed to be professional? At least… a bit?
I still find it absurd to just prompt instructions to an LLM and commit whatever the machine spits out without even looking at it, or after trying to review its batch of 3000 new lines of code and convincing yourself that you somehow “reviewed” it. This has basically nothing to do with the actual capability of modern LLMs: I know that Claude is a capable coder. I just think that, as professional engineers, we still have the responsibility of knowing what we’re pushing out into the world. If we really want to make something of value, we have to make sure that there is… well, value in what we do. Some would say only a fool would believe this. Well.
2. Can you really review all of that?
Generating a lot of code means generating a lot of work to review, and I’ve never believed the human mind was made for long code review sessions. Reviewing code is boring and extremely tiring, and if done for too long, it becomes useless or even harmful, because we start skimming the lines that seem “obvious” and inevitably miss real mistakes, or see mistakes where there are none.
3. I’m not that rich, man.
Having the tokens paid by the company you work for is one thing, but paying for your own is something else entirely. And these tokens are expensive. Like, really expensive. I would not be surprised at all if, at some point in the future, companies started encouraging developers to use fewer tokens. The ability to save computational power is a skill that will come in useful, I can bet on that.
Now look, I’m not saying you should never make an AI generate code. I’m not even saying I never do it; in fact, I do, but with a couple of specific rules:
I only generate code that I’d be perfectly capable of writing myself: if I can’t write the code I want to generate in pseudo-code, the result will most likely be trash.
- When Claude starts writing, I switch to manual mode. Not because I’m a control freak (well…): it’s just much easier and less overwhelming to review the generated code in smaller bites, rather than ingesting the complete menu at once.
- Always make Claude review his own code. He will always find issues. But beware, this is the best occasion to practice critical thinking: is Claude right and he actually found an issue in his work, or is he just trying to convince you he is in good faith by finding at least one issue? Sure, much of this might (and probably will) change with the evolution of AI models in the near future. Some of these takes might also sound pointless once AI is reliably capable of generating “good enough” code without needing this much oversight. But let me tell you something…
Just because humanity happened to invent this miraculous tool that turns one programmer into ten (a made-up number, by the way), it doesn’t mean we’re obligated to sacrifice our mental health on the altar of productivity and profit. Saving time and money won’t help either you or your employer if it leaves you miserable, burnt out, and ready to quit to start a farm. We, the people who actually build stuff, have the same right to discuss how we should use AI as that tech bro writing another It’s not this, it’s that post on Linkedin.