DEV Community: joygram

AI Lost in the Fragmented IDL Pile: Building a Single Context Hub with 'Unified AST'

joygram — Wed, 01 Apr 2026 05:14:15 +0000

In the previous article, we discussed the importance of semantic modeling to specify the identity of data and prevent hallucinations in AI agents (Cursor, Windsurf, etc.) or MCP protocols. However, when we try to apply this in practice, we hit the largest and coldest wall of reality: Fragmented Legacy.

"The backend team uses Thrift, while the client uses old code in Protobuf. Plus, design data is scattered in Excel. When we ask an AI agent to write the entire system code, it mixes these three and makes a mess. Do we have to throw everything away and rewrite with a new standard?"

Semantic modeling design started from this desperate question. Instead of breaking everything and rebuilding, an architecture was adopted: the Unified AST (Unified Abstract Syntax Tree) Hub, where all these fragmented schemas gather into one giant knowledge graph.

1. The Tragedy of Migration: AI Cannot Bridge Fragmented Contexts

Many development teams attempt to migrate with the thought, "Let's move to a better IDL standard all at once," but fail. The reason isn't a lack of human technical skill, but the impossibility of simultaneous transition across systems.

AI agents also get lost in this swamp of fragmentation.

Disconnected Metadata: When modifying a server packet, the AI cannot simultaneously attend to the validation rules of the Excel data associated with that packet.
Failure in Context Switching: After reading Thrift, when the AI generates a Protobuf structure, it misses subtle differences in field types (Optional vs. Required), creating fatal bugs.

What the AI needs isn't just access to the code. It needs a Single Context Hub that proves all these scattered pieces of data actually point to the same business logic.

2. The Solution: A Semantic Dialect Engine Based on 'Unified AST'

To solve this fragmentation, a compiler was designed to read different IDLs (Protobuf, Thrift, etc.) with independent parsers and internally merge these disparate languages into a common Unified AST.

① Non-Destructive Hybrid Co-existence

There's no need to abandon legacy code for the AI era. The semantic engine encapsulates existing .proto or .thrift files as safe External Dialects.

// ai_context.deuk
// 1. Import existing Protobuf files as-is (absolutely NO modifications)
include "legacy/item_base.proto"

// 2. Wrap legacy types in a 'meta-cognitive intent' shared by humans and AI
table<item_base::Item> = { key: "item_id" }

Thanks to this design, a team can maintain their existing infrastructure with 0.1% disruption while instantly providing the AI agent with a firm context: "The Item message in Protobuf is actually the baseline design information (Table) coming from Excel."

② Context Resolver

This is more than simple text parsing. The context resolver lifts all characteristics of the base language—such as Protobuf's field numbering system or Thrift's Optional attributes—into the Unified AST without losing them. Types promoted to the Unified AST in this way gain a perfectly equal "status."

3. Architecture Diagram: A Single Source of Truth (SSOT) for AI

The Unified AST design passes fragmented formats through a single intelligent hub.

   [Legacy & New Sources]          [Semantic Hub]             [AI & Output Code]

   legacy.proto (Protobuf)  ----+                            +-- C# (Unity Client)
                                |                            |
   legacy.thrift (Thrift)   ----+--> [ Unified AST ] --------+-- TypeScript (Web)
                                |       (Engine)             |
   new_logic.deuk (Schema)  ----+                            +-- C++ (Server)
                                                             |
                                                             +-- Agent/MCP Rule Sets

Now, a single hub pierces through all areas. When a server packet is modified, not only is the client model updated synchronously, but the validation rules for Excel data are also connected. To AI coding assistants (Cursor, Copilot, etc.), what is given as context is not fragmented .proto files and Excel spreadsheets, but a perfectly refined Single Source of Truth (SSOT).

Conclusion: Architecture Reduces AI's Cognitive Load

The Unified AST architecture was not born simply to create a "pretty IDL."
It is an extreme engineering response to the question: "How can we prevent humans and AIs from falling into the swamp of fragmented legacy systems and allow them to control the entire system on a single knowledge graph?"

By unifying system fragmentation and opening a clear path for the machine, human developers can finally focus solely on the essence of the business. That is the greatest value proven by this hybrid architecture.

Continues in the next article:

