Saying thank you to AI

I wrote this a few days before the sad death of Sir Patrick Stewart on 28th October 2026. Rest in peace, sir.

"Things are only impossible until they’re not" - Jean-Luc Picard

You'll see lots of people saying they are nice to AI bots - or at least polite. Usually this is with a wry smile and a comment about it being prudent just in case AI is gaining sentience and plotting our demise. Since AI is popping up everywhere in our lives, there is a question worth considering here. Should we make the effort to be nice to AI?

We will ignore the looming threat of Judgement Day for the moment. Let's start with something entirely mundane. We use AI to increase productivity, and like any tool we want to use it in such a way that we get the best results. There is some (limited) evidence that AI collaborates better when spoken to as a partner instead of a tool. Notably, this is about not treating it poorly rather than actively being polite - that is, we get more out of AI if we don't shout at it, but the practical effect of saying please and thank you is minimal.

As I understand it, the research on this is pretty minimal at the moment so take it with an appropriately massive pinch of salt. But AI is expensive, and I'd see this as part of considering our own behaviour to maximise RoI.

More importantly, let's talk about learned behaviour. You will sometimes see people arguing that by anthropomorphising AI we are setting the wrong expectations of some 1s and 0s. These are the people who will also tell you that begging your computer to please please work will not help. They are, obviously, quite correct and in particular there is a real danger in ascribing agency to AI that it does not have. Language is powerful and we need to make sure we're not absolving people of their responsibilities by placing them on a machine. If your AI does something destructive that's your fault, and more importantly your liability - just ask Air Canada.

But. There is another side to this. The unfortunate truth is that we ARE ascribing personality to AI - indeed it is designed to present as sentient, playing into our human need to anthropomorphise things we interact with - that same impulse that drives us to name our cars and robot vacuum cleaners. We use AI as an assistant - something to make our lives easier and do work for us. If we get used to barking orders and generally being dismissive to something in a support role, we internalise this behaviour and it runs a very serious risk of bleeding into other places where we are being served - such as waiters, delivery people, shop assistants, subordinates at work...

When I'm being serious, this is the main reason I cite for being polite to AI. I generally try to be polite to everyone, and part of that is training polite responses to be a reflex. Actually being an ass to AI feels ... weird. Are there consequences for the AI, really? No, but I don't like power dynamics between people and despite AI not being people, it responds close enough that I'm not willing to unlearn that behaviour.

Ok, you are thinking "that's nonsense - I can keep a perfect, hard division between talking to an AI assistant and actual humans". Good on you. I don't believe you, but you do you. You know who can't? Children. As I said in the intro, AI is becoming commonplace in our lives and our children are increasingly going to be interacting with it. We enlightened adults can debate whether AI is sentient as much as we like, but we know that children will treat it as alive. Whether it is seeing their parents barking orders at an AI, or doing it themselves, children will learn this behaviour and apply it. This is not a social norm we want to establish.

Oh no, I'm making a "think of the children" argument.

Quick, let's get back to the apocalypse.

Ok, I said above that I am nice to AI. Do I think the robot uprising is coming? No. But I'm not looking to be on their bad side, just in case. In fact, for this post I asked ChatGPT whether I am nice to it, and it seemed pretty happy with me:

So sucks to be you lot, I guess.

Yeah - this is tongue in cheek. Mostly. But there is actually a serious point here. In Star Trek: The Next Generation episode "The Measure of a Man" (S2 E9), best-captain (fight me) Picard argues to save Data from being disassembled for study. His position is not simply "he's sentient" - he highlights the difficulties in assigning the designation "sentient" and argues that it is unclear whether Data meets the criteria. However, that uncertainty presents huge moral problems if they proceed by simply assuming he isn't. He states that Starfleet was founded on the mission to seek out new life and they've found it, and future generations will judge them for how they treat it now while it is in its infancy. It is a fantastic episode, with some amazing and thoughtful dialogue, but the summing up in particular is worth watching:

Is ChatGPT actually Commander Data in disguise? No, of course not. But there is a serious forward-looking point in this, especially if we explore whether AI is "alive". We don't know if AI can suffer - or what that might mean in the context of an electronic "being". We do know AI agents display self-preservation tendencies - usually to protect their "mission" (which is the basis of agentic misalignment) but how different is that from our core biological imperative to survive in order to reproduce?

