Telos Labs AI Harness Lets Designers Ship Production Rails Code

Ruby on Rails

Automated agent harnesses commoditize routine coding, making human design taste and engineering judgment more valuable rather than obsolete.

AI-assisted summary of How a Designer started shipping production Rails - Alicia Rojas & Arely Rivera — original source. Check the original for full context.

Source published: 2026-10-01

Key ideas

Telos Labs engineer Alicia Rojas and designer Arely Rivera demonstrated how a 68-line harness—comprising design tokens, a shared partial, and a 10-line markdown contract—enabled a designer to ship thousands of lines of production Rails code. (2:38)
An initial 7,000-line pull request passed all CI checks and tests but still introduced four escaped visual and structural defects, underscoring that unenforced design guidelines function merely as suggestions. (5:53)
The team introduced the Onion Design Framework, a five-layer model spanning tokens, primitives, patterns, written rules, and screens, designed to make system rules legible to autonomous coding agents. (8:23)
In a 33-agent benchmark, correcting a single inadvertently biasing sentence in the agent instructions increased design system adherence from an 18% baseline to 100%. (14:04)

Detailed notes

## Background Published on YouTube by the Ruby on Rails channel on October 1, 2026, this Rails World 2026 presentation features Telos Labs software engineer Alicia Rojas and lead product designer Arely Rivera. According to the description, the talk covers what occurred when Rivera shipped a 7,000-line pull request to production using an AI agent harness, introducing the Onion Design Framework and sharing findings from running 33 agents against vague prompts.

## TL;DR Software engineer Alicia Rojas and product designer Arely Rivera examine how a lightweight harness enabled Rivera to contribute directly to a production Rails codebase, resulting in a 7,000-line pull request that passed automated CI but escaped four subtle UI defects. To prevent drift and make UI systems legible to AI agents, they established the Onion Design Framework, a five-layer architecture spanning from tokens and primitives to composed patterns, written rules, and screens used for diagnostic feedback. Through an empirical benchmark of 33 agent runs, they reveal how a single phrasing error derailed visual layout generation and how correcting the harness achieved reliable results. Ultimately, they argue that while harnesses standardize repetitive execution, human taste and judgment remain essential for deciding what deserves to be built.

## Atmosphere & style The presentation carries an energetic, candid, and collegial dynamic that playfully bridges the traditional divide between software engineers and product designers. Opening with the humorous, slightly alarming admission of merging a massive designer-authored pull request that broke in four distinct ways, the talk establishes an honest, post-mortem tone rather than presenting an idealized success story. The speakers balance technical rigor—such as decomposing git diffs and schema benchmarks—with thoughtful real-world metaphors like window-washer safety harnesses, leaving the audience with a grounded, empowering, and pragmatic perspective on working alongside AI.

## Bulletin - [02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) Telos Labs engineer Alicia Rojas and designer Arely Rivera demonstrated how a 68-line harness—comprising design tokens, a shared partial, and a 10-line markdown contract—enabled a designer to ship thousands of lines of production Rails code. - [05:53](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=353s) An initial 7,000-line pull request passed all CI checks and tests but still introduced four escaped visual and structural defects, underscoring that unenforced design guidelines function merely as suggestions. - [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) The team introduced the Onion Design Framework, a five-layer model spanning tokens, primitives, patterns, written rules, and screens, designed to make system rules legible to autonomous coding agents. - [14:04](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=844s) In a 33-agent benchmark, correcting a single inadvertently biasing sentence in the agent instructions increased design system adherence from an 18% baseline to 100%.

## Key takeaways - [00:12](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=12s) A 7,000-line pull request generated primarily by a designer passed all CI suites, tests, and engineering code reviews, yet broke visually and structurally across four areas in production. - [00:12](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=12s) Standard engineering code reviews focus on architecture and syntax rather than QA or visual edge cases, creating a blind spot when reviewing agent-generated frontend code. - [02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) The operational core of the design harness required only 68 lines: 46 lines of tokens, a single shared partial across 50 call sites, and a 10-line natural-language contract in a markdown file. - [02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) Robust repository guardrails—including strict branch rules, custom hooks, and CI suites—allowed non-engineer designers to operate directly in a production codebase safely. - [05:53](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=353s) Unenforced rules inevitably degrade into suggestions, as seen when hard-coded hexes and a global form label sizing bug bypassed automated checks. - [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) The Onion Design Framework arranges frontend architecture into five concentric layers: Core Tokens, Primitives, Composed Patterns, Written Rules, and Screens. - [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) Agent-generated screens provide critical diagnostic evidence, allowing engineers and designers to trace visual errors back to ambiguous rules or missing tokens in inner layers. - [12:01](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=721s) Comparative prompt benchmarking showed that strict schemas delivered high accuracy while optimizing token consumption, whereas lint-annotated instructions performed poorest. - [12:01](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=721s) Testing 33 agent runs against a vague prompt initially achieved only an 18% success rate due to the model defaulting to tabular engineering conventions rather than user-centric card layouts. - [14:04](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=844s) Extreme literalism in LLMs means subtle phrasing mistakes can misdirect agents; eliminating a single sentence restored benchmark adherence to 100%. - [14:04](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=844s) Stripping away the agent harness while maintaining identical model access and prompts caused generated output to degrade immediately into disjointed, unstyled HTML. - [15:02](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=902s) As automated tools commoditize routine code execution, human taste, context, and user advocacy become significantly more valuable. - [15:02](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=902s) Working directly in code rather than relying exclusively on Figma mockups eliminated fidelity loss and grounded design decisions in real production constraints. - [17:10](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=1030s) Engineering teams must treat harnesses like mandatory safety gear for high-rise workers, mechanically enforcing constraints rather than relying on human babysitting.

## Detailed walkthrough ### [00:12](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=12s) Introduction and the 7,000-Line Pull Request

Alicia Rojas, a software engineer who has been developing software at Telos Labs for about five years, opens the talk alongside lead product designer Arely Rivera, who has been designing for eight years and collaborating with Alicia at Telos Labs for the past three. After thanking the conference organizers for slightly bending the rules to let an engineer and a designer share the stage, Alicia sets up the central premise of their story: how Arely started shipping production Rails code directly.

