Designing a Harness: From design.md to Maintainable Context Engineering

In its experiment record on portable design context, Atlassian's DESIGN.md is here: what we learned testing portable design context in practice, Atlassian's DESIGN.md is here: what we learned testing portable design context in practice It reviewed a scene from the Team '26 conference: the team entered exactly the same prompt into a dashboard generation task in Figma Make, with the only variable being a portable context file named DESIGN.md. The generation result with the file added showed higher consistency with Atlassian's own design style in color palette, grid spacing, corner radius shapes, typography, and overall visual hierarchy.

But the same company, in another controlled experiment targeting a basic login page, provided DESIGN.md as the sole context input to a large language model, and the performance went in the opposite direction. In this seemingly simple generation scenario, the approach relying solely on a Markdown file took longer and cost more than the approach with structured tools or skill packages, and went through noticeably more conversation turns.

These two diametrically opposed real-world performances show that the issue is not whether that Markdown file is written elegantly and thoroughly, but whether it is fed directly to the model as an isolated file or operates within a complete system with engineering constraints. When teams try to have AI Agents take on actual product design and interface implementation, how to define the capability boundaries of a file, when to stop at a file, and when it is necessary to build a true engineering Harness constitute the most thought-provoking technical distinction in current interface engineering.

What a File Can and Cannot Do

Portable Format and Design Intent

From the file form perspective, design.md is essentially a lightweight plain-text portable specification. In practice, the first half of such files is usually composed of machine-parseable key-value pairs or design variables, used to define basic styles such as colors, spacing, corner radii, and type scale; the second half is written in natural language understandable by both humans and Agents, focusing on layout logic, information hierarchy division, gaze guidance principles, and typographic constraints.

Its primary positioning is to capture high-level design intent, telling the model what temperament and organizational form a product interface should intuitively possess. This document inherently does not include all the technical details of a production environment; it is not bound to specific front-end codebase dependencies, lacks static analysis tools for syntax and styling, and cannot encompass the vast combination of variants and edge cases that teams have accumulated on the Figma canvas. It is a highly condensed summary of intent, designed to cross barriers between different tools at the lowest possible circulation cost.

Cross-tool prototype generation

This portability, detached from specific engineering bindings, allows it to demonstrate extremely significant practical value in specific scenarios. When a design team needs to build a concept prototype for a new feature from scratch, quickly generate an interactive interface in a completely unfamiliar external tool, or attempt to port an existing design language to a new tech stack and operating system, attaching a design intent document directly is often the lowest-cost way to get started.

When customizing theme styles for enterprise clients, or writing dynamic interfaces such as reports, statistical charts, and data dashboards that emphasize structural presentation rather than engineering closure, this type of document can quickly rein in the model's divergent generation. It allows the model, in environments lacking codebase access, to still roughly follow the established visual rhythm and avoid generating chaotic interfaces that completely violate brand intuition.

The real cost of login page testing

Once the application scenario shifts to a real engineering environment, the physical bottleneck of a single file as context input becomes exposed.Large language models process text in units of tokens, each token consisting of a few characters or a single character. Loading a plain text file once may seem inexpensive, but in actual interactions it incurs substantial cumulative overhead.

Atlassian recorded detailed baseline data in a controlled test targeting a simple login page. When a single DESIGN.md was provided as the sole design context, the Agent consumed an average of 7.21 million tokens, took 6 minutes and 46 seconds, and went through 45.3 interaction rounds to complete the task. By comparison, the approach of connecting to the design system via the Model Context Protocol MCP consumed an average of 3.75 million tokens, took 5 minutes and 1 second, and reduced interaction rounds to 35.1;while the approach using the Skill mechanism, consumed an average of 4.43 million tokens, took 5 minutes and 23 seconds, and required 36 interaction rounds.

In summarizing the experiment, the officials noted that the approach relying solely on DESIGN.md consumed roughly 92% more tokens, and that across different test runs the variance in token consumption was as high as about 2.7 times, exhibiting extreme instability.

The quality boundary of the six-page blind test

