Allan Kelly's Blog

Please join me online next week when I deliver a brands new presentation for the first time: Agile Thinking for our AI Future.

Thanks to Agile Northants for organizing this Register now to join the call. Tuesday April 28, 2026 at 6.15pm.

Sergio Seelocahan invited me to join the celebrations for Agile Nottingham’s 11th birthday last month. It was a brilliant. I loved it. Great people. A great set of lighting talks. So what if I spent six hours getting there and back? I got to share the return journey work Noel Warnell which gave me an extra 2 hours of learning.

Nottingham reminded me of the old days, the happy days. How things should be. And it seeded an idea: did the decline of agile transformations bring about the fall in meet-ups and knowledge sharing, or did the decline of sharing precipitate the decline of agile initiatives?

Despite one post I’ve mostly kept quite about The Death of Agile. Mostly because agile is everywhere, it is not dead. What is dead is the market for agile and agile transformations.

Murder?

Till now my own theory has been that the rush for AI has absorbed all the discretionary time and money people and companies.

In Nottingham, Noel suggested agilistas didn’t do enough to show the benefits of agile is hard numbers. Heck, despite the story point fetish most teams have trouble telling you how many points they average each sprint. Despite my best efforts few teams know their burn rate, or expected ROI. While the world loves big data there is gold to be found in small data.

Jay Hrcsko suggested it was the rush for money. 2001-2011 was spent craving the endorsement of managers and big name consultancies. Agile became manager friendly in the 2010s, the consultants rushed in, cashed in, and gave agile a bad name. Basically this is the “SAFe killed agile” theory.

All these ideas, and others, probably played a role. Now I want to suggest that the agile community gave up.

Agile is learning

Remember the opening words of the Agile Manifesto: We are uncovering better ways.

It wasn’t just that we discovered better ways in the years leading up to 2001. We continued discovering them in 2002, 2003… we have continued to discover them every year, every month, since. But maybe we stopped sharing.

To paraphrase myself:

Agile is learning.

The opposite of agile is not waterfall, the opposite of agile is static. Not changing.

The only way you can do wrong in agile is do things the same as 3 months ago.

You should always be experimenting, changing and trying new things.

We stopped moving

Or out is another way: Agile is like a Shark, it needs to keep moving or it dies.

We stopped moving, agile stopped changing, stopped advancing. Yet, this is exactly the time when we should be learning and changing the most: AI LLMs have huge potential and we are only just scratching the surface.

We aren’t.

SAFe played a role. This Frankenstein Agile method – froze experimentation. It gave consultants a product to sell and executives a solution to buy. Like Scrum and PRINCE2 before it: nobody does SAFe perfectly, we we feel guilty about not doing so and keep trying to. That kills experimentation.

But maybe more of the blame goes to ourselves, the agile community. If true that also means we might be able to fix it ourselves.

You aren’t going to like this

This will challenge many readers. It will mean some will stop reading. So let me say, right now I want to talk about a side effect, not the thing itself.

Post COVID working from home has become very comfortable. for individuals.

It means that come 6pm we don’t leave the office and to the car/train/bus. We walk to a different room and rejoin our family. Going to a meetup is much harder: who wants to leave home office at 5.30pm, journey to a meetup in town and not get back to nearly 10pm. (You have to have a pint afterwards!)

Far easier to stay home, on the sofa, watch Netflix with your nearest and dearest.

But it means our learning is reduced. We hear fewer talks, we talk to few random people, we are exposed to fewer war stories and hear less about the promised land of agile perfection. We stop learning, we stop dreaming and yearning for better.

If we, the agile community, want to see agile rise we need to make it happen. We do that by learning.

Let’s get learning again

Let me finish on a positive note – how we might restart the flywheel.

Since Agile Nottingham things seem to be picking up – for me and the community!

XTC in London is still going, I was back at The London Pride a few weeks ago and they have a hosted event coming up.

Agile Oxford is reviving thanks to David Michel and Mike Harris.

Agile Northants is reviving, albeit online – I am speaking next month.

Steve Forbes if rebooting both Agile Standup in London and Agile Champions

More technically focused groups are still alive, local ACCUs seem to be thriving.

