dentro.de/ai

Claude Code: The Revolution Nobody Noticed

Michael Frison — Tue, 24 Feb 2026 00:00:00 +0000

Claude Code: The Revolution Nobody Noticed

How a terminal tool quietly kicked off the age of AI agents

On February 24, 2025, Anthropic released a research preview of Claude Code - a command-line tool that let an AI read files, run commands, and write code from a terminal window. There was no launch event and no viral demo, which is why the world did not notice. Mainstream was busy playing with ChatGPT, and a developer tool in terminal with a blinking cursor was not accessible to them.

But looking back something fundamentally different had happened. For the first time, an AI system was not just answering questions - it was taking action. It could look and understand a codebase, form a plan, execute it step by step, develop tests to observe whether things worked, and course-correct when they did not. Not in a research lab but in real working environments supporting the developer community. A genuine category shift, and almost nobody outside of the software developer bubble noticed that.

The Day AI Learned to Act

To understand what made Claude Code different, it helps to understand what came before it. Every major AI tool on the market - ChatGPT, Gemini, Copilot - was built on the same foundation: next-token prediction. You provide a prompt, the model calculates the statistically most likely sequence of tokens that should follow, and it outputs that sequence as text. It is an extraordinarily powerful mechanism, but at its core the model is a reactive function - it takes input and produces output, and then it waits for more input. Even GitHub Copilot, which felt revolutionary when it arrived in 2021, was essentially autocomplete on steroids. It predicted what you might type next, but it never understood the project it was working in, never ran anything, and had no way of knowing whether its suggestions actually worked.

Claude Code broke that pattern. When a developer described a problem, the system would start by exploring the codebase on its own, reading files and understanding how components connected before touching anything. It would then form a plan, make edits, run tests, read the error output if something failed, and adjust its approach accordingly. This loop of planning, acting, observing, and adjusting is what the AI industry now calls "agentic behavior," and with Claude Code it went from being a research concept to something a developer could install and use on a regular workday.

The underlying model at launch was Claude 3.7 Sonnet - capable but not yet the powerhouse that later versions would become. The experience had rough edges and not every task landed cleanly, but even in that early form the difference was unmistakable for anyone who tried it. This was no longer a text prediction engine producing suggestions for a human to evaluate and apply, but a system that could work through problems on its own and deliver working results.

One Brain, One Body

Before Claude Code, the AI landscape had a clear division of labor. Companies like OpenAI, Google, and Anthropic built foundation models and exposed them through APIs, while separate companies like Cursor, GitHub with Copilot, and various open-source projects built the tools that developers actually used by plugging into whichever model API suited them best. The brain and the body came from different manufacturers, and the tool makers had to work around the limitations and quirks of models they did not control.

Anthropic did something different with Claude Code. They built both the model and the tool that wraps around it, optimized end to end for each other. The closest analogy might be Apple, which famously designs its own chips and its own operating system so that hardware and software work together in ways that competitors assembling third-party components cannot easily replicate. With Claude Code, Anthropic created the same kind of vertical integration for agentic AI - the model's capabilities and the harness around it were designed as one coherent system, not bolted together from separate parts.

This turned out to be a significant competitive advantage. When the model improved, the tool could immediately exploit those improvements without waiting for a third party to catch up. When the tool needed specific model behavior, Anthropic could tune both sides of the equation simultaneously. The result was a tighter feedback loop between model capability and tool design than anything else on the market at the time, and it showed in the experience.

The competition noticed quickly. Within months, every major lab rushed to build their own vertically integrated equivalent - same company, same brain, same body. The playbook Anthropic had introduced became the template.

Nobody Noticed

Given the magnitude of this shift, it is worth understanding how it managed to fly under the radar of mainstream attention for so long. The answer is a combination of factors that almost seem designed to keep a revolution invisible.

The most immediate one is the interface itself. Claude Code lives in a terminal - a black screen with monospaced text that most people associate with hackers in movies or IT departments they try to avoid. There is no colorful UI or friendly onboarding wizard to ease you in. For someone outside the software development world, even looking at a terminal feels like staring into a foreign language. Anthropic built something genuinely transformative and then wrapped it in the one interface guaranteed to keep non-developers away.

Then there is the audience. Claude Code was explicitly built for software developers, and developers are a community that largely talks to itself. The excitement was real and immediate inside that bubble, with people sharing workflows and building extensions and rethinking how they approach entire projects. But developer enthusiasm rarely translates into mainstream headlines. The tech press covered it as a product launch among many, not as the paradigm shift it turned out to be. And the broader business press, which shapes how executives and decision-makers understand technology trends, barely registered it at all.

Timing played a role too. In February 2025, the public conversation about AI was dominated by chatbot comparisons and the mental model most people had for AI was a chat window where you ask questions and get answers. A tool that worked autonomously in a terminal did not fit that frame, so it was easy to dismiss as a niche developer utility rather than recognizing it as the first real-world implementation of a fundamentally new way AI could operate.

And finally, the models themselves were not yet at the level where the agentic experience felt consistently reliable. Claude 3.7 Sonnet was good enough to demonstrate the concept convincingly, but it still stumbled on complex tasks often enough that even enthusiastic early adopters treated it as promising rather than production-ready. The gap between "this is impressive" and "this changes everything" had not yet closed, which made it easier for the wider world to look the other way.

The Race That Followed

Before Claude Code, coding was not where the AI competition was playing out. The big labs were focused on making their chatbots smarter and more versatile, and while coding assistance existed as a feature in that broader race, nobody treated it as a battleground in its own right. Claude Code changed that dynamic, because within months the ability to autonomously develop, test, and deploy a working application from a single prompt became the new frontier that every major lab felt compelled to compete on.

OpenAI released Codex CLI in April 2025, two months after Claude Code's preview - their own terminal agent built on o3 and o4-mini. Google followed in June with Gemini CLI on Gemini 2.5 Pro. Both adopted the same fundamental architecture of a terminal-based agent loop that Claude Code had established. Meanwhile, the broader ecosystem of independent tools - Cursor, Windsurf, Kilo Code, OpenCode - all shifted their trajectory toward deeper agentic capabilities. OpenCode in particular grew into one of the most popular open-source alternatives, model-agnostic and free from vendor lock-in, with over 70,000 GitHub stars by early 2026. The entire industry pivoted.

Anthropic had already laid additional groundwork before Claude Code even launched. In November 2024, they introduced the Model Context Protocol (MCP) as an open standard for connecting AI agents with external tools and data sources. Claude Code supported MCP from early on, allowing it to reach beyond the local codebase and interact with databases, APIs, and third-party services. As the agentic coding space grew throughout 2025, MCP saw broad adoption across the industry - including Google's Gemini Code Assist and OpenAI's ecosystem. Having a shared open protocol for how agents interact with the outside world turned out to be just as important as the agents themselves.

The financial picture confirmed the scale of what was happening. By September 2025, Claude Code usage had grown more than tenfold in three months, reaching over 500 million dollars in annualized revenue. For a terminal tool that most of the world had never heard of, those are platform-level numbers.

When the Walls Came Down

Everything described so far happened inside the developer community, which is impressive and fast-moving but still contained within a professional group that was already comfortable with terminals and code. The truly radical shift began when people who had never written a line of code in their lives started using these tools - and it worked.

The combination of dramatically improved models and increasingly polished agentic tools lowered the barrier to the point where technical skill was no longer a prerequisite. Someone with a clear idea of what they wanted could sit down in front of Claude Code, describe an application in plain language, and watch it get built in front of them without touching a single line of code or even fully understanding what the code does. They did not need to. The application worked, and that was enough.

