Do I use AI at work?

The AI “holy war”

If you’re a software engineer right now, it sometimes feels like you’re being asked to “pick a side”. You either have to be an AI fanatic, using it to replace every aspect of your work day and even replying to emails with AI-generated responses, or you have to hate it so much that you won’t share space with it at all.

But, like most holy wars, it is possible to take a third position - the cautious and informed position that accepts that the answer is actually nuanced.

AI is actually good at some things. It’s just not very good at many of the things that people say it’s good at.

What LLMs are good at

Calling large language models (LLMs) “artificial intelligence” is a bit of a stretch. Yes, under laboratory conditions some of them have shown so-called emergent properties but for the most part they don’t actually think.

LLMs are probability engines. They have seen huge amounts of data - more than you can comprehend - and they look for patterns. They don’t reason about anything - they assemble text based on probabilities, which in turn are determined based on patterns in the source text. Agents can act, which might give them access to more input data than just the words you type, but ultimately they are still just finding patterns and generating the answer with the highest probability of satisfying you.

This isn’t thinking. It is copying. And this is what LLMs really excel at - they can do things that have been done hundreds or thousands of times before, and they can do those things faster than you can.

They don’t excel at original thinking. Original thinking can’t be reduced to a maths puzzle. But they are brilliant at doing the tasks that you already know how to do, as long as they’re small enough. LLMs are great at working on small, understandable units of work, not so much on anything larger that requires some problem-solving.

Coding is a tiny part of engineering

I am very insistent on referring to software engineers as software engineers, and not as coders.

Good engineers spend very little time actually writing code. We spend most of our time puzzling out problems - in our heads, or on whiteboards and in notebooks. On reading source materials and seeing how other people have tackled similar problems and whether those techniques can be applied to the problems in front of us.

Typically when we get to the end of that thought process, the actual coding turns out to only be a few lines. Or if it is lots of lines it’s rote or boilerplate, which needs to be abstracted away into meaningful and tidy components.

Object-oriented programming appears to be going the way of the dinosaur, but some of us cling to it because it allows us to write clean, concise and maintainable code.

If I stick to my engineering principles, and ask the AI only to work on small, understandable units, then all the AI is doing is the last part of any given task. It’s doing something I already know how to do, but a part that is - honestly - quite tedious and is getting in the way of me getting onto solving the next problem.

What I will not use AI for

You have to draw a line in the sand somewhere, and mine is that I will never use AI to replace something that I can do better. I’ll never use AI to do something that is part of my soul - part of the reason people hire me and want to work with me.

I will never use AI to write this website, blog or my newsletter. The whole point of this content is that you’re engaging with a genuine person who knows stuff. The tips I give are based on real experiences I have had and they’re written in my unique writing style. It’s a marketer’s wet dream to be able to churn out content at the speed of light, but what’s the point of that content? I’d rather miss a week here and there than produce content that is meaningless or repetitive.

I will never ask AI to replace my engineering thinking. I want every problem I solve to be a problem that I’ve solved. AI can help me understand other people’s solutions to things or digest documentation, but whenever I commit a thing to the codebase, I want to know exactly what it is doing. I might let it write a few Tailwind incantions or the like, but I’d never let it do an algorithm design without me dissecting that design and understanding exactly what it’s doing. It’s too easy for AIs to make mistakes, especially about NFRs.

I will try to avoid using AI to steal other people’s creativity. Coding is interesting - there’s a culture of sharing here that I think means, for the most part, getting inspiration from other people’s work is (or can be) OK. But with other art forms it’s more dubious: as we know, AI can only copy other people’s work, and with things like illustration that’s really not cool. I’m absolutely shit at things like this so I might use AI to help me with ideation, privately, but I will try to avoid publishing anything too creative that has been generated by AI. When it comes to actual finished products, nothing beats actual humans being paid for their work.

And this is a reminder of the biggest trap of all. AI can only copy: it can’t have original thoughts. If we remove humans from this ecosystem, we inadvertently remove original thought from this ecosystem, and we’ll eventually become a carbon-copy culture that stops innovating. I don’t want that, and I want to always ensure we only incorporate the performance boost of AI without sacrificing our souls.

My golden rule for when it’s OK to use AI

I’m forever referring to this Kurzgesagt video (the whole video is good but the link is to the relevant part) that introduces the “align tool” analogy, which I spell out in my own words here:

Use AI only as a tool. Use it if it speeds up something you would be able to do by yourself, given enough time.

This is the key thing for me. A tool stops being a tool when you use it to do something you don’t know how to do. For example, if I ask an AI to build me something in a framework I don’t understand and haven’t read the documentation for, or I ask it to replace a skill I don’t possess (such as illustration) then I have crossed the line.

In practice, this means asking it always to do small, understandable units of work, where I can follow along with its working and tweak at every step. I’ve only been using Claude Code for 1.5 days but so far this approach is working well for me, and I still feel 100% in control of my codebase. Ask me again in a year.

Further reading

I’m far from the expert on this topic, and it seems like YouTube is the place to be for nuanced, balanced views on this subject. Here are three creators I’d highly recommend you follow:

• Mo Bitar - Mo, in a dry and sarcastic and sweary way, takes down all the bullshit spouted by AI executives. He uses AI in his work, he understands AI, and he doesn’t fall for the lies about what it supposedly is. Mo is the absolute master of analogy - you know I love an analogy in my work but no one does them better than Mo.
• Alberta Tech - Alberta is a former Google senior engineer who is most famous for her tech comedy (much of it is AI-focussed too) but her longer-form content provides very real and very nuanced takes on how things are actually going for real engineers in the biggest companies.
• Sajjaad Khader - Sajjaad is a bit less nuanced and more “pro-AI” than the other two, but his content is still balanced and really interesting. He also has access to people - he has interviewed many CEOs and executives at these AI firms so you can hear their perspectives too.

What are your thoughts about using AI in engineering? What’s going on at your workplace? Let me know!