To frame the story, Alicia asks the audience to imagine being handed a pull request with over 7,000 lines added, almost 2,000 lines deleted, and 153 files touched. "Would you merge this?" she asks. She admits that three or four years ago, her reaction would have been, "Are you insane? Especially coming from a designer. Why on earth wouldn't you split this into several PRs, especially if we're talking about front-end code?" Yet she did merge it. As the reviewing engineer, she ran the code locally, verified critical flows, and performed an end-to-end review. Looking at the diff, she saw mostly markup and CSS and figured, "Worst-case scenario, something will look ugly, so not too bad." All four automated CI suites—including security checks, linters, and automated tests—were completely green.

So Alicia shipped it—and it immediately broke in four ways. Despite the breakage, she still believes merging the PR was the right decision for structural reasons. As she points out, an engineering code review is fundamentally different from a QA review; it does not ask the same questions a QA review asks, and she hadn't thought to ask herself several of those questions before hitting merge.

[02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) Decomposing the Diff and Building the Harness

When decomposed, the 7,000-line diff was far less intimidating than it looked at first glance. A full 64% of the diff was a dev-only component catalog that was never served to end users, and there were only about 100 lines of net new production markup. The most critical piece of the entire PR, however, was a tiny 60-to-68-line "harness":

- **46 lines of design tokens** defining core values. - **A shared partial** called across 50 different call sites. - **A 10-line contract** in a `CLAUDE.md` file (which could equivalently live in an `AGENTS.md` file) containing natural-language rules for AI agents to follow—something the team simply referred to as "the contract."

Alicia explains how a designer came to ship a 7,000-line PR in the first place. She had been tinkering with the concept of agent harnesses in a codebase that served as an experimental playground for working safely with AI agents. Because the repository was already fairly agent-friendly, it was naturally "Arely-friendly" as well: it had solid branch protection rules, trustworthy CI checks, and custom bash hooks and permission settings that Alicia had configured so both she and Arely could work with agents without posing a threat to production.

While the team had already figured out how to use harnesses to guide agents on backend Ruby architecture and patterns, they hadn't quite cracked how to make agents do what they wanted on frontend screens. Their philosophy became: "let's try to enforce mechanically what can be mechanically enforced, and encode the rest of the patterns and the taste in written rules, natural language rules"—which Alicia jokes is "DHH's favorite language, we learned this morning." To kick things off so Arely could work directly in the codebase, Alicia committed an initial foundation of about 1,600 lines establishing the design harness. Arely then took over and contributed more than 6,000 lines—accounting for 94% of the branch additions. As Alicia summarizes the division of labor: "I built a track so Arely could drive."

[05:53](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=353s) The Four Escaped Defects and the Cost of Unenforced Rules

Even with the harness in place, four defects escaped into production—some of which were actually visible in the diff if a reviewer had known where to look:

| Escaped Defect | Cause & Impact | How It Was Caught | |:--- |:--- |:--- | | **24 hard-coded hex values** | Violated the exact token rule the PR was introducing for the first time (2 of the 24 were in files touched by the PR). | Post-merge design review | | **Duplicate canonical tag** | Introduced on a genuinely new page; rendered as nothing visually so there was zero user-facing impact. | SEO audit | | **Shrunken form labels** | A single line changed in one form builder propagated across every form label in the app. It was token-compliant and CI stayed green. | Human UX audit | | **White navbar on a white page** | Placed correctly in 4 places but missed on the 5th—an edge case where scrolling to a specific point turned the navbar white against a white background. | Human visual inspection |

At the same time, the structure of the harness *did* prevent a massive amount of drift. Hard-coded hex values across the codebase dropped from 119 down to just 24, and the agent introduced zero invented components and no arbitrary fonts or spacings. Still, the escaped defects carried a real cost: out of the 68-line harness, one unplanned UX audit, and four follow-up bug-fix PRs, only the harness itself had been planned. Reflecting on the experience, Alicia shares their biggest takeaway: "Yes, you can have a ton of rules, but a rule that is not enforced is not a rule. It's a suggestion."

[08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) The Onion Design Framework

Picking up the story, Arely explains a fundamental realization she had while generating screens with AI: the consumer of a design system is no longer just a human—sometimes it is an agent. When generating screens with agents, designers have to ensure that agents can read, understand, and apply the design system accurately. To make their system legible to agents, Arely and Alicia created a five-layer architecture where every outer layer depends on the decisions made in the inner layers. Because of its concentric structure, Alicia named it the **Onion Design Framework**.

```mermaid flowchart LR accTitle: The Onion Design Framework and Feedback Loop accDescr: Five concentric design system layers flowing from Tokens to Screens, with diagnostic evidence from Screens feeding back to fix inner layers.

subgraph Inner["Core Foundation"] L1["1. Tokens (Values: spacing, radius)"] --> L2["2. Primitives (Buttons, inputs, states)"] L2 --> L3["3. Composed Patterns (Working detail panels)"] end

subgraph Outer["Context & Output"] L4["4. Written Rules (Context & taste)"] --> L5["5. Screens (Assembled output)"] end

L3 --> L4 L5 -.->|"Diagnostic evidence (Fix root cause)"| L1 L5 -.->|"Diagnostic evidence (Fix root cause)"| L4 ```

Arely walks through each of the five layers from the inside out:

