Davis Palmie of Factory explains the software factory, a system of agents that takes input signals such as bug reports and user feedback and turns them into production code. Topics include cost and model-choice questions leaders ask, the claim that review, debugging, docs and testing rather than coding are the bottleneck, principles for a factory (model-agnostic, sovereign deployment, SDLC-wide integration), starting with narrow use cases like incident triage, agent readiness pillars, and metrics such as signal-to-production time, interventions and cost per PR, including why token leaderboards are a poor measure. Content is drawn from the talk's own description and chapter list; the speaker's claims are presented as the talk's positions, not independently verified. # Channel Presentation Observations: "The Software Factory" (Davis Palmie, Factory) ## Source Scope - **Inputs:** Title and transcript only. No curated metadata was supplied. - **Limit:** These observations cover one video. They do not establish channel-wide patterns, cadence, or other content. ## Explicit Self-Description The speaker describes his own background: > "I'm Davis Palmy, a member of technical staff here at factory. Uh before this I co-founded Lummetric... and was acquired by factory and prior to that I was a engineering lead for Slalom's innovation lab." He also states his frame of reference: > "So I've seen AI deployments both across large enterprises and more AI native orgs." **Note:** These are the speaker's statements about himself and his experience. The transcript does not describe a channel mission or a channel self-description. ## Claimed Subject Scope The video presents one central concept: > "today I'm going to be talking to you about the software factory and how you can move towards an autonomous system that translates input signals into production code." Claimed scope runs from **input signals** (bug reports, user feedback, Sentry alerts) to **production deployment**. The speaker lists the agent's responsibilities as "triaging incidents, making plans, creating and updating docs, actually executing the code, reviewing it, testing it, rolling it out, and then monitoring that release." ## Intended Audience (Demonstrated by Content) The transcript addresses several audiences, mainly through who it names and which concerns it raises. ### Engineering and Organizational Leaders - Concerns include cost control, model selection, and organizational structure. For example: "how can I prevent massive cost overruns?" - It frames organization-wide governance: "your enterprise care about a software factory?" - It refers to "your teams," "your enterprise," and "your organization" throughout. ### Individual Engineers - It describes changing roles: "Engineers are going from typing code to governing agents." - It addresses how the role shifts: "the human engineer's role shifts to responding to exercising judgment and correcting the AI." ## Demonstrated Presentation Patterns ### Structure and Framing - **Question-driven sections.** The speaker poses numbered questions, such as "First, how can I prevent massive cost overruns?", then answers each. - **Historical narrative.** He frames progress as eras: "tab autocomplete, next token prediction" → entire files → agents → "entire systems." - **Principle lists.** The software factory is described through named principles: model agnostic, sovereign deployment, integrated across the SDLC, and surface agnostic. - **Pillar taxonomy.** Agent readiness is assessed across "eight pillars," including validation, build system, feedback loops, and observability. ### Recurring Vocabulary "software factory," "pillars," "agent readiness," "guard rails," "model agnostic," "surface agnostic," "signal to production time," "human intervention count." ### Company-Linked Assertions Many statements are attributed to Factory as company practice, such as "At Factory, you're not locked into a single model provider" and "At factory, every action is auditable." The video also references Factory's CEO ("As our CEO likes to say..."). These are company-positioned claims, presented as the speaker's account. ### Quantitative and Comparative Claims - Code review "with GPT 5.2 as with the latest Opus models, but at half the price." - Open-source alternatives "can slash your cost down to 10 to 30x cheaper." The transcript gives no methodology, sample, or source for these figures. ### External References The speaker cites news as context: "We've all seen the headlines about Uber's CTO blowing through the years, AI budget by April, or Microsoft clawing back clawed code licenses." These are reported as the speaker's framing and are not verified in the material. ### Adoption Advice The speaker recommends incremental rollout, starting with "something narrow and verifiable like incident triage," and states that engineers should keep "the human in the loop." ## Creator Claims vs. Demonstrated Material | Element | Nature | Source in Material | |---|---|---| | Speaker's background at Factory, Lummetric, Slalom | Self-description | Opening passage | | Software factory as the subject | Stated scope | "today I'm going to be talking to you about the software factory" | | Model choice reduces cost without performance loss | Claim, unsupported in transcript | "same performance on code review with GPT 5.2 ... at half the price" | | Factory offers multiple deployment options, including airgapped | Company-positioned claim | "We support everything from fully managed to bring your own machine to entirely airgapped" | | Outcome metrics beat token metrics | Stated position | "you want to measure outcomes, not tokens" | | Product features are presented alongside general advice | Observable pattern in this video | Repeated "At Factory..." statements | ## Limits and Caveats - **Single source.** No evidence here establishes channel-level patterns, recurring series, or the channel's broader audience. - **Promotional elements are visible.** The video mentions Factory's product capabilities throughout. This is an observed feature of the content, not an inference about motive. - **Transcription artifacts.** Some words appear to be mis-transcribed, such as "PTO frontier," which likely refers to a Pareto frontier. Quotations above reflect the transcript as given. - **Unverified figures and events.** Cost comparisons and news references are reported as stated and have not been checked against outside sources. # Delivery Observations: Davis Palmie, "The Software Factory" ## Scope and Evidence Limits - **Source:** One talk, one speaker, transcript only. No curated metadata was supplied. - **Not observable:** Pacing, pitch, volume, and gesture cannot be assessed from text. - **Transcript artifacts:** Several words look like speech-to-text errors (for example, "highle" for *high-level*, "clawed code" and "PTO frontier"). Quotes below reproduce the transcript as written. - **Stability:** Patterns that recur within this talk are noted as such. Nothing here establishes habits across other talks. ## Tone ### Conversational and direct - The opening is informal and greeting-based: "Hey folks, I'm Davis Palmy, a member of technical staff here at factory." - Direct address dominates: "Your agent's not just coding anymore." "Your end users don't care about how much you're spending on AI." ### Confident, with a persuasive edge - Claims are often stated plainly. "Engineers will not be replaced, but judgment and prioritization now beat mechanical implementation skill." - Strong opinions are framed as firm: "we feel pretty strongly that your software factory should have a few key principles." ### Lightly humorous - A relatable analogy with a joke: "if your kid needs a algebra tutor, you can definitely find someone cheaper than Albert Einstein." - A pop-culture reference: "It's goodart's law in real time." ## Vocabulary ### Recurring domain framing - **"Software factory"** is the central term, used throughout as the name for the system. - **"Governing agents"** and **"governance"** frame the engineer's role: "Engineers are going from typing code to governing agents." - **"Input signal"** and **"production code"** appear as a paired vocabulary for the system's inputs and outputs. - **"Abstraction ladder"** structures the history section: "climbing the abstraction ladder from tokens to files to context now to entire systems." ### Business and pragmatic language - "cost efficiency," "cost per PR," "executive visibility," "lock in," "ROI-adjacent" framing (for example, "the entire spectrum of cost performance") - "tribal knowledge," "outdated info," "dead code lingers" ### Informal intensifiers and filler - "Um" and "uh" appear repeatedly, for example "You want the maximum uh cost efficiency" and "Um, especially with the increasing effectiveness of open source models." - "Basically" is used as a summary marker: "Basically, the key takeaway here is that..." - "Obviously" appears several times: "the role is obviously evolving," "that's obviously a ton of work." ## Recurring Phrases and Structural Tics ### Question-then-answer ("Well,") Questions are posed and then answered with "Well," a repeated pattern: - "how can I prevent massive cost overruns? ... " - "Well, we think that having to back the right horse is a false choice." - "Well, the role is obviously evolving..." - "Well, team boundaries are also starting to blur..." - "Well, we typically see it as the fusion and the incremental automation..." ### Verbal enumeration Numbered points are spoken aloud in sequence: - "First, it should be model agnostic." - "Number two your deployment model should be sovereign." - "And number three, your software factory needs to be integrated across the SDLC." - "Lastly, how is this going to change the organization?" ### Transitional openers - "So" and "Now," start many sentences: "So, first we've moved through three distinct eras," "Now, that's obviously a ton of work," "Now also if agents can move across these surfaces..." ### Contrastive "not X, but Y" constructions - "But each move up the abstraction ladder has made engineers more valuable, not less." - "It's not about who spends the most on tokens. It's about who can get the highest leverage outcomes from that spend." - "Don't just turn them loose in your codebase." (imperative, paired with an earlier caution) ### Repeated product self-reference The speaker frames product capabilities with "At Factory" or "at factory," appearing across several sections: - "At Factory, you're not locked into a single model provider." - "At factory, every action is auditable." - "At Factory, we have agents available everywhere..." *Note:* Capitalization varies in the transcript, so the phrase is best treated as the same recurring pattern. ### Closing formula - Short imperative summary followed by a sign-off: "And don't token max. Measure what actually matters." Then "Thank you." ## Sentence and Rhetorical Patterns - **Rhetorical questions** are used to introduce sections: "What happens to software engineers?" - **Parallel triads** appear in lists: "keeping guard rails tight, catching code drift and setting the highle priorities" and "reviewing it, testing it, rolling it out, and then monitoring that release." - **Pithy closers:** "It never has." "Engineers will not be replaced..." - **Anaphora in principles:** The three principles are introduced in parallel form ("First... Number two... And number three..."). - **Analogies and historical framing:** "just like we don't have to feed punch cards into the machine anymore" ## Teaching and Explanation Habits ### Analogy-driven explanation - Algebra tutor analogy for model selection - Punch cards for historical comparison of code writing - Abstraction ladder for the progression of AI tooling - Goodhart's law for metric design ### Staged progression advice - The speaker repeatedly recommends incremental adoption: "You want to start with something narrow and verifiable like incident triage." - "You want to automate the individual pillars first before you turn this system into a loop." ### Concrete worked example - The incident triage example is walked through step by step: "Let your agent read a sentry alert, pull the traces in other context, and then post in Slack. But keep it so your engineers can review this..." ### Explicit signposting and summarization - "So with this the engineer's role shifts to..." - "So the undertaking of building the factory will expose tribal knowledge..." - "Basically, the key takeaway here is that..." - "So agent readiness is really a precursor to effective engineering." ### Diagnostic questions for the audience - "I bet if you look at your real engineering metrics, what's the median time to review a PR?" - "How long does it take you to reproduce user bug reports or go through and debug code?" - These questions prompt the audience to self-assess. ### Reframing a metric - "Lines of code and tokens generated are gameable metrics." - "Measure outcomes, not tokens." ## Hedging and Certainty Hedges are sparse and mostly used for opinions rather than factual claims: | Hedge | Example | |---|---| | "we think" | "we think that having to back the right horse is a false choice" | | "I bet" | "I bet if you look at your real engineering metrics..." | | "I would bet" | "the time from code written to time in production, I would bet dwarfs the time actually making those engineering changes" | | "typically" | "we typically see it as the fusion..." | | "conservatively" | "your software factory should take this pain from O of N to O of one conservatively" | Factual or product claims are typically stated without qualification, for example "We found, for instance, that you can achieve the same performance on code review with GPT 5.2 as with the latest Opus models, but at half the price." No supporting data or method is given within the transcript, so this claim is presented without visible evidence. ## Isolated Moments vs. Stable Patterns **Stable within this talk (repeated multiple times):** - "Well," as an answer lead-in - "So" and "Now," as transitions - "At Factory" product self-reference - "First / Number two / And number three" enumeration - "not X, ... Y" contrastive framing - Heavy "you/your" address **Isolated (appears once or twice):** - Algebra tutor and Albert Einstein analogy - Goodhart's law reference - Punch card comparison - "Thank you." as closer - "It never has." **Cannot be assessed:** Whether these patterns appear in other talks or contexts, since only this transcript was provided. # Observation Record: "The Software Factory: From Bug Report to Production Code" **Speaker:** Davis Palmie (rendered "Davis Palmy" in the transcript), member of technical staff at Factory. Stated background: co-founded Lummetric, an agent platform for investment teams, taken through Y Combinator and acquired by Factory; previously engineering lead for Slalom's innovation lab. --- ## Era Model of AI Engineering Palmie describes **three eras**, with each abstraction shift making engineers "more valuable, not less": 1. **Tab autocomplete** — engineer "firmly in the driver's seat" 2. **Whole-file generation** — engineer as a "discerning copy paster," still controlling output 3. **Agents** — tightly coupled to code; gather their own context, call tools, debug their own output His stated trajectory: tokens → files → context → **entire systems**. The engineer's role shifts to "governing agents" — keeping guardrails tight, catching code drift, and setting high-level priorities. ## Four Industry Questions and His Answers - **Cost overruns?** Cites headlines about "Uber's CTO blowing through the year's AI budget by April" and Microsoft clawing back Copilot licenses. Argues cost efficiency requires matching minimum effectiveness to each task, quoting Factory's CEO: *"if your kid needs an algebra tutor, you can definitely find someone cheaper than Albert Einstein."* - **Access to the best model?** Calls picking "the right horse" a **false choice**; advocates dynamic routing across providers. - **Future of engineers?** Role is evolving; line between product and engineering is blurring; engineers will build and maintain the system that builds production code. - **Organizational change?** Team boundaries blur; context must flow across them — "that was true for humans, but it's especially true for AI agents." ## Claim: Coding Was Never the Bottleneck - "Coding was the easy part." - Points to real engineering metrics: median PR review time, bug reproduction time, docs staleness, test suite maintenance, and DORA metrics where time-from-code-written-to-production "dwarfs" the actual change time. - Real need: **cohesion across surfaces** — stale docs, dead code, communication layers, which he says are "even more pronounced for agents." ## The Software Factory Concept - Defined as **the system of agents taking input signals (bug reports, user feedback) to production deployment**, spanning customer support, product engineering, deployment ops, and other roles. - Pillars: triaging incidents, planning, docs, executing, reviewing, testing, rolling out, monitoring. - **Incremental rollout caveat (explicit):** don't jump in all at once — "your teams will not have time to build trust." Start narrow and verifiable (e.g., agent reads Sentry alerts, posts diagnosis in Slack for human review). Each step needs careful ownership and monitoring **before looping the pipeline**. ## Three Stated Design Principles 1. **Model-agnostic:** Claims equal code-review performance with GPT 5.2 vs. "the latest Opus models" at half the price; open-source alternatives "10 to 30x cheaper." 2. **Sovereign deployment:** Fully managed to bring-your-own-machine to airgapped. 3. **Integrated across the SDLC:** docs, code, planning, and testing inform each other rather than flowing through "communication layers." ## Enterprise Value and Agent Readiness - Fragmentation pain reduced "from O of N to O of one conservatively" via one-time governance standardization. - Agents should be **surface-agnostic** (CLI, Slack, remote machines) with shared underlying harness and context. - **Agent readiness (8 pillars):** validation/linters, documented build/CI, feedback loops (tests), docs (readmes, agents.md), reproducible dev environments, modular code, observability, proactive security scanning. - "You can't govern what you can't see" — at Factory, "every action is auditable," with role-based access control and least privilege. ## Governance and Metrics Positions - **Humans remain in the loop** for architecture, strategy, and direction: "Engineers will not be replaced, but judgment and prioritization now beat mechanical implementation skill." - **Measure outcomes, not tokens:** token/line counts are "gameable metrics"; token leaderboards "encourage profligate spending" — explicitly frames this as **Goodhart's law in real time**. - Metrics Factory likes: signal-to-production time, human intervention count, median time to repair, shelf life of code, cost per PR. ## Notable Qualifications Preserved - "Precise execution does not prevent poor design. It never has." - Agents won't handle everything: "There will be guardrails to tighten, code that drifts. Humans need to stand as validation gates." - Building the factory will "expose tribal knowledge, manual processes, and outdated info" — presented as a benefit for both agents and humans. No contradictions with other speakers arise; the transcript is a single-speaker presentation. Model names and pricing claims (GPT 5.2, half-price parity, 10–30x savings) are presented as Factory's findings and should be treated as vendor claims, not independently verified facts. # Video Attribution Record: The Software Factory **Video ID:** `01a15ca6-e4ac-7d9f-b2f6-b059a31e82bb` **Title:** *The Software Factory: From Bug Report to Production Code*, Davis Palmie, Factory --- ## 1. Speakers and Roles ### 1.1 Primary Speaker - **Name (as spoken):** Davis Palmy - **Name (as titled):** Davis Palmie - **Name discrepancy:** The title and transcript spell the surname differently. The transcript is the only source for the spoken form. Neither source resolves which spelling is correct. - **Stated role:** "Member of technical staff" at Factory - **Speaking mode:** Single speaker, presenting to an audience. No other voices are identified in the transcript. ### 1.2 Stated Background (Self-Reported) The speaker reports the following prior roles. None are independently verified in the supplied material. - **Co-founder of Lummetric**, described as an agent platform for investment teams - Taken through Y Combinator - Later **acquired by Factory** - **Engineering lead, Slalom's innovation lab**, before Lummetric ### 1.3 Other Named or Referenced Individuals | Individual | Role as Stated | Attribution Notes | |---|---|---| | Factory CEO | Unnamed; referenced as "our CEO" | Algebra tutor analogy is attributed to the CEO. The analogy is not a direct quotation from the speaker. | | Uber's CTO | Referenced as an example | Described as having "blown through" an AI budget by April. This is a secondhand reference. | --- ## 2. Affiliation and Speaking Position - **Organization:** Factory, the presenting company - **Speaking position:** The speaker speaks on behalf of, or as a member of, Factory. - **Promotional stance:** The speaker describes Factory's products, practices, and internal framework as part of the presentation. See Section 4. --- ## 3. Referenced Sources and Third-Party Claims The transcript references the following external sources or claims. No URLs, publication names, dates, or document citations are given for any of them. ### 3.1 Named External Entities and Events - **Uber:** Claim that its CTO exceeded an AI budget by April. - **Microsoft:** Claim that it "clawed back" code licenses to reduce spend. The transcript reads "clawed code licenses." This is probably a transcription error for a specific product name, but the transcript does not confirm which product is meant. - **Sentry:** Referenced as an alert source that agents can read. - **Slack:** Referenced as a communication channel where agents post. - **GPT 5.2:** Referenced as a model that the speaker says matches the latest Opus models on code review performance at half the price. - **Opus models:** Referenced as the comparison baseline for the GPT 5.2 claim. - **Open-source models:** Referenced as alternatives said to be "10 to 30x cheaper." ### 3.2 Named Concepts and Frameworks - **DORA metrics:** Referenced when discussing time from code written to production. - **Goodhart's law:** Invoked to argue that token usage is a gameable metric. - **Agent readiness framework:** Described as a Factory framework with eight pillars: 1. Validation 2. Build system 3. Feedback loops 4. Dev environments 5. Code modularity 6. Observability 7. Security scanning The speaker says Factory "evaluate[s] this" using these pillars. The source of the framework is attributed to Factory. ### 3.3 Unsourced Quantitative Claims The following numerical claims are made without any cited source in the transcript: - Parity on code review performance between GPT 5.2 and the latest Opus models, at "half the price" - Open-source alternatives being "10 to 30x cheaper" - Token leaderboards "at big companies" encouraging "profligate spending" These are the speaker's own assertions. The transcript provides no supporting data, methodology, or citation. --- ## 4. Promotional Segments The following segments are **promotional** in nature. They describe or market Factory's products, capabilities, or commitments. > **Promotional content flag:** The majority of the presentation after the opening introduction is promotional. The sections below are flagged explicitly. - **Product capability claims** - Model agnosticism: "At factory you're not locked into a single model provider." - Dynamic routing: "We're strong proponents of... or even now have it dynamically routed." - Deployment options: "We support everything from fully managed to bring your own machine to entirely airgapped." - Surface availability: "At Factory, we have agents available everywhere from remote machines to the CLI to Slack." - Auditability and access control: "At factory, every action is auditable... role-based access control and least privilege." - **Company-specific framework:** The agent readiness assessment and the software factory concept are presented as Factory's approach. - **Closing call-to-action-adjacent statement:** The speaker states what end users "care about," framed around Factory's outcomes. **Non-promotional framing:** The opening biographical introduction and the general discussion of AI engineering eras are not framed as product promotion. They are the speaker's own narrative and perspective. --- ## 5. Availability Limits and Evidence Channels | Channel | Status | Notes | |---|---|---| | Transcript | Available | Full transcript supplied. Contains transcription artifacts (for example, "clawed code licenses," "PTO frontier," "highle," "Y Combinator" spelled normally). | | Curated metadata | Partial | Title only. No description, speaker bio, chapter markers, or source list supplied. | | Timestamps | Not available | The transcript has no timestamps. Segment locations cannot be cited by time. | | Cited sources | Not available | Referenced claims have no URLs or citations. | | Comments | Not available | No comment data supplied. Comment availability is unknown. | | Speaker identity verification | Not available | Speaker identity rests on the title and self-introduction. No external confirmation is supplied. | | Slide or visual content | Not available | The transcript is audio-derived. Any visual references (for example, displayed metrics or diagrams) cannot be recovered. | --- ## 6. Provenance Summary - **Who speaks:** One presenter, Davis Palmy (or Palmie), identified as a member of technical staff at Factory. - **Whose framework:** The agent readiness assessment and software factory concept are attributed to Factory. - **Whose claims:** Quantitative cost and performance claims are the speaker's own and lack cited sources. - **Third-party references:** Uber, Microsoft, Sentry, Slack, GPT 5.2, Opus, DORA, and Goodhart's law are mentioned without supporting citations. - **Promotional content:** Flagged in Section 4. - **Evidence gaps:** No timestamps, no cited sources, no comment access, and no independent speaker verification. --- ## 7. Verification Notes - **Named roles:** Explicit in the transcript. "Member of technical staff," co-founder of Lummetric, and engineering lead at Slalom's innovation lab are all stated by the speaker. - **Provenance facts:** Recorded above. No external sources were added. - **Promotion:** Flagged in Section 4. - **Quality judgment:** None entered this record. Hey folks, I'm Davis Palmy, a member of technical staff here at factory. Uh before this I co-founded Lummetric which was an agent platform for investment teams that we took through Y Combinator and was acquired by factory and prior to that I was a engineering lead for Slalom's innovation lab. So I've seen AI deployments both across large enterprises and more AI native orgs. With that in mind, today I'm going to be talking to you about the software factory and how you can move towards an autonomous system that translates input signals into production code. So, first we've moved through three distinct eras of AI engineering. First, we had tab autocomplete, next token prediction, and the engineer was still firmly in the driver's seat. Then AI could generate entire files and the software engineer became a bit of a discerning copy pastaster. Um, but they still heavily had control over the output of the AI. And then you had agents that were more tightly coupled with the code. They could gather their own context, call tools, and debug their own output. Now, autocomplete used to feel magical, and now at best it's it's a quaint thing we remember. You want to look at the speed at which AI engineering is climbing the abstraction ladder from tokens to files to context now to entire systems. Every shift you have here is an adjustment. But each move up the abstraction ladder has made engineers more valuable, not less. And so now we're at a transformational point. Engineers are going from typing code to governing agents and eventually you'll organize those agents into a system. That's your software factory. So with this the engineer's role shifts to keeping guard rails tight, catching code drift and setting the highle priorities and direction. But meanwhile, the system is ingesting input signals like bug reports or user feedback and outputting production code. So if you have AI systems that are producing more code than humans, there are some big questions that everyone is rightly asking. First, how can I prevent massive cost overruns? We've all seen the headlines about Uber's CTO blowing through the years, AI budget by April, or Microsoft clawing back clawed code licenses to try and cut down on spend. At Factory, you're not locked into a single model provider. And this means you unlock the entire spectrum of cost performance with LLMs. You want the maximum uh cost efficiency and the minimum effectiveness necessary for each task. As our CEO likes to say, uh if your kid needs a algebra tutor, you can definitely find someone cheaper than Albert Einstein. Second point, how can I ensure the best access to whatever model is top right now? Well, we think that having to back the right horse is a false choice. Um, especially with the increasing effectiveness of open source models. We're strong proponents of being able to choose the right tool for the right job or even now have it dynamically routed. Number three, what happens to software engineers? What does the future of software engineering look like? Well, the role is obviously evolving and the line between product and engineering is blurring. Engineers will now build and maintain the system that's responsible for building your production code and they'll set the highle direction for the software factory. And lastly, how is this going to change the organization? Well, team boundaries are also starting to blur and context needs to flow seamlessly across these boundaries. Information can't be siloed. That was true for humans, but it's especially true for AI agents. Everyone across all your teams will have a shared responsibility for the pillars of the software factory. Now, coding was the easy part. This actually was never the bottleneck. Your context is laid out in natural language. I bet if you look at your real engineering metrics, what's the median time to review a PR? How long does it take you to reproduce user bug reports or go through and debug code? Who keeps your docs current with every PR and who keeps it current with every strategy meeting? Who maintains your test suites? oftentimes the testing teams and the engineering teams and the product teams are each on their own continent. If you pull your dora metric, the time from code written to time in production, I would bet dwarfs the time actually making those engineering changes. The real need you have today is cohesion across all of these surfaces. Right now, docs will go stale, dead code lingers, and there are so many layers of communications between your different teams. Again, this is hard for human engineers, but it is especially more pronounced for agents. The necessary undertaking to build your factory is to make sure the agents can bridge all of these services and understand the nuance within your organization. So this brings us to the software factory which is the system of agents that will take you from input signal to production deployment. Your agent's not just coding anymore. It's taking on customer support, product engineering, deployment ops, and many other roles. Across these pillars, your agent should be triaging incidents, making plans, creating and updating docs, actually executing the code, reviewing it, testing it, rolling it out, and then monitoring that release. Now, that's obviously a ton of work, and you don't want to jump into that all at once. For one, it's too heavy of an undertaking, but for two, your teams will not have time to build trust in this system. You want to start with something narrow and verifiable like incident triage. Let your agent read a sentry alert, pull the traces in other context, and then post in Slack. But keep it so your engineers can review this and decide what to do. And as more correct diagnoses roll in and in from the agent, your team can start to build trust and an understanding of this pillar. So each step in the software factory needs careful ownership and monitoring before you even think about letting the the pipeline loop. But once you can tie the output of this system back to the input signal, that's when you unlock organizational self-improvement. Now we feel pretty strongly that your software factory should have a few key principles. First, it should be model agnostic. Obviously, different models excel at different tasks and with very different cost efficiencies. We found, for instance, that you can achieve the same performance on code review with GPT 5.2 as with the latest Opus models, but at half the price. And now if you look at the open- source alternatives that can slash your cost down to 10 to 30x cheaper. So at factory again you have the entire interplay of speed to task efficacy to cost. Not being locked into a single lab means you unlock the entire PTO frontier of LLMs. Now number two your deployment model should be sovereign. You shouldn't have to compromise on your security architecture or your policies to try and fit your AI deployment model in. Now at factory you can choose your workspace and your deployment model. We support everything from fully managed to bring your own machine to entirely airgapped. And number three, your software factory needs to be integrated across the SDLC. These are no longer separate uncoupled concerns. Docs changing should inform your code and vice versa. Planning goals should inform what you test for, not however many communication layers there are between strategy, product, engineering, and your testing teams. Each one of these pillars supports the software factory. And weakness in one means a weakness in the entire system. So tactically in an AI native or what does this look like? Well, we typically see it as the fusion and the incremental automation of many sub teams under the umbrella of one software factory. Some really common patterns we see are triaging incoming signals like sentry alerts, having the agent make diagnosis before the human can even answer the page. Proactively testing security, scanning for secrets or vulnerabilities. Creating, maintaining your tests, monitoring the ones that are becoming brittle or unneeded. Again, keeping docs in sync with code. keeping docs in sync with your different meeting channels and then the classic reviewing code, commenting on PRs, rollouts, monitoring releases and with the agent doing all of this, the human engineer's role shifts to responding to exercising judgment and correcting the AI in such a way that it can learn from these mistakes. Now everything is transitive across sub teams. An improvement to one group means an improvement to the entire system. So why should your enterprise care about a software factory? Well, the larger and the more fragmented you are, the more you feel the linear pain of managing teams. In tech terms, your software factory should take this pain from O of N to O of one conservatively. You can define your guardrails, your agents, your docs, testing policies, really governance just one time and then standardize it across the organization. And this standard should make sure that everyone is pulled to the highest bar, not the lowest common denominator. Now also if agents can move across these surfaces then they can hold that quality bar across teams without you having to linearly scale your time to manage each one. And if agents are moving across all these services then you have one place where context can be unified and you can have executive visibility into how the entire SDLC is performing. Now, just like model agnosticism removes lock in, your agents should also be surface agnostic. They need to be highly available to your teams. Regardless of what tools they use, your teams should not have to compromise on their processes or their tooling to try and fit your AI provider in. At Factory, we have agents available everywhere from remote machines to the CLI to Slack, any tool your teams use. And even though humans and agents may use different services, everything should share the same underlying harness and context. So the undertaking of building the factory will expose tribal knowledge, manual processes, and outdated info. Unblocking these is not only going to help your agents, but it's also going to help your engineering teams. At factory, we have the concept of agent readiness and we evaluate this based on eight pillars. The first is validation. Do you have guard rails like llinters and formatterers in place? Then your build system. Are your build commands and CI well documented? Feedback loops. You have unit and integration tests tight and you have docs like readmes, agents.mmd files. Are your dev environments cleanly reproducible such that an agent can use them? Is your code modular with clear boundaries and rules against sprawl? Do you have observability? How long does it take you to find out why something went wrong? and are you proactively security scanning so that you don't have to worry about leaked secrets or vulnerabilities. Basically, the key takeaway here is that if your agents and your human engineers are going to walk the same roads, paving them well is doubly useful. Now, you can't govern what you can't see. And that's true for agents and human engineers. You can start with this agent readiness assessment, but no matter what, your engineers must monitor agent performance and control behavior. At factory, every action is auditable. It operates under your standards with role-based access control and least privilege. For example, your teams that are building this software factory need to first build trust and understanding. That's why you should roll this out incrementally. You want to automate the individual pillars first before you turn this system into a loop. And again, precise execution does not prevent poor design. It never has. You still heavily need humans in the loop for architecture, for strategy, and for setting direction. Engineers will not be replaced, but judgment and prioritization now beat mechanical implementation skill. Agents won't be able to handle everything. There will be guardrails to tighten, code that drifts. Humans need to stand as validation gates in this factory. But just like we don't have to feed punch cards into the machine anymore, code does not have to be written by hand. Your team should be able to set the strategy and their risk parameters and then let agents execute. And knowing if your agents are executing well comes down to measuring the right things. Basically, you want to measure outcomes, not tokens. Lines of code and tokens generated are gameable metrics. These are not actually associated with outcomes. Token leaderboards at big companies just encourage proflegate spending. It's goodart's law in real time. If you decide to measure token usage, engineers are going to optimize for token usage and then it's no longer a good metric. It's not about who spends the most on tokens. It's about who can get the highest leverage outcomes from that spend. Some metrics that we like at Factory are signal to production time, human intervention count, median time to repair, shelf life of code, and cost per PR. These are real tangible outcomes. So agent readiness is really a precursor to effective engineering. Whether it's an agent or a human that ends up in that system, your agents need the exact same careful governance as your engineers, tooling, access levels, systems for review. Don't just turn them loose in your codebase. And don't token max. Measure what actually matters. Your end users don't care about how much you're spending on AI. They care about feeling the dramatic improvements that will come from your software factory. Thank you. \>\> \[music\]