AI Is a Compression Engine, Not an Invention Engine. That One Rule Explains the 95 Percent.

There is a single test that tells you, before you spend a dollar, whether an AI project has a real chance of working. Compare the size of the output you want against the size of the input you can actually give it. When the output is smaller than or the same size as the input, AI is genuinely excellent. When you hand it a little and expect a lot, it produces something that looks like an answer and is not one.

That rule is not mine. It belongs to Andrew Haisley, who spent more than thirty years building and leading software teams, from startups to Amazon, Royal Bank of Canada, and Wayfair, across Canada, the United States, and Britain. He is now retired, which means he is the rarest kind of guest on this subject. He is not selling anything. I invited him onto my podcast, The Integration Layer, precisely for that reason, and he handed me the cleanest framework for AI investment I have heard from anyone, vendor or analyst.

It also happens to explain the most uncomfortable number in enterprise technology right now: the ninety five percent of companies getting no measurable return on their AI spend.

A note before we begin. Andrew is sharing his own views and personal experience in this conversation. Nothing here represents the position of any former employer.

The rule, in his words

Andrew was careful to say this is not how you evaluate a use case after the fact. To do that, you have to run it and look at the results. This is the test you apply beforehand, to decide whether the thing is worth attempting at all.

"The rule that I apply to figure out beforehand," he said, "is the relative size of the input to the output."

Three shapes pass the test.

The first is straight compression. Feed it a long document and ask for an executive summary. Andrew first did this at Wayfair in the early days of ChatGPT, and it worked then. The output is much smaller than the input, and the model is good at identifying what matters.

The second is roughly equal size. Andrew acts as secretary for a couple of small organizations, and he scribbles bullet points during meetings. He hands the model five or six bullets, often with very little context, and asks it to turn them into prose. "Surprisingly good, actually," he said. Nothing new is being invented. The information was already in the bullets.

The third is narrowly defined and technical. He was porting some 1990s C code to a modern font library and asked for sample code showing how a specific function is used. "Definitely saved me a load of time." The scope is tight and the answer already exists somewhere in what the model absorbed.

Then there is the shape that fails. "When you go to the case where you give it a small amount of input and say, give me a lot of output, I have never seen good results from that."

I put it back to him on the show as a single line: AI is a brilliant compression engine and a terrible invention engine. He agreed, and I think that framing is worth holding onto, because it explains the mechanism and not just the symptom. When the output is smaller than the input, the information you need is already sitting in what you handed over, and the model is reorganizing and selecting. When the output is much larger than the input, the missing information has to come from somewhere, and what fills the gap is whatever is statistically plausible. Plausible is not the same as correct. Plausible is exactly what a confident wrong answer is made of.

The French horn app

Andrew plays the French horn, and the hardest part of that instrument is simply landing the right note. So he wanted a small practice app: display a random note, listen to him play it, tell him whether he was accurate, track the score over time. Not conceptually difficult. Tuner apps already exist.

He wrote a short spec and gave it to both Claude and Cursor, asking for a Swift app for iOS.

"What came out was garbage."

The interesting part is what he says next, because it is more honest than either side of the usual argument. The AI did produce an app that launched, and Andrew had never written a Swift app before. "That in itself is useful. That would definitely save me time if I was starting from scratch." The bounded piece, the boilerplate of a first Swift app, was a genuine win.

The unbounded piece was a disaster. "I had no idea what it thought it was trying to do when it came to figuring out the pitch of the note. It did not use any technique that I am aware of that would make that work." Pitch detection is a solved problem with well understood approaches built on Fourier analysis. The model did not reach for any of them. It also drew the musical staff wrong, putting lines on the wrong side.

His diagnosis is the one that should worry any engineering leader. Imagine handing that same spec to a very junior developer with no music knowledge and no experience building an app from scratch. "They might well come up with something just as bad." The model behaved exactly like an eager junior who does not know what they do not know.

"A lot of people get fooled into thinking that because the AI can spit that stuff out quickly, it is going to produce something that works correctly."

His conclusion on the whole exercise: "I am pretty sure I could have written it quicker myself, with much less frustration and probably better quality code."