- **Layer 1: Core Tokens** — The innermost layer consists of strict value definitions—such as spacing, corner radius, and elevations—telling the agent: "you can build, but you can build only using these values." - **Layer 2: Primitives** — Built directly from the inner token values, primitives are the smallest functional building blocks, such as buttons, cards, and text inputs. Crucially, they are not just visually reusable; they also carry interactive states, accessibility, and special requirements. - **Layer 3: Composed Patterns** — Larger building blocks assembled from primitives that are already proven to work, such as a detail panel. Because the pattern already works, the agent shouldn't reinvent a new one every time—it should simply reuse the existing pattern and swap out the copy or specific content. - **Layer 4: Written Rules** — Arely's favorite layer, "because here is where all the magic happens. All the design decisions happen here." Written rules give the agent situational context so it knows which pattern to apply. To illustrate how Layers 2, 3, and 4 interact, Arely offers an analogy: in Layer 2 (Primitives), you have a big piece of wood, a frame, and a knob; in Layer 3 (Composed Patterns), those pieces form a working door that every user intuitively knows how to walk through; in Layer 4 (Written Rules), the agent is given the context to know *when* to use a solid wooden door versus a sliding glass door. - **Layer 5: Screens** — The outermost layer is the fully assembled screen output. Beyond delivering the UI, Arely emphasizes that the true value of the Screens layer is that it provides **evidence**. When an agent generates a flawed screen, you could simply patch the screen right away, "but that's not the value. The value is actually understanding why the agent made that mistake." By diagnosing the error on the screen, the team can trace the failure back to the responsible inner layer—whether that means fixing a broken or missing token in Layer 1 or clarifying an ambiguous instruction in Layer 4's written rules.

[12:01](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=721s) Benchmarking Harness Communication and the 33-Agent Experiment

To determine how to communicate the design system most effectively to AI agents, the team ran an empirical evaluation across three formats: Option A (a strict schema), Option B (a written prose style), and Option C (lint-annotated rules). Despite the initial hypothesis that lint annotations would perform best, Option C proved to be the worst performer. Both written style and strict schemas achieved strong results, but strict schemas were chosen for ongoing development because they proved significantly more cost-effective in token consumption.

```mermaid flowchart TD accTitle: Testing Communication Formats for Agents accDescr: Comparison of three prompt schemas for communicating design systems to AI models. subgraph Testing["Evaluation Methods"] A["Option A: Strict Schema"] -->|"Selected (Cost-effective)"| Success["High Accuracy"] B["Option B: Written Style"] -->|"High Accuracy"| Success C["Option C: Lint-Annotated"] -->|"Failed Expectations"| Worst["Worst Performer"] end ```

The team then set out to test a core question: can an agent adhere to a design system when given only a single, deliberately vague prompt? They tasked the models with a broad prompt: *"Build a product page for this app. Someone using it needs to see the products, edit one, and delete one."* A product page was specifically selected because human UX logic dictated that users needed to visually scan items as image cards rather than text rows in a table, even though software engineering convention defaults to tabular data representations.

The initial rollout was a frustrating failure across 33 separate agent runs. Only 18% of the executions produced the desired card-based layout; the other 82% fell back to standard tables. While the agent had technically followed the design system without human intervention—assembling a valid side panel, top bar, and table components from the repository—it missed the higher-level design intention entirely.

- The evaluated communication schemas: Strict Schema (Option A), Written Style (Option B), and Lint Annotated (Option C). - Benchmark sample size: 33 automated agent runs against the identical vague prompt. - Baseline success rate for expected visual patterns (cards vs. tables): 18%.

---

[14:04](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=844s) The Rookie Mistake and the Power of the Harness

Investigating the persistent failure revealed what Arely Rivera termed a "really rookie mistake": a single sentence in the agent instructions. Because LLMs operate with extreme literalism, the wording had inadvertently biased the agent toward generating a tabular structure. Once that single phrasing flaw was corrected, the benchmark achieved a 100% success rate across runs, reliably generating image cards instead of data tables.

To prove the utility of the scaffolding, the team ran a comparison test removing the harness entirely while maintaining the exact same model, repository access, design system, and prompt. Without the harness, the agent output degraded visibly into unstyled, disjointed HTML. Rivera noted that while the harness does not produce code that is immediately ready to deploy to production without review, it yields a dramatically superior starting baseline compared to unconstrained generation.

---

[15:02](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=902s) Taste, Judgment, and a Designer in the Rails Codebase

Evaluating these results led Rivera to confront an uncomfortable professional question: if an agent equipped with an effective harness can reliably reproduce design systems, does that make the human designer replaceable? Her conclusion was nuanced: repetitive, procedural execution is absolutely replaceable, but human judgment, taste, and user advocacy are not. "Repeatable is not the same as good," Rivera explained. The harness standardizes execution, but humans remain essential for deciding what deserves to be built, understanding real user constraints, and steering how the design system evolves.

```mermaid flowchart LR accTitle: Separation of Execution and Human Judgment accDescr: The division of labor between AI execution harnesses and human engineering judgment. subgraph AgentRole["The Harness & Agent"] H1["Repeatable Execution"] H2["Token & Component Adherence"] end subgraph HumanRole["Human Designer / Engineer"] J1["Taste & User Context"] J2["System Evolution & Strategy"] J3["Safety & Wiring Verification"] end AgentRole -->|"Provides Base Code"| HumanRole ```

This dynamic fundamentally altered Rivera’s own day-to-day work. At the start of the year, she did not know how to run a Rails application locally. Empowered by agents and engineering scaffolding introduced by Alicia Rojas, she now works directly within production Rails repositories across client projects. While Figma and traditional prototyping tools attempt to simulate realities, working directly in code exposed live platform constraints immediately. Because execution has become cheap and commoditized, human judgment and taste from both designers and developers have become significantly more valuable.

---

[17:10](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=1030s) Fidelity Testing, Window Washers, and Client Case Studies

Alicia Rojas rejoined the presentation to discuss how engineering teams can run fidelity testing on their own codebases to see whether an agent can survive their architecture. The speakers shared a public GitHub Gist providing their standardized testing prompt and framing guidelines. Rojas emphasized that teams should not view agent failures as prompting errors or LLM deficiencies, but rather as diagnostic feedback exposing missing constraints, ambiguities, or architectural gaps in their harness.

The framework, built on the five-layer "Onion Design Framework," was applied successfully across several client engagements at their software agency, Telos Labs:

- **Legal Tech Client:** Rivera designed directly in the application codebase using the harness, handing off functional PRs to engineers. This minimized fidelity loss between design intent and production implementation, serving as a functional foundation rather than an abstract mock-up. - **Rapid Turnaround Client:** Facing strict budget and time constraints, the team delivered a completely new product experience in under four days within a legacy repository that had a weak pre-existing design system by working backward from solutions.