In another set of practices from Vercel, the research team recorded in How our agents build on-brand pages with design.md a blind test conducted across three typical desktop interface scenarios. For each scenario, they generated a page once with design.md and once without design.md, and strictly retained the model's first attempt as the evaluation sample.

Statistics after introducing deterministic checks based on explicit rules showed that the three pages with design.md introduced were detected with a total of 39 known defects, while the three pages without the file were detected with 91 known defects, a 57% reduction in the number of known defects. On the surface this demonstrates the normative effect of the design rules, but the evaluation results also recorded a fact that cannot be ignored: among all six pages tested, every single page had at least one fatal issue severe enough to prevent its release.

The pillar missing from a single file

Looking deeper into the engineering mechanism, it becomes clear that an isolated design.md, no matter how much its word count is expanded, remains inadequate when facing complex code production tasks. The core obstacle it faces is not whether the file contains a sufficient amount of content, but that a monolithic file lacks the supporting constructs。

It lacks a precise on-demand retrieval mechanism, forcing the model to read through all the irrelevant entries in full every time it thinks; it lacks a deterministic execution boundary and cannot mechanically intercept syntax or style violations like compile-time type checking; it lacks a maintenance pathway that can self-correct as the business iterates,and ultimately it can only degenerate into stale documentation disconnected from the codebase. These three capability gaps precisely reveal why production-grade implementation must rely on a complete layered architecture.

Two paths: outside the repository and inside the repository

The codebase as the sole branching point

To clarify the choice of Harness form, one must first answer an essential question: does the current Agent have the complete permissions and engineering environment to directly read, modify, and run the target codebase? This is the sole branching point that determines every form of context organization.

If the answer is no and the task goal is merely to deliver independent artifacts externally, then attempting to forcibly package and instill complex engineering dependencies into the model will only add overhead. Conversely, if the Agent already works within the main repository and its deliverables need to be merged directly into the main branch and deployed to production, then attempting to rely on a text that is detached from the code context to guide the model through rigorous engineering work is equally impractical from an engineering standpoint.

The lightweight path outside the repository

In scenarios outside the codebase, the target artifacts are usually independent analysis reports, product architecture proposals, one-off campaign landing pages, or high-fidelity interactive prototypes circulating between design tools. For such tasks, Vercel has explored a lightweight three-layer support system.

The topmost layer is the core intent encoded in design.md, which focuses on standardizing the reader's reading tasks, the organizational logic of the evidence chain, and the compositional judgment of the overall layout; the middle layer uses an externally publicly hosted stylesheet to provide strictly controlled CSS class names and design variables within a limited scope. The model only needs to reference these established class names when generating HTML, while the stylesheet itself is loaded directly by the browser at the rendering stage, occupying no space in the model's limited context window at all; the bottommost layer establishes a continuous evaluation loop that gradually distills human aesthetic intuition and logical corrections regarding the artifacts into concrete textual guidance, style primitives, or deterministic test cases.

The engineering path inside the repository

When the Agent goes deep inside a real enterprise production codebase, what it faces is no longer mere visual presentation, but a vast dependency tree, accessibility standards, state management, and long-accumulated code conventions.

On this path, the internal product-design approach introduced by Vercel in Teaching agents product design at Vercel demonstrates distinct systems-engineering characteristics. The approach is tightly composed of three interlocking parts: an Agent Skill that provides product judgment and codebase context to help the model understand business logic and selection preferences;a code static-checking tool, the linter, is responsible for automatically enforcing clear, mechanically decidable rules; and a closed-loop process spanning the collaboration setting continuously extracts design consensus from Slack discussions, Figma comments, and GitHub Pull Requests, providing update proposals for the engineering guidelines.

Atlassian, in Teaching AI to speak our design language describes a path starting from building a source of truth. Rather than manually writing isolated documents, they decompose the component library, icon assets, design variables, static-check rules, and foundational guidelines into highly structurally consistent, machine-readable type definitions and data structures, stored together with the actual front-end component source code in the same TypeScript file system. Based on this unified source of truth, the system then uses compilation scripts to automatically output the ADS MCP, the design system Skill, DESIGN.md, and any future integration formats that may emerge.