[Why AI Servers Die from OOM: Designing a Zero-Allocation Protocol] explores the technical reality of how data passed through this Unified AST is transmitted over the wire at hyper-speed—without wasting a single byte of memory allocation at runtime.

Project DeukPack

This article series is based on the design notes of DeukPack, an open-source infrastructure created to prevent data fragmentation.

GitHub: DeukPack OSS

Designing a Control Plane for AI Agents: The Power of Schemas with 'Intent'

joygram — Mon, 30 Mar 2026 06:54:41 +0000

This article explores an architectural challenge at the threshold of the MCP (Model Context Protocol) era: "How can AI agents grasp and handle our data without misunderstanding its intent?"

In the past, merely using formats like Protobuf or JSON to exchange data between clients and servers was sufficient. Human developers could read the code and infer the context. However, the entity reading code and suggesting business logic is rapidly shifting to AI agents like GitHub Copilot and Cursor.

This introduces a critical problem.

"I told the AI agent to write the shop purchase logic (Request: Use this data model to write the shop purchase logic), but the agent indiscriminately mixed client-only UI data with backend-only database tables."

1. The Cause of Failure: Data Lacks 'Identity'

In most traditional IDL (Interface Definition Language) environments, all objects are treated as equal structs or messages.

Fixed design data managed by designers in Excel (e.g., item specs)
Transactional data exchanged between server and DB (e.g., current gold balance)
Temporary rendering data for the client UI

Under the old paradigm, these three types of data show no visual distinction in code. Human engineers rely on names or documentation to understand the context, but to an AI agent, they are all just "identical byte blobs containing a few fields." Naturally, because their structures are identical, the AI mixes them up and ruins the logic.

2. The Solution: Structures Capable of 'Meta-cognition'

Traditional keywords like struct or message are faithful in defining the technical form of data (arrays, integers, strings), but they fail to capture the intent behind how that data is used within the system.

Instead of just introducing new keywords, a "meta-cognitive" approach is needed—one where, even if the underlying data structure remains identical, semantic encapsulation minimizes cognitive errors for both humans and AI. For example, redefining a standard struct as a record or table based on its nature implies its "principles of use" at the syntax level.

// record: Technically a struct, but informs humans and AI that it is an 'immutable value state' shared across the system.
record Vector3 {
  1> float x
  2> float y
  3> float z
}

// entity: Specifies that it's not just a data clump, but a 'living actor' with a unique ID flowing through system swarms.
entity PlayerContext {
  1> string session_id = ""
  2> int32 level = 1
}

// table: Defines 'design data' that serves as an external reference and must not be modified at runtime.
table<ItemSpec> = { key: "item_id" }

When such a structure is introduced, the system pipeline automatically provides the AI with a powerful metadata guide: "This data is defined as a table, so do not generate logic that modifies its values at runtime." This moves beyond technical type checking; it is the process of communicating the designer's Intent to the machine.

3. Structural Evolution: From "Code Generator" to "AI Control Plane"

The era of simply parsing bytes is over. With semantic declaration structures applied, the infrastructure no longer acts as a simple 'data pump' but serves as the Control Plane for the entire architecture.

Imbuing Context to Agents: When an AI bot connects to the server via MCP, the context that "this object is an entity and must only be manipulated via state-change APIs" is injected in zero milliseconds.
Defending Against Hallucination: When the AI attempts to write code modifying fields of design data (table), the IDE or compiler blocks the malfunction at the source, stating, "This object is read-only reference data."

Conclusion: Let the Data Speak Its Intent

In the era of AI-driven development, a data communication framework must not remain a mere delivery courier moving data from A to B. It must forcibly require, from the Syntax Layer upwards, that the data itself clearly declares: "For what purpose was I created, and how must I be handled?"

Only when this Identity is guaranteed can human engineers and AI agents accept each other's intents without misunderstanding, expanding the system at destructive speeds.

Continues in the next article:

In [AI Lost in the Fragmented IDL Pile: Building a Single Context Hub with 'Unified AST'], we examine the technical sleight-of-hand needed to gather highly fragmented legacy systems (Protobuf, Thrift, Excel) into one place and deliver them to the AI before issuing these identity cards.

Project DeukPack

This article series is based on the design notes of DeukPack, an open-source infrastructure created to block data fragmentation and guarantee AI agent reliability.

GitHub: DeukPack OSS