For a second there, it looked like the new essential role in software was the Prompt Engineer — the highest value thing to craft was the series of tokens fed into a foundational language model. That didn’t really pan out. Personally, I’ve barely looked at the prompts that my coding agents have authored for me over the past few months; prompts are source code, and now they’re authored the normal way source code is (by agents).
Instead of prompts, we’ve started producing something else, though I don’t think we’ve quite delineated what that thing is. The best characterization I’ve seen is that of the factory, as portrayed via The Five Levels, Gas Town, Factory.ai, and Peli’s Agent Factory. This is part of the story, but not all. Factories, generally understood, are all about output, but software engineering is not just outputting lines of code. The factory framing naturally focuses on development, but that risks missing operations — the other half, of course, of DevOps. Operations is not about producing, it’s about maintaining; it’s closer to a repair shop than a factory. Even this is incomplete, though, as other aspects of the software lifecycle — research, planning, benchmarking, etc. — will move toward agentic work styles as well, though likely with differing trajectories. These other activities are perhaps closest to the realm of office buildings. Even on the purely development side, I don’t think the notion of a software factory fully captures essential engineering activity: One of the most important roles of an engineer is removing code, through refactoring and simplification; generally speaking, factories do not dispose of their own products.
Fortunately, we already have a technical term for this class of thing: Facility. A facility is a unit of infrastructure designed and built to support performing specific types of work. And that’s what we make now. When you update your AGENTS.md file, you’re (at least in theory) building up the facility that supports coding agents in making changes to your codebase. Calling a Markdown file a “facility” might feel like a stretch, but that’s because individual documentation files are the most diminutive manifestation of this idea. Over the next year, we’ll be developing facilities orders of magnitude more sophisticated. Our traditional roles as software development engineers will shift to software facilitation engineers; our new fundamental responsibility is ensuring the effectiveness of the systems developing software, not developing it ourselves.
I think it’s essential to give this entity — the software facility — a name, because that lets us frame it as a coherent, integrated, reproducible entity with describable and quantifiable characteristics. Right now, most software facilities are scattered agent documentation files and manually booted MCP servers. This disjointedness obscures that we are gradually amassing the components of what will become cohesive, managed systems. The current logistics for managing these pieces, which typically involve using the codebase itself for storage, also create a counterproductive coupling: By putting facilities inside code repositories, we’re treating the facilities as subordinate to the codebase. This is backward. Going forward, software facilities will exist outside codebases, and will manage codebases as subordinate resources.
There’s a handful of reasons this hierarchy is necessary. A first, rather pedestrian reason is that cornerstone of organizational governance, permissions. It’s key that both humans and agents can have specific, distinct access levels to both facilities and codebases. For example, we might restrict agents from directly editing their own facility (knowing that facilities may contain agentic guardrails). We might also restrict humans from editing codebases directly — a forcing function to nudge career engineers into their new role. (Some day, directly editing codebases may require VP approval.)
A second, more rousing reason is the way our agentic engineering efforts will shift over the next year. Today, our main concern tends to be how effectively our agents can modify our existing product codebases. Going forward, the question will be how quickly our agentic facilities can re-create the entire product from scratch. The new aspiration is possessing a facility that can reproduce a competitor’s product before their launch event has even finished. To this end, it’s critical that the facility’s knowledge of previous implementations can be fully cleared — not easy if the facility and product coexist in a Git repository.
A third reason is to enable divergence of the technologies we use for source code management. Over time, I suspect we will treat the system under development as something closer to a database than an on-disk directory structure. I don’t know exactly what this looks like, but I think that tying management of facility code to product code prevents us from at least exploring options. (I also think that a new source control system is already a decade overdue.)
Given that it’s now possible to crank out replacements for large, longstanding products as a side project, the entire software-as-a-service industry is looking a little shaky. However, I think that (at least for a while, and that’s all we can ask for) selling software facilities will be a tenable business. Code is effectively free now, but proof is not. A software facility provider must demonstrate that its systems can tackle long-horizon initiatives, spanning weeks or months. If you want to claim your facility can reproduce, say, a decades-old office productivity suite in a month, you need (at absolute minimum) a month, which should be enough time to close a deal.
Framing facilities as central, essential entities also emphasizes that they will quickly become the focus of logistics. For the past decade, if your production service went down, the on-call engineer was responsible for fixing it. Going forward, if your service is down, it’s your operations facility’s responsibility to fix it; if it can’t, it’s the on-call engineer’s responsibility to fix the facility.
Now, how will these facilities get built? With more facilities? Yes. There will be facility facilities. This might sound abstract (and/or absurd) at first, but it isn’t much different from how we already develop development tools in general. Software is meta.
What does all of this mean for current teams? I think it means you should stop committing code to your product repo, right now. Your product, whatever it is, is in maintenance mode — directly contributing functionality to your existing codebase entails an unacceptable opportunity cost. Traditional engineering teams might take a month or two to build a feature by hand. Facility-oriented teams will spend a month or two building the ability to ship that same feature in less than a day. Every day thereafter, traditional engineering teams fall months farther behind their competitors.
Our job as engineers is no longer doing things, per se; it’s providing facilities for doing things. This will take hold first in software, then expand to knowledge work more generally. So, go discard your local Git changes. Actually, delete the entire product repo from your dev machine. Building is different now.