Trade-off comparison of the two paths

To establish clear criteria for technology selection, the table below compares the specific practices of the out-of-repository and in-repository paths across multiple engineering dimensions.

In actual engineering implementation, the most common mistakes often occur precisely in the mismatch between these two paths. In the exploration phase, where only an analysis report is needed, prematurely introducing heavyweight data structures and complex communication protocols will sharply drive up upfront engineering costs. In a production codebase with extremely high requirements, if a monolithic design document is simply thrown in for convenience, interaction overhead often spirals out of control, the model frequently forgets the rules amid context bloat, and ultimately all detailed failures still have to be manually investigated line by line by engineers.

Selection judgment oriented toward deliverables

Which technical approach to choose is essentially a trade-off between the deliverable's lifecycle and quality tolerance. The out-of-repository path pursues extremely high throughput and the lowest intervention cost; it allows minor unconventional code in the final implementation, as long as the visual and logical structure rendered by the browser meets the standard.

The sole goal of the in-repository path is to safeguard the code health of the production environment. It requires that every generation be properly embedded into the existing architecture, follow a unified state management pattern, and withstand the rigorous scrutiny of automated tests and build tools. Only by first identifying the endpoint of the artifact can the starting point of the context be determined.

The five-layer architecture of design context

The core rationale for splitting context

The reason all design system assets cannot be indiscriminately packaged and stacked together is that the attention mechanism of large language models exhibits a clear physical decay pattern. When tens of thousands of lines of component documentation, API specifications, accessibility clauses, and design principles are crammed into a prompt all at once, the model not only has to spread attention computation across a single inference, but also easily suffers from rule drift and selective forgetting amid the complicated information.

The token explosion and time consumption that appeared in the login page test mentioned earlier were precisely caused by the model being forced to read through the entire specification manual for every simple decision. To enable the Agent to work stably in real engineering, this monolithic information architecture must be broken, and the context decoupled and split according to the nature of the information and the timing of decisions.

The intent layer that carries orientation

The intent layer carries the core design orientation of the entire system. It answers the high-level questions of "why we design this way" and "under what circumstances it is permissible to break the rules." This layer is precisely the core content originally borne by the latter half of design.md.

It does not describe which specific parameters a button component receives, but rather expounds the system's priorities in information hierarchy, the rhythmic patterns of whitespace, the tolerance for typesetting extreme data, and the trade-off criteria when visual aesthetics conflict with information density. The intent layer provides an evaluation standard, enabling the Agent, when facing interface states it has never encountered, to make autonomous judgments consistent with the team's aesthetics based on consistent values.

The machine-readable source-of-truth layer

The source-of-truth layer centrally maintains the system's structured data sources in a unified machine-readable format, and all downstream outputs are generated from it. It completely strips away ambiguous natural language embellishment and solidifies all facts with strict Schemas of fields, types, and format rules, forming the objective factual cornerstone of the system.

In this layer, every UI component, icon asset, foundational Token, static check rule, and even copywriting guideline is decomposed into rigorously structured data entities. They clearly indicate their invocation scenarios, code snippets, property interface definitions, accessibility implementation standards, and supported state branches. Most critically, these data entities are stored in the same physical location as the actual engineering code and enjoy equal version control; any update to the design system is directly synchronized to the source of truth, fundamentally avoiding the problem of documentation and code falling out of sync.

The disclosure layer that controls rhythm

Even if the data in the source-of-truth layer is accurate enough, it cannot be thrown to the model all at once at the start of a task.The role of the disclosure layer is to establish a progressive disclosure mechanism based on the execution stage: the model obtains context at the corresponding level only when it reaches a specific step, preventing the window from being filled up from the very beginning.