While I’ve stepped back from Agile on the Beach it is still going, as is Agile Cambridge.

Plus, I hope to be in Sweden this autumn for a big conference (watch this space).

Be the change you wish to see

My advice: if you want to see an agile revival get back to learning with other people.

Get out and about. Press the flesh. Yes, it requires making and effort, the law of two feet as it was once known.

Maybe ask your employer if you can host an event. I know more groups who would meet but they need venues. If your employer wants people back in the office they should make the office more attractive.

By the way, that also means you could try asking speakers in for private talks. Ask me! – I regularly do this sort of thing.

Even if you don’t get out physically just start joining more online meetings. Yes I know they are tiring at 6pm after a day of calls.

If the change you want to see is an agile revival then you need to be that change.

Back in my coding days I worked on a death-march. Six days a week and on the seventh carried a pager. The aim was to redesign the way British Railways operated. Now everyone in the UK knows how that story ended.

While politically driven it was also a case of Business Process Reengineering – BPR. It was aggressive, IT lead and became synonymous with expensive failures.

It started with some very clever (i.e. well paid) people saying “Look at the way this company operates, with new technology you could do it so much more efficiently.” The mantra was “Don’t Automate, Obliterate.” This was more than just restructuring, it was creating “Leaner and Meaner” companies.

It went beyond individual process. It meant rethinking the way the whole company operated. My railway programme was not just about selling the industry, it sought to reimagine how trains operated: companies would run trains on the same routes just a few minutes apart and compete on price.

Expensive failures

Many, probably most, BPR efforts were expensive failures. It might be easy to flowchart a process but doing so often missed vital elements. Employees tacit knowledge which made things work was overlooked. Programming a business process the way you programme a computer ignored knowledge, experience, needs and variability of people. BPR programmes used unproven, scaled and stretch technology to a degree not done before.

BPR programmes laid off vast numbers of workers before they were finished. Many of these where hired back later when the BPR effort failed, like at British Railways.

The overworked and under valued staff who weren’t laid off had to pick up the pieces. The new systems frequently didn’t work and complaining about them was not well received. (It was against this background that the British Post office and Fujitsu started the Horizon system which would see staff put in prison and commit suicide.)

Is AI repeating the mistakes of BPR?

Which makes me ask, are companies repeating the mistakes of BPR in their rush to AI?

Like BPR, AI is being driven by technologists. Rather than start with the business need it starts with technology. How is less clear, there is much hand waving. The technology is cutting edge and by definition high risk.

Rather than showing staff how AI can make their life better, staff are being forced to use AI whether it makes sense or not. Complaints are not welcomed and there are frequent examples of how AI creates problems – like at Amazon.

The attitude to workers and aggressive language is very reminiscent of BPR. Some companies claim to be laying people off because of AI and almost everyone seems to be worrying about the prospect of AI redundancies. That is not conducive to successful change.

Tacit knowledge is being ignored again

LLMs only work with explicit knowledge: that which has been written down. If it hasn’t been written into words then LLMs don’t know it. Nor does it hold any kind of philosophy or design of how things should be done. AI might write something good today but what provision is it making for changes tomorrow? Humans are still needed to guide intent.

Before anyone says: “LLM have read millions of books so they have fewer blind spots” let me point out that there is very little written down about how YOUR company actually works. Even if you have a service manual or a standard operating procedure you may well find that people use considerable ingenuity in making the standard process work or finding ways to get work done despite it.

Most AI is a solution in search of a problem.

Most people do not spend their days writing documents, neither do most people spend most of their time reading. That an LLM can write a document is another example of a technology dog walking on its hind-legs. Clever but what use?

Get away from these “party tricks” and you find AI systems – like IT systems before them – need to work with the people, processes and systems that are already there. In time AI might replace these as well but today you have the people you have, the processes you have and the legacy systems you have. Changing more increases risk.

Thus Anthropic, OpenAI and friends are not going to replace SAP, Sage, Microsoft, SalesForce, or the other corporate applications any time soon. The remaining people would need retraining, other systems would need to be integrated, formal contracts and terms and conditions might need changing. Before that, sales need to be made, which means to salesperson needs to displace salesperson. The risk of introducing a new ERP system is enough to make any CEO reach for the whiskey.

