The AIKEA Effect

Just like the IKEA Effect, but for the AI products. Try not to overenginner when working with LLMs.

The IKEA Effect

The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly.


There is substantial evidence that people value things (including software) after they put in at least some effort, regardless of the “objective” end state.

Low-hanging fruit from the Tree of Knowledge

The current models (GPT-3.5, GPT-4, LLAMA2) are very good at working “out of the box”. So much so, that we really cannot work fast enough at integrating them. There is a broad class of “synthesize these documents in 2-3 paragraphs” that provides immediate business value. Subclasses of this solutions include:

  1. Q&A mechanism for dataset X, where you enable an AI model to query your dataset and formulate an answer to your question
    • Think of it as Bing Chat for your proprietary dataset
    • You could also use AI for a vector search throughout your dataset, but existing search algorithms also work.
  2. Synthesize a number of random document chunks in a format Y
    • A dashboard that will surface key points
    • Scan huge documents for relevant passages
  3. Turn unstructured data into a structured format to (finally) connect one system to the other.

While tackling this low-hanging fruit has obvious business value, it is also technically not very challenging. You plug a model, craft a prompt, and you’re done. And when it works – you feel a little bit guilty.

The typical AI Developer

With the obvious business opportunities, what should companies do? Obviously, they put their best people on it.

But their best people are used to solving complicated and challenging problems. It’s in their blood to go after hard things. This is how they became “one of the best people”.

They do what they are best at: try to solve a complicated engineering problem where one might not exist. Where just shoving your problem into prompt would suffice, they immediately launch into:

  • Talking about training and fine-tuning models
  • Start building infrastructure where you could call OpenAI
  • Using Embeddings where existing search algorithms are enough
  • Build complicated pipelines using the fresh findings from AI papers

The engineering also serves a bit as a reassurance that we understand the whole stack – at least I’ll understand the parts I built.

The moat of OpenAI Wrappers

The early crop of “AI Writing Assistants” (,, etc.) is not doing so well now that bigger players are catching up to them. This is often used as an illustration that it’s not worth grabbing this low-hanging fruit because this is not a viable long-term strategy.

But the fact that these companies were able to gather users, funding, and revenue just by being a wrapper over somebody else’s API is impressive.

Yes, in the age of Open Source LLMs the tech will probably not be a moat. But distribution, marketing, and speed of execution definitely can.

The multiple dividends on speed in the AI world

Not only do we not know the full extent of LLM capabilities, but we also don’t know what customers are comfortable with, what interfaces they prefer, and what improvements wait just around the corner.

Speed is always a force multiplier, but in the AI world, a shorter feedback loop is a much bigger advantage than your perfect architecture.

This is where your “best of the best” AI team can really shine. The low-hanging fruit from the tree of knowledge will keep coming for some time before we get kicked out of the garden.

Leave a Reply