Nineteen percent slower, and certain they were faster

That last sentence is not a grumble. It is the measured average.

In July 2025, the research group METR ran a randomized controlled trial with sixteen experienced open source developers across 246 real tasks. Before starting, the developers expected AI tooling to make them about twenty percent faster. Afterward, they still believed it had. When METR measured the actual clock time, they were nineteen percent slower with the AI than without it.

The feeling and the reality pointed in opposite directions. I asked Andrew why.

"It lulls you into this false sense of security. You say do X, and it produces something that is kind of like X. And you did not have to spend all afternoon thinking about how to do it yourself."

Then he said the thing that reframed the entire episode for me. "What the AI is very good at is moving things from one part of the lifecycle to the other. It does not necessarily shorten it."

You get "that sort of adrenaline rush of getting an absolute pile of stuff done really, really quickly," he said, "followed by the letdown, and realizing that what it did was not very good, and you have now got to go all the way back through it and rework it."

Sit with what that means for how your organization is currently justifying its AI spend. If the evidence on the slide is a developer survey, an adoption dashboard, or a team telling you they feel more productive, you are measuring the adrenaline rush. You are not measuring the lifecycle. METR's finding is that those two numbers can point in opposite directions while everyone involved is being completely sincere.

Andrew reached back forty years for the underlying law. Fred Brooks, in "No Silver Bullet" in 1986, argued that no single development in technology or management technique promises even one order of magnitude improvement in productivity within a decade. Andrew's view is that nothing about the current generation of AI has broken that rule. He is also careful about what the current generation actually is. People are confusing LLMs with artificial general intelligence, he said, and the symbolic reasoning problem that AI research was stuck on in the 1980s remains unsolved. "I think we will have nuclear fusion before we have AGI."

The ninety five percent

Now scale the rule up from one developer to one company.

In 2025, MIT's NANDA initiative studied roughly 300 enterprise AI deployments. About ninety five percent of the organizations had seen no measurable return on their generative AI spending, against an estimated thirty to forty billion dollars invested. The programs that did work were narrow and specialized. The ones that tried to do everything stalled.

I read that number to Andrew and asked whether it was a technology problem or a story problem.

He did not hesitate. It is the classic case of holding a hammer and going looking for nails. He has watched it before. Robotic process automation swept through large companies and most of those projects saw very little return, and some of them embedded problems that were expensive to unpick later. "But that does not mean to say there were not any good deployments of RPA. I bet there are some out there that were really good and worked very, very well."

The same, he says, applies to AI. "The scattergun, we bought Claude, go use it to solve everything approach is just not going to work."

So what does work? He described it precisely, and if you read it closely it is the input and output rule wearing a business suit.

Take a constrained problem. An existing dataset that gets updated regularly. A task a human currently does by hand and it takes them a week. Run the process multiple times and calibrate the output against a human doing the same job. "You might well get a really good payback." He offered accounting data as an example: combing through it for patterns that a person would need days to surface.

Look at the shape of that. The input is large and well defined. The output is smaller than the input. The task is repeatable. A competent human can check the result. That is a compression job, and compression jobs pay.

The five percent in the MIT study are not the companies with the best models. They are the companies that happened to point AI at compression jobs.

Amazon, and what happens when usage becomes the target

Andrew mentioned something he had read about Amazon that is worth more than most consulting decks. Internally, they had built a dashboard tracking who was using AI and how much, and that usage became part of how people were assessed.

The result was predictable. "People were just burning credits to get themselves high up on this list, and not necessarily producing anything useful with it." He says Amazon backtracked, and now takes the more sensible line: use AI where you think it improves your productivity, and let the company correlate real productivity metrics against AI adoption over time, and form an evidence based view of where it actually helps.

This is Goodhart's law arriving on schedule. The moment AI usage becomes a target, it stops being a measure of anything. And yet usage is exactly what most enterprise AI dashboards report today, because usage is easy to count and outcomes are not.

If you take one operational change from this piece, make it this one. AI adoption is not a key performance indicator. It is an input cost. The indicator is what happened to cycle time, rework, defect escape rate, and throughput on the work itself.

