A conference talk by Dru Knox, head of product and design at Tessl, recorded at the AI Engineer World's Fair 2026 in San Francisco, on harness engineering, the discipline of moving a team from using coding agents to running a software factory in which agents write the software users receive. The talk, as summarized by the creator, defines a software factory by autonomy, automation and quality, and covers inner, outer and meta loops, why harness engineering is difficult (fast-changing field, unplanned work, signals trapped in local logs), and three layers to build: a control plane, agent-ready infrastructure, and improvement loops. It also covers metrics such as manual takeovers, human PR comments, and PRs started without a human. Tessl products (skills registry, Tessl Agent, Tessl Launch) are presented as examples of this approach. The claims are the speaker's own framing and no independent verification is included in the record. # Channel Identity Observations — Video: "Harness Engineering: How to Build a Software Factory — Dru Knox, Tessl" ## Explicit Self-Description Evidence ### Speaker & Company Affiliation - The speaker introduces himself directly: **"My name is Drew Knox. I'm the head of product and design at Tessle."** - The company is described as: **"Tessle is an agent enablement platform. We help you go from scaling skills to building your own software factory."** ### Company Positioning Claims - **Product tie-in is explicit and framed honestly:** "most of the topics I'm going to talk through here today work with any stack. They're mostly techniques. Tesla makes them easy, but they're not exclusive to us." - Claimed product values: "iterative and sustainable," "batteries included," "a real commitment to being modular and open," and incremental adoption: "six months later like, oh wow, we're like 40% there to a software factory." - Product features named: **skills registry** with governance, **Linear-to-GitHub connectors**, **code review tools**, **Tesla agent**, and a **"Tesla launch"** command to turn skills into automated workflows. - CTA closes the talk: "Tesla booth is just that way. Please give a scan, come over, see us." ## Observable Presentation Evidence ### Intended Audience - The talk explicitly targets an **advanced, practitioner audience** already using coding agents: > "This is a bit of an advanced talk in the sense that like if you aren't already using coding agents what I'm about to walk through is probably not where you want to get started." - Stated prerequisites: multiple concurrent agent sessions, agents succeeding on easy/medium tasks — "you're sort of at the sweet spot for starting to think about harness engineering." - Audience is framed as fellow practitioners frustrated by fast-moving terminology: "I'm sure you're all probably as frustrated as I am with how quickly terminology changes." ### Claimed Scope of Content - A structured agenda is announced and followed: 1. Defining **software factory** and its rationale 2. **Harness engineering** (also noted as "loop engineering" — "a sign of how fast terms evolve") 3. Components of harness engineering (control plane, "agent-ifying" infrastructure, improvement loops) 4. Brief product walkthrough of Tessl ### Demonstrated Presentation Style - **Educational/conference-talk format** with numbered parts, mental models (inner loop, outer loop, "metal loop"), and pillar metrics (autonomy, automation, quality). - **Candid caveat-heavy tone:** the speaker flags honesty points such as "full disclosure upfront harness engineering... is hard" and humor about naming: "if you want to help me make them so [standard terms], I would be forever grateful." - **Opinionated positions** offered as company belief, e.g., quality payoff: "at Tesla, we believe that yes, at first as you transition, you will want to keep quality constant... but that the ultimate payoff is you should see better quality." ## Summary of Channel-Level Signals (Observable Only) - This video presents as a **vendor-led technical talk** from a product executive at Tessl, blending conceptual education with a product pitch, aimed at experienced agentic-development practitioners. - No channel-wide scope or private motivations were inferred; all observations above are grounded in quoted transcript passages. # Delivery Observations: "Harness Engineering: How to Build a Software Factory" *Basis: transcript only. Bracketed numbers (e.g., [12]) are the transcript's own markers. Audio-level features such as pace, vocal emphasis, and pauses cannot be observed from text.* --- ## 1. Overall Tone **Conversational and informal, with a practitioner's directness.** The speaker addresses the audience as peers and uses plain phrasing for technical material. - Opens with a personal introduction and product context: "My name is Drew Knox. I'm the head of product and design at Tessle." - Uses colloquial phrasing for serious points: "I promise it's worse than you think." - Expresses frustration and shared experience: "I'm sure you're all probably as frustrated as I am with how quickly terminology changes..." **Uncertainty note:** The transcript cannot show whether this is delivered warmly, dryly, or in another register. --- ## 2. Recurring Verbal Habits ### Filler and discourse markers | Feature | Observed examples | Frequency note | |---|---|---| | **"right?"** as a tag question | "...obviously have a connection, right?" / "...a very shortterm phenomenon, right?" / "The they help catch things..." | Recurs across several sections | | **"Uh"** | "Uh you've gotten to a place..." / "Uh and then we also have a suite of tools..." | Frequent | | **"So"** as a transition | "So before we get started..." / "So what do I mean by loops?" | Very frequent | | **"like"** as a hedge or filler | "...if you aren't already using coding agents..." / "Like there's no one who has come in..." | Frequent | | **"Okay."** as a section break | "Okay. Part one, software factories." / "Okay, with all that aside..." | Used at major transitions | ### Self-correction in the moment The speaker corrects mid-sentence rather than cutting the flow: > "Automation uh oh sorry I've gotten them flipped here. Uh autonomy is the first one." > "...the outer loop or sorry the metal loop is where you're going to be actually driving..." This is one of the clearest repeated delivery features: corrections are spoken aloud, not edited out. --- ## 3. Signposting and Structure The talk is heavily signposted. The speaker repeatedly announces what comes next and how many items there are. - **Agenda:** "So I'm going to walk through a few things. First, I want to define software factory... Second, we're going to then focus a lot on harness engineering... And finally, I'll walk through how the Tesla product..." - **Counted lists:** "I mentioned three key metrics." / "I've broken it into three layers." / "There are three core concepts..." - **Recap callbacks:** "I mentioned how most of the data..." / "these are the things I mentioned before the like inner outer metal loop." > "I've broken it into three layers. These aren't by any means standard terms, though if you want to help me make them so, I would be forever grateful." **Pattern:** Each major section is introduced with a count and then returned to later. This is a consistent organizational habit across the talk. --- ## 4. Teaching Habits ### Defining terms, then admitting imperfection The speaker often defines a term and then qualifies it: > "There's no strict definition... But roughly speaking, a software factory is any agentic system where..." > "It's also started to be called loop engineering over the last couple weeks." ### Distinguishing close concepts The talk repeatedly separates similar ideas: > "They sound quite similar, but there is a difference. You can have high autonomy in the sense that agents frequently are oneshotting the problems..." ### Concrete examples after abstractions Abstract points are often followed by a specific workflow: > "...all work starts as an issue on the issue tracker. It gets sent to a headless agent running in a sandbox. The agent puts up a PR and then engineers engage with comments on the PR." ### Stating prerequisites and audience fit > "This is a bit of an advanced talk in the sense that like if you aren't already using coding agents what I'm about to walk through is probably not where you want to get started." ### Candid framing of difficulty > "I think full disclosure upfront harness engineering at least uh raw unassisted harness engineering is hard for a few specific reasons that basically come down to human psychology." --- ## 5. Vocabulary and Metaphor ### Coined or repeated terminology - **Harness engineering**, **software factory**, **inner loop / outer loop / meta loop**, **control plane**, **agent enablement**, **autonomy / automation / quality** - The speaker notes the terms are unstable: "as a sign of how fast terms evolve, it's also started to be called loop engineering..." ### Figurative language | Phrase (as transcribed) | Function | |---|---| | "snake eating the moose all at once" | Contrasts incremental vs. big-bang adoption | | "stuck in the local maxima" | Describes stalled agent improvement | | "batteries included" | Describes built-in product knowledge | | "a massive grab bag" | Describes miscellaneous setup work | | "with horror" | Describes discovering hidden dependencies | **Note:** The transcript renders "elephant" as "moose," which is likely a transcription error. It is quoted here as it appears. ### Humor Light humor appears in a few places, such as "I promise it's worse than you think" and the "snake eating the moose" line. --- ## 6. Audience Address - **Second person dominates:** "you," "your team," "you're going to..." - **Collective framing:** "you're all," "folks," "most folks look at factories as..." - **Direct calls to action near the end:** "Please give a scan, come over, see us. We'd love to chat." --- ## 7. Shift Between Teaching and Product Promotion The delivery changes register partway through. - **Teaching segments:** Use general terms, hedges ("these are just techniques"), and "any stack" language. - **Product segments:** Use Tessle-specific phrasing and commitments: > "We're batteries included. So we solve the knowledge gap by saying we will keep up..." Explicit boundary markers signal the switch: > "As I mentioned, everything I've said before here are just techniques. You could go do them all yourself if you wanted." > "So I'm going to talk a little bit through how Tessle will help you if you want to use us." The speaker also notes a live video segment: "After this, I'm going to play a video while we talk. See how this goes." --- ## 8. Stable Patterns vs. Isolated Moments **Stable (observed repeatedly):** - Heavy use of "So," "Uh," "like," and "right?" - Signposted, counted structure - Inline self-correction - Definition followed by qualification - Concrete example following abstraction **Isolated (appeared once or twice):** - The "snake eating the moose" metaphor - "with horror" - "I would be forever grateful" - "full disclosure upfront" - The closing call to visit the booth --- ## 9. Limitations - **Transcript-only analysis.** Prosody, pacing, emphasis, and facial or stage delivery are not observable. - **Transcription artifacts.** The title says "Dru Knox" but the transcript says "Drew Knox." The product is written as "Tessle" in some places and "Tesla" in others. Quotations preserve the transcript's spelling. - **Single talk.** Patterns are drawn from one presentation, so they describe this delivery and should not be generalized to the speaker's usual style. # Observation Record: Harness Engineering — Dru Knox (Tessl) ## Speaker Identification - **Speaker:** Dru Knox (self-introduced), Head of Product and Design at Tessl. Company described as an "agent enablement platform." ## Scope & Prerequisites (as stated) - Talk positioned as **advanced**: assumes attendees already use coding agents, run multiple sessions, and see agents succeed on easy/medium tasks. - Claims apply to any stack; Tessl "makes them easy" but techniques are not exclusive to Tessl. ## Part 1: Software Factories ### Definition - No strict definition exists; terminology shifts quickly. - Working definition: an **agentic system where all shipped output is created by agents**; engineering teams become **internal tool builders** improving the factory. ### Three Pillars (stated order) 1. **Autonomy** — how much humans must correct/nudge agents. 2. **Automation** — how much agents can run without human review before acceptance. Speaker notes these are distinct: high autonomy with low automation is possible (agents one-shot but humans still review everything). Autonomy must precede automation. 3. **Quality** — product quality via user analytics, test quality/coverage. ### Claim: Factories improve quality, not just speed - Speaker argues most view factories as velocity ("a little bit of slop" but more features) — calls this a **short-term phenomenon**. - Position: with a factory, "the idea of a backlog kind of goes away," enabling test quality improvements and refactors; keep quality constant (or small dip) during transition, then raise it. - Additional claim: easier contribution from non-technical roles; "more dynamic and inclusive development experience." ## Part 2: Harness Engineering - Also recently called **loop engineering** — cited as evidence terminology evolves fast. - Core practice: building the loops that automate and improve the factory. ### Three Loops - **Inner loop** — pre-PR, fast/cheap, run constantly; drives autonomy. - **Outer loop** — post-PR, expensive exhaustive checks (agentic QA, mutation testing); encodes verification that builds trust; drives automation. - **Meta loop** (transcribed "metal loop") — observes agent logs, PRs, issue tracker, user feedback; finds escaped mistakes; feeds fixes back into inner/outer loops; driver of "AI-nativeness." ### Stated Difficulties (attributed to "human psychology") 1. **Fast-changing discipline** — teams "become AI researchers"; best practices go stale and become anti-patterns. 2. **Unplanned work** — competes with shipping; "perpetually hard trade-off" (local maxima vs. missed deadlines). 3. **Illegible information** — signals hidden in local logs, individual machines, people's heads. ## Part 3: Three Layers of Harness Engineering (speaker's own, non-standard terms) 1. **Control plane** — issue tracking → headless agent in sandbox → PR → engineer comments (Tessl's flow). Three common components: issue tracker kickoff, review (GitHub PRs easiest), skills registry/shared repo. 2. **"Agent-fitting"** (transcribed "agent it") — exposing CLIs, APIs, product access, prod logs, execution environments; governance/compliance questions. Speaker claims: "I promise it's worse than you think" — no one finds it easier than expected. 3. **Improvement loops** — repo maintenance sweeps, playbooks for common tasks, identifying repeated tasks for automation, output-quality feedback into skills. ## Part 4: Tessl Product (vendor section) - Pitch: incremental ("small lifts rather than one massive" migration), batteries-included best-practice knowledge, modular/open, automated loops. - Features: skills registry with governance/security review; Linear→GitHub connectors ("more connectors coming soon"); agentic code review suite; Tessl Agent for mining PRs/issues to find automatable repeated tasks; out-of-the-box weekly maintenance scans; `tessl launch` — turn any skill into an automated workflow run in a sandbox (supports Tessl Agent, Codex, Claude Code, Gemini per speaker). ## Success Metrics Suggested - Drive down manual takeovers and human PR comments. - More PRs initiated without human input. - Hold quality constant, then raise it. ## Qualifications Preserved - Definitions explicitly non-standard/evolving; speaker acknowledges inventing layer terminology. - Autonomy ≠ automation distinction maintained. - Speaker's quality claim is a stated belief ("we believe," "we think"), not presented as measured result. # Video Attribution Record ## Video - **Title:** Harness Engineering: How to Build a Software Factory — Dru Knox, Tessl - **Video ID:** `01a15ca6-eaca-7989-9216-948d8729dd04` ## Speakers & Roles - **Dru Knox** (transcribed as "Drew Knox") — **Sole speaker**, self-identified as **Head of Product and Design at Tessl** (transcribed variously as "Tessle"/"Tesla"). - Role: **Company representative / presenter** delivering a conference-style talk. - No guests, narrators, or other speakers appear in the transcript. ## Promotional Segments (Flagged) The talk transitions from general technique discussion into **product promotion for Tessl**. Promotional content includes: - Explicit framing: *"how the Tesla product uh briefly can help you along that journey"* — followed by disclaimer that techniques *"work with any stack."* - **Tessl product pitch:** iterative adoption, "batteries included" best-practice maintenance, modularity/openness, automated loops. - **Feature walkthrough:** skills registry with governance; **Linear-to-GitHub connectors** (with "more connectors coming soon"); code review tool suite; **Tessl Agent** for mining PRs/issues; **`tesl launch`** command to turn skills into automated workflows supporting external coding agents (**Codex, Claude Code, Gemini** per speaker intent). - **Closing call to action:** *"Tesla booth is just that way. Please give a scan, come over, see us."* ## Referenced Sources & Claims - **No formal cited sources** (papers, studies, links) are named in the transcript. - Speaker references general industry context only: terminology changing fast; "loop engineering" as an emerging alternative term for harness engineering. - Speaker presents proprietary opinion/claims on Tessl's behalf ("At Tesla, we believe...") — **third-party unverifiable company claims**, not external citations. ## Provenance & Availability Notes - **No curated metadata supplied** — speaker identity/role comes solely from self-introduction in the transcript. - **Comment availability:** Not indicated in source material; **unknown/unavailable**. - A **product demo video** is mentioned mid-talk ("I'm going to play a video while we talk") but its content is not in the transcript. - Transcript contains notable spelling variance for company and product names (Tessl/Tessle/Tesla) — treated as the same entity per speaker intent. Quick introduction. My name is Drew Knox. I'm the head of product and design at Tessle. Tessle is an agent enablement platform. We help you go from scaling skills to building your own software factory. So today I'm going to talk about a few things. The core is going to focus on harness engineering which we see as sort of the new discipline of agentic development and how you can use it to ladder up to a software factory. So before we get started a few prerequisites. This is a bit of an advanced talk in the sense that like if you aren't already using coding agents what I'm about to walk through is probably not where you want to get started. So, I'm sort of assuming that if you're working with coding agents, you're used to having a couple sessions at a time. Uh you've gotten to a place where coding agents will for like easy tasks and maybe medium complexity tasks frequently do the right thing. This you're sort of at the sweet spot for starting to think about harness engineering, starting to think about a software factory. What I'm going to say here is not exclusive to that, but that's where you'll get your best results. So, I'm going to walk through a few things. First, I want to define software factory and talk a little bit about why you might want to build towards one. Second, we're going to then focus a lot on harness engineering, which is kind of the core practice or skill that you'll use to reach a software factory. We'll talk about what are going to be the components you work on while you're doing harness engineering. And finally, I'll walk through how the Tesla product uh briefly can help you along that journey. But most of the topics I'm going to talk through here today work with any stack. They're mostly techniques. Tesla makes them easy, but they're not exclusive to us. Okay. Part one, software factories. What are they? There's no strict definition. I'm sure you're all probably as frustrated as I am with how quickly terminology changes and migrates in the in the industry today. But roughly speaking, a software factory is any agentic system where all of the end product of what you're building and shipping to users is created by agents and your software engineering teams effectively focus on building the factory. So they work on making the factory more autonomous, more automated, and raising the quality of what it produces. I'll go into each of those terms in just a second. That's kind of the core idea of a factory though is everyone on your team effectively becomes internal tool builders and then you're building a system that produces your product. So I mentioned three key metrics. These are sort of like the pillars you need to think about when building towards a software factory and they sort of go in this order. So autonomy is effectively how much human intervention do you need to get to the right answer. So how many times you need to correct the code or provide a nudge on how the agent should be building. Automation uh oh sorry I've gotten them flipped here. Uh autonomy is the first one. It's how much do you have to do humans have to correct? Automation is how much can you let them run, right? How much do you need to review or build trust in the solution before you accept it? They sound quite similar, but there is a difference. You can have high autonomy in the sense that agents frequently are oneshotting the problems you're giving them, but low automation because you don't trust it yet. And so you're reviewing all of the code directly. You are manually verifying everything. So they are distinct things that obviously have a connection, right? You have to build up autonomy first before you can move to automation. The final quality, probably the most self-explanatory, how good is the product that you're actually producing for your users? These metrics are like your usual user analytics, your uh test quality, your test coverage, etc. As you work towards a factory, you're going to go improving autonomy. then approving automation all while keeping quality constant and then the sort of payoff at the end. Why would you want a software factory is that ultimately we think you can raise quality once you have a factory. So talk about this a bit. I think most folks look at factories as a way to ship faster. They'll say like oh yeah you'll get a little bit of slop but my god you'll you'll launch so much more features like the cost return the ROI will be worth it. I think that's a very shortterm phenomenon, right? As agents are sort of coming online and getting better. In reality, yes, you will move to higher velocity with a factory. But every team has backlogs of bug fixes or improvements that they wish they could be making that they just don't have time to do or explorations that they wish they were they were doing. With a software factory, the idea of a backlog kind of goes away. And so you actually just have much more capacity to work on test quality improvements, architectural refactors. So at Tesla, we believe that yes, at first as you transition, you will want to keep quality constant or maybe like a very small dip, but that the ultimate payoff is you should see better quality uh in the code that you're producing. Also, it's great for your overall team collaboration styles. So once you've moved to a software factory, it's much easier for people who aren't in technical roles to contribute ideas. So it's easier to explore more and to have more perspectives coming in and contributing while your engineering team is much more focused on building the underlying system that everyone is using to push features out to your users. So I think ultimately it leads to a more dynamic and inclusive uh development experience. So, how do you get to a software factory? Harness engineering, uh, as a sign of how fast terms evolve, it's also started to be called loop engineering over the last couple weeks. Um, this is really the core discipline that you're going to take to get towards a software factory. At its core, harness engineering is, you know, I mentioned the software factory is building your product. you are building the loops that automate and improve the quality of your factory. So what do I mean by loops? What are the loops that you might be working on? There are three core concepts each at maps to a certain phase of development. So you have your inner loop which is as the coding agent is working on a PR before it has put it up. Right? So these are very fast iterative loops. You want them to be cheap. You're expecting the agent to run them all the time. Improvements here will drive better autonomy. The they help catch things and correct the agent without your uh coming in and human intervention. Once the PR is up, you move to the outer loop. So this is where you're going to put more expensive exhaustive checks that don't make sense to run over and over again as the agent is iterating on features, but they do encode things that otherwise a human would have to verify to build confidence in the system. And so this is because they're more expensive, but they are taking away human review time. They can be worth it, right? So this is where you might put something like aentic QA or where you might say like run mutation testing to check the quality of our test suite. This is for expensive things you want to run once when the PR goes up and then have the agent iterate on on the results. Finally, you have the metal loop. This is where you'll drive quality. So the metal loop sits outside of the development process. It observes your coding agent logs. It looks at PRs, your issue tracker, user feedback, and it's basically finding mistakes that are making their way through the pipeline to your users or that you had to correct as a human to stop that from happening and it feeds back into the inner and the outer loop to make sure that that mistake is not made again. So the outer loop is what really kind of once you have the infrastructure for each of these loops, the outer loop or sorry the metal loop is where you're going to be actually driving from a certain percentage of like how AI native am I? You're going to be driving it up by investing in your metal loop. Before we get into like what are the components, what do you do to actually accomplish this? I think full disclosure upfront harness engineering at least uh raw unassisted harness engineering is hard for a few specific reasons that basically come down to human psychology. So the first hopefully this one will go away over time but it's a new discipline and it's changing very fast and so a lot of teams that get into harness engineering you basically become an AI researcher just to try and keep up. you're reading papers, you're watching blogs, you're coming up with best practices that go out of date the next week and then two weeks after that and actually at some point they become antiatterns and you don't want to do them anymore. Uh, and so there just like a lot of time and space you'll devote to keeping up with how to do harness engineering. And so if you want to get into this discipline, you need to have a sort of upfront approach to how you're going to solve this problem. How are you going to make time and space to keep up with the knowledge that's changing every week? The second, and this one is more durable in my opinion, harness engineering is fundamentally unplanned work. So you will start shipping a feature. You have no way to anticipate will agents fail? How will they fail? How long is it going to take me to fix it? And all of that work that you're going to do to try and make the agent better competes with shipping, right? So it will slow you down from getting the features out. And we all know that is just a perpetually hard trade-off to make. You either don't do it and you get stuck in the local maxima of the agent never improves or you do it and you miss your deadline for the feature and you get in trouble and so no one ever does it. The final piece is that once you've solved these initial problems to like make time and space for harness engineering, you'll find that a lot of the information you want access to is not available. it's hidden away in local coding agent logs or it is on someone's machine somewhere. It's in someone's head. A lot of the signals that you want to see to make agents better, you need to do some work to move your workflows onto surfaces where everything is saved and publicly available for later optimization loops. Okay, with all that aside, then what are the pieces that you should be working on as you're doing harness engineering? I've broken it into three layers. These aren't by any means standard terms, though if you want to help me make them so, I would be forever grateful. The first layer, and these are sort of like in the order you need to do them as far as Tesla is concerned, is you have to get your control plane right. And so I mentioned how most of the data that you want to have access to to make agents better and move towards a software factory is not legible. If you move your workflows into for example at Tessle we have all issue all work starts as an issue on the issue tracker. It gets sent to a headless agent running in a sandbox. The agent puts up a PR and then engineers engage with comments on the PR. So it still has manual correction. It still has manual interface but now all of your touch points with the agent are legible. So we can you can then point tools at them to pull that information down and make things better. Typically the three things that everybody comes to when they're trying to set up a control plane. So you have some way of tracking issues and kicking off agent work from that. You're going to have some way to review. GitHub PR review is probably like the easiest. Uh and then you're going to have some way to uh standardize and distribute workflows, playbooks, things that make the agents better. Typically, that ends up being something like a skills registry or a shared GitHub repo where you push skills that improve agent quality. Next is a massive grab bag that I call agent it, which is uh if anyone's ever tried to move like a project that had a lot of local config into something that someone else can set up and you realize with horror all of the dependencies that you thought were cleanly isolated and are not, you basically are going to have to go through the same thing with agents. There's going to be all these things that you thought were easily accessible by an agent, right? Like CLI, API access, giving a way for the agent to click through your product to build it. I I promise it's worse than you think. Like there's no one who has come in thinking like, yeah, yeah, yeah, it's not going to be that hard for us has left saying that at the end. And so there's just like a lot of pieces you'll work work through. And this is probably the most unplannable and most like spend a week, spend two weeks and just get it done. But it will come through things like writing writing down in your company brain how you get work done, what are your workflows, etc. You're going to have to give access to all your internal services, which will require governance and like API access questions. You're going to want to give a way to access production logs. Uh, and that's going to have its whole own question of like what's your compliance stance, things like that. Uh, and then you'll need an environment where the agent can execute the code that it is running. There's infinite more, but they're generally pretty company specific, and you'll just work through as you try to get agents to put code up without you intervening. You'll quickly learn what are the problems. Finally, this is where you'll end up spending most of your time. These are the improvement loops. So these are the things I mentioned before the like inner outer metal loop. These are components that tend to go into your metal loop. So repo maintenance. You're going to want things that sweep your codebase every day, every night, every week, something like that to look for problems. You're going to want playbooks for common development practices. So how to add a feature to your CLI. You're going to want to find a way to identify repeated tasks and automate them and ideally as quickly and easily as possible because otherwise people won't do it. And then you're going to want something that looks at the output quality just on a consistent basis and brings back improvements and learnings to the rest of your codebase. So say things like, oh, I saw the agent made this mistake. Let's update a skill on add like the playbook you have for adding features to the CLI. Let's update that so it doesn't make this mistake again in the future. So those three control planes Tessle sort of exist to try and help you solve them. As I mentioned, everything I've said before here are just techniques. You could go do them all yourself if you wanted. There's plenty of tools that do that. So I'm going to talk a little bit through how Tessle will help you if you want to use us. To start, why would you want to use us? So we focus really hard on making it relatively iterative and sustainable to get to the cutting edge. So we try to make it like a bunch of small lifts rather than one massive snake eating the moose all at once. We're batteries included. So we solve the knowledge gap by saying we will keep up and you will have an agentic experience that basically knows the best practices of harness engineering is kept up to date on your behalf. We have a real commitment to being modular and open. So we don't think every component of a factory is going to be bestin-class with a single company. We want to make sure you can pick and choose what is the most important piece for your stack. And then like I said, we focus on making it easy. So we have automated loops for you that you can install and just react to the changes that are proposed. And we really try to make sure it's just incremental steps so that you six months later like, oh wow, we're like 40% there to a software factory. We never had to stop and delay shipping or anything like that. So the first place that Tesla helps is in setting up your control plane. We have a skills registry where you can publish and version the workflows and the automations that you're working on with built-in governance things like security reviews, quality reviews, controls for who can publish and update what. We also have easy connectors for issue trackers to GitHub. Right now we're focused on linear to GitHub. So you can basically file a linear ticket and get it to run a GitHub workflow uh with more connectors coming soon. Uh and then we also have a suite of tools for code review. So this make it easy to set up your standards for agentic code review as well as more targeted checks. See here an example of something that like a workflow that has been posted to the registry being scanned for security quality uh and how much it actually improves the agents output. After this, I'm going to play a video while we talk. See how this goes. So, uh, we have an agentic experience called Tesla agent, which will help you with creating and then maintaining your improvement loops over time. So, the first thing that we do is we will help you with that change management of like how do I actually make the time to find repeated tasks and set them up in automation. So the agent will mine through PRs, issues, things like that and find like every week you do a hunt for flaky tests. Why don't we just set that up as a skill for the workflow and then we'll put it in automation on a GitHub action. So we help you actually make time to do the automations just like one workflow at a time. The second is that we come with a lot of out ofthe-box maintenance tasks. So I mentioned you want to have weekly scans for things like architecture quality, code duplication, uh how good are your test suites, do you have any security vulnerabilities? So if you use Tesla, you can just sort of like oneclick install a bunch of those things and just get weekly improvements to your codebase without any other effort. And then finally, we offer a way to turn any skill into an automated workflow. So it's through a command called Tesla launch where you effectively take a sk a skill that codifies a workflow. You can then pick a particular coding agent that you want to handle it. Tesla agent can be one of them. But for most coding tasks you probably want to use something like codeex, cloud code, gemini. We have access to all of them and we will run them in a sandbox that has the appropriate permissions. Can be long running. Uh we'll have GitHub token so that it can put up a PR and respond to comments as you leave them. Uh, so it just makes it really easy to automate workflows like that. And so with these things together, we just make it really easy to get started and just one at a time find an improvement, take a workflow, turn it into a skill, ship it to everyone, and then get your improvement loops going. The what you're going to want to focus on as you're doing this work is driving down manual takeovers, driving down human PR comments. So these are like metrics that you can track to see like how far am I towards software factory. And then over time you want to see more PRs initiated without human input. That's a sign that you're automating more. And then of course you want to first hold quality constant and then aim to drive it up after that. That's it. If you want to learn more Tesla booth is just that way. Please give a scan, come over, see us. We'd love to chat. Um thank you all for your time.