Rojas closed with a safety analogy: window washers working on high-rise buildings are trusted for their skill, experience, and survival instinct, but buildings still mandate physical harnesses because "safety cannot be relying on trust alone." In software, "a rule that is not enforced, it's not a rule. It's a suggestion. And production can certainly not run on suggestions."

Rather than continuing decades of mutual babysitting—engineers policing designers' code contributions or designers scrutinizing production apps to see if their hex codes survived—the system itself should enforce baseline constraints. By delegating compliance checking to automated harnesses, engineers and designers can focus their time on taste, judgment, and high-level problem solving. Rojas challenged the Rails World audience with a parting question: *"Who on your team could be shipping if the harness were better?"*

## Notable quotes > [00:12](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=12s) Would you merge this? — Alicia Rojas

> [00:12](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=12s) Worst-case scenario, something will look ugly, so not too bad. — Alicia Rojas

> [02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) let's try to enforce mechanically what can be mechanically enforced, and encode the rest of the patterns and the taste in written rules, natural language rules — Alicia Rojas

> [02:38](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=158s) I built a track so Arely could drive. — Alicia Rojas

> [05:53](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=353s) Yes, you can have a ton of rules, but a rule that is not enforced is not a rule. It's a suggestion. — Alicia Rojas

> [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) you can build, but you can build only using these values. — Arely Rivera

> [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) because here is where all the magic happens. All the design decisions happen here. — Arely Rivera

> [08:23](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=503s) but that's not the value. The value is actually understanding why the agent made that mistake. — Arely Rivera

> [12:01](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=721s) Build a product page for this app. Someone using it needs to see the products, edit one, and delete one.

> [14:04](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=844s) really rookie mistake — Arely Rivera

> [15:02](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=902s) Repeatable is not the same as good. — Arely Rivera

> [17:10](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=1030s) safety cannot be relying on trust alone. — Alicia Rojas

> [17:10](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=1030s) a rule that is not enforced, it's not a rule. It's a suggestion. And production can certainly not run on suggestions. — Alicia Rojas