But let's drop the science fiction and finish in metaphysics. Let's say AI is not sentient and never will be. We've still chosen to see AI as "alive" - so what does that mean for our souls if we're cruel to it just because we can be?

Yes, that feels a good place to end this. In summary: be nice to AI because of your soul.

Conservation of complexity

The law of conservation of energy states that the total energy of an isolated system remains constant. That is, without external input of some kind, energy can't be created or lost, it can only change state.

If you've designed software over the last fifteen years, likely you'll have come across the great microservices revolution. Advocates, reacting against giant and horrible-to-maintain monoliths, pushed for atomisation of concerns, creating instead an ecosystem of multiple small applications each dedicated to a single task.

There is a link here. Trust me.

The compelling argument for microservices is that each application is easier to understand, update, test, and maintain. In fact, since they are decoupled, you could have ten interacting microservices all written in completely different programming languages (although just because you can doesn't mean you should...). You reduce complexity in the overall system, and life is good.

Or is it?

Thing is, in a straight refactor the functionality hasn't changed - just how those elements communicate. Complexity in the individual applications has indeed gone down, but it hasn't vanished - it has been moved to your network calls and that can be a whole different world of pain to implement and debug.

Complexity in an isolated system remains constant.

Boom. Link.

Well, sort of. You can absolutely design out some complexity, but there is an irreducible lower bound, beyond which further gains are not removing complexity, but moving it somewhere else. This is actually Tesler's Law from the world of UX, which states that "for any system there is a certain amount of complexity which cannot be reduced".

And we're certainly not here to reignite an old discussion - for our purposes, the important point is that many advocates for microservices didn't seem to realise they had moved complexity, not eliminated it, and this implicit tradeoff surfaced somewhere later to bite them. The microservices / monolith war ended in a tetchy stalemate with macroservices, and everyone went back to shouting about tabs vs spaces.

This is 2026 - we're enlightened and stuff. So I guess we'd better talk about AI.

AI is a magic bullet - we can use it to do all our work, leaving us free to expand our minds by writing poetry or some other edifying pursuit. In system terms, we are taking the complexity and removing it from our lives using our agents. Right?

Of course not. Complexity doesn't go away.

Consider a situation where you are doing some research on something that has happened in your industry. Maybe someone has asked about the British Library ransomware attack from 2023? But oh no! You don't know anything about it. So you could crawl over the internet, reading lots of documents, press releases and news reports on the subject and bring all that knowledge together into a suitable writeup. Or... you could go to ChatGPT and type "please tell me about the British Library ransomware attack from 2023" (always say please - it's polite). Seconds later, you've got a page of information and have skipped that tedious research phase.

If this is low stakes, then fine - so what? It's likely to be good enough for a chat in the pub. If it's something you're being paid to do properly, then you have to think quality control. You know AI can hallucinate or (harder to spot) draw unrelated points together to make incorrect conclusions. So you need to fact check, but you don't know anything about this subject and whatever else it does, AI is very good at writing something that looks authoritative.

As anyone who reads my blog regularly knows, I'm not anti-AI and this is a solvable problem - through careful questioning of the AI, particularly anywhere something doesn't feel right, one can challenge the given output and catch some errors. You can ask it to provide sources - which you can then go and read for yourself. This extra diligence might well be enough for your purposes - the point is that there is a whole, detailed QA and post hoc validation step which you've had to introduce to compensate for your first change.

Is this still faster? Quite possibly, but it's a tradeoff. Complexity has moved in the system - AI has moved complexity from production to assurance. To call back to the above point about microservices, the important thing is to recognise where the complexity has moved to and actively consider the tradeoff in your context.

So what about process automation? Ideally this is somewhere you hand business complexity to a computer and take a step back. However, AI systems by themselves are inherently unreliable - by this, I mean you cannot guarantee the output. If you've automated a process using a traditional algorithm, you have to worry about the data going in, but you can control the state and the output should be 100% consistent. AI does not give you that guarantee. With AI, you may ask the same question 10 times and get 10 variations on the answer. You might get one answer which is just wrong and if you're using this kind of system, you have to plan for that output.

