AI in engineering companies · Start here

AI is not my first rodeo

What seven hype cycles taught me about this one

Catherine Ives-YimPublished 27 September 2026 · 13 min read

I have worked through several booms before this one. Four were about technology: the dot-com rush, Y2K, the knowledge management wave and the great ERP programmes. Three were about method: business process re-engineering, PRINCE and Agile. Each arrived with the same promise, that this would change everything, and each time the promise was partly true. What went wrong was almost never the technology or the method itself.

AI is the latest. It is more capable than anything that came before, and I use it every day, to write software, to analyse data and to build tools. But the patterns around it are familiar, and they are worth setting out, because the organisations that did well in the earlier cycles were not the fastest or the boldest. They were the ones that asked plain questions early.

The dot-com boom: real businesses caught in someone else's bubble

During the dot-com years I was chief operating officer of a publicly listed technology company. Money flowed in fast and easily, and the City's advice was to spend: grow organically, grow by acquisition, become a global business. There was a real market for what we did. We had real customers paying real money, and the turnover was strong.

Then two things collided. Worry about Y2K made large corporate customers freeze their budgets, and over-investment in vapourware products and businesses made investors pull back from the whole sector. Caught between the two, the business failed. The administrators saw that a stripped-down version of it could survive, and asked me to put together a rescue plan if I could find new investment. I did, and the company and many of its jobs were saved. Many similar businesses did not recover.

The internet did change everything, and the technology was never the problem. The lesson I took was harder. Having real customers is not enough if you are financed and advised as though the boom will last. When the money turns, it turns on everyone in the sector, including the businesses that were doing things properly. And plans built for growth at any cost leave no room to absorb a shock from somewhere else.

The AI version. Capital is again pouring in, and the advice is again to scale fast. Many AI products are a thin layer over someone else's model, and some will disappear when the model provider adds the same feature or changes its prices. But the sharper risk is for the sound businesses around them: companies with real customers, financed and staffed on the assumption that AI investment will keep flowing. The questions an investor, a lender or a board should ask are the ones we should have asked in 1999. What does this company own that others cannot copy? What does it depend on? What happens if that dependency changes, or if the money stops? And how long could it survive on its customers alone?

Y2K: the heroes nobody noticed

In the lead-up to 2000, the consultancy where I was chief operating officer had a whole department dedicated to Y2K. Its job was to help businesses understand their legacy code, search it for the date problems hidden inside, and find and test the fixes. The systems were complex, often global, and some were written in languages few people still knew. There was no AI to read the code, trace the faults or write the tests. It was hard, unglamorous work, done line by line.

It paid well. More importantly, it became one of the great education programmes of its time. Engineers around the world were suddenly exposed to code bases, architectures, cascading faults and global footprints they would probably never otherwise have seen.

Then 2000 arrived and nothing collapsed. People asked what all the fuss had been about, and missed the point entirely. The disaster had been averted, by people hunched over screens for months, and the first step everywhere had been the dullest one: finding out what systems you actually have, what is inside them and who owns them.

The AI version. Two parts of this are back. The first is the inventory, now with a legal deadline. The EU Cyber Resilience Act requires makers of connected products to know which software components are in each product and to handle vulnerabilities in them. The first job is a software bill of materials. Inside organisations, the equivalent for AI is a list of every AI tool in use, who uses it and where it sends data. Many organisations cannot yet produce one.

The second is the education. AI can now read legacy code, trace faults and draft tests far faster than we could in 1999, and that is a real gift. But the Y2K generation learned how large systems really behave by doing that work themselves. If AI does all of it, we need another way for engineers to gain that understanding, or we will have fast tools and fewer people who can tell when they are wrong. And when AI-assisted work prevents a disaster, expect the same reaction: people asking what the fuss was about.

Knowledge management: capturing knowledge is easy, keeping it is not

In the late 1990s, organisations spent heavily on capturing "what the company knows" in portals, intranets and document systems. The programmes that failed mostly failed because nobody owned the content, nobody was rewarded for keeping it current, and within a year people no longer trusted what they found.