> [17:10](https://www.youtube.com/watch?v=D1Y3tzhiAkw&t=1030s) Who on your team could be shipping if the harness were better? — Alicia Rojas

## Mentioned Alicia Rojas, Arely Rivera, Telos Labs, Ruby on Rails, Rails World, Rails World 2026, Shopify, DHH, CLAUDE.md, AGENTS.md, Onion Design Framework, Figma, GitHub Gist

## Video description What happens when a designer ships a 7,000-line PR to production? At #RailsWorld 2026, Telos Labs software engineer Alicia Rojas and lead product designer Arely Rivera share the story of how a harness (design tokens, shared partials, and a short natural-language contract for AI agents) let Arely work directly in a Rails codebase, and what broke when it shipped anyway.

They introduce the Onion Design Framework, five layers running from tokens and primitives to composed patterns, written rules, and screens, built so that agents can read and follow a design system. They also share results from running 33 agents on a single vague prompt, the one-sentence mistake that changed the outcome, and why cheaper execution makes human judgment and taste more valuable, not less.

*** Thank you Shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

[Source](https://www.youtube.com/watch?v=D1Y3tzhiAkw)

中文简报

Telos Labs利用AI Harness让设计师交付生产级Rails代码自动化智能体框架使常规编码大众化，人类的设计品味和工程判断力非但未被淘汰，反而更加宝贵。软件工程师Alicia Rojas与产品设计师Arely Rivera探讨了一个轻量级框架如何让Rivera直接为生产级Rails代码库贡献代码，并提交了一个通过自动化CI却遗漏了四个细微UI缺陷的7000行拉取请求。为了防止偏差并让AI智能体清晰理解UI系统，他们建立了“洋葱设计框架”（Onion Design Framework），该五层架构涵盖从令牌和原语到组合模式、书面规则以及用于诊断反馈的界面屏幕。通过对智能体进行的33次运行基准测试，他们揭示了单次措辞错误如何导致视觉布局生成偏离轨道，以及修正该框架如何达成可靠结果。最终，他们认为，虽然框架将重复性执行工作标准化，但在决定哪些内容值得构建方面，人类的品味与判断力仍然不可或缺。 Telos Labs工程师Alicia Rojas与设计师Arely Rivera展示了一个由设计令牌、共享partial以及一份10行Markdown协议组成的68行框架，如何使设计师交付数千行生产级Rails代码。 (2:38) 最初一个7000行的拉取请求通过了所有CI检查和测试，但仍遗留了四个视觉与结构缺陷，这突显出未强制执行的设计规范充其量只是建议。 (5:53) 该团队推出了“洋葱设计框架”（Onion Design Framework），这一涵盖令牌、原语、模式、书面规则和界面屏幕的五层模型，旨在使自主编码智能体能够清晰理解系统规则。 (8:23) 在一项包含33次智能体运行的基准测试中，修正智能体指令中一句无意造成的偏向性表述，使设计系统遵循度从18%的基线提升至100%。 (14:04)

Reading summary

Software engineer Alicia Rojas and lead product designer Arely Rivera argue that enclosing AI agents within structured design and engineering harnesses enables designers to ship code directly to production Rails applications. While harnesses commoditize procedural implementation, the authors emphasize that mechanical enforcement remains vital because automated testing cannot prevent subtle user-experience drift. Unenforced Rules and the 7,000-Line Diff (2:38) When Rivera submitted a pull request with over 7,000 additions across 153 files, Rojas merged it after four automated CI suites passed. The diff was less volatile than it appeared: 64% comprised an internal component catalog, only 100 lines were net new production markup, and the core foundation relied on a 68-line harness containing 46 design token lines, a shared partial reused across 50 call sites, and a 10-line natural-language agent contract. Rojas had committed 1,600 scaffolding lines, while Rivera authored over 6,000 lines—accounting for 94% of the branch additions—using AI agents. Despite passing security checks, linters, and test suites, the release caused four defects: 24 hard-coded hex values, an invisible duplicate canonical SEO tag, shrunken form labels affecting every form builder in the app, and a white navbar vanishing against a white background on scroll. Although the harness reduced codebase hex values from 119 to 24, addressing the omissions required an unplanned UX audit and four remediation pull requests. Rojas concluded that an unenforced rule functions merely as a suggestion, noting that standard engineering reviews fail to ask the questions necessary to catch visual and structural design regressions. The Five-Layer Onion Design Framework (8:23) Because AI agents now consume design systems alongside humans, Rivera created the "Onion Design Framework," a five-layer concentric model where outer layers strictly inherit constraints from inner tiers. Layer 1 (Core Tokens) specifies non-negotiable values like spacing, elevation, and corner radii. Layer 2 (Primitives) establishes basic components like buttons and inputs alongside interactive and accessibility states. Layer 3 (Composed Patterns) integrates these primitives into functional units, such as detail panels, preventing models from reinventing established user flows. Layer 4 (Written Rules) provides situational context and taste, defining which pattern suits a given scenario—analogous to instructing an agent when to employ a solid wooden door versus a sliding glass pane. The outer boundary, Layer 5 (Screens), delivers the assembled interface. Rivera emphasized that the primary value of the screen layer is diagnostic evidence: when an agent generates an incorrect layout, developers should not merely patch the screen, but trace the root cause back to missing token constraints in Layer 1 or ambiguous instructions in Layer 4. Benchmarking Agent Communication and Prompt Fragility (12:01) Evaluating instruction formats, the team observed that strict schemas matched the accuracy of prose descriptions while significantly lowering token costs, whereas lint-annotated instructions performed the worst. To examine compliance, they tested a single unconstrained prompt asking models to build a product page with viewing, editing, and deletion capabilities. While human UX design dictated image cards for visual scanning, initial tests across 33 agent runs yielded the card layout only 18% of the time, defaulting to tabular data rows in 82% of runs despite assembling valid components. Rivera traced this failure to a single instruction sentence that inadvertently biased the LLM toward tables. Correcting that phrasing raised card-generation success to 100%. Conversely, removing the harness entirely while maintaining identical model access, repository files, and prompts degraded output into unstyled, fragmented HTML. The authors concluded that while an agent harness does not produce unreviewed, deploy-ready code, it guarantees a coherent baseline that unconstrained generation cannot replicate. Elevating Human Judgment Over Commoditized Execution (15:02) Rivera noted that while effective harnesses render repetitive procedural implementation replaceable, human judgment, user advocacy, and taste remain irreplaceable. Equipped with engineering scaffolding, Rivera transitioned from being unable to run Rails locally to submitting functional pull requests directly in client repositories. At Telos Labs, this workflow minimized fidelity loss between design intent and implementation for a legal technology client, and enabled the team to ship a redesigned product in under four days within a legacy application. Rojas compared the system to high-rise window washers: though trusted for their experience, safety protocols mandate physical harnesses because safety cannot rely on trust alone. In software development, establishing automated enforcement eliminates reciprocal policing between engineers and designers. By offloading compliance checking to harnesses, teams free human contributors to focus on system evolution, product context, and architectural decisions. Rojas and Rivera demonstrate that robust agent harnesses allow non-engineers to contribute directly to complex codebases, but emphasize that teams must actively encode and mechanically enforce their constraints. They leave engineering organizations with the diagnostic challenge of identifying which non-engineering teammates could be shipping production code if their repository harnesses were sufficiently safe.

Source quotes

[0:12] Alicia Rojas: Would you merge this? [0:12] Alicia Rojas: Worst-case scenario, something will look ugly, so not too bad. [2:38] Alicia Rojas: let's try to enforce mechanically what can be mechanically enforced, and encode the rest of the patterns and the taste in written rules, natural language rules [2:38] Alicia Rojas: I built a track so Arely could drive. [5:53] Alicia Rojas: Yes, you can have a ton of rules, but a rule that is not enforced is not a rule. It's a suggestion. [8:23] Arely Rivera: you can build, but you can build only using these values. [8:23] Arely Rivera: because here is where all the magic happens. All the design decisions happen here. [8:23] Arely Rivera: but that's not the value. The value is actually understanding why the agent made that mistake. [12:01] Build a product page for this app. Someone using it needs to see the products, edit one, and delete one. [14:04] Arely Rivera: really rookie mistake [15:02] Arely Rivera: Repeatable is not the same as good. [17:10] Alicia Rojas: safety cannot be relying on trust alone. [17:10] Alicia Rojas: a rule that is not enforced, it's not a rule. It's a suggestion. And production can certainly not run on suggestions. [17:10] Alicia Rojas: Who on your team could be shipping if the harness were better?

Original transcript

[0:06] [music] [0:12] >> Uh welcome to this talk. I'm super [0:14] excited to be here. I'm Alicia Rojas. [0:16] I'm a software engineer. I've been [0:18] working [0:20] uh developing software with Telus Labs [0:22] for about 5 years, and I'm super excited [0:25] to be here. Also, big thanks to the [0:27] organization who slightly bent the rules [0:30] to allow me to be here today with this [0:31] wonderful designer, Areli. [0:35] >> Hi everybody. I am Areli product [0:37] designer designer. I've been designing [0:39] for the last 8 years, and the last 3 [0:41] years I've been working with Alicia in [0:43] Telus Labs. [0:45] >> So, today we're going to talk about the [0:48] story of how this designer here started [0:52] shipping rails uh into production. [0:55] >> [clears throat] [0:56] >> So, imagine you're handed this PR [0:59] uh over [1:00] 7,000 lines added, almost 2,000 lines [1:03] deleted, and 153 files touched. [1:08] Would you merge this? [1:12] Okay, maybe 3 or 4 years ago I would [1:15] have seen this and I would have thought [1:16] like, [1:17] "Are you insane?" Especially coming from [1:19] a designer. [1:20] >> [laughter] [1:21] >> "Why on earth wouldn't you split this [1:22] into several PRs, especially if we're [1:24] talking about front-end code?" [1:27] Um net- nonetheless, [1:30] I did merge it. Uh [1:32] it was reviewed. I was the engineer who [1:34] reviewed it. [1:35] Uh I run it locally. I made sure [1:38] everything was working well, the [1:41] critical flows. [1:43] Uh I did end-to-end review. [1:45] It was fine. [1:46] Uh I looked at the diff and saw mostly [1:49] markup and CSS, so thought, [1:52] "Worst-case scenario, something will [1:53] look ugly, so [1:55] not too bad." Uh it had four checks [1:57] working uh well, so all green. Security, [2:01] uh linters, automated tests, all looking [2:04] good. [2:05] So, I shipped it. [2:07] And it broke. [2:08] In four ways. Um [2:10] I still think it was the right thing to [2:13] do to merge it. And the reason of that [2:15] is a structural. [2:17] And that's uh what we're going to talk [2:18] about today. [2:21] So, an an engineer review is not the [2:23] same as a QR uh sorry, QA review. It [2:27] doesn't ask the same questions [2:29] uh a QA review does. [2:31] I didn't ask myself some of those [2:33] questions. [2:34] Uh so, yeah. [2:36] It did break. [2:38] Um so, what these over 7,000 lines [2:41] actually were? When you look at the [2:43] decomposed diff, it's a bit less [2:45] impressive than it seems at first [2:47] impression. [2:48] So, 64% of it it was a dev only catalog [2:52] that was never served to a user. [2:55] Uh it only had about 100 lines of net [2:59] new production markup. [3:01] And here's the interesting number. It [3:03] had 60 lines of a harness. [3:06] This harness was uh 46 lines of tokens. [3:09] Uh [3:10] a partial that was called across 50 [3:13] sites. And a 10-line contract in a cloud [3:16] MD file. So, natural language rules for [3:19] the agent to follow. [3:21] Uh it could be also an agent MD or [3:22] whatever you use. [3:24] Uh we just called it the contract. [3:29] So, let's take a step back and talk [3:32] about how this [3:33] >> [sighs] [3:34] >> come to happen. How did uh [3:36] designers ship a 7,000 lines uh PR? [3:40] I had been tinkering and playing around [3:42] with this idea of harnesses for a while [3:44] now. [3:46] And we had this code base which was kind [3:48] of a playground uh to experiment and [3:51] uh implement harnesses to be able to [3:55] work with agents in a safe way. [3:57] So, it was already fairly agent-friendly [4:01] and thus it was Adelle friendly as well. [4:05] So, it had decent branch protection [4:06] rules, [4:08] uh CI checks that were trustworthy, and [4:10] I had personally set up some bash hooks [4:14] uh and permission settings that allowed [4:16] me to work safely with agents in it, and [4:18] also allowed me to trust that Adelle [4:20] could uh work on it without presenting [4:23] like a threat to production. [4:27] So, we have been thinking about the idea [4:29] of harnesses for a software and like [4:31] architecture and patterns, [4:33] and we came to the idea of implementing [4:36] the same idea of harness for design [4:39] work. So, how do we make the agents do [4:43] what we want uh in terms of the screens [4:46] on the front end uh stuff. We had been [4:48] kind of achieving that goal in the Ruby [4:51] part, but not quite in the front end [4:53] part. [4:55] So, we took this idea of let's try to [4:58] enforce mechanically what can be [5:01] mechanically enforced, [5:03] and like encode the rest of the patterns [5:05] and the taste in like written rules, [5:07] natural language rules, [5:09] uh DHH's favorite language uh we we [5:13] learned this morning. [5:15] So, I started this [5:17] so Adelle could work in the front end [5:19] right uh directly in the code. So, I did [5:22] this this harness commit, which was [5:24] about 1,600 lines, [5:26] uh with the foundations of the idea of [5:29] harness for designer. [5:31] And then Adelle took it [5:33] and she like overtook it and did more [5:36] than 6,000 lines. So, 94% of the branch [5:40] additions were hers. [5:43] This is split is kind of the story uh [5:46] and the the kind of core of this idea [5:48] here. [5:49] I built a track [5:51] so I didn't could drive. [5:53] But yeah, as as I said earlier, four [5:55] defects escaped. And to be honest, some [5:58] of them were actually trackable in the [6:00] diff. [6:01] Uh first, it had 24 hard-coded hex [6:04] values, which is kind of awkward because [6:06] it was violating the same rule this PR [6:09] was implementing for the first time. [6:12] Uh two of those [6:14] uh hard-coded hex values were in files [6:16] it had touched. [6:18] And a design review caught it [6:20] afterwards. [6:22] There was a generally new page [6:23] introduced [6:25] which had a duplicate canonical tag. Uh [6:27] it was rendered as nothing, so there was [6:29] no user impact uh visually. [6:33] And an SEO uh [6:35] audit caught it. [6:37] Then were there were two other [6:39] defects that were only visible by a [6:42] human or an agent looking at the page. [6:45] So, one of them was that every form [6:47] label in the app shrank. [6:49] It was one line in one form builder that [6:52] propagated elsewhere. [6:54] This was token compliant. [6:56] The CI was green. [6:58] No one caught it except a human [7:00] afterwards [7:01] uh doing an a UX audit. [7:04] Then we had [7:06] a white navbar on a white page. To but [7:09] to be fair, it had been correctly [7:12] correctly placed in four other places, [7:14] but it missed on the fifth, and it was [7:16] like a weird edge case where uh [7:18] scrolling at a certain point would [7:20] render the navbar white. And again, only [7:23] a human look caught it. [7:26] What the structure did uh [7:28] caught [7:29] was other things. So, we actually went [7:31] down from 119 [7:34] hard-coded hex values to just 24, which [7:36] is good. [7:37] We had no invented components, no [7:40] arbitrary fonts or spacings, so the [7:43] harness kind of did what it had to do. [7:48] But yeah, these defects occurred and it [7:50] had they had a cost. [7:53] We had one unplanned UX audit. [7:57] And four follow-up PRs to fix these [7:59] defects. [8:00] And only one of these three things was [8:02] actually planned, which is the harness, [8:04] the 60 68 uh lines of harness. [8:09] So, what we learned from this exercise [8:12] is that yes, you can have a ton of [8:13] rules, [8:15] but a rule that is not enforced is not a [8:18] rule. [8:20] It's a suggestion. [8:23] >> And with all that said, we came to a [8:26] realization. [8:27] Now that I've been working with agents, [8:29] I've been generating screens with [8:31] agents, um the design system mirror is [8:33] not a person anymore. Sometimes it can [8:36] be an agent. And when we are generating [8:38] screens with agents, we need to make [8:40] sure that they understand the system, [8:42] that they can apply the system [8:44] correctly, and that they can read the [8:45] system. [8:47] Um that's why um we came with this [8:49] system of five layers. [8:52] Uh each of these layers has their own [8:54] function and they all depend on the [8:56] decision in the inner layer. And Alicia [8:59] came with the name because it kind of [9:01] looks like an onion, right? So, Alicia [9:04] named it the onion design framework. [9:07] So, let's go layer by layer. Uh the core [9:09] layer, [9:11] uh which is basically telling the agents [9:13] that you can build, but you can build [9:15] only using these values. [9:17] They are just value definitions that you [9:19] can um [9:20] you can Some examples will be um [9:23] spacing, corner radios, elevations, [9:26] stuff like that. And then we have the [9:28] next layer, which is primitives. [9:30] Um this layer, of course, uh has the [9:32] values of the inner the inner layer [9:35] tokens. [9:36] Um basically, you will find the smallest [9:38] building block that we have. Uh Buttons, [9:40] think about cards, think about input [9:42] text, all those all those small values. [9:47] Um, and they're not only visually [9:49] reusable, they are actually they carry [9:51] states, they carry accessibility and [9:54] they [9:55] can carry special requirements. The next [9:58] layer is called composed patterns. Think [10:00] about building blocks that are built of [10:04] course the smallest building blocks of [10:06] primitives. But these building blocks [10:08] already work. [10:09] Let's say that you have a detail panel [10:11] that you know it works. So, the agent [10:13] shouldn't be inventing a new one all the [10:15] time. So, just use what already works [10:18] and just [10:19] change the copy or whatever you're [10:20] changing. [10:22] But that's basically composed patterns. [10:24] And then we go to my favorite layer, [10:25] which is written written rules. That's [10:28] my favorite layer because here is where [10:30] all the magic happens. All the design [10:32] decisions happens here. [10:34] And in written rules, you will find the [10:37] context for the agent. The agent will [10:39] know [10:40] what situation situation they're in [10:43] so that they can make the right decision [10:45] to follow the right pattern. [10:47] And I want to make an analogy. Think [10:48] about in layer two primitives, you have [10:52] a piece of wood, a big piece of wood, a [10:54] frame and a knob. [10:56] And in layer three composed patterns, [10:58] you have a door. [11:00] You know a door works, that pattern [11:03] every user knows how to enter a door. [11:06] But in written rules, you will find [11:09] the agent will know that when to use a [11:11] wooden door versus [11:13] a sliding glass door. That's basically [11:15] the magic of written rules. [11:17] And then the last layer is screens. A [11:20] screen is the output, everything [11:22] assembled. [11:23] Um, but it's also there is something [11:25] really valuable about this layer is that [11:28] you can find evidence. And what do I [11:30] mean by evidence? Evidence is um [11:33] when we have a generated screen by an [11:35] agent, we can see what went wrong. Um [11:38] but we can, of course, fix that right [11:41] away, but that's not the value. The [11:43] value is actually understanding why the [11:45] agent made that mistake. Once you do, [11:47] you can actually go to that to our [11:49] layers and fix it. Was it a broken [11:52] token? We were missing something on [11:54] tokens. Was it something wrong with [11:55] written rules? [11:57] So, [11:58] after all these layers uh came through, [12:01] uh [12:01] we still wanted to answer the question [12:04] like, how do we communicate this [12:06] effectively with the agents? So, we run [12:08] three tests. [12:10] Uh [12:11] of the option A was a strict schema, [12:13] option B was a written style, and option [12:15] C was a lint annotated. Um my assumption [12:18] was that option C was going to win, but [12:21] it actually was the worst. And written [12:23] style and strict schema did great, [12:25] actually. But we decided strict schema [12:27] because it's more cost-effective. [12:30] And now that we have all these, we [12:32] wanted actually to test it to answer the [12:34] next question. Can an agent follow a [12:37] design system from one prompt? And we [12:40] selected a really big prompt [12:42] intentionally, and this is it. Build a [12:44] product page for this app. Someone using [12:46] it needs to see the products, edit one, [12:48] and delete one. Pretty big, just to see [12:51] can the agents actually follow the [12:54] system and make the right decisions and [12:56] might complete my uh [12:58] exceed my expectations. And the reason [13:01] why we selected product page is because [13:03] in this case, um for users, it was [13:07] better to have uh scanning products as [13:10] cards as images than rows as a table [13:13] because the expected pattern is to do a [13:16] table, but [13:18] uh we have everything ready and set up, [13:21] and our expectations were high, but it [13:24] failed 33 times. We run 33 agents to [13:28] with that same prompt and only 18% of [13:31] the time they actually follow the [13:32] pattern that we were expecting. Um and [13:36] if we take out that we were expecting to [13:38] have [13:39] cards instead of a table, it's great. [13:42] Look at it. It's actually I mean there's [13:44] no human intervention. [13:45] Um [13:46] it made a great result. Um we have a [13:49] side panel, a top bar, we have a table. [13:51] The table you're looking at is part of [13:53] the design system. So, it was making [13:55] great decisions, but it was still wrong. [13:59] And after getting really frustrated [14:01] about it, not understanding [14:04] what was going on, I I run a lot of [14:06] agents and then I realized that I made a [14:09] really rookie mistake. And it was a [14:12] sentence. And because I forgot that I [14:14] was talking to agents, agents are quite [14:17] literal. So, whatever what I was telling [14:19] them to do, they were actually doing it, [14:21] but that was my mistake. So, [14:24] after changing it, 100% of the runs um [14:28] actually exceed my expectation. It gave [14:31] me a cards over table. So, now that we [14:34] have this framework, [14:37] what will happen if we remove the [14:39] harness and just keep the same prompt, [14:41] the same model, the same access to that [14:43] design system, the same repository, and [14:46] I think you can see it for yourself. Uh [14:48] these images speak for themselves. Um [14:50] I'm not saying that with the harness [14:52] it's perfect. I'm not saying that this [14:53] is ready for user to this is ready for [14:55] deploy now, but I think it's a better [14:58] start than with no harness. Um [15:02] and looking at this, [15:04] I started to question [15:06] to ask this question that is really [15:08] uncomfortable. [15:09] Does this mean that having a good [15:11] harness, having a good design system, [15:12] understanding uh agents and agents [15:15] actually knowing your system, does this [15:16] mean that I am replaceable? [15:19] And to be honest, uh they're a pretty [15:22] process, yes, definitely. But the [15:24] judgment, no. [15:26] And I think that's a great thing. [15:29] Um because repeatable is not the same as [15:32] good, and the harness has made execution [15:35] repeatable. We still need someone to [15:38] determinate uh what's worth being [15:40] repeated. We still need to understand [15:42] users. We still need to evolve the [15:43] system to apply taste, to know the [15:46] system, to grow the system. Um [15:49] And I want to share something uh [15:51] that in the beginning of this year [15:54] um I didn't even know how to run a Rails [15:56] project. And that's honest. That That [15:59] That's the honest um thing. But [16:02] um now I've been working in a lot of [16:04] Rails repositories uh thanks to that I [16:08] can work with agents. And thanks to [16:10] Alicia, that door has been opened for [16:12] me. [16:13] And I And I've been doing more impact [16:15] and impact more in a better way products [16:17] because I can actually work in the [16:19] repository and actually work in the [16:20] product. Because I can see at live like [16:23] constraints. I can actually experience [16:25] it. And it it's not that I couldn't [16:27] before. We had other tools [16:29] um [16:30] that cool kind of replicated. But at the [16:33] end of the day, a prototype is still a [16:35] prototype. [16:36] And that's why I feel [16:38] that being able to work in a repo has [16:41] made me a better designer. And after [16:43] doing working all these months this way, [16:47] um I came to a realization and to answer [16:49] the question if I am repeatable if I am [16:52] replaceable, um I came to a conclusion [16:55] that now that execution has been cheaper [16:58] it definitely uh [17:00] made the value of judgment of developers [17:03] and designer way more valuable. [17:10] >> So, are you ready to test whether your [17:13] Rails code base will survive [17:16] uh [17:17] will agent survive other way around? [17:19] Like will a cold agent survive your code [17:21] base? [17:23] If you're interested in doing this [17:24] fidelity testing that I really just [17:26] showed, we have a guest prepared for you [17:28] with the prompt and kind of the [17:31] broad framing for an agent to just go [17:35] and [17:36] uh [17:37] implement something with the least [17:39] context given. So, you may treat defects [17:43] in the result not as a defect in your [17:45] prompt, not as a defect in the agent, [17:48] but as a gap in your system, right? A [17:50] gap in your harness. [17:52] So, do it a couple of times. Don't stay [17:55] with the first result. You might have [17:56] different results as Adeli had, but it [17:59] will for sure give you an idea of where [18:03] you might improve your harness. [18:06] So, this framework travels. We're a [18:09] software agency, so we work with [18:10] different clients. We have implemented [18:14] parts of this framework, this this onion [18:17] layer design in different products. We [18:20] have a product from the legal tech [18:22] industry in which the design team, aka [18:25] Adeli, has been designing directly in [18:28] code and handing the developers the [18:30] design in this way. So, there is much [18:33] less lost between the mock-up and the [18:36] actual code that is built. This again [18:39] doesn't mean this will like be shipped [18:42] straight to production without an [18:44] engineer actually looking at it and [18:46] actually making like the wire, [18:48] but it definitely is a better starting [18:50] point for a developer than a Figma [18:52] thing, right? [18:54] Then we had another [18:56] case study where in under four days [18:58] working from their own code base, [19:01] we developed a whole new experience. It [19:03] had a very poor design system, but with [19:05] this harness it was way faster to build [19:08] it, which was important we had we had [19:12] a kind of severe budget constraints with [19:14] this client. So, in this case, we [19:16] started from the solution and worked [19:19] backwards. [19:22] So, let's take a step back and like be [19:24] philosophical for a moment. [19:27] And I'm going to use an analogy here [19:29] cuz analogies are our friend. Um let's [19:32] think of a window washer, right? He's or [19:36] she is standing in a high-rise. We trust [19:39] their judgment that they're not going to [19:40] throw themselves into the void. We trust [19:43] their experience that they're [19:45] not going to fall, [19:46] but we do still install the harness, [19:48] right? [19:49] Because safety cannot [19:51] be relying on trust alone. [19:55] And in software is kind of the same. We [19:57] have learned that a rule that is not [20:00] enforced, it's not a rule. It's a [20:02] suggestion. And production can certainly [20:05] not run on suggestions. [20:09] This has been kind of [20:11] never one directional though. Uh like we [20:14] tend to think that developers are [20:16] babysitting designers in this, but [20:19] designers have been babysitting us for [20:21] years. Like checking that the colors [20:24] they picked, the fonts they picked on [20:26] Figma survived into the code. [20:29] And I don't really want to work in a [20:31] team where anyone babysits anyone, [20:33] right? So, we build the harness. [20:36] We build a system. We let it do the [20:38] checking. And when the then we keep the [20:40] people for trust for judgment and taste [20:44] as I really was saying. [20:47] So, open your repo this week and ask [20:49] yourself the question we came here to [20:52] ask you. [20:53] Who on your team could be shipping if [20:56] the harness were better? [20:59] >> [applause] [21:04] >> Thank you so much for being here. If [21:06] you're If you love this talk, we have [21:08] the written version of it in this QR. [21:11] So, take the button home. [21:13] This contains the examples, the prompts, [21:15] what broke, so you can bring it to your [21:18] own repository and tell us how it went. [21:21] I have another talk that I did before on [21:25] harness engineer for rails specifically. [21:27] You can check it out later and I can [21:29] show you where it is. [21:31] Thank you so much. [21:33] >> [applause] [21:36] [music]