This is a remarkable inversion of how software has been made for decades. Traditionally, building an application required either learning to code yourself or hiring someone who could. Both options involved significant investment of time or money, which meant that the vast majority of ideas people had for tools and applications simply never got built. The agentic tools removed that bottleneck, and in doing so they unlocked a population of potential creators who had always had the ideas but never had the means to realize them.

By late 2025 and into early 2026, this was no longer a theoretical possibility but something happening in practice. Non-technical professionals were building internal tools for their teams and automating workflows that had previously required IT support or weeks of dedicated developer time. The terminal, which had been the very thing that kept this revolution invisible to the mainstream, was becoming a surprisingly accessible workspace for people who would never have imagined themselves using one.

From Chatbot to Agent

The AI curriculum I developed at dentro.de/ai is structured around a simple mental model: BEFORE → INSIDE → AFTER the AI black box. BEFORE is the large-scale training phase where the model gets built. INSIDE is the trained model itself, a mathematical function that takes input and produces output. AFTER is what happens when you use it. In the chatbot era, this was a linear sequence: your prompt went INSIDE the model, a response came out AFTER, and then it was up to you to do something with that response before sending the next prompt. A one-way flow with the human in control at every step.

What Claude Code changed is that INSIDE and AFTER became a loop. The model produces not just text but an action - editing a file, running a command. The result of that action feeds back as new context, the model processes it again, produces the next action, and keeps going until the task is complete. The model INSIDE did not change - it is still predicting the next token. What changed is that the AFTER layer stopped being a dead end and became an autonomous feedback loop. From a straight line to a circle. That is the shift from chatbot to agent, and it is what I described in my earlier writing as the difference between AI adoption and AI transformation. When a developer stops reading the code and simply evaluates whether the application works as intended, they have crossed that line. They are no longer doing the work with AI assistance - they have become the orchestrator.

Most people have not yet come to terms with what chatbot-era AI means for their work. They are still attending workshops on prompt engineering and debating whether AI is overhyped, while AI has already moved on to this fundamentally different paradigm. The transition from reactive chatbot to autonomous agent accelerated out of sight in a space most people never look at, and by the time it reaches them there will be no runway left to prepare. Developers had a year-long head start and their background in mathematics and IT gives them a natural advantage in grasping what is happening - even though many of them still do not fully understand how AI functions inside the black box either. For everyone else, the gap is not just wider - it is growing in a direction they cannot even see. They are already playing catch-up on the chatbot era while the agentic era accelerates in the dark, invisible to anyone not embedded in the developer world. By the time it surfaces into mainstream awareness, there will be no gentle on-ramp. This is exactly why I built dentro.de/ai - to help people build that understanding before the ground shifts under them.

When ChatGPT launched in November 2022, it was immediately recognized as an inflection point - the "iPhone Moment" that brought AI into mainstream consciousness. Claude Code's launch in February 2025 deserves a similar place on that timeline, but for the opposite reason. Where ChatGPT was the most visible AI event in history, Claude Code was one of the least visible, and yet the shift it represents - from AI that talks to AI that acts - may prove to be the more consequential one. I described the AI adoption trap as optimizing for today locking you out of tomorrow. Claude Code's first year is a concrete illustration. The people who recognized the chatbot-to-agent shift early are positioned for what comes next. For everyone else, the good news is that catching up is still possible and not as difficult as it might seem - the underlying concepts are learnable, and understanding them changes how you see everything that is happening around you.

The dentro.de/ai curriculum covers everything from how models are built to how they behave when you use them, structured around the BEFORE → INSIDE → AFTER framework. It is designed for anyone who wants to understand AI at a level that makes shifts like this one visible before they become unavoidable.

AI Adoption is a Trap

Michael Frison — Mon, 19 Jan 2026 00:00:00 +0000

AI Adoption is a Trap

Optimizing for Today Might Lock You Out of Tomorrow

Everyone tells you to implement AI. It is what the conference speakers promote, what competitors are doing, where the money is being made, where the big headlines are. And they are not wrong - AI delivers real productivity gains, cost savings and a strong feeling of competitive advantage. It seems like the right thing to do.

It sounds paradox, but that is precisely why it is a trap.

Not because AI is overhyped, or because the productivity gains are smaller than vendors promise. The trap is more subtle: by adopting AI to optimize your current business, you lock yourself into today's structures that may not survive what comes next.

You will not hear this argument at AI conferences. The stages are filled with people selling adoption. The insight that adoption itself might be the problem has no natural advocate - no one profits from saying it (aka you read it here first!).

Most companies assume that using AI today is all that is needed to prepare for an AI-driven future. They deploy chatbots, automate workflows, accelerate content creation. Almost all of this is optimizing the present, not preparing for the future. A company using AI to make selected processes faster is not building toward a future where AI handles complete business functions autonomously. It is doing what it already does, slightly faster - while reinforcing structures that may need to be completely rethought.

I explored the distinction between AI adoption and AI transformation in a previous article. Here I want to argue that the standard adoption path is not just insufficient - it is actively dangerous.

How Optimization Becomes Lock-In

When you improve a process with AI, you don't just make it faster. You encode it into software, build APIs around it, train people to depend on it, and produce metrics that justify its existence. You celebrate the success and every workflow you optimize becomes harder to replace. You are cementing your current business in place.

It happens gradually over time and each optimization makes sense on its own. In the long run however, the cement hardens, and you find yourself locked into a direction - not by a single decision, but by the accumulated weight of many small improvements that now define your organization.

This happens at precisely the wrong moment. Previous technology waves - personal computers, internet, mobile, cloud - changed infrastructure, channels, or interfaces. Companies could adopt new capabilities by replacing existing structures. AI changes something more fundamental: cognition itself, how decisions get made, who makes them, and at what speed. This is not a new tool to add - it is a potential reorganization of how value gets created.

When the ground is stable, optimization makes sense. When the ground is shifting, it can leave you perfectly adapted to a landscape that no longer exists.

The Zero-Sum of Organizational Capacity

The trap has a second dimension: organizational capacity. Every company has limited resources for change - attention, talent, change tolerance, management support. This capacity is zero-sum. As soon as it is spent for optimizing current workflows, it is no longer available for preparing for a different future. The people running AI adoption are not simultaneously designing the AI-native organization. The executive attention consumed by deployments is not available for questioning fundamental assumptions.

So optimization both locks you into current structures - plus it consumes the resources you would need to escape.

Consultants Won't Pull You Out

If this trap is obvious, why does everyone walk into it?

Because no one gets paid to warn you. Consulting firms sell AI pilots, tools, and workflow automation - tangible, billable, with slide decks showing before-and-after metrics. They cannot easily sell future strategic blueprints that might or might not materialize. There is no case study for a transformation that is anticipating future capabilities that are currently challenging to imagine. The market systematically pushes toward adoption, while the advice companies might actually need is to invest in understanding rather than deployment, and in flexibility rather than efficiency.

You Don't Know What You Don't Know

The market dynamics are only the surface. The deeper issue is a skill gap.

Understanding AI transformation requires a literacy most executives have never had reason to develop. Not the ability to use AI tools - which by now is straightforward. The ability to see how AI might reorganize value chains, which structures are temporary, what an AI-native competitor might look like. This does not come from vendor demos or pilot projects. It comes from sustained engagement with the technology itself.

