Offloading vs offshoring

Posted on by Mark Myers Leave a comment

These two words sum up both the long-term danger of AI and why it is so useful to some of us.

Offloading is getting AI to do work that you already know how to do yourself, freeing you up to do other things.

Offshoring, on the other hand, is getting AI to do work that you don’t actually know how to do yourself.

With the first, you retain the skills and control; with the later, you become dependent on somebody or something else.

It’s a distinction that has huge implications for our skill sets and the future of the IT industry.

If I, for example, use AI to write code, I could just do it myself, I understand what I’m expecting at the other end and can then validate and correct the results. It is simply making my job easier and faster.

However, someone without the same expertise is effectively offshoring their work. They have to trust the output implicitly, without being able to validate or correct it, and they don’t learn anything from the experience.

Now currently I learn bits and bobs from AI. I’ll ask it to do something relatively simple, and when I’m reviewing its output, I’ll go, “Oh, that’s a clever way of doing that,” or, “I didn’t know you could do it that way.” I’ll then be able to track it down to a GitHub repository or something similar, where someone much, much cleverer than me has implemented a new approach, and AI has used it.

Brilliant! Fine! But that’s offloading tasks. I could have worked it out myself, and I knew where to look and how to track it down. In that situation, AI is no threat to me. It is only a benefit.

However, if I have to trust AI implicitly and am not gaining any knowledge from the experience, then I am offshoring my work. Sooner or later, I risk either being replaced or finding myself in a vulnerable position because I lack the necessary skills.

Those of us who are successfully offloading our work, without realising the wider consequences, are actually contributing to this problem. If we, as more senior members of the industry, are not giving younger people the opportunity to develop the expertise that will enable them to use AI effectively, we are running the same risk as we did, as I seem to recall, about ten years ago.

So much mid-level and lower-level IT work was offshored to places such as the Indian subcontinent that it became increasingly difficult to hire people locally because they hadn’t had the opportunity to develop the required skills.

We are in danger of doing that to ourselves all over again, but this time we’re not even offshoring the work to another human being. We’re handing it over to machines controlled by very, very rich people, who will not fail to take advantage of the situation.

So, again, it’s the same boring warning, and you’ll have seen it in a billion posts. But don’t forget how things work. Remember how to do them yourself, and make sure you pass on your knowledge to another human being near you who can use it.

Don’t be selfish with your skills.

Grammar as a Core Technical Skill.

Posted on by Mark Myers Leave a comment

As someone who is dyslexic, I was overjoyed when computers generally stopped giving a damn about my poor grammar. 1

It is therefore with mounting horror that I realise all the old grammar rules and sentence structures are now back as deeply technical skills, again thanks to AI.

To a certain extent, this has crept up on us. But when you write requests and requirements for any kind of code generation or rule-based agentic AI, you have to get the punctuation and structure right.

There are a lot of safety checks built into these systems. In fact, I’m surprised by just how many, all trying to stop human beings from doing something stupid. But they can’t protect against everything.

You can also quite easily correct a lot of mistakes by simply telling the AI to adjust or undo something, but that costs tokens, effort, computing power, time and all that kind of stuff.

What is becoming more and more apparent is that, as AI’s are increasingly tailored to be more human and to listen to instructions in a human way, having to talk like a formal human again is becoming an important technical skill.

And I suspect this is affecting the technical community rather more than they would like.

I’ve managed to escape some of this, having had to do so much more finance and management work in many of my current roles. But when I found myself being sloppy and not writing prompts as if I were talking to a manager, I discovered that the AI was making presumptions, doing odd things and costing me tonnes of tokens.

TLDR; When you’re coding with the help of AI, talking to it as if you’re talking to a manager is now the most efficient way of doing your job.

Yes, you can give detailed technical requirements, but they have to be in cohesive, well-structured sentences.

Sorry.

  1. Although command line tools are still a bit grumpy over the bad spelling bit.[↩]

Agile Corporate term: “Ticket redistribution”

Posted on by Mark Myers Leave a comment

Definition

A phrase used when working in Agile teams for moving a ticket off my plate and onto somebody else’s because I’m busy.

Explanation

This is another one of those lovely Agile phrases that makes an action seem far more seemly.

If you’re too busy or your priorities have changed, you don’t fob off your tickets, pass them on to someone else or even reassign them. You redistribute them.

It makes everything sound so much more pleasant and organised, rather than everybody panicking and running around.

Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.

Are cloud vendors the true entities under threat from AI?

Posted on by Mark Myers Leave a comment

Let’s start by being specific. I’m talking about cloud software vendors, not software vendors in general. So this has nothing to do with the recent recoding and release of the entire Adobe suite. That’s a different conversation.

Most cloud software vendors offer a function that is already available within the major cloud services but which is awkward or difficult to configure, non-obvious, or has various pitfalls. Essentially, they provide a framework for your cloud, usually for a specific function.

As we all know, frameworks are designed to offer simplicity and ease of use, but to do that, they often have to roll up or hide a lot of the features you might actually want or display them in a slightly different way.

This is one of the core reasons why frameworks often start out seeming like a brilliant idea but end up a burden. Say a problem seems really hard to solve, and a company comes along and says, “Yes, we’ll do this for you. It’ll make it easier.”

However, as a system matures,   you add features and gain complexity, and the overlayed framework or cloud vendor’s system can actually become harder to update, maintain and pay for, than if you’d simply done it directly using the original cloud services.

And I think this is where generative AI coding tools are starting to change things.

AI can now remove a lot of this particular problem. It can provide the initial ease of implementation that frameworks and cloud vendors offer, without necessarily being any harder to edit after implementation.

So you could start off with Azure or AWS, sit down with Claude or whatever AI tool you prefer, and get it to write you a function or feature. It will go off and do that, producing nicely documented code that does what you want.

However, one of the core things people don’t like about AI written code is that, once it had been produced, very rarely would humans go through and work out exactly how it had been done. This made it potentially harder to maintain.

But that’s not really any different from using a vendor’s product or a big framework. You put it in, it does a very fast job initially, but going back and changing anything can be an absolute devil.

However, AI has not only provided that first fast implementation that a vendor or framework would offer, but it also writes a lot of its own documentation. Anyone who’s read one of those monstrous README files that AI code generation tools produce will know what I mean.

More importantly, AI is actually quite good at going back, reviewing what was done previously and making amendments without screwing everything up. And it’s getting better and better at it.

It’s that speed of updating, but also the fact that doing so costs comparatively little compared to paying for a framework, dealing with the risk of nobody maintaining it, or continuing to pay a vendor’s licence costs, that makes AI a genuine advantage for the customer.

So you end up, three or five years down the line, with a system written directly using basic cloud services, which is well documented and which you can change whenever you need to.

If a vendor goes out of business, changes direction or suddenly changes its pricing, you’re suddenly under threat.

There’s also the question of rewriting.

People who have given AI an existing codebase and asked it to recreate it in something else, notably Rust at the moment, will know just how good AI is becoming at doing that.

Compare this with the sheer monumental difficulty of migrating from one framework or vendor to another.

I say this as someone who’s been doing migrations for 30 years.

This is one of the genuine jobs for AI, and I think it’s why, when you’re talking to almost any cloud software vendor, they themselves go on and on about what their own AI functionality gives you.

Because I suspect they’re the ones, more than almost anybody else, facing a genuine threat from AI taking away their particular market.