"They are betting on it being magic"

I asked Andrew the money question. Across all these boardrooms, what is the most expensive thing companies currently believe about AI that is simply false?

"Well, they are betting on it being magic, are they not?"

He invoked Arthur C. Clarke, the line about any sufficiently advanced technology being indistinguishable from magic to someone who does not understand it. And then, with the freedom of a man who is not looking for his next job, he said the quiet part.

The vast majority of people making these decisions do not understand the technology at any depth. They take a briefing from a large consultancy, they are told that everyone is adopting AI and they will be left behind if they do not, and so they adopt AI. What they do not do is work out what it is actually good for and what it is not. "So I think there is a great deal of money being spent on completely useless projects."

Asked how much of the AI activity inside large companies is theatre, his answer was "probably most of it." He compared it to the wave of large companies in the late 2010s that decided they needed to be more innovative and responded by creating a department of innovation. "I cannot think of anything less innovative than that."

The real cost of the theatre is the next decade, not this one

Here is where the conversation turned, and it is the part I would want a CFO to read twice.

The damage from a scattergun AI program is not just the money burned. It is what the burn does to the organization's appetite afterward. "When a lot of these chickens come home to roost, it is going to set back the adoption by quite a bit," Andrew said. He described the company that gets a bad result from an unfocused program, and then, years later, turns down a genuine ten percent efficiency gain in a specific part of the business, because the institutional memory says: no, we got burned on that, we are not doing that again.

That is the argument for discipline, and it is not an argument against AI. It is the opposite. The waste is what will make your organization cynical about the wins that are real.

For the record, Andrew and I do not fully agree here. I said on the show that AI is a technology that will fundamentally change how we work. He pushed back immediately. "The current AI is not going to fundamentally change how we work. It is just another thing that will, when used correctly, make our lives a bit easier and a bit more productive." I still think he is understating it. But I would rather publish the disagreement than pretend the conversation was tidier than it was, and I notice that his position is the one supported by the data we both cited.

The test, before you fund anything

Here is the framework, assembled from his rule and everything downstream of it.

1. Check the ratio

Is the output you want smaller than or equal to the input you can supply? Summarize, extract, transform, classify, retrieve, explain. Those are compression jobs and they are fundable. "Build me the thing" and "run this process" are invention jobs. They get a research budget, not a production budget.

2. Cost the specification

Andrew's sharpest practical point is that you can force an invention job to succeed by specifying it in enough detail. But if the spec has to be that detailed, writing it costs more than doing the work. If your product manager has to describe which pitch detection algorithm to use, you needed an engineer, not a prompt.

3. Make sure someone can check the output

This condition runs through everything he said. "It really depends on you having a very good idea of what the right answer should look like." An AI deployment with no competent human checker is not an efficiency. It is an unreviewed junior with production access.

4. Measure the lifecycle, not the feeling

Cycle time, rework, defect escape rate, throughput. Never adoption, never credits burned, never self reported speed. METR is the proof that self reported speed can be confidently, sincerely wrong.

5. Bound it

Narrow and specialized is the whole finding of the MIT study. Scattergun is the ninety five percent.

The people who win

Andrew's advice for anyone who feels they are falling behind was not "learn the tool." It was learn the edges of the tool. Learn what it is good for and what it is not, the same as any technology you have ever adopted.

He was blunt about the anti-pattern he is hearing from large engineering organizations: a junior developer has the model write the work, submits it for review without understanding it, and then feeds the reviewer's feedback back into the model until it passes. "You will never learn anything there. Ultimately you will probably get fired as well."

The line I offered him at the end of the show is the one I keep coming back to. The people who win will not be the ones who trust AI the most. They will be the ones who know exactly when not to.

That is not a hedge against AI. It is how you end up in the five percent.

If you are sizing an AI program and want a second pair of eyes on whether the spend is aimed at compression jobs or invention jobs before it goes to your board, reach out.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, and the host of The Integration Layer, a podcast on AI, enterprise systems, and the work of making them fit together. Connect on LinkedIn or reach out at tripathis@qubittron.com.