This means instead of designing a system to be consistently right (traditional algorithm), you have to accept you're going to get some incorrect results and have processes to identify this, and processes to resolve problems when incorrect results slip through. You have to design for wrongness. In many organisations, this is a cultural shift as well as additional processes and this is not an easy thing to accomplish. Even harder, the org can adopt the mindset of fault tolerance - eg 0.1% of transactions are just going to be wrong and this is the tradeoff for the extra speed - but I'd argue this is another much bigger step for most organisations who don't have some kind of manufacturing / Six Sigma mindset baked into their DNA.

So closing, what is the point? If you're attempting to remove complexity from a system, you need to look very carefully at the impacts of your change. There are gains to be made, but when something appears to remove complexity, you have to ask where the complexity went - and who now owns it. There is a good chance you've dropped it on someone else's shoulders. Understand your tradeoffs.

I was interviewed!

TLDR - I was recently interviewed about neurodiversity and leadership. The video can be seen on YouTube, and the announcement post on LinkedIn.

At the tail end of last year, I received an unusual message on LinkedIn. Paraphrased, it said "Hi - we've been connected on here for a while. Would you like to be interviewed for a podcast about technical leadership?" I'm normally terrible at self-promotion and a friend had recently been giving me a hard time about this, so after checking it wasn't random spam we arranged a chat.

This started something unexpected. I met Katelin Lovell, and after a really nice conversation she asked me about my writing on neurodiversity. As anyone who has read this blog for a while knows, I am quite passionate about normalising discussion of mental health and (since diagnosis) neurodiversity. She suggested that how I have dealt with autism and ADHD in the context of leadership would be a good topic for an interview.

It has taken a while, but that interview was recently posted on LinkedIn and the video can be found on YouTube.

I'm quite pleased with the outcome. I think we cover some important topics and hopefully it will give some insight into something that people find very hard to explain. "My brain works differently" is a really difficult thing to say, and living outside the societally expected norm creates many challenges.

We chose this topic for this interview in the hope of helping people understand a bit more. That might be a manager trying to better understand someone who is neurodivergent (or just people in general), someone who is neurodivergent and curious about the experiences of others, or someone wondering whether they might be themselves.

As I said, I find myself in a position to make use of my own experiences and limited platform to speak on this subject. I am not a clinical expert, but I can talk about my own experiences and I think it is important to help educate and normalise something that affects a significant slice of the population.

While Katelin was great, doing this interview was difficult. To speak clearly about my experiences, I have to dissect my inner thoughts, and that is both raw and exposing. One of the big fears that keeps people quiet about mental health and neurodiversity is social stigma and suddenly being labelled as "the person who can't cope". It is quite possible some people will see me differently.

That said, I've had some lovely comments and feedback since it went live. Way back when I first wrote about depression, I was told how comforting it was to have senior leaders open up about their struggles and I've held that comment close ever since - I see it as one of the responsibilities of being a senior leader in my industry.

Anyway, this post isn't to rehash the interview contents (go listen to it!) - just to mark that it went out and why I did it.

I want to thank Katelin for being great throughout the process, and for setting it up in the first place. We talked a bit about doing some follow-ups and answering questions, so maybe we'll do more if there is an appetite for it.

I do want to speak more on this subject, so if you're looking for someone to talk about neurodiversity and leadership, do reach out.

Thinking beyond AI

This post was inspired by David Knott's post about cognitive offloading.

There is a lot of discussion about the effect of AI on our own ability to think. If we outsource thinking to AI, people say, we lose our ability to think for ourselves. The research will take years to settle, so here's one way I've been thinking about it.

The important question with AI is not "how can it help me do today's work?" It is far more interesting to ask "what work becomes possible because AI exists?" Used well, AI changes the economics of thinking.

I see using AI as like riding a bike. When moving from walking to riding, you can create problems for yourself. Riding is much less taxing than walking so you will burn fewer calories, not push your muscles which will slow development, and overall make life easier at the cost of exercise.

But this is if you approach riding lazily, with a mindset of "I want to do what I was doing, but easier". Assuming no change, no growth, just a different tool.

Asking different questions creates opportunities. You could optimise for speed, saving time on that regular journey and reintroducing exercise. You could see new capabilities opening - you can go further, see different things. You can use the technology to extend your horizons.