Learning from BPR failure

BPR never really went away, it was moderated and became BPM – business process management – and BPI – business process improvement . We in the IT profession learned to work in small steps, integrate feedback, let business and users drive, and to manage the change with employees rather than bludgeoning them.

AI will probably take the same route. Right now the vendors have an incentive to hype it but in time – and perhaps with some high profile failures – things will moderate. Companies will remember that AI is a technology, and technology needs to be applied to a need. In time processes and companies will change but it won’t happen overnight.

Subscribe to get Allan’s thinking in your mailbox (+ free book)

Ever worked for a company that made ridiculous decisions but was still a nice place to work? For me it was Dodge Group. Beautiful office with great people where I could eat my lunch by the side of the Thames. Watching boats and dangling my feet over the water in Kingston.

I was employed as a coder but it was actually my first experience of Product Management. I went out and met customers. I prioritise the incoming asks. I got to devise solutions and think about the future of the product.

Those days are gone, for me, the company, and, if we believe the AI hype, Coders and Product Managers too.

Product Managers who code

I always advise against having hybrid Coder/Product Managers but the idea keeps resurfacing. Especially in current discussions of LLMs and AI. You can see the attraction: no need for a Product Manager to explain the ask to a Coder, no time wasted talking, no miscommunication and one vision of how it should work. Like me at Dodge.

Then for the company: no Coder means no wage costs. No bolshie programmer attitude. No failure to understand business needs or lack of appreciation for customers. Sweetness and light as ideas move directly from the Product Manager’s mind into code, into customers hands and money comes back.

A few weeks ago I got to talk this over with Peter Hilton, another coder turned Product Manager. I said I felt the desire to have managers code reflected the low status of engineers in the UK. Managers were happier with other managers and not dirty engineers with code under their finger nails. Peter saw the opposite: he saw the engineer hero worship of Silicon Valley trying to ordain everyone a coder.

The killer question for me is: what does the product manager do if they get a spare hour or two?

Underlying the belief that spare Product Manager hours should be spent coding (with or without an AI) is the assumption that there is not enough code and not enough features. More features means more sales. This immediately starts to smell like a feature factory.

Is lack of code the real problem?

I’ve always believe that a Product Manager with spare time should pick up the phone and speak to a customer. Or go and read market research, analyse incoming feature requests and support calls. Review strategy. Speak to stakeholders.

A Product Manager does not add value by building product. They add value by multiplying the value of the work done by builders. Making sure the highest value items are worked on. That the product-market fit is right. That customers are getting the expected benefits. And that everyone knows the strategy so the construction work is focused.

Today we are constantly told that AI makes Coders more productive. Thousands of lines of code can be written in a fraction of the time. Economically that means that the cost of code is less: AI makes code cheap. That might justify paying the Coders less but it means the multiplier is more important.

Why would Product Managers stop doing the high value work of strategy, customers and prioritisation to do the low value work of coding? It doesn’t make sense. Just because you can do something doesn’t mean you should.

At the same time some people are questioning why we need Product Managers at all. Why not just ask the LLM “What features should my app have?” But, if you can ask an LLM so can your competition. An LLM might be a short cut to a quick Product decision but while it delivers an instant fix it has no longevity. If you find yourself playing feature poker you need to change the game.

Competitive advantage

To gain competitive advantage your Product Managers need to find new insights which are not in an LLM. This might be from doing things LLMs can’t do, like visiting customers, watching them, talking to them, understanding their intent. Or looking at data which is not available to an LLM – feature requests coming from existing customers, talking to sales people about failed sales, or analysing your own data.

In fact, because LLMs make research from public sources easier and cheaper, it becomes more important to find things that your competitors can’t find. When you have a product in the market existing customers should be a goldmine of information.

Additionally, in a world were it is cheap and easy to identify and add functionality then products are going to become crowded and less usable. Deciding what to leave out becomes more important.

Subscribe to get Allan’s thinking + e-book

Picture copyright Robert Cook

