Boost AI Coding Build Preview Speed 10× with Piece’s Fragment‑Aware Build

Motivation

Traditional development feedback loops treat a file as the minimal unit of change, but AI agents often edit much smaller units such as a single function, React component, interface, class, or JSX block. The build system should therefore understand these internal semantic fragments.

Why files are no longer the smallest unit

Large‑language models now support long context windows, allowing AI to work with files that contain thousands of lines. Files remain a stable collaboration boundary, but they are not necessarily the most natural minimal feedback unit for AI‑driven edits.

Limits of existing build systems

Modern tools (Gradle, Vite, Webpack, Turbopack, TypeScript, Kotlin, Go) provide incremental compilation, task caching, and hot‑module replacement, yet their change entry points still revolve around files or modules. They answer “Did the file change?” rather than “Which semantic fragment changed?”

Fragment‑aware build concept

A semantic fragment (or simply “fragment”) is defined by five attributes:

Identity : e.g., DashboardPage.tsx#UserCard Structural range : its location and boundaries in the source

External shape : exported name, signature, props, or type

Dependencies : type and runtime dependencies, including unknown ones

Feedback target : whether it can be previewed, validated, cached, or rolled back locally

When an AI agent modifies a fragment, the build system should generate a structured update plan that answers:

Which fragment changed? Did its external shape change? What other fragments are affected? Which preview targets need updating? Which build artifacts can be reused? Which changes require a full file‑level or project‑level fallback?

Prototype implementation (Piece)

The open‑source prototype https://github.com/phodal/piece demonstrates the idea across several languages:

TS/JS: uses the TypeScript AST to extract declaration‑level fragments.

React: builds preview targets around component fragments.

Kotlin: leverages the Kotlin/JVM PSI / Analysis API.

Go: delegates compilation feedback to go build / go test.

.pic DSL: validates that the fragment model works outside of React.

Typical processing pipeline:

Extract fragment list → Compare with historical snapshot → Identify changed fragments → Check external shape → Propagate impact → Construct minimal closure → Apply safety checks → Generate feedback plan → Update preview and build artifacts

The challenging part is not parsing the structure but deciding fragment identity stability, external‑shape comparison, dependency classification, handling unknown dependencies, and determining when a local change is safe versus when a full rebuild is required.

Example: TSX file decomposition

Consider a large DashboardPage.tsx file containing several declarations (interfaces, constants, exported functions). The prototype parses it into distinct fragments such as User, UserCardProps, statusColorMap, UserCard, and OtherCard. Each fragment can be tracked independently, allowing the build system to rebuild only the affected parts.

Safety boundary

Fragment‑aware build must first verify that a change is locally safe. If a modification only affects a component’s JSX, the system can update that preview alone. If the change touches a type definition, runtime constant, or global side‑effect, the system may need to fall back to file‑level or project‑level rebuilding.

Relationship to existing incremental techniques

Fragment‑aware build does not replace hot‑update, incremental compilation, or caching; it extends those mechanisms to operate on internal semantic units. The goal is to answer “When an AI modifies a function, component, interface, or JSX block, can the system produce a fine‑grained update plan instead of merely reporting that a file changed?”

Implementation details

Overall flow of the prototype:

Long TSX file
 → Incremental parser
 → Declaration‑level fragment list
 → Fragment dependency graph
 → Preview target resolver
 → Closure constructor
 → Virtual module
 → Build engine
 → Preview / build artifacts

After several iterations, the current implementation supports the language‑specific pipelines listed above and uses a .pic DSL to verify that the fragment model works independently of React.

Conclusion

Files will continue to serve as storage and collaboration boundaries, but in the era of AI‑driven coding they are no longer the most natural minimal feedback unit. Fragment‑aware build redefines the feedback boundary, providing the infrastructure needed for the next generation of AI‑enhanced IDEs.