In the repository root directory, trigger rules for various scenarios can be defined through an extremely short entry file; after entering a specific execution unit, the reading order and governance logic of context are strictly specified through internal configuration files; when the Agent enters the code-writing stage for a specific feature module, the system then retrieves the corresponding business reference documents on demand. For scenarios with mature precedents, provide best-practice examples that have been verified in production; for domains where standards have not yet been established, explicitly display a list of specification gaps. Each rule is assigned a stable unique number, scope of application, explicit exceptions, and positive and negative examples, ensuring that the model obtains precise information slices at the correct nodes.

Execution-Deterministic Constraint Layer

Any fact that can be definitively determined by machine algorithms should never be left to the luck of a large language model—this is the core engineering watershed in building an efficient Harness. The constraint layer is composed precisely of such toolchains that possess deterministic blocking capabilities.

The absolute boundaries of styling are fortified by an underlying controlled CSS system and style primitives; the validity of component parameters is directly defended by the compiler's static type system; and code invocation compliance and missing accessibility attributes are intercepted in the background at millisecond speed by static checking tools. All that is left for natural-language prompts to handle is the fuzzy space involving semantic understanding, trade-offs in information organization, and subjective aesthetic judgment.

A Continuously Evolving Feedback Layer

Any system that lacks a self-correcting loop mechanism will inevitably and gradually fail as the business evolves. The feedback layer exists to capture deviations in day-to-day product and engineering collaboration, so that the context can continuously absorb nourishment from the production front line.

This layer is built on concrete collaboration tools and code review processes. It continuously collects design discussions from instant messaging groups, review comments on the Figma canvas, and traces of manual modifications in code merge requests. The system aggregates these scattered feedback items, automatically distills candidate update entries for the design specifications, and after manual approval by the design system team, merges them into the source-of-truth layer to complete the system loop.

The Practical Value of the Five-Layer Architecture

The division of these five layers is no castle in the air; it precisely maps to the concrete steps of industrial-grade implementation. The intent layer safeguards direction, the source-of-truth layer accumulates assets, the disclosure layer reduces overhead, the constraint layer holds the bottom line, and the feedback layer drives evolution.

Only by clarifying the boundaries and responsibility allocation of each layer can the team have a clear target when advancing actual construction. The subsequent build-out work unfolds step by step, from the shallow to the deep, precisely along this logical sequence.

Build-Out Part One: Input and Source of Truth

Real Tasks and Baseline Establishment

The first step is to establish an evaluation baseline, providing an objective reference for comparison for subsequent context adjustments. Prompt adjustments without a measuring stick are, in the vast majority of cases, just blind luck.

In engineering practice, the team must distill a set of representative real test scenarios from actual business, for example, Vercel fixedly adopted seven core scenarios in its exploration process. At this stage, it is necessary to strictly lock down the mock input data used for testing, the target model version, the prompt template, and the viewport size at rendering time, and to run repeatedly in a bare-model state with no design system or auxiliary tools connected at all.

The team needs to fully retain the original input and output records from this stage, the generated code files, and the interface rendering screenshots, and precisely tally the time and token count consumed by a single task. Only by recording these most primitive trial-and-error processes and human feedback can the true outline of the baseline state be sketched.

The completion criterion for this step is: having a fixed set of real business scenarios, locking the mock inputs, test models, and rendering viewport, and fully recording the prompts, generated code, interface screenshots, and time and consumption records from before Harness was introduced.

Write a minimal intent file

The second step is to supplement the intent layer of the design system without introducing technical implementation details. The mistake many teams are most prone to making at this stage is translating the entire component manual into natural language without restraint.

A qualified minimal intent file should keep its length restrained to a very short scale, focusing on distilling those global decisions that are visible to the naked eye through code. It needs to clearly explain the interface's primary audience and core reading tasks, specify how data charts and key evidence should be arranged and displayed, and clarify the compositional logic and visual flow between different sections. On this basis, it should clearly define the scope of effect of each design principle, common exceptions, and the global style primitives allowed for use in the system.

Resolutely eliminate empty wishful descriptions such as "the interface should remain modern and aesthetically pleasing" and "interactions need to be smooth and silky," and by all means avoid copying any specific component parameters or underlying implementation logic at this step.