When I first studied economics I was taught that queuing was a form of non-monetary payment. My teachers pointed to the Soviet Union and described how, in a non-market economy, queues were the price people payed rather than money. In a free market when demand exceeded supply prices rose, that increase was information which pulled in other suppliers until supply matched demand.

Or maybe prices rose to the point were people decided they would spend their money on something else. Or maybe a bit of both. With a queue people paid with their time by standing in line but without the feedback loop of price there was no signal.

Wake up and see the queue

If I had a magic wand and I could magically teach everyone one thing it would be: queuing. Everybody knows how to queue (stand-in-line for American readers) but almost nobody knows the meaning of queues or how they arise.

At the same time I want to open eyes to the implication of queues. If I could motivate our leaders to fix just one thing it would be queuing and the implications of queuing theory.

It is a simple economic model. We could discuss market failure, exceptions, and a lot other “special cases” but the theory is sound. It also does a long way to explain why the USSR no longer exists. Queuing theory is sound too, and it is more than a theory, it is mathematically provable, there are equations.

Spoiler: if you study queuing theory itself it turns out to be more complicated. It is not just about shortages. However, the basic premise stands: time in a queue is a form of pricing, often a hidden cost.

Hidden costs

Now the killer: The cost of queuing doesn’t appear on any balance sheet anywhere.

Cash flow reports don’t measure time spent queuing, value lost from queues, workflows, lack of flow, disruption from queues, human costs of queues (extra stress, lost time, lost work-life balance) or simply any queue in any organization, anywhere.

Queues increase costs directly because it takes longer to get the benefits, e.g. if I queue for an hour to see a doctor then it is one hour longer before I have a diagnosis and can start medication. This is a form of cost of delay.

I was reminded of this by John Burn-Murdoch’s FT column “How London unwittingly killed housebuilding” (probably paywalled). He describes how new safety reviews have created an 8 month delay in building projects which can render house building uneconomic.

Once you know what you are looking for you see it everywhere, but unless you know about queuing theory, or been trained in economics or systems thinking it is invisible. And it gets worse.

Queues also cost because they increase complexity. If I have to queue for an hour to buy a chicken then I have to go to the shop and hour early. That also decreases choice and options because costs increase (time) which makes some options unviable. (And for those still interested, that decreases your agility because it both reduces options and increases lead time.)

That complexity increases dramatically when there are multiple queues (I need to queue for chickens and for chicken feed). When those queues are intertwined complexity increases again (I’m not allowed to buy chickens unless I can show I have chicken feed to give them.)

For humans that complexity increases cognitive load. Because I am thinking about buying my chicken feed and chickens my brain forgets what I am supposed to be at the doctor’s.

Complexity and cognitive load isn’t measured on balance sheets and cashflow statement either but this is where so many organisations, especially large corporate ones, destroy their own capabilities.

Because none of this appears on any financial report, then someone – manager, consultant, CEO, politician – can save money by cutting capacity to service the queue. This is cutting the back office, it looks harmless but it is insidious. The impact might not happen immediately so it looks like a cost-free saving, but over time it degrades system performance.

To continue the building example: suppose we have 20 people reviewing building plans and it takes two months to get a Yes or No. If we remove half the team, 10 people, then we have saved money, 10 salaries. That will appear on financial statements almost immediately. At first output looks the same because there was work in progress.

The work of 10 people will silently disappeared into a queue but the queues will impose costs nobody measures. The organization with the longer queue sees no financial consequence – yippee!

The 10 people left might change their work patterns to compensate: they might do the easy cases first. They might even work harder or longer for a while. Eventually those compensations will wear off. Plan review will take an extra 2 months. Since the easy cases have been done there is a higher ratio of hard to easy cases so things slow down further. And since the system has less capacity any variability will have a greater impact.

But there are external costs: the companies waiting in the queue do see a cost, a cost of delay. One place saves while another pays. This is what economists call an externality, the cost shows up somewhere else.

Rampant corporate queues

This kind of problem is absolutely rampant inside large corporate entities in both the private and public sectors (think immigration processing). Waiting for security review, architecture review, budget approval, business case review, sign-off, meeting, meeting, meeting. The more these queues cross over the higher the cognitive load, it is nye on impossible to know how things should work or how to accelerate work. Often these externalities are actually internal, one department saves while another looses out.

