The Software Factory: From Bug Report to Production Code — Davis Palmie, Factory

AI Engineer · 18 min · 157 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:12Hey folks, I'm Davis Palmy, a member of technical staff here at factory.
  3. 00:18Uh 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.
  4. 00:34So I've seen AI deployments both across large enterprises and more AI native orgs.
  5. 00:41With 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.
  6. 00:55So, first we've moved through three distinct eras of AI engineering.
  7. 01:02First, we had tab autocomplete, next token prediction, and the engineer was still firmly in the driver's seat.
  8. 01:11Then AI could generate entire files and the software engineer became a bit of a discerning copy pastaster.
  9. 01:19Um, but they still heavily had control over the output of the AI.
  10. 01:23And then you had agents that were more tightly coupled with the code.
  11. 01:27They could gather their own context, call tools, and debug their own output.
  12. 01:32Now, autocomplete used to feel magical, and now at best it's it's a quaint thing we remember.
  13. 01:39You 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.
  14. 01:52Every shift you have here is an adjustment.
  15. 01:56But each move up the abstraction ladder has made engineers more valuable, not less.
  16. 02:04And so now we're at a transformational point.
  17. 02:07Engineers are going from typing code to governing agents and eventually you'll organize those agents into a system.
  18. 02:17That's your software factory.
  19. 02:19So with this the engineer's role shifts to keeping guard rails tight, catching code drift and setting the highle priorities and direction.
  20. 02:32But meanwhile, the system is ingesting input signals like bug reports or user feedback and outputting production code.
  21. 02:43So if you have AI systems that are producing more code than humans, there are some big questions that everyone is rightly asking.
  22. 02:52First, how can I prevent massive cost overruns?
  23. 02:57We'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.
  24. 03:10At Factory, you're not locked into a single model provider.
  25. 03:14And this means you unlock the entire spectrum of cost performance with LLMs.
  26. 03:21You want the maximum uh cost efficiency and the minimum effectiveness necessary for each task.
  27. 03:29As our CEO likes to say, uh if your kid needs a algebra tutor, you can definitely find someone cheaper than Albert Einstein.
  28. 03:40Second point, how can I ensure the best access to whatever model is top right now?
  29. 03:47Well, we think that having to back the right horse is a false choice.
  30. 03:52Um, especially with the increasing effectiveness of open source models.
  31. 03:57We're strong proponents of being able to choose the right tool for the right job or even now have it dynamically routed.
  32. 04:05Number three, what happens to software engineers?
  33. 04:08What does the future of software engineering look like?
  34. 04:12Well, the role is obviously evolving and the line between product and engineering is blurring.
  35. 04:19Engineers 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.
  36. 04:32And lastly, how is this going to change the organization?
  37. 04:35Well, team boundaries are also starting to blur and context needs to flow seamlessly across these boundaries.
  38. 04:45Information can't be siloed.
  39. 04:47That was true for humans, but it's especially true for AI agents.
  40. 04:52Everyone across all your teams will have a shared responsibility for the pillars of the software factory.
  41. 05:00Now, coding was the easy part.
  42. 05:04This actually was never the bottleneck.
  43. 05:06Your context is laid out in natural language.
  44. 05:10I bet if you look at your real engineering metrics, what's the median time to review a PR?
  45. 05:17How long does it take you to reproduce user bug reports or go through and debug code?
  46. 05:24Who keeps your docs current with every PR and who keeps it current with every strategy meeting?
  47. 05:30Who maintains your test suites?
  48. 05:32oftentimes the testing teams and the engineering teams and the product teams are each on their own continent.
  49. 05:38If 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.
  50. 05:50The real need you have today is cohesion across all of these surfaces.
  51. 05:54Right now, docs will go stale, dead code lingers, and there are so many layers of communications between your different teams.
  52. 06:05Again, this is hard for human engineers, but it is especially more pronounced for agents.
  53. 06:12The 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.
  54. 06:24So this brings us to the software factory which is the system of agents that will take you from input signal to production deployment.
  55. 06:35Your agent's not just coding anymore.
  56. 06:38It's taking on customer support, product engineering, deployment ops, and many other roles.
  57. 06:46Across 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.
  58. 07:03Now, that's obviously a ton of work, and you don't want to jump into that all at once.
  59. 07:10For one, it's too heavy of an undertaking, but for two, your teams will not have time to build trust in this system.
  60. 07:19You want to start with something narrow and verifiable like incident triage.
  61. 07:25Let your agent read a sentry alert, pull the traces in other context, and then post in Slack.
  62. 07:31But keep it so your engineers can review this and decide what to do.
  63. 07:37And as more correct diagnoses roll in and in from the agent, your team can start to build trust and an understanding of this pillar.
  64. 07:46So each step in the software factory needs careful ownership and monitoring before you even think about letting the the pipeline loop.
  65. 07:55But once you can tie the output of this system back to the input signal, that's when you unlock organizational self-improvement.
  66. 08:07Now we feel pretty strongly that your software factory should have a few key principles.
  67. 08:14First, it should be model agnostic.
  68. 08:18Obviously, different models excel at different tasks and with very different cost efficiencies.
  69. 08:25We 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.
  70. 08:35And now if you look at the open- source alternatives that can slash your cost down to 10 to 30x cheaper.
  71. 08:44So at factory again you have the entire interplay of speed to task efficacy to cost.
  72. 08:51Not being locked into a single lab means you unlock the entire PTO frontier of LLMs.
  73. 08:59Now number two your deployment model should be sovereign.
  74. 09:05You shouldn't have to compromise on your security architecture or your policies to try and fit your AI deployment model in.
  75. 09:13Now at factory you can choose your workspace and your deployment model.
  76. 09:17We support everything from fully managed to bring your own machine to entirely airgapped.
  77. 09:25And number three, your software factory needs to be integrated across the SDLC.
  78. 09:30These are no longer separate uncoupled concerns.
  79. 09:34Docs changing should inform your code and vice versa.
  80. 09:39Planning goals should inform what you test for, not however many communication layers there are between strategy, product, engineering, and your testing teams.
  81. 09:50Each one of these pillars supports the software factory.
  82. 09:54And weakness in one means a weakness in the entire system.
  83. 10:00So tactically in an AI native or what does this look like?
  84. 10:08Well, we typically see it as the fusion and the incremental automation of many sub teams under the umbrella of one software factory.
  85. 10:19Some 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.
  86. 10:31Proactively testing security, scanning for secrets or vulnerabilities.
  87. 10:38Creating, maintaining your tests, monitoring the ones that are becoming brittle or unneeded.
  88. 10:46Again, keeping docs in sync with code.
  89. 10:48keeping 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
  90. 11:05to exercising judgment and correcting the AI in such a way that it can learn from these mistakes.
  91. 11:13Now everything is transitive across sub teams.
  92. 11:17An improvement to one group means an improvement to the entire system.
  93. 11:23So why should your enterprise care about a software factory?
  94. 11:28Well, the larger and the more fragmented you are, the more you feel the linear pain of managing teams.
  95. 11:37In tech terms, your software factory should take this pain from O of N to O of one conservatively.
  96. 11:45You can define your guardrails, your agents, your docs, testing policies, really governance just one time and then standardize it across the organization.
  97. 11:59And this standard should make sure that everyone is pulled to the highest bar, not the lowest common denominator.
  98. 12:08Now 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.
  99. 12:20And 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
  100. 12:32is performing.
  101. 12:35Now, just like model agnosticism removes lock in, your agents should also be surface agnostic.
  102. 12:44They need to be highly available to your teams.
  103. 12:47Regardless 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.
  104. 12:59At Factory, we have agents available everywhere from remote machines to the CLI to Slack, any tool your teams use.
  105. 13:07And even though humans and agents may use different services, everything should share the same underlying harness and context.
  106. 13:17So the undertaking of building the factory will expose tribal knowledge, manual processes, and outdated info.
  107. 13:28Unblocking these is not only going to help your agents, but it's also going to help your engineering teams.
  108. 13:35At factory, we have the concept of agent readiness and we evaluate this based on eight pillars.
  109. 13:43The first is validation.
  110. 13:45Do you have guard rails like llinters and formatterers in place?
  111. 13:49Then your build system.
  112. 13:52Are your build commands and CI well documented?
  113. 13:56Feedback loops.
  114. 13:57You have unit and integration tests tight and you have docs like readmes, agents.mmd files.
  115. 14:06Are your dev environments cleanly reproducible such that an agent can use them?
  116. 14:12Is your code modular with clear boundaries and rules against sprawl?
  117. 14:17Do you have observability?
  118. 14:19How long does it take you to find out why something went wrong?
  119. 14:24and are you proactively security scanning so that you don't have to worry about leaked secrets or vulnerabilities.
  120. 14:32Basically, 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.
  121. 14:45Now, you can't govern what you can't see.
  122. 14:48And that's true for agents and human engineers.
  123. 14:52You can start with this agent readiness assessment, but no matter what, your engineers must monitor agent performance and control behavior.
  124. 15:03At factory, every action is auditable.
  125. 15:06It operates under your standards with role-based access control and least privilege.
  126. 15:11For example, your teams that are building this software factory need to first build trust and understanding.
  127. 15:20That's why you should roll this out incrementally.
  128. 15:24You want to automate the individual pillars first before you turn this system into a loop.
  129. 15:31And again, precise execution does not prevent poor design.
  130. 15:37It never has.
  131. 15:39You still heavily need humans in the loop for architecture, for strategy, and for setting direction.
  132. 15:46Engineers will not be replaced, but judgment and prioritization now beat mechanical implementation skill.
  133. 15:58Agents won't be able to handle everything.
  134. 16:00There will be guardrails to tighten, code that drifts.
  135. 16:04Humans need to stand as validation gates in this factory.
  136. 16:09But just like we don't have to feed punch cards into the machine anymore, code does not have to be written by hand.
  137. 16:17Your team should be able to set the strategy and their risk parameters and then let agents execute.
  138. 16:24And knowing if your agents are executing well comes down to measuring the right things.
  139. 16:31Basically, you want to measure outcomes, not tokens.
  140. 16:37Lines of code and tokens generated are gameable metrics.
  141. 16:41These are not actually associated with outcomes.
  142. 16:45Token leaderboards at big companies just encourage proflegate spending.
  143. 16:51It's goodart's law in real time.
  144. 16:53If you decide to measure token usage, engineers are going to optimize for token usage and then it's no longer a good metric.
  145. 17:03It's not about who spends the most on tokens.
  146. 17:06It's about who can get the highest leverage outcomes from that spend.
  147. 17:12Some 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.
  148. 17:25These are real tangible outcomes.
  149. 17:30So agent readiness is really a precursor to effective engineering.
  150. 17:37Whether 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.
  151. 17:52Don't just turn them loose in your codebase.
  152. 17:56And don't token max.
  153. 17:59Measure what actually matters.
  154. 18:02Your end users don't care about how much you're spending on AI.
  155. 18:06They care about feeling the dramatic improvements that will come from your software factory.
  156. 18:12Thank you.
  157. 18:30[music]