The completion criterion for this step is: the intent file can be read in full within one screen, and throughout it contains no full specifications or technical implementation details of specific components.

Establish a structured source of truth

The third step is to transform design specifications into a structured source of truth that machines can parse, so that downstream distribution formats shift from fragile manual maintenance to automated generated artifacts. This is the watershed determining whether the entire system can be implemented at scale.

The team needs to conduct a systematic structural decomposition of the existing design system. Using TypeScript's type system or standardized Schema formats, encapsulate all color and size variables, property definitions of common components, accessibility specification entries, standard copy paradigms, and interaction state branches one by one as independent strongly typed objects. Each component entity needs to clearly come with textual descriptions of its applicable scenarios, standard code usage examples, value constraints for input parameters, and mandatory requirements for accessibility labels.

The most critical organizational principle is that this Schema must be stored in the same directory of the same code repository as the actual source code of the frontend components, subject to unified version change and review pipeline constraints. Any modification to a component implementation must mandate synchronized updates to its corresponding source-of-truth description.

The completion criterion for this step is: the defined Schema comprehensively covers usage instructions, code examples, property interfaces, content specifications, and accessibility requirements, and is located in the same place as the production code and governed by version control.

Indexing and progressive disclosure

The fourth step is to build an index system and an on-demand disclosure layer, preventing the model from getting lost in a single session due to information overload.

In system design, the size of the trigger entry point should be compressed to the absolute minimum. The entry file placed in the repository root is only responsible for declaring the task-type determination logic and the load timing of the corresponding resources; it does not itself contain the specific rule text. When a task clearly matches a certain type of interface development, a dedicated Agent Skill is then dispatched to drive the complete execution flow.

Specific rules and reference assets must be physically decomposed by business domain and respectively grouped into product logic judgment, interface visual quality, system state resilience, copywriting language standards, and reference materials for specific pages. For excellent examples accumulated by the team in actual business, distill them into universally applicable best-practice modules for the model's reference; for ambiguous areas where clear design specifications have not yet been established, create a public gap list that explicitly warns the model that blind divergence is prohibited in these areas and that the most conservative and generic approach must be used. Every cascaded detailed rule must be assigned a globally unique fixed number, clearly indicating its source, applicable environment, exemption special cases, and accompanied by clear positive and negative comparison examples.

The completion criteria for this step are: the external trigger entry point only declares trigger timing; each rule has a stable unique identifier, source provenance, scope of effect, special-case explanation, and positive and negative examples; areas without established specifications have a public gap list.

Stage Completion Criteria Comparison

To facilitate progress checking and course correction during implementation, the following table summarizes the core metrics, common errors, and clear signals for proceeding to the next step for the first four steps.

After completing these four steps, the team has in effect already prepared for the Agent a well-structured, precisely scoped contextual knowledge base that will not easily cause attention to drift. But a knowledge base alone is not enough to guarantee flawless code output; the focus must next shift to deterministic execution at runtime and convergence of entry points.

Building the second part: constraints and entry points

Style primitives that define the boundaries

The fifth step is to converge style primitives and component boundaries for the design system, fundamentally shrinking the model's room for trial and error. Too much freedom tends to make generated code deviate from the specification.

In actual implementation, the model must be provided with design variables and class name utilities that have clear semantics and strictly closed boundaries. When assembling interfaces, the model is strictly limited to selecting from the established set of style primitives, preventing it from writing inline styles with arbitrary values or making arbitrary global overrides on its own.

There is an extremely critical engineering tradeoff here: anything that does not need to enter the model's context window must be kept out of it. In the external lightweight approach, Vercel hosts the public stylesheet externally; when the page renders, the browser engine directly fetches and parses this set of style rules. The large language model only needs to know "which class name this card container should use," without needing to understand or even memorize the dozens of specific CSS properties behind that class name. This approach not only greatly saves costly token resources but also firmly concentrates the final parsing authority for styles in a controlled, deterministic runtime environment.

