Original video: WF2026: Software Factories & Keynotes ft. Microsoft, OpenAI, OpenClaw, Z.ai (GLM), MiniMax, HF Link: https://www.youtube.com/watch?v=htM02KMNZnk Start I just watched the opening of the first day of AI Engineer World’s Fair
- The theme is called Software Factories, which literally translates to "software factory". This word can easily be said in vain, but the real value of this opening is that several guests brought it back to the engineering site. The narrative of AI coding has been changing over the past year. The first thing everyone cared about was completion. What I cared about later was chatting. Later, I was concerned about whether the Agent could change the code, run tests, and open PRs by itself. Now comes a bigger change: the team begins to care about how to organize these capabilities into a stable production system. My judgment is straightforward: Software Factory deserves attention because it pushes AI programming from "tool efficiency" to "organizational efficiency."
- From Copilot to Factory: The subject has changed. In the early days, the subject of Copilot was developers. You write half of it, and it fills in half; you describe your intention, and it gives you a piece of code. The AI at this stage is much like a very fast co-pilot, and its core benefit is to speed up local actions. Today, the subject has begun to become "workflow". The entire chain of a task from when requirements enter the system to splitting, retrieving context, modifying code, running tests, explaining failures, fixing regressions, and generating review materials can be participated by the model. This is what the term Software Factory means: putting the model into the engineering production line, exposing it to real constraints, and continuously completing tasks in the engineering system. So I prefer to understand it as a new way of organizing engineering production. There are models, IDEs, terminals, CI, testing, code reviews, task management, knowledge bases, permissions and security boundaries.
- The model stack is getting thicker. There is a very important implicit consensus in this opening: AI programming is no longer just about the model itself. Of course the model is important, but what really makes the difference is the entire layer of systems outside the model. If a coding agent wants to be effective in the long term, it needs at least four types of abilities. First, it requires understanding the current code base. Second, it needs to know the mission objectives and acceptance criteria. Third, it must be able to call real tools, such as searching, editing, testing, and executing commands. Fourth, it must be able to re-integrate failure feedback into the next round of actions. If you only look at the model output, you will think that code generation is already very powerful. If you put it into a real engineering site, you will find that many difficulties lie outside the model: how to organize the context, how to execute commands, how to control permissions, how to recover from failures, and how to make humans trust the process. The real moat will gradually shift from "whose model is smarter" to "who can organize models, tools, data, processes and feedback more stably."
- Five premises of Software Factory If Software Factory is regarded as a slogan, it can easily become "let AI write software automatically". This sentence sounds exciting, but its practical value is limited. A more pragmatic question is: What conditions are met before AI can take over the real work of an engineering team? The first prerequisite is clear task boundaries. The Agent needs to know what to change and what not to change. The more complex the code base, the more important boundaries are. The second premise is retrievable context. Code, design documents, interface conventions, historical PRs, error logs, and test reports should all be reliably available to the Agent. An agent without context will behave like a confident newcomer who has just joined the job. The third prerequisite is an executable tool chain. It is difficult for a model that only chats to form a closed loop. It must be able to run tests, read error reports, modify files, re-execute, and then organize the results for people. The fourth premise is a traceable process. The team can't just get the final code, but also know why it was changed as it was, which assumptions were verified, and which risks were not covered. The fifth premise is that humans can intervene. The closer you get to a production environment, the greater the need for approvals, rollbacks, permissions, auditing, and accountability boundaries. Software factories will amplify team capabilities and process vulnerabilities.
- Agent Manager will become a new role. Another interesting point in the opening is that everyone starts to discuss Agent Manager. This role can be understood as "the person who manages AI employees", but I think this term is easy to be entertained. More precisely, an Agent Manager is someone who turns goals into executable tasks. He must be able to split tasks, define acceptance criteria, judge the output quality of the Agent, and know when to take back the task and do it himself. This has implications for both developers and product managers. The people who will be really popular in the future will be those who can break down complex problems into a set of verifiable workflows. Product managers will be more like system designers. They need to write requirements to be more executable, boundaries to be clearer, and acceptance to be more specific. Developers will be more like production line designers. They want to make the code base, tests, documentation, and CI more suitable for Agent participation.
- Why is the Software Factory suddenly established now? This concept has been talked about in the past, but this year it sounds more concrete. The reason is that several things have matured at the same time. First of all, the model's code capabilities and long context capabilities have reached a new stage. They can already read larger code snippets and handle longer task chains. Second, tool invocation and local execution environments have matured. Agents can more naturally enter the environments developers use every day and gradually move away from isolated chat boxes. Third, companies are beginning to truly integrate AI programming into their delivery processes. As soon as you enter the delivery process, the question changes from "can you generate code?" to "can you deliver it reliably?" This is also what I think is worth watching. It does not talk about AI programming as magic, but discusses a more realistic system engineering problem: how to connect unstable intelligence to an organization that requires stable output.
- What can the team do now? If you are a developer, I suggest doing three small things first. First, complete the "entry information" of the code base. For example, project structure, startup method, test commands, common pitfalls, interface contracts, and coding style. Agents, like newcomers, need good onboarding. Second, write tasks into verifiable units. Don’t just write “optimize experience” or “fix login.” Clearly write down trigger conditions, expected behavior, exceptions and acceptance methods. Third, add tests and logs to a level that can support the work of the Agent. What the Agent fears most is a lack of feedback. Without feedback, it can only guess. If you are a product manager, you can also start changing the way requirements are expressed. A new standard for high-quality PRD in the future is whether it can be broken down into tasks by the Agent and whether it can be verified by the engineering system. When AI enters the software production line, the most important documents will become two types: one tells the Agent what to do, and the other tells the Agent what level of performance is considered qualified.
- My Judgment The term Software Factory may be over-marketed in the future. Every new word goes through this step. But the direction behind it is clear: the software team will move from "people using tools" to "people designing systems, and the system coordinates a batch of intelligent tools." There will be a lot of new infrastructure here. For example, Agent-specific task system, context management, permission sandbox, code base memory, automatic evaluation, PR interpreter, rollback mechanism, audit log, and development environment specifically for Agent. New organizational divisions of labor will also emerge. Some people are responsible for converting requirements into executable tasks, some are responsible for maintaining the Agent working environment, some are responsible for reviewing model output, and some are responsible for precipitating failed samples into the next round of rules. This may be how AI programming truly changes the software industry. It won't just make everyone write code faster, it will redefine what "software delivery capabilities" are. So my biggest feeling after watching this opening scene is: Software factory has finally begun to change from a beautiful word to a set of problems that can be checked on the ground. Does your team have clear task boundaries? Is there a searchable context? Is there an executable toolchain? Is there a traceable process? Is there any mechanism for human intervention? The answers to these questions determine whether AI is just a faster chat window in the team or a production line that can truly produce engineering results.