But I also saw a different failure, and it taught me more. A company I worked for had one of the early knowledge management systems, built on IBM technology. It decoded the meaning of documents, searched by concept rather than keyword, and drew knowledge maps of who knew what across the organisation. In many ways it was a forerunner of today's AI systems, and it worked brilliantly across global businesses.

Then Microsoft launched SharePoint Portal Server. In its early versions it was nowhere near as capable. But IT departments wanted to become "more Microsoft", and the new platform brought new training, new qualifications and a new line on the CV. Solid, working systems designed for multinational use were pushed aside in favour of something embryonic. Years later, some of those departments were still configuring SharePoint and getting nowhere near what they had switched off.

The lesson was not about IBM or Microsoft. It was that technology decisions are sometimes driven more by what looks good on a CV than by what the business needs. Riding the next wave is exciting. Continuing to exploit a system that works, and is not glamorous, rarely gets anyone promoted.

The AI version. Using AI to search company documents, usually called RAG, is knowledge management again, with a far better search engine. It fails in exactly the same ways. An AI that confidently quotes last year's procedure is worse than no answer at all, so the old basics still decide success: tidy, versioned documents, a named owner, and a system that says plainly when it does not know.

And the CV-driven pattern is back too. Today anyone can use AI to build a working system in a weekend. That is a real achievement, and it is also where the danger starts. A system that works on a laptop is not a system a business can depend on. Turning a hobby system into a professional one needs decisions about architecture, infrastructure, security, where the data comes from and who is accountable for it. Those decisions do not appear in a demo, and they are exactly what the enthusiasm tends to skip.

ERP: the hype and the reality

ERP came hot on the heels of business process re-engineering, and was largely driven by it. Re-engineering started in the United States with mixed and often poor results, and the big consultancies brought it to the UK as they expanded overseas. Its results deserve an article of their own. The ERP platforms that followed promised one integrated system for the whole business, and the major vendors were rolling them out to organisations of almost every size.

At the time I was systems architect and lead consultant at a company that specialised in commercial-grade workflow systems. We did not sell re-engineering, but we did a great deal of systems analysis: straightening out the wrinkles in how work actually flowed, and making businesses more efficient without tearing everything up. From there I watched the big ERP programmes closely, and the stories coming out of the industry were consistent. Budgets were immense and often overshot by a long way. Businesses were re-engineered to fit the ERP model, rather than the system being fitted to the business. For the consultancies and the contractors they hired, ERP was a gold rush, billed by the day for years. For many of their clients, the benefits of those early systems fell a long way short of the confidence with which they had been sold.

In 1998 I was offered a speaking slot at an international business systems conference, and called my talk "ERP: the hype and the reality". The demand to attend was so great that the organisers had to put screens in the lobby and in overflow rooms, and I had follow-up conversations for months afterwards. Plenty of people knew something was wrong. They wanted someone to say it plainly.

ERP did not go away. The platforms continued to thrive, and over the years the promises came much closer to reality. But it took the industry years to mature, and many early customers paid for its education.

The AI version. "AI transformation" programmes carry the same risks: very large budgets, the business reshaped to suit the tool, and confidence running well ahead of results. The answer is the same as it was then: start small, with one real problem, fit the technology to the work rather than the other way round, measure the result honestly, and build on what works. I describe AI adoption as a ladder of five levels for exactly this reason. You cannot skip rungs, and each one has to earn its place before you climb to the next. AI will mature too. The question for each organisation is whether it wants to pay for that maturity itself.

The methods: PRINCE, Agile and the right tool for the job

Alongside the technology booms ran a series of booms in method. Business process re-engineering was the first I saw at close quarters, and its story deserves an article of its own. PRINCE and Agile followed.

I saw both from inside an international product engineering consultancy that was working with global businesses. PRINCE was a driving force at the time. Project managers went on courses, came back with certificates and enthusiasm, and tried to introduce the full model to companies that simply were not ready for it. Projects became bogged down in the method. To this day I have never seen a pure PRINCE implementation. Companies and project managers learned to flex it, and to combine it with parts of other approaches, including Agile.

