The Philosophy of Coding Architecture: What If the Car's Wheel Became the Protagonist?

What if the wheel of a car became the protagonist?

1. Where the problem begins: rethinking the relationship between the whole and its parts

When a designer or developer builds a service (say, a Q&A platform), they typically think in terms of the individual pieces that make it up — the engine, the logic, the UI elements, and so on. In this way of thinking, the overarching purpose, "the service," almost always comes first.

For example,

the wheel is a crucial component that lets a car move,

yet it gets valued only as one part that the "car" happens to need.

But as technology advances, this structure begins to show its limits, and may even become the problem itself.

Because the small components we build may, over time, take on new meanings far beyond their originally intended scope and come to play independent, self-directed roles.

The concept that captures this precisely is what we might call "the paradox of the part overtaking the whole" — the Wheel Paradox.

It describes how we first build a component to serve an "automated service,"

but in reality that component comes to assert its own intrinsic value

and ends up wielding greater influence than the system it was built for.

Here is one real-world example:

- Initial purpose: a simple NLP parsing module for generating answers to questions.

- Later shift: by collecting customer feedback data and analyzing behavioral patterns, it evolved into the core engine of a real-time decision-support system.

- Final state: it now handles insight generation and authorization decisions across every data process in the organization, taking on a central role in company-wide operations.

This is the result of moving beyond the narrow focus of a "Q&A" feature; what matters is that the module itself became a core element operating across a far more complex and expansive domain.

2. What is a welded wheel?

It refers to a situation where the "wheel" is "fused to the car's framework, unable to detach or be used freely." This can be expressed clearly in code design as well, and it generally refers to cases where something is tightly coupled to a specific environment or platform.

For example, code of the following form is a classic case of the problem:

```python
def process_user_query():
s3_client = boto3.client('s3')
bucket_name = "user-data-bucket"
response = s3_client.get_object(Bucket=bucket_name, Key="query.json")
```

This code directly references AWS S3 cloud storage and the `boto3` SDK,

so any time you move it to another cloud (such as Azure or GCP),

or to a local file system, you have to rebuild the entire implementation.

In other words, a design that fails to remove external dependencies ultimately fails on both technical flexibility and reusability.

Such a state is judged to be bad architecture from an engineering standpoint, and economically it becomes a source of wasted capital.

Because if even the smallest component fails and then needs to be changed, you end up having to redevelop the entire service.

That is, if we build a reasoning engine and it only connects to AWS,

then the moment we try to apply that engine to an airplane or install it on a standalone server inside a factory, a new configuration is inevitably required — and this is precisely the "welded wheel" that obstructs sustainable growth.

So the important question is this:

We need to confirm whether each module we build can still operate on its own and create value in a variety of environments even after the car or the service is gone — so how do we set up those conditions?

3. What is true modularization? → Independent survival

It demands a deeper understanding than merely "splitting up code" inside the software. True modularization has to go beyond logical separation; it must be judged by how much intrinsic value the component holds in and of itself.

To describe this concept quantitatively, we introduce the following three key requirements.

1. Self-contained executability

- It can take input data, process it, and produce output without any external API calls.

2. Multi-format support

- It can recognize and convert data delivered in a wide range of formats such as JSON, CSV, Parquet, and Protobuf.

3. Built-in error-recovery mechanisms

- Even under network failures or resource overload, it must be able to save and restore the intermediate state of its work.

4. Timeout and resource-monitoring systems

- It monitors things like CPU utilization and memory leaks in real time to prevent instability.

These criteria are tied not to specific lines of code but to a design philosophy that asks, "What is my purpose, and where can I operate?" — and it is through this that every component can survive in real-world operation.

For instance, consider a reasoning-engine component designed as follows:

- At first: it parses a sentence and offers an answer.

- Later shift: it identifies customer behavioral patterns and, on that basis, classifies the type of problem.

- Final role: it functions as the central technology of a company-wide intelligence platform, ensuring transparency in organizational decision-making and proposing alternatives.

This was just a small function originally built for Q&A,

but it shows how, over time, it naturally acquired new meaning.

In other words, the moment the wheel draws more attention than the car body

is the moment this design truly shines.