Most companies - especially outside software and technology - do not have this understanding in their leadership. Executives rose through product, sales, operations, finance, strategy. Their careers gave them no reason to develop technical intuition about AI - or even IT in general. And this gap is difficult to close from within. Technical people - geeks! - rarely climb organizational ladders in that kind of environment.

This creates a catch-22. Because of the skill gap, it is difficult to recognize that the gap exists. Psychologists call this cognitive bias the Dunning-Kruger effect: the skills needed to evaluate your own competence are the same skills you are missing. The less you understand about AI transformation, the more confident you feel that adoption is enough. Consultants agree, the metrics is looking good and everything appears fine.

This is why closing the skill gap must come first - before pilots, tools, and consultants take over. Without it, every other decision is made blind.

The Challenge of Imagining What Doesn't Exist

There is a deeper challenge that makes this genuinely hard: transformation into an AI native organization requires imagining a future that doesn't exist yet.

Leaders are being asked to design organizations for a world two or three years out - a world of AI-native companies with capabilities we can only partially glimpse today. This not only requires the skill mentioned above, but also creativity, imagination, and risk taking. It is easier to optimize what exists than to envision what might replace it.

The companies that adopted AI heavily in 2025 optimized for 2025. By 2028, those optimizations may be liabilities. The question is not whether to use AI, but whether you are building for the future or locking into the present.

The Way Out

There is a way out. In the previous article comparing AI Adoption with AI Transformation I described the model of an elite unit - a satellite organization with access to the parent company's resources but freedom from its constraints. This unit can do something that internal AI adoption cannot: work on both timelines at once.

The experts in such a unit understand your business and have the skills to implement tactical AI improvements. But because they are simultaneously designing the AI-native blueprint, they do this work differently. They know which optimizations are of temporary nature and which would cement you in place. They can improve the present without blocking the future, because they are the same people building what comes next.

This is the escape from the trap: not avoiding AI, but placing it in hands that are designing the future blueprint rather than defending the status quo.

But even this model requires something from leadership: enough understanding to recognize what is being built, and to protect it from internal resistance. The skill gap cannot be delegated.

The skill gap is the trap within the trap. For leaders ready to close it, dentro.de/ai offers a learning path designed for non-technical executives - not to make you technical, but to give you the literacy to see what you are missing.

AI Adoption vs AI Transformation

Michael Frison — Thu, 08 Jan 2026 00:00:00 +0000

AI Adoption vs AI Transformation

Learn from DTM to Build AI-Native Organization

The pressure to "adopt AI" echoes earlier technology waves: the personal computer, the internet, mobile. Each time, organizations that merely bolted new technology onto existing structures captured only a fraction of the available value.

AI is no different - except the stakes are higher, and the window shorter.

The critical distinction is between AI adoption (adding tools to existing workflows) and AI transformation (redesigning the organization around AI capabilities). One makes humans faster. The other builds a machine with end-to-end workflows.

The Homologation Problem: Why "AI-Enhanced" Falls Short

The term "homologation" comes from motorsport. In the late 1980s, DTM regulations required manufacturers to produce road-legal versions of their racing cars - a minimum number of street vehicles had to be sold to "homologate" (officially approve) the race car. The problem: building homologation specials required speed, risk tolerance, and engineering freedom that mass-production organizations simply couldn't deliver. BMW's solution was M GmbH; Mercedes-Benz leaned on AMG. These weren't internal departments - they were elite external satellites, structurally separate but strategically aligned, with permission to operate by different rules. These units didn't just operate differently - they attracted different people. Engineers and specialists who would have been absorbed into corporate hierarchies elsewhere could finally work alongside peers who shared their intensity, freed from committees and compromise.

Today's legacy companies face their own homologation moment. AI demands capabilities - speed, experimentation, tolerance for failure - that their existing structures cannot deliver. But most are not following this proven playbook for radical innovation. Instead of creating structurally separate units to build something genuinely new, they are simply becoming AI-enhanced. They deploy chatbots, provide co-pilots, accelerate workflows. They work faster but remain structurally unchanged - the same reporting lines, the same approval chains, the same data silos now with fragmented AI bolted on.

By contrast, AI-native organizations are architected differently from inception. Data flows continuously across the entire operation - clean, structured, and fully integrated into every workflow. This doesn't happen by accident; these organizations have done the hard work of preparing their data foundation before connecting the machine. AI systems don't just recommend; they execute within defined guardrails, with humans governing exceptions and setting strategy. Workflows aren't accelerated versions of legacy processes - they're redesigned from first principles around what AI makes possible.

Dimension	AI-Enhanced (Adoption)	AI-Native (Transformation)
Data	Fragmented, batch-processed	Continuous flows, single source of truth
Decisions	AI recommends, humans approve	AI executes within guardrails, humans govern
Workflows	Existing processes accelerated	Processes redesigned around AI capabilities
Talent	AI tools distributed to existing roles	Roles reconceived; human focus on judgment, creativity, relationships
Speed	Incremental improvement	Order-of-magnitude change

The AI-enhanced company is a faster version of its former self. The AI-native company is a different species.

Why an AI Department Cannot Transform You

The instinctive organizational response to AI pressure is familiar: create a team. Companies establish AI Centers of Excellence, embed data scientists in business units, hire a Head of AI reporting into IT or Strategy.

These moves are necessary but insufficient. An AI department can optimize components. It cannot redesign the machine while the machine is running.

Genuine transformation requires:

AI literacy at the executive level. Not technical fluency, but genuine understanding of what AI can do. Executives must have seen it in action, grasped its capabilities, and be able to think through what it means for their operations, their products, and what their customers will need next.
A Chief AI Officer with genuine authority. Not a technical advisor, but an executive who owns outcomes, controls budget, and has a seat at resource allocation decisions.
Board-level buy-in. Directors who understand enough to back the transformation - approving the investment, protecting the elite unit, and holding steady when it starts to disrupt the core business.

Without this, AI remains an operational experiment rather than a strategic commitment.

So if an internal AI department cannot deliver transformation, what can? The answer lies in a model that has already proven it works - in one of the most intensely competitive, publicly scrutinized environments imaginable: high-calibre motorsport.

The DTM Model: Why Legacy Companies Need External Elite Units

When BMW and Mercedes-Benz committed to winning DTM, they faced a fundamental problem: how does a company optimized for one thing become excellent at something entirely different?

The conventional approach would have been to create an internal motorsport department - hire some racing engineers, allocate budget, embed the team within the existing organization. Both companies recognized this wouldn't work. They didn't try to make their mass-production organizations faster and more agile. They recognized that the capabilities required for competitive racing - building homologation specials, developing and maintaining race cars, running a championship campaign - were structurally incompatible with what made them successful at building reliable, profitable sedans. The solution was separation: elite external units with access to parent company resources but freedom from parent company constraints.

AMG, founded by former Mercedes engineers Hans Werner Aufrecht and Erhard Melcher, could attract talent motivated by performance rather than corporate advancement. BMW Motorsport - later known as M GmbH - could specify components that would never survive a standard business case review. Both could iterate at speeds impossible within normal product development cycles.

Legacy companies facing AI transformation confront the same structural problem. The capabilities required to build AI-native systems - data fluency, rapid experimentation, comfort with ambiguity, willingness to cannibalize existing products - are often incompatible with the cultures and processes that made these organizations successful in the first place.

The DTM lesson is clear: don't try to transform the whole organization at once. Establish or partner with elite external units that can operate by different rules.

The parallel is direct:

Motorsport Elite Unit	AI Transformation Unit
Access to parent company resources (capital, brand, distribution)	Access to enterprise data, customer relationships, existing revenue
Freedom from parent company constraints (approval chains, cost targets)	Freedom from legacy tech stack, existing process requirements
Permission to cannibalize (racing cars competed with production image)	Permission to disrupt (AI-native offerings may cannibalize core business)
Talent attracted by mission, not corporate ladder	Talent attracted by building the future, not maintaining the present
Clear performance metrics (lap times, championships)	Clear performance metrics (speed to market, unit economics, customer value)
Technology transfer back to parent	Capability transfer back to parent

The strategic insight: you cannot transform a legacy organization by working within its constraints. You must create a protected space where different rules apply, then manage the interface between old and new.

And here's the unexpected dividend: both M GmbH and AMG still flourish today, many decades later. What began as elite units to win racing championships evolved into standalone brands. The elite unit you create to solve today's structural challenge may become tomorrow's growth engine.

The Threat Landscape: Known Competitors and Unknown Entrants

Executives often frame AI transformation as competitive necessity: "Our rivals are adopting AI, so we must keep pace."

This framing is dangerously incomplete.

Yes, established competitors are deploying AI - mostly in the same AI-enhanced mode, generating similar incremental gains. The greater threat comes from organizations being built right now, designed around AI from inception.

These AI-native entrants carry none of your burdens:

No legacy technology. They build on modern data architectures, not decades of accumulated systems.
No cultural resistance. Their people joined knowing AI would be central, not fearing displacement.
No process debt. Their workflows are designed around what AI makes possible, not what humans historically did.
No cannibalization anxiety. They have no existing revenue to protect.

Startups currently in formation will enter your market within the next months or years with cost structures you cannot match and speeds you cannot achieve - unless you build the organizational capability to operate differently.

The motorsport lesson applies here too: Mercedes and BMW were absolutely racing against each other - the 190 Evo 2 versus E30 M3 rivalry was one of the most intense battles in touring car history. But they were also racing against irrelevance. And that threat was not hypothetical: Audi's V8 quattro took the DTM championship in both 1990 and 1991, proving that a competitor willing to do things differently - in this case, four-wheel drive to promote their quattro technology - could disrupt even the fiercest established rivalry.

The same dual pressure applies to AI transformation. You are competing against established rivals adopting AI. But you are also competing against the possibility that AI-native entrants will make your entire category obsolete.

A Diagnostic Framework: Where Does Your Organization Stand?

Before defining initiatives, assess your current position honestly:

1. Data Readiness

Can you access a unified view of customer, operational, and financial data today?
How long does it take to answer a novel business question with data?
What percentage of your data is trapped in spreadsheets, emails, and undocumented systems?

2. Leadership Alignment

Can your executive team articulate what an AI-native version of your company looks like?
Is there genuine agreement on the pace and scope of transformation required?
Does AI appear in strategic planning as a capability priority or merely a technology line item?

3. Talent and Culture

Do you have people who have built AI-native systems, or only people who have implemented AI tools?
Is your culture comfortable with experimentation and failure, or optimized for predictability?
Can you attract talent that has alternatives at AI-native companies?

4. Structural Permission

Is there an organizational space where different rules apply - faster decisions, different success metrics, freedom from legacy constraints?
Do leaders of transformation initiatives have genuine authority, or are they advisors to power?
Is there explicit permission to cannibalize existing offerings?

5. Governance and Risk

Are your board and executive team equipped to oversee AI-driven transformation?
Have you addressed regulatory, ethical, and operational risks specific to AI deployment?
Is there a clear accountability structure for AI outcomes?

The North Star: Defining the Destination Before the Journey

Transformation without a destination is expensive wandering. Before launching initiatives, leadership must articulate what a fully AI-driven version of their organization looks like:

Data flows freely: All operational data moves continuously through the organization - no silos, no manual handoffs, no waiting for reports. The AI can see everything it needs to see.
AI executes, humans govern: Routine decisions and operations are handled by AI within defined guardrails. People focus on judgment, relationships, and strategy - the work that requires human insight.
The system learns: Every interaction, every outcome feeds back into the machine, making it smarter over time. The organization improves continuously without deliberate effort.

This North Star serves as an alignment mechanism. Every AI initiative can be evaluated against it: Does this move us toward the destination, or does it merely optimize a structure we intend to replace?

The Path Forward: Principles, Not Prescriptions

Every organization's transformation path will differ. But certain principles hold broadly:

Start with the North Star. Define the destination before launching initiatives. Use it to evaluate every proposal.

Build an elite unit. Create a protected space with access to resources but freedom from constraints. Staff it with people who want to build the future, not preserve the present. Give it real authority and clear metrics.

Elevate AI literacy. Ensure executives and board members understand AI strategically, not just technically. Transformation cannot be delegated.

Accept cannibalization. Your AI-native unit may threaten existing business lines. This is a feature, not a bug. Better to disrupt yourself than be disrupted by others.

Manage the interface. The relationship between the elite unit and the legacy organization must be deliberately structured. Technology transfer, talent exchange, and strategic alignment require ongoing attention.

Move faster than comfortable. The organizations being built to replace you are not waiting. The competitive window is shorter than it appears.

Conclusion: From AI Tools to AI-Designed Organizations

The companies that won DTM battles in the 90s didn't just build faster cars. They built organizational structures capable of producing faster cars - elite units with permission to operate differently, connected to but protected from the parent organization.

The companies that will lead their industries in the AI era will not simply adopt AI tools. They will design organizations around AI capabilities, creating structural advantages that tool adoption cannot match.

This is not a technology decision. It is a leadership decision, a governance decision, an organizational design decision.

The question is not whether to adopt AI. The question is whether to transform - and whether you have the strategic courage and organizational imagination to do it before someone else forces the choice upon you.

AI is not a feature upgrade. It is a company redesign.

For leaders looking to build AI literacy without drowning in technical detail, dentro.de/ai offers a 3-week learning path designed for non-technical executives.

The Great Squeeze - Understanding LLM Information Density

Michael Frison — Sat, 20 Dec 2025 00:00:00 +0000

A modern Large Language Model (LLM) is capable of retrieving and connecting information from a massive body of knowledge, yet the resulting model weight is surprisingly small compared to the data it was trained on. This compression is possible because we have moved from an architecture of data storage to one of mathematical representation.

In traditional computing, we rely on Data Persistence. If you want to "know" 10 trillion words, you must store 10 trillion words in a database. LLMs break this 1:1 relationship through a process of high-density compression. We aren't building a digital library; we are training a mathematical representation of that library.

In this article, we will look at how this "Squeeze" works by breaking it down into five parts:

Bits vs. Brains: Why traditional databases hit a "Storage Wall" and how Conceptual Representation provides a way around it.
The Vocabulary Filter: How trillions of raw data points are funneled into a finite set of Tokens.
The 200:1 Ratio: Looking at the math of Llama 3, distilling 15 Trillion "seen" tokens into 70 Billion Parameters.
Intelligence as Loss: Why the "lossy" nature of these models is actually what enables Reasoning and pattern recognition.
The Outcome: How this compression allows us to fit the essence of a global knowledge base into a "Pocket Galaxy."

1. The Core Concept: Bits vs. Brains (The BEFORE)

In traditional computing, we operate under the principle of Data Persistence. If you want a system to "know" a specific fact, you must store it as a discrete entry in a database. To scale this knowledge to encompass a vast body of information - trillions of words of human history, science, and code - you simply add more storage. You build a digital warehouse where every word has a fixed address. This is a 1:1 relationship: more knowledge requires more physical bits.