The systems “work” but they work at a high, hidden, cost. I would also argue that this is corrosive to trust between the parties and feeds into the feeling that “nothing works” any more.

As I said, I wish I could open people’s eyes, I wish I could make them see how queues are not cost free but undermine progress, delivery, trust, and rational thinking.

Subscribe to get my thinking in your mailbox (and a free book)

Picture copyright Kirill Razumov

Even if you do not use OKRs and KPIs I’d appreciate a few minutes of your time, please read on.

And if you do use either OKRs or KPIs then please, take a couple of minutes to help me.

As some of you know I’ve given a lot of thought to the interaction of KPIs and OKRs lately – you can download my paper here (free).

Now I’m running a little survey to better understand the role KPIs play in organization. (This is kind of the wrong way around, I should have gathered the data first but I’m iterating, I hope to use what I find out with the survey in future work.)

The survey is here and should only take a couple of minutes.

If you would like to see my results then please share your e-mail address at the end.

And, as they say on the radio: if you would like to discuss any of the issues raised in the survey, or my paper last month, then please get in contact, even book yourself some time with me.

Many thanks – O, and please share this survey with anyone you think could help.

I was at the dentist recently. Don’t worry, my dentist is nice and my teeth are fine. I was in the chair for about five minutes. But the admin!

Until recently I had to fill in two or three forms: to confirm my health (good, no change), sign as an NHS patient (again), and possibly a marketing form for the dental practice (yawn). A couple of years ago they started sending me the forms by SMS in advance. But I never did them, far too fiddly on a phone screen.

Now the practice sends the forms in e-mail before hand. But their system didn’t recognise me I tried to complete them and I gave up. At the practice they have me an iPad with the form. That didn’t work well either and the receptions had to get involved.

Digital

The thing is: the dental practice has gone – or is at least trying – to go digital. Get rid of the paper, streamline the processes. But they’ve done it really badly. The technology they have put in doesn’t work, doesn’t enhance my experience as a customer patient, doesn’t save reception time and can actually make more work for the dentist!

Nor is there any point in complaining, sorry, make suggestions for improvement: there is nobody to listen.

In the today’s “digital” world of today throwing technology at a problem fundamentally fails to appreciate how today’s digital is different to yesterdays IT. Being digital is more than having an system on a computer for people to use.

My dentist is not unique, either as dentist or as an example of how digital technology makes things worse – my gym/pool is just as bad. They have the most annoying app. Too often companies buy, or are sold, digital technology as a “point solution.”

Paper forms? – buy an app to send e-mail, box ticked, job done. (Although, if the system doesn’t integrate with the management system, confuses customers and makes work for staff there is no benefit.)

Booking need to be taken? – give people an app, box ticked. (Although, if it is slow, temperamental and posts too many notifications it won’t enhance the customer experience.)

Security needs to be improved? – ask for the password a second time, send them a SMS, give them a custom app. (Even if that means the average day starts with six password entries, four text messages and another four authentications in the app.)

Yes, all these problems this existed in yesterdays IT centric world and that is part of the reason things needed to change. In the Digital world the technology is not just a bag on the side, its part of the whole offering.

On the one hand this is everyones job to get right. But, there is one specific tole which should be looking at this, connecting technology and business, thinking about the whole offering and putting customers first: the Product Manager role.

Let me suggest the common theme here is: Product Management is Missing in Action.

Failuring to think Product

Its not just that such companies haven’t hired a Product Manager or given them responsibility for the whole, it is that so many companies don’t even know they should have a Product Manager. They probably don’t even understand what the role is or why they exist. Someone needs to think about the whole product – the dental service, the gym experience.

Sure some of what I am describing is work for Business Analysis, some is work for Designers, some is simple technology, and there is work for User Experience Researchers. But where does all of that come together? Who owns it? Who connects it with the company agenda?

It is not just the Product Manager role which is missing, it is Product thinking that is missing. There is a failure to appreciation that technology is the business now. There is a product here, part technology, part physical or experiential and someone needs to consider the whole. If that doesn’t happen end result is not going to be good.