4. How MAEUM AI OS implements this — real-world application

In MAEUM AI OS, we take this architectural philosophy as a foundational principle,

and we aim to follow the design norms below.

1. For our programming language, we set Python as the default stack.

- The reason is that it has an outstanding ecosystem for NLP and machine learning.

It integrates directly with Hugging Face, LangChain, LlamaIndex, and the like,

and developers can pick it up easily.

It also lets us efficiently build simple yet modular training/inference cycles.

2. Enforce a dependency-minimization policy

- Avoid connecting directly to external services (such as AWS S3) or platform SDKs,

and design it so that it can operate as long as it simply receives input data.

Each component must define a clear interface and be able to run independently.

3. Standardize the input/output interface

Regardless of the format, the work must be carried out using the `read_input()` and `write_output()`

methods. For example, you would write code like the following:

```python
class ReasonerEngine:
def __init__(self):
self.memory = {} # internal state storage (no external dependency)

def analyze(self, input_text: str) -> dict[str, any]:
return {
"intent": detect_intent(input_text),
"entities": extract_entities(input_text),
"confidence_score": compute_confidence()
}

def save_state(self, state_data: dict):
pass

def load_state(self, state_file_path: str):
pass
```

Since all logic is passed as strings or dictionaries,

it can be reused across various systems and remains insensitive to changes in environment.

4. Ensure the ability to operate independently

- Even if the entire car (the service) disappears,

the reasoning engine or routing module must still run inside a factory or perform flawlessly aboard an airplane.

5. Include error-recovery capabilities

- It must be possible to recover after a failure, and we need a scheme for keeping intermediate results in a file or a temporary database.

5. Evaluating alternatives — the limits of other architectures

1. Whole-service-centric design

This is the case where, from the very start, all components are bound together in tight coupling in the pursuit of achieving the "overall purpose."

This approach gives rise to the following problems.

- Future role shifts are unpredictable → you cannot know in advance at what moment a particular component will come to be responsible for core outcomes.

- Refactoring is hard → because the small pieces are fixed into the framework, separating or porting them is difficult.

- It induces economic waste → there is a risk that investment in an individual part ultimately leads to the failure of the entire structure.

2. Using high-performance languages (such as Rust or Go)

Rust and Go offer excellent processing efficiency,

but they come with the following constraints when it comes to natural-language understanding and applying machine learning.

- The data type-conversion process is not simplified, making them unsuitable for real-time insight-generation work.

- After training an ML model, you still need to integrate with a Python environment in order to use the weights, vectors, and so on directly.

- Because there is a great deal of interaction within the pipeline, maintainability suffers.

In the end, for these reasons, we conclude that flexibility matters more than performance.

In other words, being in a state that can operate in any environment

and able to create meaningful value on its own — that is the truly important goal.

6. Final summary and introducing the meta-pattern

Lee's philosophy of "the moment the wheel becomes the protagonist"

is not about software design as such; it poses the question of how a system itself should be made to change and evolve

so that it comes to possess a life of its own.

At first we thought of them as tools for a "service,"

but in reality, over time, each component we build

can come to have its own standards and value and operate independently.

We can therefore state it clearly as follows.

Every software component must survive not by its initial purpose,

but by the value inherent in itself.

Whatever it is and wherever it is used,

it must be able to run inside a factory without a car,

and it must work without issue even when mounted on an airplane.

On this basis, MAEUM AI OS puts the following norms into practice:

1. Minimize external dependencies

2. Ensure the ability to run independently

3. Support diverse formats and include error-recovery mechanisms

4. Keep a simple, interface-centric design throughout data processing

These carry an influence that goes beyond just one way of developing a platform.

Innovation from here on will unfold in ever more complex and multilayered forms.

No matter how focused a given service or platform is on achieving a specific purpose,

the small algorithm hidden inside it —

if it has the ability to learn or to judge —

should be made to grow on its own and take on a core role.

The last thing I want to say is this:

"We should be developing code not for the sake of a service,

but as tools that change the world and survive."

The fact that the wheel has surpassed the car body

can be proof that our technology is truly "alive,"

and from that very moment, we begin to pursue better architecture.

— This is the deeply essential design philosophy that MAEUM AI proposes.