Science fiction and AI: the mistake of reading technology wrong

Has anyone ever sold you a system saying it would "solve everything"? Months later, the team invented a side spreadsheet to cover what the system does not do. The promise was big. Reality came out small and expensive. This pattern has a curious root: a good part of the tech industry read science fiction and AI as a product catalog, not as a warning. Historian Jill Lepore called the sector's leaders "bad readers". She is right, and it directly affects the software you buy.

What "reading science fiction wrong" means

Frankenstein is not a tutorial on how to create life. It is a book about a guy who creates a thing and runs from the responsibility. Blade Runner is not an android pitch. It is about what is left of the human when everything becomes a product.

But part of Silicon Valley took those stories and extracted the machine from them, throwing the moral away. The result shows up in launch vocabulary: "superintelligence", "we will solve death", "this will change civilization". Then you open the product and it is a chatbot that gets the zip code wrong.

The problem is not the exaggeration itself. It is that the exaggeration becomes a business model. Whoever promises to transform civilization never has to prove they cut your cost per ticket by 12%. The yardstick disappears.

Why this reaches your company

You do not buy manifestos. You buy tools. But the tool comes wrapped in the manifesto.

In practice, it shows up like this:

• Fiction roadmap. You sign the contract for what "is coming in Q3". Q3 arrives, the feature does not.
• Price anchored in the future. The plan costs as if the AI already did the work of three people. It does the work of half a person.
• Hidden dependency. Your data, your flows and your history sit in a system that changes course whenever the founder changes dreams.

I saw this up close at a services client. They signed an AI support SaaS at R$ 2,400 a month, promised "solves 80% of tickets on its own". After four months, the real automatic resolution rate was 19%. And the team spent time reviewing what the AI answered wrong. Total cost went up, not down. The software worked. The promise is what was fiction.

Whoever sells the future is rarely held to the present.

Lepore's point that matters to managers

Lepore is talking about democracy, and her argument is serious: when a handful of companies decide what the future is and treat it as inevitable, people stop feeling they have a choice. "This is how it is going to be" ends the debate before it starts.

Translate that into your company. When the vendor says "everyone is already migrating to this", they are running the same play on a smaller scale. Inevitability is a sales technique. It works because it wears you down.

You have a choice. You always did. The right question is not "is this the future?". It is "does this solve my Tuesday morning problem?".

How to evaluate a tool without falling for the pretty story

A short script I use when a client asks me whether to sign up for something:

1. Ask for the number, not the vision. "How much does this cut from my time per order?" If the answer is an adjective, bad sign. If it is "we do not know, it depends on your volume", good sign. Honesty is less scary than enthusiasm.

2. Test with your most annoying case. Not with the demo example. Take that order with three exceptions, a client who wants a separate invoice, partial delivery. That is where the tool shows its real size.

3. Ask how you leave. Can you export data? In what format? How long does it take? If the exit is hard, the price will go up. That is not pessimism, that is how the model works.

4. Set the judgment deadline before you start. Sixty days. Metric in writing. If it does not hit, cancel without drama. Without that, every piece of software becomes permanent by inertia.

5. Separate software from process. A lot of what people buy as a tool is actually a decision nobody wanted to make. No SaaS solves "we do not know who approves the discount".

AI does work, but for tasks of the right size

None of this is anti-AI. I use AI every day and it saves me real hours.

What works is boring to write in a release. Things like:

• Sorting incoming email into three categories, with a clear rule for what the AI is not sure about.
• Transcribing a meeting and pulling out the decisions, with a person reviewing in two minutes.
• Filling in a proposal draft based on data that is already in your system.

Each of those saves 20 minutes to two hours a week. It does not change civilization. It changes your Friday. At one small client, automating email sorting alone cut around six hours a week of manual work. Running cost: less than R$ 100 a month in API.

The difference between that and the big promise is scope. Small task, predictable input, verifiable output. When the task is big and vague, the AI looks like magic in the demo and turns into rework in production.

The antidote is reading properly

Reading well, in Lepore's sense, is tolerating ambiguity. It is noticing that the story has context, cost and consequence. It is not jumping straight to the cool part.

Applied to software, reading well is:

• Reading the contract all the way to the price adjustment clause.
• Reading the usage chart of your own system before switching vendors.
• Reading your team's faces when you announce the new tool. That silence says a lot.

There is a nice irony here. The industry that promises artificial intelligence could use a bit more of the natural kind. Read carefully, ask again, accept that the answer might be "you do not need it".

My opinion, no middle ground: most companies that want to "adopt AI" need to fix three manual processes first. It is less exciting and it makes a lot more money. Pretty software on top of a messy process only makes the mess faster.

Start with the problem, not the tool

If you are evaluating something right now, do the exercise backwards. Instead of "what does this tool do?", write down in one sentence the problem that bothers you. No jargon. Something like: "it takes me three days to answer a quote". Then look for the smallest thing that solves it. Sometimes it is AI. Sometimes it is a form and an email template.

That is the kind of conversation I like to have before writing any line of code. If you want to talk through what makes sense in your case, take a look at how I work.

A client of mine signed up for an AI support SaaS at R$ 2,400 a month. The promise: "it solves 80% of tickets on its own". The reality, four months later: 19%.

The software worked. The promise is what was fiction.

Silicon Valley read science fiction as a product catalog, not as a warning. Frankenstein became a tutorial. The result reaches you wrapped in "superintelligence" and "this will change civilization".

Then you open the product and it is a chatbot that gets the zip code wrong.

I am not anti-AI, I use it every day. It is just that what works is boring: sorting email, pulling decisions out of meetings, filling in a draft. At one small client, sorting alone cut six hours a week with less than R$ 100 of API. It does not change civilization, it changes your Friday.

Before asking "what does this tool do?", write down in one sentence the problem that bothers you. No jargon. If you want to talk through your case, reach out.

#AI #Technology #Automation #DigitalTransformation #Software