Take my morning swim: the pool operators repeatedly fail to refresh the app when opening times change. It is so bad I’ve given up using it, I take my chances. So what benefit are they getting?

This is more than just saying such companies need Product Managers. Those Product Manager needs to lead others to see that digital technology changes the customer experience and changes the product/service itself. Hence why I talk about Product thinking.

If a business is going to embrace digital it needs to do more than just use digital technology. It needs to think of the whole product and the whole customer experience. This applies too AI as well, AI is still digital technology and if AI is deployed without due thought to the whole product and digital experience, both customer and provider are going to miss out on benefits. It might even make things worse.

Signup for the my latest posts by e-mail and download a free book

Photo from Caroline LM on Unsplash.

Once again I find myself coming back to Reid Hoffman’s quote about early products:

“If you’re not embarrassed by the product when you launch, you’ve launched too late.” Reid Hoffman, founder LinkedIn

Reid is articulating an idea that comes up again and again, whether called a prototype, technology demonstrator, proof of concept (PoC), steel thread or walking skeleton, or, the dreaded, minimally viable product (MVP) he is calling out the value gained by early feedback.

What is different here is Reid is directly challenging us to go below our own expectations and our own beliefs of what is truly needed. At the same time he is laying a trap: the need for more work is built in.

While PoC, walking skeleton, MVP (especially) and the others terms all have their own logic for going small, they are too often in used by those in power to get what they want while downplaying other people’s wants. Oddly, the person demanding the MVP is usually happy to pass over what others want while insisting the things they want is minimal.

What all these formulation are trying to do is learn and, perhaps, start the feedback loop.

A technology demonstrator or proof of concept aim to learn what the technology can do.

A walking skeleton, aka steel thread, aims to learn how all the pieces fit together.

An MVP, should, help us learn about what the market wants from the product.

Like doing a limbo dance, all these ideas are asking “How low can you go?”

Reid is saying the same thing, and at the same time saying “Don’t kid yourself or anyone else that it is done.” A useful addition.

Similarly, when I did Product Management training with Pragmatic they had a catch phase: “You opinion, while interesting, is irrelevant.” I even have that quote on mug from a grateful product manager!

Yet in the last few weeks I’ve been feeling guilty for my part in pushing this idea. I’ve used all these formulations over the years to say to people: “Lets do something small, see what happens and learn.” But this idea is being used wrong.

When challenged that this is irresponsible I’ve been happy to point out that this approach has limits: I won’t offer a cure for cancer to test market uptake. (This was particularly relevant with a client who was actively trying to cure cancer.)

I’ve been horrified by the actions of xAI as they released a product with no safeguards at all. This was going lower than I ever imagined possible.

Their product that removed the freedom of people, particularly women, to appear as they want to appear. I, and every other person on the planet, has the right and freedom to appear fully clothed, and the freedom to restrict images of ourselves.

The same is true in other fields recently. Copyright now only seems to apply to those with the money to enforce it – as was said about the English legal system: “justice is open to all – like the Ritz Hotel”. Or consider democracy: moving fast seems to have broken it and fixing it is hard.

While I have been challenging tech builders to build less and learn more for years I have always assumed there was a level of shared values, common understanding and simple decency that formed a lower limit. Something so common that it didn’t need spelling out.

Without shared values it is very likely that one side will feel cheated by the other. I’ve seen many engineers roll their eyes and shrug their shoulders when told to build a “minimally viable product.” Without shared values these engineers feel they are being asked to cut quality while stuffing the product with features. Akin to building a car with many cup-holders but no breaks.

I’d like to say the answer is shared values. On long lasting teams that can work, but often technology teams have only just met and share very little to start with.

The answer, as is often the case, is to step back and be clear about what you are trying to achieve, ask “why?” Be clear about what is minimal in the market and clear about what technology you are demonstrating. By all means challenge yourself and others but remember there are limited, don’t claim to cure cancer.

Many years ago I got to meet one of my heroes and better still share dinner with him: Charles “Chunk” Moore, inventor of the Forth Language. The reason Forth is called Forth if because Chuck saw it as a fourth generation language: one that could be used by regular people to instruct their machines. To anyone not blessed with a mathematical aptitude that might seem like a joke – in Forth if you want to add 2 and 2 you write “2 2 + .”.

