A conference talk by Tereza Tížková of Factory on what it takes to build a software factory — a software lifecycle run autonomously, from collecting signals and prioritizing to building, validating, and improving. She argues a software factory is more than a swarm of coding agents, since writing code is the easy part, and lays out three principles: staying agnostic (fitting existing team workflows, automatic model routing with claimed ~25% savings), staying autonomous (long-running Missions, workers running in sequence with fresh context, validators checking code they didn't write, including a validator that clicks through the app), and continuously improving (a deferred context engine for reduced token use, agent-readiness checks for codebases). She closes on the human role: deciding what to build rather than how. Topics covered include the Coinbase cost example, model routing, caching, defining 'done', long runs and cheating agents, the validation contract, AI adoption as a power law, plugins, and unwritten team knowledge. Note: descriptions of cost savings and product behavior come from the speaker's talk and are not independently verified. Timestamps from 0:00 (intro) to 21:30 (letting agents take the annoying work) are included in the source record. # Video Identity Observations ## Source Overview - **Title:** *What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory* - **Format:** Conference-style talk, evidenced by spoken address ("Uh hi everyone... I'm Teresa") and closing applause ("\[applause\]"). - The transcript is the only supplied source; no curated metadata beyond the title. ## Intended Audience - **Enterprise engineering leaders and builders**, not hobbyists — the talk centers on organizational adoption, cost, and governance: - "should I build your own or outsource it, what works in production already, what are the main challenges and how much is this all going to cost?" - "the technology is catching up and it's possible to build this in production for **enterprises like EY or Adobe**" - **Practitioners evaluating AI agent adoption**, including skeptics anticipating objections: "we got a lot of questions like does it actually work? What if the model mis routes? Is it slower?" - Engineers specifically addressed in cultural references: "if you are engineers you probably can agree that sometimes AI really makes a mess." ## Claimed Scope - The speaker claims definitional authority over a broad, emerging concept: "everyone is talking about software factory but only few people are actually building one." - Scope covers the **full software lifecycle with autonomy**, not just code generation: "I would define the software factory as the whole loop the whole life cycle of developing software with autonomy." - Explicitly broadens scope beyond coding agents: "software factory is **not just coding agent** and it's not even a swarm of coding agents even thousands of agents." - Claims organizational-transformation scope: "we believe you should really rebuild your organization from ground up." ## Self-Description Evidence (Creator Claims) - **Affiliation with Factory:** "My name is Theresa. I work at a company called factory.com and we've been building uh this concept of the software factory for quite a long time." - **First-hand product knowledge:** - Factory's "automatic model routing": "we built uh a thing in factory called automatic model routing" - "Factory missions" — long-running agent sessions: "the missions work in the loop and iterating on task until it's done and they can do it even for weeks" - "deferred context engine" and "agent readiness framework" described as Factory products/practices - **Role evidence suggesting customer-facing work:** "I like to just learn what users are building and get feedback," plus a customer example ("real mission from our customers that run 16 hours"). ## Demonstrated (Not Just Claimed) Patterns - **Definitional framing habit:** "I like to define things by what they are not" — the talk proceeds by exclusion and analogy (agents compared to human teams repeatedly). - **Evidence style:** third-party citations (Coinbase CEO's token-spend chart, Stanford data on AI code quality) plus conservative internal claims: "this is our benchmark which is very conservative... You can save for example 25%." - **Closing stance:** deliberately optimistic on AI's labor impact — "I think they will not [lose jobs]... I want to be positive" — ending with the sign-off "go touch some grass and let your agents build for you." ## Boundaries of Observation - All audience, scope, and identity conclusions above are limited to this single talk; no channel-wide patterns are inferred. - No private motives are attributed; the stated optimism and product positioning are taken only from direct quotes. # Delivery Observation — Tereza Tížková, "What It Actually Takes to Build a Software Factory" ## Overall Register The delivery is **conversational and lightly formal**, with frequent verbal fillers and self-corrections typical of a live technical talk. Openings like *"Uh hi everyone. Hey what's up? I'm Teresa"* signal an informal, peer-to-peer tone aimed at a technical audience rather than a polished keynote style. ## Recurring Vocabulary and Phrases - **"Software factory"** — the central term, repeated throughout: *"everyone is talking about software factory but only few people are actually building one"*. - **"Loop" / "in the loop"** — arguably the most repeated technical word: *"the whole loop the whole life cycle"*, *"it's all loops with smaller loops"*, *"work really continuously in the loop"*. - **"I think"** — frequent hedging marker: *"I think they will not"*, *"I think this is big challenge for agents as well"*, *"I think the direction is clear"*. - **"Important thing / important thing is"** — used repeatedly to flag key points: *"important thing is it doesn't just help uh spend money"*, *"important thing is uh the validators judge code that they didn't write"*, *"important thing is nothing is actually removed"*. - **"Uh"** — a very high density of filler sounds throughout, consistent with spontaneous speech. ## Teaching Habits - **Definition by contrast.** She explicitly names this habit: *"I like to define things by what they are not."* She then negates candidate definitions one by one: *"software factory is not just coding agent and it's not even a swarm of coding agents"*. - **Enumeration of pillars.** She structures the talk around a three-part framework: *"the three important things is being agnostic… then you need to be autonomous… And third thing always improving."* - **Human-organization analogies as a teaching device**, used at least three times: - *"it's similar to building the real team of humans"* - *"Same with when with humans have like other colleagues verifying their code"* - *"when you join a new company there are a lot of rules that are not really codified anywhere"*. - **Anticipating audience questions.** She restates likely skepticism before answering: *"when we launched this we got a lot of questions like does it actually work? What if uh the model mis routes?"* and *"lot of questions we got on this was also So how do we handle caching?"* - **Numbered procedural walkthroughs**: *"how the routing works uh there are four parts. First… then you have the classification… after that… and then you go."* ## Communication Patterns - **Personal-experience framing**: *"was surprising for me for the first time"*, *"at least from my experience"*, *"I like to just learn what users are building and get feedback"*. - **Chart-based narration**: she repeatedly references slides as anchors — *"this is the scary chart"*, *"this is one warning chart"*, *"this chart is from CEO of Coinbase"*. - **Deliberate tone-setting around conclusions**: *"So I want to be positive"*, *"so I want to really end this positively"*, and a casual sign-off: *"thank you so much go touch some grass and let your agents uh built for you."* - **Self-aware asides**, e.g., dismissing jargon: *"it's a framework I don't like the word framework but uh take it as a hygiene check"*; and a playful admission: *"maybe this is a bit weird, but I just like that it's all loops with smaller loops."* ## Stable Patterns vs. Isolated Moments **Stable (repeated across the talk):** the loop vocabulary, "important thing is" signposting, human-team analogies, question-anticipation, hedging with "I think", and heavy filler usage. **Isolated (appearing once, insufficient repetition to call a pattern):** - The "power law" framing of AI adoption risk (*"you either succeed big or you can fail big the same way it's a bit of power law"*). - The historical analogy of humans as *"human computers"*. - The vivid anecdote about the engineer migrating codebases where *"it just created the product but it didn't work"*. ## Uncertainty Notes - Whether the human-organization analogy counts as a deliberate teaching strategy or incidental repetition cannot be determined from delivery alone, though its three occurrences make it the strongest candidate. - The name appears as both "Teresa" and "Theresa" in the transcript; the video title spells it "Tereza Tížková," so transcription inconsistency is likely, and no claim is made here about the correct spoken form. # Observation Record: "What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory" ## Speaker Identification - **Sole speaker:** Identified in the transcript as "Teresa" / "Theresa"; curated title identifies her as **Tereza Tížková** of **Factory** (factory.com). No other speakers with substantive content appear. --- ## Central Thesis - Few people are actually building software factories, and even fewer know what it takes; Tížková claims the technology is "finally catching up," enabling production deployment for enterprises like **EY** and **Adobe**. ## Definition of a Software Factory - Defined as the **whole lifecycle of software development with autonomy** — not just code generation: - Collecting signals (user feedback, logs), prioritizing, orchestrating, executing, validating, production testing, and iterating while continuously improving. - **Definitional exclusions** (explicitly "what it is not"): - Not just a coding agent. - Not even a swarm of coding agents, "even thousands of agents" — writing code is "the easy part"; engineers don't spend most of their time writing code. - Not a consultancy or abstract strategy; she argues you must **rebuild your organization from the ground up**. ## Historical Context (claimed) - The concept wasn't feasible before ~2023; early efforts (AutoGPT, BabyAGI) failed due to LLM hallucination, context-length limits, poor reasoning, and lack of isolated agent environments. ## Three Principles of a Software Factory ### 1. Agnostic - Independent of LLM choices and of existing org workflows; must work across Slack, GitHub, etc., and let users bring their own subscriptions. - **Model-agnostic routing:** cites the Coinbase CEO's chart showing spend reduction *without* reduced token spend via default-model changes, caching, no spend limits (but visibility), and smart routing. - Factory's **automatic model routing**: classifies task difficulty from prompt, codebase structure, tools used; picks the **cheapest model above a threshold**; can switch models mid-task if failing. Claims ~**25% savings** (described as a "very conservative" benchmark) plus reliability and speed benefits via provider failover. - Anticipated objections she lists: misrouting, slowness, hidden cost, task failure, caching — all called "valid questions." - **Caching:** open models on dedicated compute can cache too; passing savings to users is "just a pricing decision. It's not a technical challenge." ### 2. Autonomous - Agents need trust, permissions, and governance; she cites predictions agents will run "a year or more" without human-in-the-loop — "that sounds ambitious," but Factory **missions** already run for weeks. - **Loops:** the hard question is not the loop but **defining "done."** Modern criteria are open-ended/nondeterministic vs. clear completion criteria in classic programming. - Acknowledges the "scary chart": long autonomous runs are increasing **but not reliably production-ready**; notes **cheating risk** — agents may optimize for passing tests rather than genuinely accomplishing the task. - **Mission architecture:** - Orchestrator writes the **validation contract** *before any code*, assigns to **worker** agents, reviewed by **validators** (~40% of a 16-hour real customer mission was validation). - Workers run **in sequence**, not in parallel swarms — claimed to yield "fresh context / fresh head," though each worker can have parallel sub-agents. - Two validator types: **scrutiny validator** (linters, types, tests, rigorous code checks) and **user testing validator** (clicks through the product in a virtual computer). Anecdote: a code migration where competing products produced a non-interactive "dummy result," caught only by real clicking. - Enabled by recent progress in **computer use** and persistent VMs. ### 3. Always Improving - **Context bloat:** enterprises use "hundreds of tools" whose schemas bloat context and cause wrong tool selection. Factory's **deferred context engine** progressively discloses tools — "nothing is actually removed, it's just hidden" — claiming **50%+ token savings at scale**. - **Power-law risk:** adopting AI is binary — "you either succeed big or you can fail big." An unstructured codebase can end up *worse*; cites Stanford data that unprepared codebases degrade under AI. Notes a "big and growing gap" between casual adopters and deliberate ones. - **Agent readiness:** a hygiene-check framework (reproducible dev environments, tests, documentation, code style, linters) correlating codebase quality with AI-adoption productivity; big customers run the checks and follow recommended actions. - **Tacit knowledge:** parallel to human organizations — unwritten rules learned by observation. Solutions launched: **plugins** (packaged reusable skills/context) and **auto** (auto-updating documentation). ## Position on Human Labor - Explicitly **rejects** the "permanent underclass" outcome: "I think they will not," and states "I want to be positive." - Historical abstraction narrative: humans as human computers → programming languages → coding agents → managing agent teams; humans move up to deciding **what to build, not how**. - Suggests AI will take the **annoying** work (alignment meetings, status syncs), freeing humans for "the cool stuff." --- ## Qualifications and Tensions Preserved - **Ambition vs. evidence:** she simultaneously cites multi-year autonomous-run predictions ("that sounds ambitious") and admits long runs are "still not that reliable" and "still not solved." - **Conservative benchmark:** the 25% routing savings is self-described as very conservative ("even more probably") — presented as directional, not settled. - **Cheating risk** is admitted as an unresolved problem tied to poorly written completion criteria. - **Discomfort with the word "framework"** for agent readiness ("I don't like the word framework") — offered instead as a "hygiene check." - Positive labor outlook is explicitly framed as a choice ("I want to be positive"), not a settled conclusion. # Video Attribution & Provenance Record ## Video Identification - **Title:** What It Actually Takes to Build a Software Factory — Tereza Tížková, Factory - **Video ID:** 01a15ca7-28c5-776e-ad2e-a7885ad4f808 ## Speaker Roles | Speaker | Role | Evidence | |---|---|---| | **Tereza Tížková** ("Theresa" in transcript) | Solo speaker, employee of Factory (factory.com), presenting a conference-style talk | Self-introduction: "I'm Teresa... I work at a company called factory.com" | | Audience | Unidentified | Applause and music noted at end; no audience speech in transcript | No guest interviews, narrators, or additional named speakers appear. The entire transcript is the presenter's own talk; no transcript markers separate her claims from others' claims (e.g., quoted tweets or third-party data are paraphrased by the speaker, not directly sourced). ## Referenced Sources & Third-Party Claims All third-party material is relayed by the presenter; original sources are not linked in the transcript: - **Coinbase CEO tweet/chart** — claim that Coinbase reduced AI spend without reducing token usage, via default model changes, caching, no spending limits, and smart routing. - **Stanford data** — claim that without a structured codebase, AI can degrade code quality (specific study unnamed). - **"Scary chart"** — unnamed chart showing autonomous task duration increasing over time. - **Colleague example** — an agent loop building a 3D-printed logo (colleague unnamed). - **Anecdote** — an engineer migrating codebases with Factory's "droid" agent; competing products produced non-interactive results (engineer and products unnamed). - **Customer example** — a real customer mission that ran 16 hours, with validation taking ~40% of the process (customer unnamed). ## Company / Product References (Presenter's Own Organization) The speaker references Factory's products and internal benchmarks throughout; these are **promotional first-party claims**, not independent evaluations: - Factory's software factory dashboard - **Automatic model routing** — claims ~25% cost savings ("very conservative" internal benchmark) - **Factory Missions** — long-running agent sessions (weeks); orchestrator/worker/validator architecture; **validation contract** concept - **Deferred context engine** — claims ~50% token savings at scale - **Agent readiness framework**, **plugins**, and **auto** documentation updates Enterprise customers named: **EY**, **Adobe**. ## Availability & Community Signals - **Comments:** No comment section or audience Q&A is present in the transcript; availability cannot be confirmed. - **Slides/charts:** Multiple on-screen charts are referenced but described only verbally; their visual content is unavailable from the transcript. ## Uncertainty Notes - Speaker's name appears as "Theresa/Tereza" in the transcript; title metadata gives "Tereza Tížková." - "CH GPT lounge" and "autog baby agi" appear to be transcription artifacts likely referring to ChatGPT launch, AutoGPT, and BabyAGI — recorded as unverified. - No timestamps are available for segment boundaries. Uh hi everyone. Hey what's up? I'm Teresa. Uh and today I will be talking about software factory. uh everyone is talking about software factory but only few people are actually building one and even fewer people know what it actually takes to build one and how to define it. So I will be talking about what is a software factory, should I build your own or outsource it, what works in production already, what are the main challenges and how much is this all going to cost? Uh my name is Theresa. I work at a company called factory.com and we've been building uh this concept of the software factory for quite a long time but finally uh the technology is catching up and it's possible to build this in production for enterprises like EY or Adobe uh I would define the software factory as the whole loop the whole life cycle of developing software with autonomy which doesn't mean just coding and generating code by that I mean collecting all the signals reacting to user feedback to logs, prioritizing what's important, then orchestrating it all, executing, validating, doing really good uh testing in production and then iterating on all this uh while also continuously improving in the process and gaining new knowledge and new skills. So this is just our dashboard how our software factory looks if you if you look at it and it's catching the whole cycle there. uh this is just some history and by history I mean 2023 in AI. So the software factory wasn't really possible before even though we always had this idea from the beginning of uh CH GPT lounge and others we had this idea of the continuous loop there was autog baby agi already with the concepts of iterating on the software but it didn't work before because the LMS were hallucinating there was problem with context length uh problem with the reasoning quality uh different problems like this or we were missing good environments where the agents can actually work in the isolation. So all this kind of led to why the software factory is the paradigm that's starting to be popular now and actually useful. I like to define things by what they are not. So I want to say software factory is not just coding agent and it's not even a swarm of coding agents even thousands of agents because generating code writing code that's the easy part compared to all the others. uh engineers don't even spend most of the time uh just writing code. The challenges are the rest of it. Uh so this is what I want to enhance and it's also not just some consultancy or just some abstract strategy that someone will try to sell you and to your organization. Uh I think the approaches are of course different but we believe you should really rebuild your organization from ground up to be ready to become a software factory like you can't invite a consultancy and just throw something in the middle of your organization. You should really be mindful and rebuild it from scratch. uh this is the approach I like uh showing to building the software factory and I think it's similar to building the real team of humans because there is a lot of agents as I said they will be testing validating iterating and it all can end up as a big chaos uh so you need to be mindful and I would say the three important things is being agnostic in the software factory so being independent of LLM choices uh of how you already work as the organization then you need to be autonomous. So you need to give the agents the right trusts and all this permissions and governance and you need to trust it to run really for a long time because the predictions are that agents will run even a year or more years without the human in the loop. Of course that sounds ambitious but for example our missions already our long runninging sessions already build uh things and run for weeks. So it's not that crazy. And third thing always improving. So same as human organization you need to onboard any new people in your team by giving them good uh code base understanding good structure documentation and also let them improve in the process and gain new knowledge and share it share it within the team. So these are the three points and now let's talk about the agnostic one. Uh I think the important thing to point out if you are a builder and building different primitives of the software factory you need to be ready for how everyone is already working you need to work across environments like Slack, GitHub and connected to everything and you need to also allow people to already bring subscriptions they are using because there is every every time there is like new technology, new frontier models, uh new benchmarks and it's so difficult to catch up but also to predict what we'll be winning. So it's best to be agnostic for everyone. Uh then there's the topic of being agnostic to models. Uh this is a topic of a lot of discussions recently and this chart is from this chart is from CEO of Coinbase uh who tweeted about how they started uh started saving money in their organ or organization on AI but without reducing the token spend. So the black line is how much they spent on tokens. They continue growing and token maxing but they stopped spending so much money. Uh how they did it uh different tricks like different default default models for people. So stop pushing people to use only the frontier as a default. Then caching of course uh to stop preferring the stuff every time. And then no limits on spending but just needing to see the results if you spend a lot. And the last thing that's really important topic is routing. So smart routing between LLMs and just a token optimizing between uh the LMS instead of just spending so much tokens. Uh we built uh a thing in factory called uh automatic model routing and there's been a lot of questions around it but what it does is it automatically routes between different models in your process. The important thing is it decides first what model is most optimal and then uh it can switch to different model if it's failing the task or in case of any troubles but it usually doesn't happen and important thing is it doesn't just help uh spend money. It also helps with reliability or with speed because open source models are often faster and uh if one LM provider fails you can just switch to another one automatically. So it really does more things than just saving the money. This uh is our benchmark which is very conservative. I prefer conservative benchmarks but I think the direction is clear. You can save for example 25% but even more probably. Uh how the routing works uh there are four parts. First you just assign the task and you don't really need to do anything but as an organization you can for example give different permissions and different default models to different people which is very useful like marketing or sales or engineers can both uh have different default models and then you have the classification which is the important part. This is the magic of the routing. You need to really uh look at the structure of the prompt of the uh code base of how difficult the task is, what tools are being used, all these factors and make a classification of difficulty of the task. Uh after that you basically do a threshold of what is enough to accomplish the task and you choose the cheapest model above the threshold. So cheapest model that is predicted to accomplish your task and then you go. Okay. So when we launched this we got a lot of questions like does it actually work? What if uh the model mis routes? Uh is it slower? Is it more expensive actually? What if the model can't accomplish the task or what if it needs to upgrade? And how do you handle caching? So I think these are all valid questions and that's why it's so difficult to build a good router like you need to basically classify it very well and the challenge is to not not to need to switch too often but even if you're switching in the middle of the task to difficult to more difficult model you still overall are faster probably because it's still worth uh this is just some overview of caching uh lot of questions we got on this was also So how do we handle caching? Do we do discounts for users? Uh because LLM LLM labs of course save a lot of money by caching and skipping all the context prefill all the time. Uh open models can do this as well. I think people sometimes forget this and you can just host open models as well uh on dedicated compute and you can take the same advantage of the caching. Uh so I want to enhance uh the final price for users. is just a pricing decision. It's not a technical challenge because everyone can do caching. It's just what price you pass on the users and what deals you make with the API providers. So this is uh being agnostic and now the autonomy which is the core of the software factory. Uh everyone is talking about loops. Uh loops I think have been here the whole time already in different context. They are just now leveling up and moving to the context of agents. You probably heard about the Ralph loop and specifying the tasks and splitting to subtasks for agents. Uh this is a known concept and uh the question is not the loop itself but the question is how how you define what it means to be done in the loop. This is one example from my colleague uh he he made a loop uh of agents building 3D printing of our logo. uh I think here you can see what is the challenge of the loops because uh before in programming loops had clear criteria of what it means to be done while now the criteria become open-ended because a lot of the tasks are very nondeterministic it's basically open world you can do even real stuff like printing something and it's really difficult to define how do you verify that the loop was done that the task was accomplished so that's the difficult part uh yeah they just need to be verifiable This I call the scary chart. It basically shows that the tasks and how long they run autonomously with agents have been increasing. But still it's not that reliable. Even if you can run for a very long time, it doesn't mean that it will be reliable in production and you still probably need to need to iterate on it and uh provide feedback. So it's still not solved and there are problems like cheating. For example, if you write the what it means to be done in the wrong way, the agent can try to pass your tests but not really like not really verify what you need to do and accomplish but instead try to solve just passing your test. So cheating by that uh we have something called factory missions and this is like long longunning sessions of the agents. We just call it missions because we send the agent to the mission and uh the missions work in the loop and iterating on task until it's done and they can do it even for weeks and uh the main agent is orchestrator and then it's uh assigns work to workers agents and then validators who review the task. So this is one example uh real mission from our customers that run 16 hours and just just to see how important is the validation as well. it takes even 40% of the whole process. Uh to summarize, the orchestrator just decides and writes the conditions what it needs to be done. Then it gives it to the agents called workers. The agents work on it. And what is interesting or worth noting is that they work in a sequence. So they don't work in a swarm or parallel. The agents work in sequence and everyone accomplishes something and passes it to the next one. uh we actually found that if you do this you end up with more fresh context and kind of fresh head. Same with when with humans have like other colleagues verifying their code. So similar thing we just let the agents pass to the next one. But still every worker of the sequence can have parallel agents doing smaller tasks. So I don't know researching on the web or building files during that. So they are in sequence and everyone has sub agents as well. and validators they review the output and provide feedback and send it back to the beginning. Uh important thing is uh the validators judge code that they didn't write. Uh there's something from the orchestrator agent called validation contract uh that's written before any code is done. And first type is scrutiny validator. Second is user testing validator. The scrutiny is the one who really verifies how the codebase looks. the liners types tests it's really rigorous check of the code but the second I think is really interesting is user testing validator and that's the one who is really in the arena trying the things so it doesn't care how it was made it just goes it works in its virtual computer and it clicks on the stuff and really checks if everything works I've seen one engineer migrating uh code bases with droid with our agent and uh it really needed the agent in the end to click through the stuff because with other products it just created created the product but it didn't work and was wasn't interactive. It was just a dummy result. So our agent that really clicked on the stuff uh allowed to check that it's actually working and not just looking good in the code. I think this is one cool thing that was also allowed by the progress in computer use and the persistent environments virtual machines for agents which also wasn't here before or wasn't that great but now it's really great so it's allowing to go in the arena as an agent. Uh this is just one example of real mission from our users. I I like to just learn what users are building and get feedback and this is just uh how it can look in your dashboard. And this is how I visualize the missions. What is interesting is that it's just a loop with smaller loops because every of the agents are running in loops as well, but overall it's like one big loop. Okay, maybe this is a bit weird, but I just like that it's all loops with smaller loops. Uh, okay. And the third part, always improving, always learning. Uh there is this elephant in the room context with agents. A lot of questions which are valid are like how do you navigate the context blo because you work on these long missions in the software factory and how do you actually keep the context clean and that's very valid because enterprises especially they use hundreds tools they use Figma, notion, Gmail, drive, slack like hundreds tools on average. So all these have specification in the code. all these have schema and parameters and log descriptions. So, uh it can cause agent to really bloat with that and pick wrong tools if there are two tools that sound similar or to actually lose context because they fill up the the context window and need to compress. So, this is really dangerous. Uh for this we have something within the software factory called uh deferred context engine and we build it such that we just progressively disclose what's in the context and what tools to use. So we basically have a surprise tools uh that help later only if they are actually needed. So it first just has short list of the tools and uh only a short descriptions and when it's needed actually in the code uh they can call the tool and fully load it. So important thing is nothing is actually removed it's just hidden and not reachable until needed. So it's just for later and important thing is it actually saves a lot of tokens uh at scale once you use more and more tools. uh the more actually you save it really scales and you can save 50% of tokens or more. Okay. Uh another thing which is tricky and was surprising for me for the first time is that when adopting AI you either succeed big or you can fail big the same way it's a bit of power law. So if your codebase is not ready, if you don't have structured codebase and all important things, then adopting or turning into software factory can actually make you end up worse and make your code degrading. And uh there is a big and growing gap in productivity between those who just adopted AI versus those who actually thought about it a bit more. Uh there is another data from Stanford about yeah without structured uh code base and being ready and documenting well the AI can make your code worse and I think if you are engineers you probably can agree that sometimes AI really makes a mess and this can really compound more and more and it's difficult to go back. uh we have something as a part of the software factory uh we have something called agent readiness and it's a framework I don't like the word framework but uh take it as a hygiene check of your codebase and things you should do because there is actually nice correlation between how your codebase is looking and all the details there and how good you're going to adopt the AI and end up productive instead of uh with a messy code base. So there are things like how how reproducible is your developer environment or if you have written good tests if you have all things well documented what's the style of your code all the tests and llinters uh everything that you would do also to keep codebased screen. So these factors actually show to be very useful and we have our bigger customers actually go through this agent readiness framework and do all checks and then they can follow up with recommended actions uh how to fix that. Uh I think one more thing about the context and the continuous learning in the software factory is the most of the time when working with AI or at least from my experience is that you keep repeating to agents how how do you want the things done and you feel like the agent doesn't really get you and I think this is again nice parallel with human organizations and teams because when you join a new company there are a lot of rules that are not really codified anywhere like you just learn and observe how things are done and there are a lot of things between the lines that you can't really learn anywhere else than just observing. I think this is big challenge for agents as well and one thing we launched for that is plugins which are like packaged reusable skills and context and the things behind the scenes that you can really codify or auto which is automatically updating our documentations and uh yeah and um reviewing and documenting what you have. So the question is what will happen to us humans if we build software factory like this? Uh will humans just lose jobs and go to permanent underclass? I think they will not. And uh I want to be positive. So I'm thinking of this parallel of humans just moving up uh levels up to the uh to the cooler tasks than before. I think we actually had before the same same experience of us as humans abstracting some levels up and we actually started ourselves as human computers. We actually were the computers doing all the most detailed stuff at the beginning. Then we had programming languages codifying some of it, abstracting and then coding agents. So outsourcing some of it but uh still being in the loop very closely uh and very monitoring everything. And now we are moving kind of up to software factories where we manage these agents as I said orchestrator agents and workers and validators and all these teams structured teams of agents that work really continuously in the loop and we just monitor and decide what to build. Uh so I want to really end this positively. We should be as humans deciding what to build in the software not how to build it. uh because that's up for the agents and by this uh continuous cycle of autonomous software I think we can actually achieve that. Uh this is one warning chart or if someone thinks AI will take the cool cool stuff from us. I believe actually it will take the annoying stuff and in enterprises and organizations you already spend a lot on alignments on the meetings as I mentioned basically the thing behind between the lines that you really need you need to get context from everyone share your status sync on the things on meetings so all these things could be actually outsourced to your software factory and you could be just talking about the cool stuff okay so this is it thank you so much go touch some grass and let your agents uh built for you. Thank you. \[applause\] \>\> \[music\]