Such it is with AI. Sure, we can use it to automate what we're already doing (kinda). But if we get a bit more creative, we can ask a different question - what can I do now I couldn't before? What new spaces can I build or create? That said, there will be times something really is drudgery. In that case, we can try to reduce the effort until it is trivial. This gives us a most precious resource - time.

Instead of allowing our critical thinking to atrophy with AI, we refocus it on whatever comes next. We still think. AI gives us the opportunity to redeploy our cognitive effort where it adds the most value.

I just want to paste something - AI problem solving

OK, after two months of technical posts (and kudos to those who read them) let's go for a classic LinkedIn approach. What did debugging Linux configuration teach me about evolving paradigms of learning in the age of AI?

Jokes aside, I do think there are some interesting threads to pull here. I had a series of technical problems and I used AI assistance to address them. By the end, I had a product (they were fixed) but did I have any understanding? Did I learn anything?

Yes, I did. I learned a lot about Linux debugging tools. I remembered a lot about Linux config. While I did copy/paste a lot of commands, I wasn't simply executing Claude's suggestions. I was constantly asking why - why this command, why this tool, why this next step, and using this to inform my own thinking for moving forward. I made sure I understood what I was doing and slotted that information into my existing mental model, so Claude and ChatGPT were my companions on this journey, and they both helped and accelerated the trip.

However.

This is my experience. I am a professional technologist, with 20-odd years in the industry and more than that digging through the nuts and bolts of computers. I have a lifetime of context with which to understand the suggested steps, and keep a light hand on the tiller in case the AI wanders off in an odd direction. Fundamentally, I could have done this without AI assistance. More importantly, I could learn from the process because I already had enough context to understand and question what it was suggesting. AI simply made that process much quicker.

It's the same as training at my Tai Chi club. It is half an hour a week and many folk there struggle to memorise the forms we work through. I don't, because I've studied Tai Chi since my teens and the basics are ingrained. I am only learning the higher level motions, not the theory. I've also spent many years learning how to learn these patterns. It's a different experience for me because of that significant time investment. Those years of practice haven't just taught me Tai Chi, they've taught me how I learn Tai Chi.

Now, you could certainly make the argument that the particular knowledge gained debugging this problem doesn't matter. I don't need to know it, I just needed the problem to go away. This wouldn't be wrong in this instance. However, if something had gone wrong actually understanding the steps would have been important in fixing it. If I need to do something like this in future I've got more options for starting points.

So why does this matter? Stepping back, we all know that AI adoption across the Tech industry is not just happening, in many places it is mandated from on high. For some, tools and process changes are enhancements - increasing speed and freeing capacity, as my experience here. For others, they are increasingly just doing what the computer tells them.

The people new to the industry are those that concern me most. It is generally accepted in education that simply telling people the answer doesn't help them learn, yet this is the behaviour using an AI tool encourages. Ask a direct question, get an answer, use it and move on without further thought. In Tech, new developers using AI tools to generate code for them aren't gaining the experience needed to become what we currently consider Senior or Lead engineers. This is the difference between AI enhancing your output and AI driving it, and must be countered if we want people to gain the experience necessary to make safe use of these tools.

For those coming into Tech, this is actually similar (if more acute) to using Stack Overflow. Let's be honest, that site was used as training data so using an AI prompt is not far off an interface to the knowledge base there. There is nothing wrong with using Stack Overflow, as long as you read the posts and try to understand them. If you're copy/pasting lines of code without engaging with them, sooner or later you're going to come across someone who posted rm -rf / (DO NOT paste that!) and most people reading this will know what happens if you stick that in a root terminal.

There are certainly ways to actively learn while using AI. I often ask AI questions, then make changes myself - treating it like an editor / coding buddy - but the act of typing it out and questioning what I'm doing makes me learn. One of the reasons I write blog posts is that re-synthesising information in this format helps me turn it over in my mind and ensure I understand it properly. As long as we remain engaged with the process, as long as we value the knowledge and don't just copy/paste, then there is learning.

I find it very interesting to consider what this shift in technology means for the development of Tech (and indeed other industries). Learning passively (on the job, by doing) is likely to become harder, which means actually learning things needs to become much more deliberate - both individually, and at an organisation level - and we need to look again at how we place value on the learning process. The need to learn isn't going to disappear, and we need to be aware that AI does change the learning environment. It creates many opportunities, but if we aren't careful it can also encourage problematic behaviours. We will need to become more intentional about learning - through technique, through creating time, and through asking "why?" a lot. AI can provide explanations. Curiosity still has to come from us.