But the “users” Charles had in mind were not average office workers. His typical user probably had PhD in maths, more likely astrophysics. If Forth was an everyday language it was the everyday language of rocket scientists.

Over dinner someone asked Chuck “What surprised him most about the way computers had developed?” (this was 30 years after he created Forth.) I remember his answer like it was yesterday “I alway expected people would write more of their own software for their machines.”

Today corporate IT department hate end-user written code, they go to great lengths to stop it ever existing. Once it does it poses security risks, it may create costs, it may be difficult to move to new machines or break when software updates, it diverts users from doing their real job. That said, end-user create systems can be among the most innovative systems in the company precisely because they were created to serve a real need.

What has this to do with AI?

Well, there is a lot of talk about AI making programming available to regular workers. If claims being made for AI are true then in a few years Chuck might not be so surprised. AI coding is offering a world were everyone can all tell their computer what we want and it will write the code.

In many ways I love this: programming will be democratised, anyone can do it, everyone can have the joy of coding. However, right now I’m doubtful this world will happen but lets accept it as so. In a world were average workers can create their own computer programs and systems there are going to be a lot of problems.

Imaging this world for the moment: there will be an explosion of “home made computer programs”. Jevons Paradox write large: why buy software when a tool can create it for you?

Shadow IT explosion

Corporations are facing an explosion of Shadow IT systems as users who can’t program use AI to create new systems.

One reason corporate IT hate such systems is because of they create security headache. Who knows what ports will be opened and vulnerabilities will be created. And when a popular library needs a security path who knows which shadow systems need an update? And what if the update breaks the system?

Of course AI might help with all the security problems but what about testing? (Especially when a naive user might accidentally create an ethical issue.)

Even programmers dislike testing. Every programmer is convinced they are the chosen one and don’t need to test. What about people who have never coded in their lives? And after all, how can a computer get it wrong?

Some errors might be acceptable, some might be fatal. What about regulated companies? What if a user automates their own work but fails to consider regulations?

If we are to see a boom in end-user systems we also need to see a boom in testing. As testers have always told us “you can’t trust the programmer” so who is going to do it? who is going to pay for it?

And what about usability and disability regulations? Particularly those included in employment law.

Anyone who has ever created a product knows how hard it is to create a product which many users love, let alone how to persuade other people to use it. Now, since everyone can magic up a similar systems for themselves why would they? Why should I learn to use your ugly system when I can create my own?

Which means, there is going to be proliferation of systems which do much the same thing. Yet each one will be different, different individuals different workflows, which means a lack of consistency – what does that do for the outcome and customer experience?

And anyway, if Jill and Josh both build a their own workflow systems, that is two systems that need cybersecurity, testing, maintaining and yet are slightly different and only usable by one person – Jill or Josh. Having two overlapping systems which cost is just the kind of thing corporate IT want to eliminate for good reason.

AI coding still takes time

Don’t forget either that every time some takes time to pause their regular work for long enough to engage with an AI code writer and create a new system to automate their work it takes time. Maybe 5 minutes but it could be 5 days. While they will be more productive in the long(er) run the immediate effect is to slow things down. Now multiple that by the number of people who create their own solution. In the short run we can expect to see a productivity dip while everyone goes off and automates their work.

Some percentage of those system will never pay back the time invested but since this is end-user IT those system will never appear on a portfolio investment plan. It is fantastic that opportunities for improvement that were overlooked, or couldn’t make a business case, will now be realised there is also a downside. These systems will impose costs of maintenance, duplication and misplaced effort.

Don’t take this as my conversion to corporate IT departments – they can be unbelievable painful to work with. The fact that it can be so very hard to exploit these opportunities is a damning indictment of corporate IT processes and ways of working.

In the short run the explosion of end-user AI generated systems are going to increase their workload and costs. Throwing corporate IT and checks away might cure the immediate problem but will store up more problems for later. Don’t throw the baby out with the bathwater.

Signup for the my latest posts by e-mail and download a free book

Maybe I’ve been avoiding AI – so please forgive this rush of posts.

