Cloudflare Proposes the Agent Development Lifecycle to Enable Autonomous Software Factories

Cloudflare Proposes the Agent Development Lifecycle to Enable Autonomous Software Factories Cloudflare has introduced the concept of the Agent Development Lifecycle (ADLC) to replace traditional SDLC assumptions, offering primitives like Workflows and Artifacts so autonomous AI agents can manage entire development pipelines rather than just code generation. Rapid AI code generation has shifted development bottlenecks downstream to code reviews, deployments, and production maintenance. Building autonomous 'software factories' requires purpose-built infrastructure to bridge the gap from 80% reliability to mission-critical production standards. Cloudflare positions its Workflows and Artifacts products as the foundation for agents to dynamically orchestrate testing, deployment, and operational tasks. Downstream Bottlenecks in the Traditional SDLC AI has dramatically accelerated code implementation, but making code creation fast and cheap has overwhelmed downstream stages of the Software Development Lifecycle. Engineering teams and open-source maintainers face immense volumes of pull requests, bug triage, and production stabilization demands. Cloudflare argues that keeping humans in the loop to babysit agents at every step fails to scale, necessitating an Agent Development Lifecycle where agents handle validation, deployment, and operational responsibilities. The Reliability Threshold for Autonomous Software Factories The broader industry ambition of 'software factories'—autonomous systems that take an issue or idea and deliver it directly to production—mirrors autonomous driving. Getting an automated system to work 80% of the time is relatively simple, but running production systems requires moving past 99% reliability to handle complex edge cases and subjective changes. Standard linear CI/CD configurations in files like GitHub Actions YAML are insufficient for orchestrating the multi-role, highly variable checks required to safely deploy software without human intervention. Orchestration with Workflows and Artifacts To support end-to-end agent autonomy, Cloudflare offers Cloudflare Workflows alongside Artifacts as code storage. Workflows provide dynamic, state-persisting orchestration capable of launching containers, browsers, and Flue agents, enabling automated tasks like trace inspection, metric observation during rollouts, and feature flag management. Combined with tooling such as @cloudflare/ci, these primitives aim to let organizations build autonomous, resilient pipelines across all phases of the development lifecycle.

Cloudflare提出智能体开发生命周期ADLC，打造全流程自主“软件工厂” Cloudflare宣布将传统软件开发生命周期（SDLC）升级为智能体开发生命周期（ADLC）。由于AI代码生成导致下游验证和维护环节严重受阻，Cloudflare主张赋予智能体涵盖构建、测试、部署及维护的端到端能力，并推出结合Workflows和Artifacts的底层工具链以支持自主软件工厂。 AI使代码编写变快变便宜，却导致开源维护者与生产工程师面临下游审核和系统稳定性的重压。 多数团队仍让人类充当各环节瓶颈，ADLC旨在让智能体自主接管验证、部署与故障排查等全生命周期任务。 自主软件工厂面临类似于自动驾驶从80%可用性迈向99%以上高可靠性的挑战，传统CI/CD流水线无法应对复杂的非线性与主观场景。 Cloudflare通过Workflows（步骤编排、状态持久化、启动容器/智能体）和Artifacts（代码存储层）等基础设施支撑ADLC落地。 从SDLC到ADLC的转变 随着AI加速代码实现，软件交付速度成倍提升，导致评审、合并、部署和故障响应等下游环节不堪重负。目前大部分团队仅在各个环节中零散指导智能体，仍受限于人工瓶颈。Cloudflare认为应当以ADLC取代SDLC，通过向智能体开放API和工具，使其能够代表用户自主管理从需求输入到生产运维的全流程。 软件工厂的可靠性挑战 构建自主软件工厂面临与自动驾驶汽车类似的门槛，即从80%的成功率走向99%以上的极高可靠性。生产环境涉及角色协同、日志追踪、灰度发布等复杂场景，无法仅靠静态的线性CI/CD脚本解决。要让团队放心交出生产权限，必须配备专门的基础设施来应对难以预先设计的边缘情况。 基于Workflows与Artifacts的基础设施 Cloudflare提出以Workflows和Artifacts作为核心基础原语。Workflows能够动态编排多步骤任务、自动重试、跨周期持久化状态，并具备启动容器、智能体或浏览器的能力，支持测试、检查指标与渐进发布；Artifacts则充当代码存储层，二者结合为运行端到端自主软件工厂提供了底层支撑。