In the same consultancy, Agile worked well in software teams. It gave them a steady rhythm and real momentum. The trouble started when it was applied to change outside the area it was conceived for. Large-scale change in an organisation is quite different from building a new IT system. Culture takes over, and careful planning of operations and of people matters as much as the changes themselves. Agile can run the small tasks inside that change well. Shoe-horned in as the method for the whole change, it is often a bad fit.

The best-documented example I know is close to home. In the early 2010s the Department for Work and Pensions adopted an agile approach for Universal Credit, one of the largest welfare reforms in a generation. In 2013 the National Audit Office reported that the department had taken on "a new project management approach which it had never before used on a programme of this size and complexity", found weak management, ineffective control and poor governance, and noted £34 million of new IT systems written off. People who worked on it later described a fixed, waterfall-style contract with agile development bolted on, inside a strong command-and-control culture. The method was not the root cause. Applying it to the wrong kind of problem, in the wrong culture, was.

The same thing happened in the private sector with the so-called Spotify model of squads and tribes, published in 2012 and copied by organisations around the world. A product manager who later worked there wrote that Spotify itself had never fully implemented it, and that other companies had copied something that did not really exist.

Each method had a sound idea at its core. Each also created an industry, and large consultancies earned fortunes selling the method as the product. The organisations that benefited took the idea and applied it in proportion, to the kind of problem it was designed for. The ones that suffered bought the whole package and followed it to the letter.

The AI version. "AI transformation" is already being packaged in the same way: frameworks, maturity models, certifications and programmes measured in years. And the same mistake is waiting: taking something that works well in one place, such as AI coding tools in a software team, and imposing it on work it was never designed for. I should be honest that my own five-level ladder is a framework too. The test I apply to it, and to anyone else's, is simple. Does it help you choose the next small step and measure whether it worked? If it mainly produces slides and invoices, it is the old pattern again.

What the cycles have in common

Looking back, the lessons are short.

The technology is usually real. The timescales and business cases usually are not. Believe in the capability; be sceptical of the plan.
The boring foundations decide the outcome. Inventories, ownership, clean data, version control. They are cheap compared with the cost of skipping them.
Big bangs fail; small steps compound. Start with one problem that matters and measure it.
Know what you depend on. Every boom creates new dependencies on suppliers, platforms and people. Write them down.
Buy outcomes, not methods. A method is a means. If the plan is measured in documents, ceremonies or certifications rather than results, be wary.
Choose for the business, not the CV. A working, unglamorous system is often worth more than an exciting new one. Ask who benefits from the change.
Put numbers on the uncertainty. Before a large commitment, model the range of outcomes, not just the best case. A simple simulation of cost and benefit often changes the decision, or at least the size of the first step.

None of this is an argument for caution for its own sake. The organisations that did well in the earlier cycles moved early and deliberately. They were simply clear about what they were building on.

Why this matters now

AI is moving faster than any of the earlier waves, and it is cheaper to start. That is good news, and it also means mistakes are made faster. The engineers and leaders who have been through a few cycles have something useful to offer here, not because we know more about the latest models, but because we recognise the patterns around them.

I use these tools daily, and I think they are the most useful technology I have worked with. I also remember what the earlier booms cost the organisations that forgot the basics. Both of those things are true, and holding them together is, I think, the most useful thing experience can bring.

For boards and investors: believe in the capability, test the plan, and ask what the business will own at the end.

For leaders commissioning AI work: start with one problem, measure it honestly, and be wary of anything sold as a multi-year transformation.

For IT and engineering teams: do the dull foundations first. Inventories, ownership and clean data will decide the outcome.

For everyone: when the next wave arrives, and it will, ask who benefits from riding it.

I would be interested to hear which of these earlier cycles you lived through, and which lesson you think the AI boom is most likely to forget.