Attractor Guidance and Trajectory Mining: The Convergence Mechanism of AI Native Engineering

#ai #openspec #harnessengineering #promptengineering

AGE (Attractor Guided Engineering) is a set of AI-native engineering methodology that I developed during the creation of nop-chaos-flux.

https://github.com/entropy-cloud/nop-chaos-flux is a large-scale frontend framework project developed entirely under AI leadership.

Unlike typical Harness methodologies, the conceptual origin of AGE lies in the controlled convergence picture of dynamical systems in mathematical physics. Consequently, compared to methodology summaries based on accumulated experience, its introduction carries a distinct innovative character. When large AI models directly read documents and practices related to AGE, they often miss the point, frequently falling back into the engineering language they are more familiar with. For example:

Interpreting the attractor as a boundary, guardrail, or stronger constraint;
Understanding skills as the primary carrier for knowledge organization;
Framing the problem of information form as "whether to unify specs";
Understanding the plan as an execution checklist or approval page;
Treating logs, bugs, and history as retrospective archives rather than as part of the system's convergence mechanism.

But the real point is not any of these.

1. AI Is a High-Frequency Random Expansion Force; the System Must Possess Endogenous Convergence Capability

In an engineering system, AI acts more like a high-speed expansion force with inherent randomness. If it is to continuously participate in the system's evolution without causing overall drift, the capacity for convergence cannot be entrusted to the model itself. Instead, it must be endogenous to the entire system composed of the Agent, documentation, code, and verification/audit/memory mechanisms. In other words, what truly keeps the system converging stably is neither any spontaneous sense of direction from the AI, nor the unexternalized architectural judgments residing in a few individuals' minds, but rather the structural landscape provided by this extended cognitive system.

2. Generic Skills Cannot Substitute for a Project-Specific Attractor

Generic skills, at best, grasp the common knowledge of a task type or domain, but they generally lack an understanding of why this particular project is designed this way. In particular, they lack a firm grasp of the project's positioning, architectural trade-offs, design philosophy, overarching principles, historical baggage, and current baseline. Therefore, they are insufficient to form a project-specific attractor. When the system can only access a mass of information lacking clear authority hierarchies, proof relations, and precedence constraints, the increase in information paradoxically amplifies conflicts and heightens system instability. What is truly needed is neither generic architectural boilerplate nor some formulaic directory structure, but rather the project's own specific design ideas, semantic authority chains, and long-term convergence direction.

The substance of attractor guidance is not "writing the architecture down clearly," but organizing the project-specific design ideas, macro principles, authority relations, proof chains, and historical negation space into a systemic structure that can continuously shape subsequent evolutionary trends. That is to say, the attractor is not a document, but a stable convergence topology jointly carried by multiple repository artifacts.

3. Information Itself Is Independent of Form, but Form Affects the Efficiency of Intelligent Computation

Information in itself is independent of form; the same semantics can reside in different carriers such as documents, code, tests, DSLs, and logs. However, form significantly affects the efficiency, stability, and ambiguity rate of intelligent computation. Therefore, the question is not whether a unified spec must be adopted, but whether the mode of information organization fits the domain logic. Rather than flattening knowledge into a planar list of fixed formats, a better approach is often to independently organize it by domain concepts, semantic relations, and authority levels, and to establish a topological structure through links. Domain-specific expression has greater potential to achieve efficient information organization and semantic transfer.

The emphasis is not on "unified form," but on "structure submitting to the domain."

4. The Plan Is a Local Convergence Closed Loop and Must Accept External Auditing

The role of the Plan is not to serve as a temporary draft within a session, but to act as a verification closed loop and convergence mechanism for a given round of local changes: why make the change this time, what the boundaries are, what defines true closure, and what follow-up obligations remain. Precisely because of this, the Plan itself and its execution results must be subjected to mandatory external auditing to avoid the self-verification trap where "the implementer defines completion and then declares completion themselves." As for the specific structure of the Plan, it does not need to be absolutely uniform; it can be dynamically adjusted based on project complexity, task risk, and the current reliability of the AI—for example, whether to introduce a skill selection review or how to set the closure gate intensity.

5. Trajectories Are Core Objects, and Trajectory Mining Is a Generative Mechanism for Future Convergence Capability

From the perspective of dynamical systems, one extremely critical but frequently overlooked object is the trajectory. Most practices remain stuck at the task-driven level: once the task is done, the scaffolding seems useless, and whether the history is preserved is irrelevant. This is precisely the common blind spot.

Merely focusing on whether a single task is completed is not enough; what matters more is continuously recording the system's evolutionary trajectory. The significance of the trajectory is not just to record what happened in the past, but to continuously extract trend signals and periodic signals from the system's history, such as:

Which misunderstandings recur repeatedly;
Which locally correct decisions are accumulating into a directional error;
Which audit false positives are wasting the system's budget;
Which design debts cyclically resurge;
Which temporary patches always grow back into structural problems.

This trajectory information should not be discarded after the task ends; rather, it should be further distilled into tendentious audit prompts, calibration rules, normative document patches, or constraining document increments, thereby forming an ever-strengthening convergence force. Compared to the current practices that still generally remain at the task-driven level, trajectory mining represents an upgrade from "completing tasks" to "shaping long-term controlled evolution."

Conclusion

AI is responsible for expansion; the project-specific attractor is responsible for orientation; the Plan is responsible for local closed loops; trajectory mining is responsible for continuously strengthening the convergence capability. And all of this must be built upon an information organization that conforms to the domain's semantic topology, rather than relying on generic skills or fixed templates.

What attractor guidance addresses is where the system evolves in the long run; what trajectory mining addresses is how the system continuously generates stronger convergence capability from its own history. It is the combination of these two that truly allows AGE to surpass the common narratives of skills, guardrails, workflows, and review-agents.

References:

DEV Community