Engineering managers spent the past few decades figuring out ways for many programmers to work together on a shared codebase. This work dates all the way back to the “Systems Development Lifecycle” ([RAND, 1975](https://www.rand.org/pubs/reports/R1855.html)) - today commonly referred to as the “Software Development Lifecycle” (SDLC), which defines the following phases: AI has made the step that was previously the slowest and most expensive — implementation — the fastest and cheapest. That, in turn, has had an impact downstream: overwhelming the people responsible for all the other steps in the SDLC. This ranges from open-source maintainers bombarded with thousands of pull requests and issues, to production engineers trying to save production from falling over as the rate of software delivery increases orders of magnitude. We are all trying to save our systems, our customers, and ourselves from slop. The answer — paradoxically — is to empower agents to do more. It’s only fair! You’d never let an engineer on your team write code, expect someone else to validate it, merge it, deploy it, hold the pager in production, and triage incoming bugs. But that’s what most companies are doing right now with agents. Models have improved remarkably, and agents are running over longer time horizons, able to take on much larger tasks. But they are not yet used evenly across the SDLC. Cloudflare treats agents as our customers. They can [buy domains](https://blog.cloudflare.com/agents-stripe-projects/), create [temporary accounts](https://blog.cloudflare.com/temporary-accounts/) and [use the entire Cloudflare API](https://blog.cloudflare.com/code-mode-mcp/). We know that agents need APIs and tools to be able to manage the full SDLC on behalf of our customers — not just the start of it. And so today we’re introducing the start of a new set of tools that let agents step beyond just generating code and take on more of the SDLC. We’re sharing what we’ve built and learned trying to solve this for ourselves: There’s something bigger here though. When we look at the SDLC, even with the best automation, its assumptions do not scale for the volume of code agents can write and the pace at which software engineering teams must move to compete. We think it’s time to replace the SDLC with the ADLC — the Agent Development Lifecycle. Right now, [everyone](https://x.com/zachlloydtweets/status/2069789929073262945) [is](https://x.com/matanSF/status/2066578088184680920) [talking](https://x.com/dexhorthy/status/2081797628552270027) [about](https://x.com/bcherny/status/2077929390806073807) [building](https://x.com/gokulr/status/2032271386161684665) “software factories” — agent-driven systems that take input and autonomously build, improve, deploy and manage software. Take an input, whether it’s a production error, a bug report from a customer, or an idea for a new feature, and delegate it entirely to an agent. Even with agents, most software projects are constrained by human-in-the-loop steps. Humans prompting agents, telling them to keep going, instructing agents to apply feedback from a code review, constantly babysitting many agents and giving them instruction. On most software teams, the human still manages each step in the SDLC model — the only change is that they delegate tasks within each step to an agent. And so the dream behind software factories is: what if you reimagined this approach and built a factory for the entire process of building software? How can we shift more human time towards the things that truly require human inspiration, taste, and judgement? It would leave us more time to design, to talk to customers, and to dream bigger. A software factory has to manage the same steps in the SDLC, but it demands much more from the platform it is built on. Because when you hand over the keys and let the agent drive, every manual step that previously relied on a human must be adapted to be: We need something new if we are going to make software factories safe to use for real production software. Software factories face the same challenge that other autonomous systems like self-driving cars do — the challenge of going from working successfully 80% of the time, to some number of nines past 99%. An autonomous vehicle is loaded with sensors and technology that a regular car doesn’t have. Lidar sensors, cameras, powerful compute to run inference, and connectivity to a central command system that can take over remotely if needed. For an autonomous vehicle to be 80% as good as a human at driving, we probably don’t need all of this. Self-driving got to around 80% as good as humans 10 years ago. But that’s not the bar to clear — the bar is to be much better and safer than a human driver. That’s what we expect when we hand over the keys to a machine, in order to feel safe taking a nap driving down the 101 at 60 mph. And that’s why autonomous vehicles have technology that is purpose-built for self-driving — it’s what builds trust and handles the edge cases that cannot be designed for upfront. The same is true of self-driving software. Ask yourself — why *haven’t* you yet just let your agent auto-approve and merge its own PRs to your production services? The higher the stakes of what you build, the longer your list of reasons almost surely is. When you start to unpack not only all the things that can go catastrophically wrong in this process, but also that are necessary to building the right thing for customers, it is remarkably complex. It doesn’t fit into a linear set of steps in a GitHub Actions YAML file, and it goes way beyond running traditional automated tests. Even a small change to a dashboard can span roles, specializations and org structures, and subjective changes are the hardest to test and to delegate. Most of these things are probably not part of your CI/CD pipeline at all today. But they will need to be, if you want them to still happen, while giving full control to the agents running the software factory. To let agents drive the whole process, we need a better way to orchestrate these dynamic series of steps. We think that is a [Workflow](https://blog.cloudflare.com/ci-workflows), with the capability to spawn containers, agents and browsers. A Workflow that can set feature flags and enable them for a test user, investigate logs and traces, observe production metrics as a change gradually rolls out, and do everything else that is needed in order to ship safely. [Cloudflare Workflows](https://developers.cloudflare.com/workflows/) let you chain together multiple steps, automatically retry failed tasks, and persist state for minutes, hours, or even weeks. They are designed to encode complex and dynamic business processes in a logical and well-understood program. [This blog post](https://blog.cloudflare.com/ci-workflows) breaks down why Workflows, in tandem with [Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/), make defining and triggering CI/CD pipelines fundamentally simpler. For example: Workflows go beyond a series of linear steps though. They can be [defined dynamically](https://blog.cloudflare.com/dynamic-workflows/), and they can spawn agents or other Workflows. [This example](https://flueframework.com/docs/guide/workflows/#example-cloudflare-workflows) shows a Workflow that reviews new data from the past day. The Workflow has full control over when and how the agent is prompted, and can pass along context between steps: Once you see this pattern, and are “Workflow-pilled” as Cloudflare is, you start to ask: what else could I have a Workflow handle for me? What other human-bottlenecked steps could I delegate to this combination of Workflow + [Flue agents](https://flueframework.com/)? With [Workflows](https://developers.cloudflare.com/workflows/) able to orchestrate complex steps, and [Artifacts](https://developers.cloudflare.com/artifacts/) as the storage layer for code, when you look at the SDLC stages, everything an agent needs to own the whole process of building, shipping, and maintaining software is on Cloudflare: Right now, the people on the bleeding edge are building the software factories of the future. Eventually software factories will become, just like agents and AI, the normal way people build software. But for most people and most organizations, we’re not there yet. We want to change that. In order to do so, the questions we’ve asked ourselves are: how can we make things simple and accessible so that everyone on the Internet can benefit from a paradigm shift like this? And what are the base layer primitives that we can open up to everyone, from the smallest startup to the largest platforms in the world? In this case, we think the primitives are here. There’s more to do to connect them, to keep building our own software factory and learn from it, but right now, today, we’re ready for you to build your machine that builds the machine, on Cloudflare. Get started with [@cloudflare/ci](https://blog.cloudflare.com/ci-workflows), [build an agent](http://blog.cloudflare.com/agents-on-cloudflare), and see how much of the SDLC you can make autonomous.