However, as we move into the scale of the collective human record, we hit the Storage Wall. Storing every fact as a unique, searchable record is not just expensive; it is architecturally inefficient for the type of cross-domain synthesis we expect from modern AI. We don't just need to retrieve data; we need to represent the logic behind it.

This is the shift from "The Warehouse" to "The Mix." Imagine a gigantic mixing console (our LLM) with billions of faders (our Parameters). In this new paradigm, we don't save the books into the console. Instead, we pass the data through the circuitry to find the optimal "position" for every fader. By the time the process is finished, the original text is gone, but the faders are tuned to a specific frequency that represents the patterns of that information. We have successfully traded raw bits for a mathematical brain.

Modern AI systems often combine both: they use the 'Mix' (LLM) for reasoning and a traditional 'Warehouse' (Vector Database/RAG) for facts. The LLM becomes the librarian who understands the logic of the books, while the database ensures the text remains exact.

2. The Input: The Vocabulary Gatekeeper

Before any knowledge can reach the faders, it has to pass through the Vocabulary. This is the first bottleneck of the Squeeze. Think of it as a fixed "Patch Bay" at the front of our console. While the collective human record contains an almost infinite variety of words, characters, and symbols, the LLM only understands a specific, finite list of snippets.

We call these snippets Tokens. A typical modern model might have a Vocabulary of roughly 128,000 tokens. This is the first layer of compression: instead of dealing with the raw, chaotic stream of trillions of characters, the model maps everything it "sees" to this internal list.

This is made possible by sub-word tokenization. The system doesn't necessarily store the word "Information" as a single unit. Instead, it might break it into "In", "form", and "ation". This Lego-like approach allows a relatively small dictionary to represent almost any concept in any language. By the time the data enters the "Inside" of the model, it has already been filtered through this gatekeeper, turning petabytes of raw text into a standardized sequence of numerical IDs that the mixer can actually process.

3. The Math: 15 Trillion vs. 70 Billion (The INSIDE)

To understand the sheer scale of this transition, let's look at the classic Llama 3 family of models, which set the standard for these density ratios. During its training phase, the model was exposed to a corpus of roughly 15 trillion tokens. If you were to store that volume of raw text in a traditional database, you would be looking at approximately 15 to 20 terabytes of data.

In the "Inside" of the Squeeze, we funnel that entire 15-terabyte library through our mixer console. The result is the Llama 3 70B model, which contains exactly 70 billion parameters.

The Squeeze Ratio:

For every single fader on the console, the model has "seen" over 200 different tokens of information.

The Weight Squeeze:

The final model weight is roughly 140 gigabytes.

We have effectively distilled the logic and patterns of 15,000 gigabytes of text into a 140-gigabyte mathematical representation. This is a 100:1 reduction in physical size, but the "Information Squeeze" is even more extreme in the smaller Llama 3 8B model. There, 15 trillion tokens were squeezed into only 8 billion parameters - a ratio of nearly 1875 tokens for every single knob on the console. This extreme "over-training" is why smaller models are increasingly capable of complex reasoning: they have a much higher density of learned experience per parameter.

While Llama 3 was a 'dense' model (using all 70B faders at once), modern 'sparse' models might have 200B faders but only use 10B for any given word. This makes the 'Squeeze' even more complex - we are compressing knowledge not just into faders, but into routing logic that knows which faders to touch.

4. Intelligence is Loss

This massive reduction in size comes with a cost: it is a "lossy" process. Unlike a ZIP file which you can decompress to get back the exact original document, an LLM cannot recreate the 15 terabytes of training data perfectly. In our mixer analogy, we have 70 billion faders but we are trying to represent the patterns of trillions of tokens. There aren't enough faders to record everything exactly.

However, this loss is not a bug; it is the source of intelligence. Because the model cannot "memorize" everything, it is forced to find mathematical short-cuts. It has to learn that "Paris" is often associated with "France" and "Capital" rather than trying to remember every specific sentence that mentions those words.

This is the transition from retrieval to Generalization. By discarding the specific, noisy details of individual data points, the model uncovers the underlying structures of language and logic. We call this Reasoning. The Squeeze forces the model to move beyond being a parrot that repeats facts and transforms it into a system that "understands" the relationships between them.

This architecture also explains the phenomenon of Hallucination. Since the model is a probabilistic reconstruction and not a database, it does not "look up" facts - it generates them based on the tuned positions of its parameters. When the model encounters a gap in its signal density - a rare fact or an obscure connection - it still follows the logic of the "Mix." It produces a result that is grammatically and logically consistent with its training, even if it is factually incorrect. In the Great Squeeze, we trade absolute factual fidelity for the ability to reason across the entire spectrum of human knowledge.

5. The Big Picture (The AFTER)

The result of this operation is a fundamental decoupling of knowledge from raw storage. We have moved from the unmanageable BEFORE state of massive, static datasets to an AFTER state where information is functional rather than just persistent. The library is gone, but the "Mix" is set.

This architectural shift has two primary implications. First, it changes the economics of information access. By compressing a petabyte-scale corpus into a few billion parameters, we move the burden from massive hardware clusters toward more efficient, specialized compute. We are no longer limited by the speed of a database search or the capacity of a physical warehouse.

Second, it confirms that intelligence is a byproduct of efficient representation. The fact that 70 billion faders can represent 15 trillion data points shows that the collective human record is not just a pile of facts - it is a system of patterns. By finding the "Squeeze," we haven't just saved space - we have created a mathematical map of human logic. This represents a pivot in computing: we are moving from machines that store the world to machines that represent its rules.

Developing 3-Week AI Curriculum

Michael Frison — Sun, 30 Nov 2025 00:00:00 +0000

Developing a Three-Week AI Curriculum as a Personal Side Project

About half a year ago I launched dentro.de/ai with a simple idea in mind: provide clear, simplified explanations of modern AI in one place: "Inside AI".

In the background there was always a bigger plan. I wanted all those loose pieces to eventually line up as a complete scaleable learning path. Not just a glossary here, a visualizer there, a blog post over there, but something you could actually follow from start to finish.

That missing piece is finally here: a 3 Week Learning Curriculum that ties everything together and walks you through the AI Black Box from the outside in.

This post is a bit of a behind the scenes story of how and why I built it, what ended up in the course, and how you might use it, whether for yourself or to teach others.

The problem that kept poking me

Around me, more and more people were "using AI", without really knowing what it is. Only to be puzzled, when it seemed not to perform well. I have the strong believe that a) it is easy to gain that AI knowledge and b) this knowledge is a huge enabler to better use this new technology.

Within our work environments we now are tasked not only to use AI, but to build workflows, educate business partners, evaluate risks and prepare for the future. All this by not being an engineer - and no desire to become one. We don't need to implement transformers from scratch. We need to reason about what these systems can and cannot do.

I went through that journey myself and was puzzled that easy-to-consume education is rare for AI. Which is why is started outlining it myself:

one article about how LLMs work
an analogy about the AI lifecycle
a glossary entry here, a visualization there
a few good videos and visualizations

It helped teaching too, but only if I sat next to them and arranged the pieces in the right order.

At some point I realised I was rebuilding the same mental map over and over again. That is when the idea of a structured curriculum stopped being "nice to have" and became the actual goal.

The mental model that everything hangs on

The anchor for the whole project is one simple model:

BEFORE → INSIDE → AFTER the AI Black Box