The completion criterion for this step is: code generated by the model can only call controlled Token and class name primitives, and public style resources can be parsed in the browser without entering the prompt context.

Mechanical rules go to static checks

The sixth step is to push all deterministic engineering rules down to the static checking system, reducing the attention burden at the prompt level.

Many teams are accustomed to emphasizing all kinds of coding details in exhaustive detail in the prompts given to the model, such as "do not use attributes with unescaped characters," "all interactive elements must include accessibility labels," and "a specific icon import syntax must be used." Such rules are not only large in number but are also very easily ignored by the model in long-context environments.

A more engineering-deterministic approach is to convert all of these requirements, which fully conform to mechanical judgment logic, into the project's linter rules or compiler type constraints. In the local build pipeline or the Agent's runtime container, once the model generates code that violates such rules, the static checking tool will immediately throw error logs containing precise line and column numbers and fix suggestions, driving the model to make targeted corrections based on the explicit error information. What remains in the natural-language guidance files should be only those non-mechanical judgments that require trade-offs in the context of the business.

The completion criterion for this step is: the prompt no longer repeatedly admonishes any mechanical rules that can be automatically intercepted by the compiler or static checking tools.

Unify at the entry point of the collaboration scene

The seventh step is to build for the team a unified invocation entry point located in the actual work interface, seamlessly injecting design context into daily collaboration. Independent demos detached from the production environment are often difficult to truly roll out.

On this point, the explorations of two representative companies show an engineering orientation that converges by different paths. In its actual business collaboration, Vercel deeply integrates design capabilities into the instant messaging tool Slack. Team members, through the @design-agent bot based on the internal development framework eve, initiate interactions; the Agent automatically loads the latest design.md file and public stylesheets in the background, completes code generation and temporary rendering, and then directly returns in the discussion thread high-definition rendered screenshots of the interface and a preview deployment link that can be interacted with in real time, for the product and engineering team to verify immediately.

Atlassian, meanwhile, is committed to distributing the unified design source of truth to multi-platform development environments. Through the ADS MCP protocol, specially packaged design system Skills, and structured content output, they seamlessly deliver the unified design context to the Cursor editor, the enterprise internal Slack collaboration space, the intelligent assistant Rovo, and the design tool Figma Make. Regardless of whether team members are in a coding tool, a design canvas, or a communication platform, they are invoking the same design system core.

The completion criterion for this step is: team members can trigger the Agent through a single instruction or entry point in their daily collaboration tools, and can directly obtain verifiable artifacts, including real screenshots, preview environment links, or runnable code.

The commonality behind the interface forms

The industry debate over whether to fully embrace MCP or prioritize Skill often appears superficial in the face of concrete engineering practice. The essence of MCP lies in defining a set of general cross-system communication protocols, suitable for use in complex IDE environments that require dynamic cross-tool data retrieval and connection to remote services; while Skill is more oriented toward packaging, within a controlled framework, the execution logic of specific business processes andaccompanying knowledge。

Which interface protocol to adopt depends to a large extent on the specific team's existing engineering toolchain and host environment. From the perspective of deeper governance logic, the focus of the two companies highly overlaps: the core lies in establishing a unified entry point that allows the team to reach it anytime and anywhere, establishing a source-of-truth release pipeline free from manual synchronization, and ultimately forming a continuously self-correcting工程闭环。

约束执行的标准对照

搭建下半程的重心完全落在工具的硬性约束与工程落地形态上，下表归纳了最后三个构建步骤的核心衡量指标与典型误区。

Only when the constraints have deterministic enforcement power and the invocation entry point is firmly placed within the daily workflows of engineers and designers is the skeleton of the entire Harness truly built. But for this system to avoid rapidly aging amid long-term business iteration, a rigorous evaluation and governance system must also be established.

Evaluation metrics and governance mechanisms

The execution path for evaluation and correction

The eighth step is to establish a quantifiable and sustainable evaluation and correction loop for the entire Harness; it is the core means of keeping the system's rules effective and stable.

