Not because AI isn't transformative, it absolutely is. But because teams are building blind. They're trying to create products without understanding what it actually does.

The Blindspot That's Killing AI Products

You can't build a product with a tool you don't understand. Basic principle. But somehow with AI, everyone's thrown this out the window.

Product teams are shipping features based on vibes. Building roadmaps and overpromising toward capabilities that don't exist. Getting surprised when their AI confidently lies because nobody told them that's literally what LLMs do.

It's wild - we have this insanely powerful technology, and nobody's taking the time to understand what it actually does versus what they hope it does.

Why Nobody Takes The Product Perspective

Here's what pisses me off: every other successful product starts with understanding the actual capabilities and constraints of the technology. You don't build mobile apps without understanding what phones can do. You don't build web services without understanding browsers.

But with AI? Everyone's either believing the AGI hype or dismissing it as autocomplete. Nobody's actually mapping out what this thing does.

So I did. Not the marketing promises. Not the doomer scenarios. The actual capabilities (according to using and researching).

I like to outline it as a today, tomorrow and day after framework, where I can estimate what order this will take place in. The when is an educated guess on the likelihood but then again when has humanity not surprised us?

The Today, Tomorrow, Day After Framework

Today (September 2025)

What Actually Works:

• First drafts, synthesis, pattern matching at scale

• Code generation for routine tasks

• Following clear multi-step instructions

• Maintaining conversation context

What's Broken:

• Can't understand "why" - just patterns

• Multi-week planning? Forget it

• Doesn't know when it's wrong (confident hallucination is a feature)

• Zero genuine strategy or creativity

Tomorrow (Early 2026)

What Gets Better:

• Step-by-step reasoning you can follow

• Cross-format memory and synthesis

• Natural voice with minimal delay

• Actually admits uncertainty sometimes

What Still Won't Work:

• Independent judgment

• Original innovation

• Self-directed goals

Day After (Late 2026)

What Becomes Reliable:

• Complete apps for defined problems

• Multi-day research projects

• Self-correction workflows

• Confidence indicators

What Stays Broken:

• Understanding causation

• Genuine creativity

• Edge cases humans handle easily

Why This Breaks Your Roadmap

Without understanding these capabilities, your product roadmap is fiction.

You're promising features requiring AGI when we're building pattern matchers. Designing UX that assumes AI understands context when it just matches patterns. Building business models requiring capabilities that won't exist for years, if ever.

Meanwhile you're missing what's actually possible.

Teams that get this are building insane products. Not solving traditional problems - creating entirely new categories that only make sense with superhuman pattern matching plus fundamental limitations.

The Real Competitive Edge

Right now, most teams are building toward an AI that doesn't exist.

The teams that understand the actual trajectory? They know what features to build now, what to plan next quarter, what to ignore completely. They're not surprised by limitations because they designed for them.

This gap between understanding and hoping is about to become the gap between winners and everyone else.

You can't build products with tools you don't understand. And right now, almost nobody understands the tool.

This led me down a rabbit hole to find some possible alternatives such as IPFS(Inter Planetary File System), storj and the maidSafe network(SAFE network) which is not up yet and am actively researching it.

So back to IPFS, what actual features or benefits does it have you may ask…?

Well the IPFS boasts a versioned file system, is a peer-to-peer model thus no single point of failure, and uses content addressing and multihashing. To be more clear IPFS is a decentralised general-purpose file system that uses a distributed hash table (DHT) and Merkle DAG to route and transfer content-addressed data, not a storage or cloud service provider.

There are quite a few solutions to a different suite of protocols but through my research, all of them seem to have one similarity which is that they used content-based addressing.

In exploring Internet decentralization, the concept of content-based addressing is quite compelling. Picture asking me to fetch coffee beans from your kitchen, which I've never visited before. In a traditional IP-based scenario (location-based addressing), I'd try to retrieve the beans from the precise location you instructed, like the first jar on the second shelf. If the coffee beans aren't there, I'd return empty-handed, unable to fulfil your request and get the beans back.

On the other hand, content-based addressing, akin to what IPFS uses, behaves differently. No matter where in the kitchen you last left the coffee beans, I'd search for and retrieve the actual 'content' - the coffee beans themselves. This content-driven approach, relying on unique identifiers (hashes) for specific content, provides robust data integrity and reduces redundancy in the system. Any change in the content changes its hash, which makes data tampering evident and ensures you always get the coffee beans you asked for, not something else.

However, like all systems, IPFS has its own set of challenges. The issues range from potential unreliability with private data (the content is accessible to anyone with hash access), limited security for verifiable content, and complexity in setting up a local node. Additionally, the system is not very beginner-friendly, consumes larger bandwidth, and lacks economic incentives for setting up a local node for the network.

Given these challenges, you might wonder why someone would still choose to use IPFS. It's essential to remember that every technology has its pros and cons, and the choice often depends on specific needs and contexts. For instance, despite its limitations, IPFS shines in its decentralized nature and freedom from a single point of control.

Indeed, the value IPFS provided to me as an end-user turned out to be exceptional. The ease with which I could upload my website through Fleek was remarkable. This process was as simple as pointing it to my React Native GitHub repo. Within the next minute or so, it was deployed either under my own custom ENS domain or one would be provided for me. This streamlined approach is just one example of the many solutions built on IPFS. Others include notable projects such as Fleek, Audius, the Brave browser, the Opera browser, and more, all demonstrating the diverse applications and expansive potential of the IPFS ecosystem.

I have tried to skip all technical jargon for now but would definitely love to write a more technical piece focusing on either core concepts or topics in the future and would love any sort of feedback if you made it this far!

References:

https://en.wikipedia.org/wiki/Content-addressable_storage

https://en.wikipedia.org/wiki/InterPlanetary_File_System

https://docs.ipfs.tech/

https://github.com/ipfs/specs

https://fleek.co/hosting/

Projects featured on the IPFS-ecosystem

An interesting read regarding the average website lifespan - link