BEFORE covers setup and training: data, architecture, tokenisation, model lifecycle
INSIDE covers how the finished model functions: parameters, weights, embeddings, attention, layers, probabilities
AFTER covers what happens when you use it: prompts, context, tools, workflows, evaluation

Once that frame was in place, all the separate elements on the site suddenly had a clear place to live. The 3 week course is basically this model stretched out in time and filled with concrete reading, watching and doing.

What the 3 week curriculum looks like

The curriculum is called "How to Learn AI in 3 Weeks". It is written for people who are serious about understanding modern AI at a high level, but who do not necessarily want to code or push matrices around.

Each week focuses on one phase of the Black Box and has three flavours: Overview, Learn, Practice.

Week 1: BEFORE - where models come from

Week 1 is about everything that exists before you type a single prompt.

You look at:

how text becomes tokens and token IDs
how data, scale and training define the AI Model as product
the lifecycle of a model from early research ideas to large training runs

You read the AI model lifecycle article, browse the AI timeline, and poke around with tools like Tiktokenizer to see sentences or numbers chopped into tokens.

By the end of the week, "AI" looks a lot less like magic and more like an engineered product with a long supply chain.

Week 2: INSIDE - the model as a mathematical function

Week 2 is about peeking inside the Black Box. Orignially this was my main driver years ago: the desire to understand what exactly is happening in the Black Box and why. It is a fascinating area and people are rightfully puzzled as to why this works so well.

Focus in the 2nd week is on:

how a trained model is a fixed mathematical function - this is VERY important to get across. People still discuss with LLMs thinking they are now teaching them.
why everything is cut in tokens and vectors rather than words and sentences - and how this has a big influence on the functionality of LLMs.
how the model always outputs a probability distribution over possible next tokens - one after the other.

The material mixes the long form blog post on LLMs with high signal videos (by legends 3Blue1Brown and Andrej Karpathy) and visualizers where you can literally watch probabilities flow through a tiny model.

The goal is not to memorise formulas, but to get the basic idea of what happens when sending a prompt to the model.

Week 3: AFTER - how models behave when you use them

Week 3 looks at the output of the model and clarifies concepts like inference and context window, but also haluzinations.

You explore:

why the same prompt can produce different answers
why different models behave differently on the same task
how prompting structure and context help or hurt
what simple evaluations and benchmarks look like in practice

This part is deliberately experimental. You try classic failure prompts, compare models and temperatures, and build a tiny evaluation set for your own domain.

The point is to develop a feel for strengths, blind spots and failure modes. Impressive demos are one thing, but using the tools as solid assistants is another.

Stitching the site into one coherent thing

The curriculum is not a separate product sitting next to the rest of dentro.de/ai. It is more like a guided tour that walks through all the existing content in a structured sequence. Visualizations and Glossary are helpful, but also the 3 main articles I have composed so far with teaching in mind:

The sections Industry Landscape and AI News are obviously helpful when going further.

The site started as a collection of these pieces. The curriculum is what makes them feel like a single, purposeful resource.

It also works backwards: writing the course forced me to tighten, rename, and sometimes rewrite the underlying material so that it fits the mental model cleanly. It helped me too to connect remaining loose ends.

Who I wrote this for

I had three kinds of people in mind while building this.

People who already use AI tools a bit, but are keen to understand how they function - high level - under the hood.
People who sit between technical and non technical worlds and have to explain AI decisions in human terms.
People who do not want to chase scattered links and need one place they can consult or refer others to.

It is not designed for:

builders or researchers
people who want a coding bootcamp
anyone looking for a bag of "magic prompts"

If you work with AI models day in day out you will probably find the level too gentle. If you are trying to get from "I am lost" to "It finally clicked", you are at the right place.

From curriculum to lecture material

One side effect of finishing this is that it is now much easier to explain the topic live.

Because the curriculum has a clear spine and a set of examples for each phase, it translates almost directly into:

a short "AI in one hour" talk
a half day workshop using some of the experiments
a three part lecture series that follows the weekly structure

I designed it so that, with a bit of preparation, other people could give those sessions too. Everything is on the site and referenced explicitly, so you do not have to dig through personal notes to reconstruct the argument.

If you work in a company or teach and want a structured way to introduce modern AI without turning everyone into engineers, I hope this gives you a starting point.

Where it stands now

Is the curriculum finished and perfect? No :)

What I can say is that it now feels legit and good enough that I am comfortable standing behind it as "a solid starting point".

Future me will almost certainly rearrange things, add better examples, and fix what time and progress in the field make outdated. For now, I am mostly satisfied that the original plan worked: the loose ends of dentro.de/ai have been stitched into something that feels like a complete path rather than a pile of resources.

If you do decide to go through it, or use it with a group, I would be very interested in what helped, what confused, and what is missing. That feedback will probably shape the next half year of evening work.

In the meantime, if someone asks you "How should I learn how this AI stuff actually works", you are welcome to send them here:

How to Learn AI in 3 Weeks

Hopefully it saves you a few explanations and starts a few good ones.

Understanding Open Source in AI Models

Michael Frison — Tue, 15 Jul 2025 00:00:00 +0000

Analogy to understand Open Source in generative AI Models

We often hear the terms "Open Source" and "Open Weights" in the world of AI models - but what is the difference? Traditional software uses open source for full transparency and reproducibility. AI is not like traditional software, because the "brain" - our fully trained model - is a compressed representation of the huge amount of training data.

The good news is we can use our Mental Model BEFORE → INSIDE → AFTER the AI Black Box again - but this time to explain Open Source vs. Open Weights in AI:

Let's dive deeper and explain Open Source vs Open Weights in the context of AI models - with the help a car analogy ( again!) for clarity and to help making informed decisions. For terms like Parameters (the Model Weights in "Open Weights") or Training, see the AI Glossary.

Open Source in Traditional Software

Open source has transformed software development - examples include Linux, Python, the Apache web server and many others:

Full access and transparency. The complete source code acts like a recipe. Users can view, modify, and share changes.
Community collaboration. Developers contribute fixes and improvements.
Reproducibility. The code and instructions allow rebuilding from scratch.
Licenses. Generous options like MIT or GPL support usage, modification, and distribution - including commercial implementations.

This approach lowers costs, speeds innovation and allows full transparency. AI models differ in key ways.

Open Source Applied to AI

AI models involve more than code. They result from processes like architecture design, data curation, and very compute hungry large scale training. Also see the how LLMs work post.

Components of an AI model, which you would expect all for truly open source:

Architecture. The structure, such as transformer-based designs.
Training code. Scripts for the training process.
Training data. Large datasets used in training.
Model weights. Learned parameters after training.
Inference code. Tools to run the model.

Open Weights vs Open Source

Many AI models labeled as open source are actually only open weights. These provide weights, architecture, and inference code, while keeping training data and training processes hidden. Users can run, fine-tune, and deploy the model with this setup - but they cannot recreate it from scratch.

Customization becomes easier, and community contributions grow.

No insight into biases or data sources means risks like ethical issues remain unknown.

True open source models share all elements for full reproducibility and transparency allows audits for safety, which expands innovation.

In mid-2025 all major organisations (except Anthropic) released Open Weights models.

To get an overview - and also a ranking - the LMArena is a good resource: they list the model licence and Open Weights models are typically released under a differenct licence than "Proprietary".

Car Analogy for Clarity

The car analogy illustrates the differences and highlights levels of control in AI:
From Closed Source to Open Weights to truly Open Source.