In actual operation, one cannot rely on subjective random spot checks by individual engineers; a strict blind-testing mechanism must be enforced. After selecting baseline scenarios, retain the model's first-round attempt outputs and attach tamper-proof identification records to each changed version. When the evaluation process finds defects in generated results, the repair strategy must follow the convergence principle of "fix at the lowest level, not the highest": only deviations involving subjective aesthetics and information organization should have correction notes added to the intent file; recurring layout paradigms should be distilled into reusable primitives in the stylesheet; and mechanical defects that can be logically determined must immediately be written into new linter rules or test cases. Resolutely avoid simply blaming everything on the prompt and endlessly expanding the text.

The real exploration cost of the intent file

Many people easily underestimate the process of producing a concise design document, mistakenly believing it is just a simple memo casually written by a designer. The actual engineering investment often takes a starkly different and much heavier form.

When reviewing the incubation process of a high-quality internal design.md, Vercel revealed that the entire construction and calibration process went through more than 200 actual runs in total.Among these more than 200 runs were complete task rounds, targeted checks of local rules, trial runs of exceptional boundaries, and engineering detours where work was scrapped and restarted midway.Distilling humans' vague aesthetic perception into precise instructions that a model can understand stably and interpret with minimal ambiguity requires extremely tedious engineering refinement behind the scenes.

Improvements brought by structured context

In Atlassian's Atlassian Design System: Building the context engine for the AI era recorded targeted query tests, MCP backed by structured content delivered up to a 52% improvement in query accuracy compared with a baseline Agent without MCP configured. And in code generation tests, also from Atlassian, an environment driven by a structured source of truth raised final code accuracy by 4.9%, accompanied by an 11% reduction in errors, a 34% average reduction in task completion time, a 16% reduction in token consumption, and a 26% decrease in tool call frequency.

Manual Governance and System Maintenance

The ninth step is to establish a long-term manual governance mechanism and clear boundaries of responsibility, which is an important line of defense against the system failing as personnel change and the business evolves.

A robust Harness must have rigorous channels for human intervention. Feedback from the business front line cannot be written directly into the source of truth without review; the system must introduce a clear review process and designated owners. Every addition, modification, and deprecation of a rule must be accompanied by an incremented version number and leave a traceable commit record in the code repository. For blank areas not yet covered by the design system, a publicly transparent gap list must be maintained to prevent the Agent from running wild in specification blind spots.

Atlassian summarizes the long-term health of an AI-native design system into four organic dimensions: AI can smoothly understand the specifications; AI can skillfully use the specifications to build interfaces; emerging interaction patterns explored by AI can feed back and be consolidated into system assets; and AI can assist the team in maintaining the health of the system itself. In their practice, every update to the source-of-truth content automatically triggers, in the background, the evaluation pipeline and code health checks, ensuring that new rules do not have destructive side effects on existing business.

Harness is not a static asset to be configured once and then left alone, but rather a dynamic, evolving system that requires sustained investment of engineering resources and human governance.dynamic evolving system.

Role change: being accountable for outcomes

The intersection of aesthetics and implementation

Along with the evolution of context engineering and Agent infrastructure, the division of responsibilities among different technical roles in teams is undergoing profound restructuring. This change is especially dramatic in the interdisciplinary field of design engineering.

Vercel, in Design Engineering at Vercel , gives a clear definition of the design engineer role: such talent must deeply combine keen aesthetic perception with solid front-end engineering capabilities, be able to fundamentally and deeply understand the problems faced by the business, and possess the full-stack ability to independently complete design, code construction, and even final release and launch. In terms of day-to-day focus, they must not only examine at a macro level the architectural soundness and runtime performance of reusable components, but also at a micro level relentlessly address cross-browser consistency, interaction experience for multimodal input, fine-grained adaptation to system preferences, and uncompromising accessibility standards.

From stages to delivered outcomes