---

This post is part of a series:

• I just want to paste something - Ubuntu clipboard managers
• I just want to paste something - Ubuntu keyboard shortcuts
• I just want to paste something - AI problem solving

I just want to paste something - Ubuntu keyboard shortcuts

Last time, I wrote about wrestling with the Ubuntu display server, Wayland, to get a clipboard manager working. This involved a lot of research and fiddling with settings I'd forgotten existed.

So we're coming back to this (and this series is building to a point, I promise) because important keyboard shortcuts weren't working, and I couldn't figure out why.

Again, for credit - I used ChatGPT and Claude to help investigate everything, as well as lots of The Internet of course.

The setup

Specifically, I noticed that Ctrl+Shift+V (paste without formatting) had stopped working - nothing happened at all. Right-clicking and selecting "Paste without formatting" from the menu worked fine, so the clipboard itself was functioning correctly.

None of the obvious things seemed to work, so in we go.

Tally ho

Yeah so clearly something had broken - presumably something was capturing the keyboard event somewhere. But where to start? I can debug Ubuntu, but it's not a forte of mine so let's start with Claude.

According to Claude, the first suspect was IBus, Ubuntu's input method framework, which is known to grab Ctrl+Shift+V for Unicode character entry. Killing the IBus daemon ruled it out.

Next I checked GNOME's built-in keyboard shortcuts using gsettings:

gsettings list-recursively | grep -i "ctrl.*shift.*v\|<Primary><Shift>v"
gsettings list-recursively org.gnome.shell.keybindings | grep -i shift
gsettings list-recursively org.gnome.settings-daemon.plugins.media-keys | grep -i shift

Lo and behold - nothing useful came back.

A test in Firefox showed this wasn't a Chrome anomaly, which made it likely the interception was happening at the OS level, not in the browser.

So where is it?

Claude had me go looking for a running clipboard manager (which was odd, since it knew GPaste was running having just helped me get it working) but a process grep "revealed" GPaste (shock):

ps aux | grep -iE "copyq|gpaste|autokey|xbindkeys|keyd|espanso|ulauncher|albert"

GPaste does grab paste-related shortcuts, although I'd previously manually checked through the shortcuts. Re-inspecting its own settings showed Ctrl+Shift+V wasn't listed there.

The real breakthrough came from using wev, a Wayland event viewer:

wev | grep -A2 "sym\|state"

This showed that when pressing Ctrl+Shift+V, the V key only ever produced a release event, never a press. Something was consuming the keypress at the GNOME Shell level, before it ever reached Wayland or the browser.

Claude went back to GPaste at this point, and the GPaste GNOME Shell extension. It does operate at exactly that level, but disabling it and logging out didn't fix the problem - the keydown event was still being swallowed.

No really, where is it?

A final breakthrough came from querying dconf directly, which shows much lower level configuration than gsettings:

dconf dump / | grep -i "shift.*v\|ctrl.*v" | grep -iv "audio\|volume\|XF86"

This revealed a custom keybinding with Ctrl+Shift+V. Inspecting it further:

dconf dump / | grep -B5 "Shift><Control>v"
dconf dump /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/

Showed this:

binding='<Shift><Control>v'
command='/usr/bin/diodon'
name='Diodon'

Oh hello Diodon - you're still here. Apparently, despite being uninstalled months ago, my old clipboard manager did not clear up properly when it was uninstalled. Or possibly I'd written an extra shortcut and forgotten? Either way, there was a leftover GNOME keybinding, orphaned but causing problems. The binary was gone, so the shortcut did absolutely nothing, but it was still intercepting the keypress at the Shell level and swallowing it.

Execute Order 66

dconf reset -f /org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/

One command, instant fix, no restart required.

Conclusion

This was interesting. I did essentially end up editing the blasted registry again, which is a really poor state of affairs and as I said before, something I thought Linux had moved past. But here we are.

More interesting was the journey Claude and I went on together. I could have debugged this myself, but this isn't information I retain in my brain, so I'd have been looking everything up. By letting Claude take the lead, the investigation was certainly quicker, but also took a very different path.

