The simplicity is real. The complexity is also real—it has just moved address.
Three researchers — Sharique Hasan, Alexander Oettl, and Sampsa Samila — have offered organizations a clarifying lens: the apparent simplicity of large language models is not the elimination of complexity, but its migration. With their GAS framework, they trace how the trade-offs between generality, accuracy, and simplicity do not vanish when a user opens a chatbot — they retreat inward, settling into infrastructure, compliance, and specialized labor. In this light, the race to build the most intuitive interface may be less consequential than the capacity to govern what that interface quietly demands.
- Organizations adopting LLMs are discovering that the smoother the user experience, the denser the hidden machinery required to sustain it.
- Compliance officers, infrastructure engineers, and domain specialists are absorbing trade-offs that once lived at the surface — creating new pressure points that leadership rarely sees until they fail.
- The GAS framework reframes the competitive question: advantage belongs not to whoever deploys the simplest tool, but to whoever best manages the complexity that simplicity redistributes.
- Companies are being urged to stop treating LLM integration as a technology rollout and start treating it as a socio-technical design problem — one requiring deliberate choices about abstraction, workflow, and team composition.
- The field is moving toward a more honest accounting of what AI adoption actually costs, shifting attention from the user interface to the organizational architecture beneath it.
Three researchers have published a framework that reorients how organizations should think about large language models. Sharique Hasan, Alexander Oettl, and Sampsa Samila built their argument around something they call the Generality-Accuracy-Simplicity framework — GAS — and its central insight is this: when a chatbot feels effortless to use, the difficulty has not been solved. It has been relocated.
For years, the conversation around LLMs has focused on the user experience — the clean interface, the instant answer, the absence of training requirements. But Hasan, Oettl, and Samila argue that this surface ease conceals a deeper reorganization inside companies. The trade-offs between generality, accuracy, and simplicity have not disappeared; they have been pushed inward, into infrastructure teams, compliance functions, and the domain experts who must shape these tools for specific business contexts. The user sees a button. Behind it, complexity thickens.
The GAS framework names this redistribution explicitly. Competitive advantage, the authors suggest, does not come from having the simplest interface — it comes from managing what that simplicity requires. That means designing abstraction layers thoughtfully, aligning workflows so tools fit how people actually work, and assembling teams whose expertise spans technology, business, and domain knowledge.
The paper is strategic rather than prescriptive — it offers no deployment checklist. Instead, it offers a lens: LLM integration is not a technology adoption challenge but a socio-technical design challenge. The complexity cannot be eliminated. The question is only how to distribute it in ways that generate advantage rather than friction.
Three researchers have published a framework that reorients how we should think about large language models in organizations. Sharique Hasan, Alexander Oettl, and Sampsa Samila submitted their paper to arXiv in June 2025, revised it in May 2026, and titled it around something they call the Generality-Accuracy-Simplicity framework—or GAS. The insight is deceptively simple: when you hand someone a chatbot that seems to do everything and requires no training, you have not actually eliminated the hard choices that come with any powerful tool. You have moved them.
For years, the conversation around large language models has centered on the user experience. A person opens an interface, types a question, gets an answer. The simplicity is real. But Hasan, Oettl, and Samila argue that this surface-level ease conceals a deeper reorganization happening inside companies. The trade-offs that used to live at the edge—the question of whether you wanted a tool that was general-purpose or highly accurate, simple to use or powerful—have not disappeared. They have been pushed inward, into the organizational machinery itself.
Consider what happens when a company decides to deploy an LLM. Someone has to build the infrastructure to run it. Someone has to ensure it complies with regulations. Someone has to monitor its outputs and catch errors. Someone has to integrate it with existing systems in ways that actually make sense for the business. The user sees a button. Behind that button is a thickening layer of specialized work, architectural decisions, and institutional knowledge. The simplicity is real. The complexity is also real—it has just moved address.
The GAS framework names this explicitly. Generality, accuracy, and simplicity are not problems that technology solves. They are problems that technology redistributes. An LLM can be general-purpose and simple to use, but that generality and simplicity come at a cost paid elsewhere: in the infrastructure teams that have to keep it running, in the compliance officers who have to verify it is safe, in the domain experts who have to teach it to behave correctly for their specific use case. The competitive advantage, the authors suggest, does not come from having the simplest interface. It comes from managing the complexity that simplicity requires.
For organizations trying to integrate these tools, the implication is a shift in how to think about the problem. It is not primarily a technology adoption challenge. It is a socio-technical design challenge. That means thinking carefully about abstraction layers—how much complexity do you hide from which users, and at what cost? It means aligning workflows so that the LLM fits into how people actually work, not forcing people to work around the tool. It means building teams with complementary expertise: people who understand the technology, people who understand the business, people who understand the domain where the tool will operate.
The paper ranks as strategically important rather than immediately actionable. It does not offer a checklist or a deployment playbook. Instead, it offers a lens through which to see what is actually happening when organizations adopt LLMs. The simplicity users experience is real. The complexity organizations must manage is also real. The question is not how to eliminate that complexity—you cannot—but how to distribute it in ways that create advantage rather than friction. That distribution is where the actual work begins.
Citações Notáveis
Apparent user-facing simplicity of LLMs masks increased organizational complexity, and competitive advantage depends on managing that redistributed complexity.— Hasan, Oettl, and Samila, per the GAS framework paper
A Conversa do Hearth Outra perspectiva sobre a história
Why does it matter that the complexity moved rather than disappeared? Couldn't an organization just accept the complexity as a cost of doing business?
Because where the complexity lives determines who bears it and whether you can actually manage it. If it lives in infrastructure, you need infrastructure expertise. If it lives in compliance, you need legal and regulatory knowledge. If it lives scattered across five different teams with no one owning it, you have a problem that money and time will not solve.
So the authors are saying that companies that win will be the ones that deliberately architect where that complexity goes?
Exactly. They are not saying complexity is bad. They are saying the companies that understand they have a choice about where to put it—and make that choice deliberately rather than by accident—will have an edge.
What does that look like in practice? How does a team actually do that?
It starts with asking different questions. Not "How do we make this tool easier for users?" but "What work does making it easier for users create elsewhere, and who is equipped to do that work?" Then you design backward from there. You build abstraction layers. You hire people with the right expertise. You align your workflows to the tool rather than fighting it.
Is this saying that the simplicity we see is kind of an illusion?
Not an illusion. Real. But incomplete. It is like looking at a ship and seeing the hull and the sails, and thinking that is all there is. The complexity is real too. Both are true at the same time.