Closed Source:

A taxi ride. Users decide direction and route. The engine under the hood stays unknown.

Open Weights:

A purchased car. Users know engine details and specs. Build processes and component sources remain secret.

Open Source:

A self-built kit car, such as a Lotus 7 replica. All parts and specs arrive. Users can improve, change, and build from scratch.

Examples from 2025

The AI landscape is highly dynamic and constantly updated. The examples give an indication, but in reality there are many thousands more additional models.

Closed Source:

OpenAI ChatGPT 5
Anthropic Claude Opus 4.1
Google Gemini 2.5 Pro
xAI Grok 3

Open Weights:

Meta Llama family
Google Gemma family
xAI Grok 2.5
DeepSeek models like R1 or V3.1
selected Mistral AI models

Open Source:

Apertus LLM from Swiss AI
EleutherAI models
BigScience Bloom
TII/UAE Facon-40B

The Open Source Initiative serves as the primary authority in establishing and reviewing AI standards within the open-source community.

Business Implications

These differences guide AI choices and support strategic decisions.

   Innovation and savings. Open weights allow customization without full development costs.
   Risk control. Partial openness may hide biases or compliance problems.
   Ethics and trust - to enable fairness checks for areas like healthcare or government.
   Market trends. Open models already approach closed-source performance in benchmarks.

In Summary

Often labled as Open Source is really only Open Weights and does not share training data and methods. While Open Weight models are powerful and econimical, they lack transparency and might surface unwanted biases.

How AI Large Language Models (LLM) Work

Michael Frison — Fri, 25 Apr 2025 00:00:00 +0000

How Large Language Models like ChatGPT Work

You're likely interacting with AI (Artificial Intelligence) more and more, perhaps using tools like ChatGPT for drafting emails, summarizing reports, or even brainstorming ideas. These Large Language Models (LLMs) have become remarkably capable, but how do they actually work? What's happening behind the screen when you type a prompt and receive a well informed response?

This post aims to provide a high-level, conceptual understanding of the core mechanics behind LLMs. It's designed for the tech-interested who want to grasp the fundamentals without needing a deep dive into complex mathematics or code. Think of it as looking under the hood to see the main components, not rebuilding the engine. We'll explore how these models process language, how they "learn," and what's actually happening during that near-instantaneous generation of text.

The Building Blocks: Turning Words into Numbers

At their core, computers operate on numbers - not the usual complexities of human language. The first step for an LLM is to convert text into a format it can understand: numbers. This involves two key concepts Vocabulary and Tokenization.

An LLM has a predefined, fixed dictionary called a Vocabulary. This isn't just a list of words; it includes common words, punctuation, and often parts of less common words (sub-words). The size varies - smaller models might have 30k-50k "tokens" in their vocabulary, while large, multilingual models can exceed 100k. (See an example here.)

Tokenization is the process of breaking down your input text (the prompt) into these predefined tokens from the vocabulary. For example, the word "unbelievably" might be split into tokens like "un", "believe", "ably". Each token in the vocabulary has a unique numerical ID. So, your sentence becomes a sequence of numbers that the model can mathematically process.

You might wonder how the model handles words with multiple meanings, like 'bank' (river side) versus 'bank' (financial institution). In most modern LLMs, the Tokenization process itself is primarily based on the text's characters and frequency statistics, not its meaning. Therefore, the word string 'bank' would typically be assigned the same initial token ID (or sequence of sub-word IDs) regardless of its intended meaning in the sentence. The crucial step happens inside the neural network: through mechanisms like attention, the model analyzes the surrounding Context. This allows it to generate vastly different internal representations (called contextual embeddings) for that 'bank' token ID depending on whether nearby words relate to finance or geography. The model learns this ability to interpret context during its massive Training phase.

The Core Task: Predicting What Comes Next

Surprisingly, the fundamental task of most LLMs is simple to state: predicting the next token. Based on the sequence of tokens it has seen so far (the Context), the model calculates the probability for every single token in its vast vocabulary of being the next one in the sequence.

Think of it like an incredibly sophisticated auto-complete feature. It considers the context – the words and sub-words that came before – to make the most statistically likely prediction for what should follow. Complex abilities like answering questions, summarizing text, or translating languages emerge from repeatedly performing this next-token prediction, stringing together the most probable sequence of tokens that fulfill the prompt's request.

Inside the Model: Layers, Weights, and Fixed Knowledge

So, how does the model make these predictions? It uses a complex structure inspired by the human brain: an artificial neural network with many layers. Input tokens (as numbers) enter the network and are processed through these layers. Each layer performs mathematical transformations on the data passed from the previous one, allowing the model to analyze the sequence and identify increasingly complex patterns and relationships between tokens – even those far apart in the text. This ability to weigh the importance of different parts of the context is crucial for understanding meaning and generating relevant text.

The "intelligence" or capability of the model resides in its parameters, which are primarily Weights and Biases. These are millions, often billions, of numerical values associated with the connections between the artificial neurons in the layers. They act like tuning knobs, determining how information flows and is transformed throughout the network. When you hear a model has "7 billion parameters" or 7b - it's mostly these weights and biases.