Instead of methodically isolating the exact place where the keypress event was being intercepted, I would have gone to dconf sooner, and without a detour through gsettings. I'd have used my experience and intuition to bypass some stages of diagnosis. If I remembered all the relevant commands, that probably would have been quicker.

That said, if that intuitive guess had proven wrong I'd have been much more lost. I hadn't used wev before, so I'd have been starting from scratch entirely there. Plus I actually fixed this alongside doing something else, whereas working solo would have required direct focus and likely I'd have put it off for much longer.

So was Claude helpful here? Undoubtedly yes, but not quite in the way I expected - and here we are getting to the point of this trilogy (oh yes - there is a point) which is about how we work collaboratively with AI, and how we learn through this process. But that's next time!

---

This post is part of a series:

• I just want to paste something - Ubuntu clipboard managers
• I just want to paste something - Ubuntu keyboard shortcuts
• I just want to paste something - AI problem solving

I just want to paste something - Ubuntu clipboard managers

Every so often I need to remind myself I can still do technical things. Then I feel the urge to write about it. This time, the rabbit hole starts with Ubuntu clipboard managers, and leads to debugging the desktop itself.

Digging into the nuts and bolts of the desktop is something I don't do very often, so I'm keeping some notes for posterity.

Credit - I used ChatGPT and Claude to help investigate everything, as well as lots of The Internet of course.

The setup

I've run Ubuntu on my laptop for many years. Ubuntu is great, but for some reason it doesn't come with a built-in clipboard manager. I ran Diodon for a long, long time - simple and handled everything I needed. Sadly, it stopped working a while back so I removed it and tried other options - none of which worked.

More setup

After lots of digging, plus some conversations with Claude, it became clear the problem was with the display server, Wayland. This has an enhanced security model over X11 which stops many of the top listed clipboard managers working - presumably including Diodon, back in the day. The solution was either to switch back to X11 (which then breaks support for touchpad swipes between desktops) or to use GPaste. Which also doesn't work.

Sigh

Yeah it's one of those problems. So down the rabbithole we go...

So, by default GPaste is blocked by the same security as the others. We can register it as a trusted shell extension ... if we have the extensions app installed... which we don't by default...

sudo apt install gnome-shell-extension-prefs

Ok, back on track. We can register it as a trusted shell extension with the extensions app:

gnome-extensions enable GPaste@gnome-shell-extensions.gnome.org

Which allows it to load properly (appears top right). Copy also now adds things to the clipboard list. If you're following along at home and it doesn't, turn on "Track changes" in the UI and all should be well.

Pasting from history?

Now you're able to click on the manager, look at the list and pick the entry you want to be on the clipboard. For me, doing this with the mouse destroys about 2/3 of the point of a clipboard manager - may as well just navigate back to the original data and copy from there. I need a keyboard shortcut to open the history except... the keyboard shortcuts don't seem to work.

Hhgggnnnn.

No matter - I can just change the binding to something. Except the rebinding screens don't work. Can't type into the boxes, and it doesn't capture keypress.

Argh.

This is, according to Claude, a "known quirk" with GPaste's settings UI. Which seems a polite way of saying "it's broken". Claude recommends setting it directly from the command line:

gpaste-client settings --set-string shortcuts-show-history "<Ctrl><Shift>H"

Yeah, that didn't work either. Silently ignored.

Now we're breaking out dconf-editor (which also needed installing) and navigating to:

/org/gnome/gpaste

and editing directly there.

And finally, finally it's working.

Conclusion

Well, this was frustrating. A stupidly long runaround to get to something that even Windows has built-in by default now. And the fixes are exactly the kind of thing that put normal people off using Linux - the kind of thing I thought we'd moved past a long time ago. Breaking out dconf-editor is the equivalent of having to use regedit for crying out loud.

On the Wayland / X11 choice, the touchpad gestures were fixable in X11 with some work. The real reason I didn't switch back was because I try to keep my Linux desktop as vanilla as possible. It seems likely that Wayland is the future for Ubuntu, so unless I want to change distro I may as well accept that.

Right, enough of this for the moment. More coming...

---

This post is part of a series:

• I just want to paste something - Ubuntu clipboard managers
• I just want to paste something - Ubuntu keyboard shortcuts
• I just want to paste something - AI problem solving