For a long time, the software industry's R&D pipeline has been accustomed to splitting product and engineering work into isolated process stages: product managers output requirements documents, designers sketch static visual mockups on a canvas, front-end engineers reproduce pixels in code against the designs, and finally testers gatekeep acceptance. In this chain, everyone tends to be responsible only for the deliverable of the stage they are in.

When a high-caliber Harness can take over a large amount of repetitive interface-building work, the key shift is no longer superficially requiring someone to "both draw interfaces and write code," but rather that the entire team's focus should thoroughly shift from being responsible for a single "process stage" to being accountable for the final "online outcome." Designers and engineers no longer need to expend massive effort on tedious design walkthroughs and pixel-perfect back-and-forth, but instead jointly bear direct responsibility for the actual product experience ultimately delivered to users.

Code-adjacent design exploration

Under this evolutionary trend, some design practitioners with a forward-looking vision have begun to proactively break down the invisible barriers between tools. Ryo Lu, head of design at Cursor, in a tutorial interview Full Tutorial: Design to Code with Cursor's Head of Design shows a way to complete feature design and prototype building directly in a code editor, a brand-new workflow.

In this way of working, design exploration is no longer limited to arranging layers on a static canvas; instead, from day one it runs directly in a real code environment with the help of an Agent. Code prototypes naturally come with complete data state management, handling for extreme text overflow, and real browser response feedback. They fundamentally eliminate the massive information loss andcognitive bias

The actual place of canvas tools

On the relationship between design tools and code environments, Ryo Lu gave an equally direct answer in the interview Ryo Lu — It's All the Same Thing : for early product architecture exploration, divergent brainstorming of vague concepts, and scenarios that require precise two-dimensional spatial layout and free arrangement, he still unhesitatingly uses Figma. The real trend is that designers move more proactively toward codebases and running real software, shortening the distance between intent and implementation, rather than making an either-or choice between graphical interfaces and code.

Infrastructure that moves toward outcomes

Starting from real business pain points, going deep into specific code contexts and runtime environments, and ultimately taking full responsibility for the product outcomes users see and use—this is the certain direction in which the entire shape of software building is evolving.

Looking back at the decomposition and construction process detailed throughout this article—from the initial minimal intent file that captures design principles, to the carefully deconstructed structured source of truth, to the strictly defensive static checks and the deeply integrated collaboration entry point—the fundamental value of this progressively layered Harness is by no means to replace human professional thinking. Its entire mission is to serve as solid infrastructure that translates human aesthetic orientation and engineering rigor into a code language that Agents can understand and execute, allowing creators to step away from endless mechanical repetition and focus on the creative decisions that truly require wisdom and passion.

References

1. Atlassian's DESIGN.md is here: what we learned testing portable design context in practice — https://www.atlassian.com/blog/ai-at-work/atlassians-design-md-is-here-what-we-learned-testing-portable-design-context-in-practice — Atlassian，2026-06-15

2. Teaching AI to speak our design language — https://www.atlassian.com/blog/ai-at-work/teaching-ai-to-speak-our-design-language — Atlassian，2026-06-02

3. Atlassian Design System: Building the context engine for the AI era — https://www.atlassian.com/blog/ai-at-work/atlassian-design-system-building-the-context-engine-for-the-ai-era — Atlassian，2026-05-28

4. Teaching agents product design at Vercel — https://vercel.com/blog/teaching-agents-product-design-at-vercel — Vercel，2026-06-25

5. How our agents build on-brand pages with design.md — https://vercel.com/blog/how-our-agents-build-on-brand-pages-with-design-md — Vercel，2026-08-31

6. Design Engineering at Vercel — https://vercel.com/blog/design-engineering-at-vercel — Vercel，2024-03-29

7. Full Tutorial: Design to Code with Cursor's Head of Design — https://creatoreconomy.so/p/design-to-code-with-cursor-head-of-design-ryo-lu — Peter Yang，2025-11-16

8. Ryo Lu — It's All the Same Thing — https://www.dialectic.fm/34-Ryo-Lu-It-s-All-the-Same-Thing-2cd46137d5888051889cfd660458f2a3 — Dialectic，2025-12-18