Crucially, after the initial training phase (which we'll discuss next), these weights and biases are fixed! The trained LLM, on its own, is like a final, incredibly complex mathematical function. Its core knowledge is static and encoded within these parameters. During standard use (called inference), the model itself does not learn new information from your prompts. However, it's important to know that this base model can be part of a larger system that uses techniques like Retrieval-Augmented Generation (RAG) to pull in live information, giving the appearance of real-time learning.

Learning the Patterns: The Immense Task of Training

How do these billions of parameters get their values? Through a massive and compute-intensive Training process. The model is fed enormous amounts of text data – potentially the internet, books, articles, code, and more, known as Datasets.

During training, the model is repeatedly given sequences of text and asked to predict the next token. Its prediction is compared to the actual next token in the training data. An "error" value is calculated based on the difference. Then, using sophisticated optimization algorithms, the model's weights and biases are minutely adjusted to slightly reduce this error. This cycle of predicting, comparing, and adjusting is repeated trillions of times across the vast dataset.

This training process is computationally immense, requiring specialized hardware (like thousands of GPUs or TPUs) running continuously for weeks or months. It's a major reason why developing foundational LLMs is incredibly resource-intensive and expensive. (For an analogy of the complete lifecycle see How AI Models work, explained with Cars.)

Through this intensive process, the model doesn't "understand" language in a human-like, conscious way. Instead, it builds a powerful internal model of the statistical relationships in the data. This goes beyond simple patterns; it learns to represent grammar, facts, reasoning paths, and different styles as complex mathematical transformations, all encoded within the final values of its weights and biases. Critically, the patterns it learns directly reflect the data it was trained on. If the data contains bias, inaccuracies, or predominantly certain viewpoints, the model will inevitably learn and potentially replicate them in its outputs.

Putting It All Together: From Prompt to Generated Text (Inference)

This is how the journey from prompt to model response (Inference) looks like:

Prompt: You provide your input text.
Tokenize: The text is broken down into tokens with numerical IDs.
Initial Context: These tokens form the starting context sequence.
Network Pass: The sequence is fed into the neural network with its fixed weights and biases.
Predict Probabilities: The model calculates the probability of every token in its vocabulary being the next one.
Select Token: A token is chosen from the probability distribution. While simply picking the single most likely token (greedy decoding) is an option, it often leads to repetitive text. Instead, a sampling strategy is used. A controlled amount of randomness is introduced (often adjusted by a setting called Temperature), which allows less probable, but still plausible, tokens to be selected. This is key to the model's ability to generate creative and diverse outputs.
Append to Context: The chosen token is added to the end of the current context sequence.
Repeat: This updated, longer context sequence is fed back into the model (Step 4) to predict the next token. This loop continues, generating the response one token at a time.
Stop: The process stops when the model generates a special "end-of-sequence" token, reaches a predefined maximum length, or fulfills another stopping condition. Models have a Maximum Context Length (Context Window) – they can only effectively "remember" or consider a certain number of recent tokens when making predictions.
De-Tokenize: The sequence of generated numerical token IDs is converted back into human-readable words and sentences.

Summary: Sophisticated Patterns, Not True Understanding

Large Language Models like ChatGPT are fascinating engineering. They operate by tokenizing language, processing it through layered networks governed by billions of pre-learned weights and biases, and predict the next token in a sequence based on context. Their apparent knowledge comes from statistically learning patterns in vast amounts of text data during an intensive, costly training phase, after which their core parameters are fixed.

Understanding these basics helps appreciate both the power and the limitations of these AI tools. They are incredibly sophisticated pattern-matching and generation engines, excellent at manipulating language based on the data they've seen. They are not, however, thinking or understanding entities in the human sense. Keeping this conceptual framework in mind can help users leverage these tools effectively while maintaining realistic expectations about their capabilities and potential pitfalls, like inherited biases.

Explain AI Lifecycle with Car Analogy

Michael Frison — Tue, 08 Apr 2025 00:00:00 +0000

AI Model Lifecycle - Analogy Explained with Cars

The process of creating, deploying, and using Large Language Models (LLMs) involves numerous intricate steps. Given the complexity in AI development, drawing parallels to more familiar industrial processes can aid understanding. This guide presents an analogy, comparing each stage of the LLM lifecycle to the established process of designing, building, distributing, and using a car.

While AI models and automobiles are fundamentally different, examining their lifecycles side-by-side offers insights into the structure and challenges of LLM development. A key contrast arises during the core "production" phase: car manufacturing centers on the physical assembly of components, whereas LLM creation hinges on a vast computational training process to embed knowledge from data.

We are using our proven mental model BEFORE → INSIDE → AFTER the AI Black Box:

Stages 1-5 → BEFORE
Stage 6 → INSIDE
Stages 7-9 → AFTER

The comparison below demystifies the LLM journey:

BEFORE the AI Black Box

1. Architecture Design & Research

- Define the LLM's goals (chat, code generation, image analysis, etc.).
- Select the target model size (influences capability and resource needs).
- Design the core neural network structure (e.g., Transformer architecture, number of layers).
- Choose the fundamental learning algorithms.
Car Analogy: Conceptualization & Engineering
- Define purpose (sedan, truck), target market.
- Create detailed CAD designs (chassis, body).
- Simulate performance.
- Select core technologies (engine type).

2. Data Curation & Preprocessing

- Gather massive datasets (text, code, images) - the raw information the LLM learns from.
- Clean, filter, and format this data for training effectiveness.
- Decide the mix of different data sources to shape the LLM's knowledge base.
Car Analogy: Material Sourcing & Specification
- Select specific materials (steel, plastic).
- Define quality standards for parts.
- Source components (engines, tires).

3. Training, Tuning & Alignment

- Run initial, smaller-scale training experiments to test approaches.
- Tune technical settings (hyperparameters) for optimal learning.
- Perform alignment (e.g., using human feedback - RLHF) to make the LLM safer, more helpful, and better at following instructions.
Car Analogy: Prototype Building, Testing & Calibration
- Build test vehicles (prototypes).
- Conduct extensive tests (road, crash, emissions).
- Tune engine software (ECU), adjust suspension based on test data.

4. Infrastructure & Code Finalization

- Configure large clusters of powerful GPUs or specialized AI chips (TPUs).
- Finalize the optimized software code that will manage the training process.
- Set up systems to monitor the complex training run.
Car Analogy: Factory Tooling & Manufacturing Process Design
- Set up the factory assembly lines.
- Program the manufacturing robots.
- Define quality control checkpoints.

5. Large-Scale Model Training (Core Creation)

- Execute the main training process, feeding the entire curated dataset through the model architecture using the prepared infrastructure and code.
- This is the primary learning phase where the LLM's internal parameters are iteratively adjusted based on patterns identified in the vast amounts of data, crystallizing its knowledge and capabilities.
- A computationally intensive step requiring significant time (weeks/months) and energy.
Car Analogy: Mass Manufacturing (Assembly Line)
- Run the production lines, systematically bringing together sourced components and sub-assemblies according to the design.
- This is the primary physical construction phase where the car is assembled piece by piece into a functional vehicle.
- Relies on defined processes, robotics, and human labor to build cars efficiently at scale.

INSIDE the AI Black Box

6. Trained Model Weights (Parameters)

- The result of training: the final set of numerical parameters (often called model weights). These numbers are the trained LLM's core intelligence.
- What are Parameters? Think of parameters like the potential "information capacity" of the model. More parameters (e.g., 7 billion vs. 70 billion) mean the model has more capacity to store complex patterns and knowledge learned from the data. It is roughly analogous to a car having more seats or a larger engine - it indicates a greater potential capacity or power, though not guaranteeing better performance in all situations. This parameter count is a key differentiator between LLM sizes.
Car Analogy: Finished Car (Off the Production Line)
- The physical vehicle, fully assembled.
- Calibrated and ready for distribution.
- The number of seats or engine size indicates its capacity/power category.

AFTER the AI Black Box

7. Deployment & Access Provisioning

- Package the model weights and necessary software code.
- Make the LLM accessible via the company's digital channels: API portals, websites (for direct use or downloads), or developer platforms (SDKs).
- This is how the finished LLM "product" reaches its users.
Car Analogy: Logistics, Dealer Network, Sales & Marketing
- Ship finished cars to established dealerships.
- Utilize the sales and service network infrastructure.
- Market and sell the vehicles to customers through these channels.

8. Inference Engine & Interaction

- The software environment that loads the model weights (parameters).
- It handles Inference: the process of using the trained model to generate output based on new input.
- Users provide this input as a Prompt: the specific text, question, or instruction given to the LLM.
- The engine manages the computation needed for the LLM to respond to the prompt.
Car Analogy: Operational Systems & Controls (ECU, Pedals, Wheel)
- The car's computer (ECU) interpreting sensor data and driver input.
- The physical controls (steering wheel, pedals) used by the driver to direct the car.

9. Ongoing Model Usage (Inference, Not Live Training)

- The end-user repeatedly interacts with the LLM by providing prompts.
- Each interaction triggers the inference process: running the user's input through the fixed, pre-trained model weights (parameters) to generate a response.
- Crucially, this standard interaction does not typically retrain or modify the underlying LLM in real-time. It is executing a complex mathematical function on a static set of parameters, not engaging in a "live" learning conversation. (Note: Interaction data might be collected separately by the provider for future model improvements, but that's distinct from the immediate inference.)
Car Analogy: Driving the Car
- The driver continuously uses the controls (like the steering wheel, pedals) to operate the car within its designed capabilities.
- Adjustments like changing the seat position, turning on the heater, or selecting a radio station are user inputs/settings within the car's fixed system - analogous to providing different prompts.
- Ignoring wear and tear, the act of driving and making these adjustments does not fundamentally change the car's engine design, chassis, or core engineering. The user is operating a defined, isolated product.