That may well be because it seems to be everywhere and constant at the moment. The hype is overwhelming. I use the word hype deliberately, certainly AI – specific massive neural-net systems – do make possible incredible changes, and will effect the way we work for decades to come.

I do not buy the argument that this means that everything that came before is irrelevant, or that anyone (like me) who does not lace every single statement with AI is in someway a cynic and needs to be left behind. Rather, I see these as arguments that are used to sideline naysayers.

I’ve been keeping my AI thoughts to myself because I feel it would be detrimental to share. I know I’m not alone here; discussing AI with a friend before Christmas he felt the need to add “Please don’t share these comments.”

This came home to me when I read this: “OpenAI in particular should beware hubris. One vc says discussion of cash burn is taboo at the firm, even though leaked figures suggest it will incinerate more than $115bn by 2030.” (OpenAI’s cash burn …, The Economist, December 30.)

So here are some thoughts on where we are with AI

#1 Hype makes it difficult

Between the bubble and the hype it is very difficult to have a have an informed conversation about AI. Even without the hype it would be difficult because this is an emerging technology.

#2 Fear over hope

Rationally I know that technology advances benefit humans, create new jobs and improve living standards. However, one can’t help fearing what is to come because of the constant repetition of “AI will cut jobs” (and who is saying it, #6 below.)

#3 Applications

While an LLM writing a document is impressive few of us spend our days writing documents. This is the equivalent of early micros shipping with BASIC. This was cool if you could programme (or learn); it was useful, to some degree but only if you knew what you were doing. Ultimately it was the emergence of games and then basic word processing and calculation applications which made micros worth the investment.

That is why Apple II was a hit and MSX was not, VisiCalc beat Microsoft BASIC. It is the ARM powered Archimedes failed (no killer apps) but ARM powered phones are omnipresent.

To realise the potential of AI/LLM/neural-nets those applications need building. Some are emerging, for example in healthcare, in law enforcement and environmental.

#4 What problem are you solving?Applying AI to a problem means we need to have an idea what the problem is (requirements), then we need to construct a product (development), somewhere along the line we need to understand the details (specifications), as I described last time, we need to test the result (testing), get it into hands of users (deployment) and refine the result (feedback and iteration).

Recognise that? Just because it is a shiny new technology doesn’t mean those things go away.

This is one of the reason’s AI initiatives are failing. “Just use AI” may impress investors but simply asking an LLM for a document is little more than a party trick. While we need experimentation people are trying to force AI into every conversation and neglecting the basics.

#5 Unappreciated costs

AI is creating jobs, at the moment many of those jobs are low paid, tedious and hidden away behind sub-contractors in Africa, e.g. tagging and moderation.

Then there is the great unmentionable: Power consumption.

In an age of climate change, where we know the damage our power systems are doing to the environment it is disgusting that these systems are given away free.

Please don’t say “they are powered by renewables.” The world hasn’t finished removing fossil fuels so every data centre powered by renewables is reduces the fossil fuel removed form the mix. Nor is it just power consumption: there are grid connections.

Where I live in London companies are building data centres. But London has a shortage of homes. The data centres v. homes debate is only just getting going. Sometimes it can feel like machines already have mastery: people are loosing jobs and homes to machines.

#6 The rise of the right (sorry)

The AI cheer leaders – Thiel, Musk, Andreessen, Altman, etc. – are aligned with the right of American politics. It sometimes seems the AI revolution and the destruction of post-1945 world order are the same thing. For AI to succeed, must we jettison post-1945 morals?

The arrival of the internet was associated with the creation of opportunities. People like Vince Cerf and Tim Berners-Lees were positive role models who kept their politics quiet. The American oligarchs leading the AI boom envisage a Brave New World rather than The Culture.

(Anyone else see Huxley’s “T” icon in the Tesla badge?)

Looping back, ironically, the “absolute free speech” espoused those oligarchs is not extended to anyone expressing scepticism about the brave new world.

Ultimately, it would be easier to be positive about AI if, instead of emphasising about job cuts we talked about new opportunities. But that itself is a political decision that few talk about.

Signup for the my latest posts by e-mail and download a free book