When Anyone Can Build Software, Who Decides What Not to Build?

The views here are my own. The examples are composites drawn from twenty years across several institutions, and none of them describes any particular situation.

An appealing assumption is gaining ground: now that generative models can write code, map integrations, and produce technical documentation in seconds, enterprise architecture is an expensive relic of a slower era.

Before I argue against that, let me concede the part that is true, because most defenses of our profession skip it and lose the room in the process.

A meaningful share of what architecture groups did five years ago is now a commodity. Reference diagrams, integration inventories, capability maps, target-state decks, standards documents nobody read past page four. An agent produces those faster than my team does, and frequently better. If your architecture function is staffed to produce artifacts, it should get smaller, and that correction was overdue long before anyone had heard of a transformer.

I have sat in enough review boards that took three weeks to return cosmetic comments on a diagram to know that model deserved to be automated out of existence.

So the question is not whether architecture survives intact. It is what becomes more valuable once building software stops being the expensive part.

My answer, which the rest of this piece defends: judgment before commitment. The ability to look across domains, recognize when locally rational decisions create enterprise consequences, and arbitrate before capital, data, and organizational behaviour are committed to them. It is the only part of the work that cannot be pushed down or coded away, and it is also the part most architecture groups currently hold no real authority over.

What accumulates is not the code

Start with the economics, because that is where the executive case actually lives. When the cost of a foundational input collapses, the market does not stop needing expertise; the value shifts to the complement. Software has never been expensive because code was hard to type. Software is expensive because you operate it, secure it, staff it, integrate it, govern its data, change processes around it, and live with its decisions for a decade.

Cheap generation does not remove any of those commitments. It accelerates our ability to make them.

The obvious rebuttal deserves a serious answer. If generating is cheap, rewriting is cheap too. Build fast, throw it away, rebuild. Why should anyone care about architectural debt in a world where an agent can regenerate a service in an afternoon?

Because code is the disposable part, and code is not what accumulates. What accumulates is state.

• The data your systems have already written and that other systems now depend on.
• The integrations other teams built against your interface while you were not looking.
• The contractual and regulatory obligations attached to where that data sits, how it moves, and how its lineage is established.
• The operating processes built around the system, and the habits of ten thousand users who depend on it behaving a particular way.

None of that regenerates in an afternoon, and none of it is in the repository.

The asymmetry is the whole point. Implementation gets easier to replace while everything surrounding it stays exactly as persistent as it was, and the cost of building falls, so we create those commitments faster than we discover their consequences. That is not an argument for slowing down. It is an argument that deciding what deserves to become persistent has become the scarce input, precisely because building no longer is.

The question one level out

I learned this long before generative models existed.

Early in my career I built a homegrown Smart BI capability bolted onto an internally developed CRM. Two weeks of work for something that had been scoped at three months. It reached production almost immediately, it cost close to nothing, and business users could build their own reports by drag and drop; the business was delighted. By every measure anyone applied at the time it was a success. I was very proud of it, and I told the story for years.

Years later I understood what I had actually built: a silo.

Jeanne Ross of MIT described a firm’s architectural maturity as four sequential stages: business silos, standardized technology, optimized core, then business modularity. The operative word is sequential. You do not skip a stage; you pay for each one in accumulated foundational discipline. What I had done was add another silo to an organization already full of them, at a speed that made it look like progress.

The analysis my tool automated was being done by hand in spreadsheets. I treated the spreadsheets as the problem and removed them. I never asked why they existed. Whether people simply preferred Excel, or whether the software data model could not answer the question the business was actually asking of it, I do not know to this day, because I never went and found out. If it was the second, and I suspect it was, then I solved nothing. I wrapped the gap in two weeks of custom code and made it harder to see.

Years later the line of business asked for longitudinal reporting, cross-domain aggregation, and planning. The tool integrated with nothing, extended to nothing, had no underlying data platform, could not scale, and had to be rebuilt from scratch.

The project was not a technical failure. It delivered what had been asked, faster and cheaper than anyone expected. Within the frame I had been given it was a success. The failure sat one level above that frame.

I had asked how to solve the problem well. I had not asked whether it was the right problem, for whom, and what the answer would need to become in three years. An hour on that would have changed the decision.

I call it the question one level out, and I insist on the name because it is not a review, not a framework, and not a committee. It is a deliberate widening of the frame before commitment, and it is worth nothing unless it happens before. Nobody asked it in that organization, because nobody there held the enterprise frame. There was architecture, but it existed only as diagrams.

Local and enterprise here are not attitudes, and I am not describing carelessness. It is a context problem. A squad operates a narrow window at high resolution: it sees its own domain, its customers and its constraints in real detail. The enterprise frame is the inverse, an enormous window at low resolution. Neither is superior, both are necessary, and no organization I know of has ever gotten the second one for free.

That was one developer working by hand, and the bill arrived years later. Today an agent reproduces the same pattern in an afternoon, across fifty teams at once. The speed of implementation has changed completely. The delay between a local decision and its enterprise consequences has not. That is the trap.

Picture an organization where every delivery team is performing well. Marketing stands up a client engagement engine with its own vector store. Logistics ships a self-contained routing service. Customer service bridges two platforms with generated gateways. Every demo lands. Every team delivers. Each initiative makes sense inside its own boundary.

Then the seams appear.

• Several competing definitions of the same customer, each authoritative in the domain that built it.
• Sensitive data flowing into storage nobody classified for it.
• Two or three teams independently building versions of the same capability.
• Inference costs that only surface after adoption, because each team optimized for delivery rather than enterprise economics.

Not one of these is a failure of the teams. That is precisely the problem. Enterprise incoherence does not require bad local decisions. It emerges from good local decisions taken independently.

Generative tooling amplifies this, and the mechanism is worth stating plainly. Lower production cost enables more production. More production means more independent decisions. More independent decisions mean more interfaces, more data dependencies, more operating commitments, more room for local optimization. Those commitments accumulate faster than the organization discovers what they cost.

Which gives us the paradox I expect to define the next few years: the cheaper software becomes to create, the more expensive incoherence becomes.

The bottleneck has moved. It is no longer our ability to build. It is our ability to decide coherently.

Context is not the same as authority

The objection makes itself: if the agent operates in a narrow frame, give it a wider one.

That objection is stronger than most architects would like to admit. Give a capable model the right systems, the architectural history, the constraints and a critique loop, and it will challenge assumptions well. I have seen one push back on a requirement more rigorously than plenty of governance forums I have watched operate. I see no fundamental reason why models cannot do increasingly sophisticated architectural reasoning, and on volume alone we have already lost: a well-instrumented agent ingests more documented context than any architect I know.

The harder problem is organizational.

A model optimizes inside the frame it is given, and the person building that frame has already made the decisive call: this request deserves to be implemented. Ask for a pipeline between two systems that disagree and you get an excellent pipeline, clean, tested, observable, permanent. But the real problem may not be integration at all.

• Two departments may have conflicting incentives.
• The underlying data model may never have supported the question now being asked of it.
• Front-line staff may be skipping mandatory fields because the process adds fifteen minutes of friction to every customer interaction.

A technically excellent pipeline automates the symptom and institutionalizes the dysfunction. None of those reasons was in my own frame either, and I was a human being standing in the building where the answer was.

So the architectural question is sometimes not how we should build this, but whether this problem should be solved this way at all. A model can increasingly help answer that. Answering it analytically and acting on the answer organizationally are different things. Telling a funded executive sponsor that automating their request will institutionalize a dysfunction is not an analytical act. It requires standing: someone able to challenge a locally rational initiative on behalf of the wider interest, in an organization that has decided this person has the legitimacy to do it.

Some institutional context is also different in kind from documented information. Someone who sat through two failed migrations does not merely hold facts about them. They carry a cost they paid, and it changes which risks they will accept again. We should not romanticize that: where such knowledge lives only in six people’s heads, that is our failure to write it down, not proof of our indispensability, and much of it can and should become accessible to machines.

But assume excellent models, excellent retrieval and excellent institutional memory, and one thing remains. When a pipeline leaks client records, misprices a consequential decision, or fails an audit, the organization still needs someone who can answer to the executive committee, the board, the auditor or the regulator. Someone owns the decision. Someone signs. That is not a statement about the limits of the technology. It is a property of institutions.

What does not distribute

The strongest argument against a central architecture function is not that architectural judgment stops mattering. It is that most of it can be distributed. Put senior engineers inside the domains. Encode the standards in the platform. Turn constraints into policy-as-code. Give teams paved roads and let them move. Most architectural decisions do belong as close as possible to the teams that will live with them, and any architecture group insisting those decisions route through a central committee is rebuilding the bureaucracy it claims to have abandoned.

One category resists distribution: arbitration across domains when incentives conflict.

A business unit cannot reasonably be expected to optimize against its own objectives. A team with a funded initiative is poorly placed to decide that the enterprise is better off if that initiative is delayed twelve months. A domain will rarely volunteer that its local capability should disappear into a shared one owned elsewhere. And a team rewarded for delivering is not the natural place to decide that the best enterprise answer is not to build at all.

These are not failures of leadership or judgment. They are predictable consequences of organizational design. Local incentives produce local optimization, and no amount of exhortation to think enterprise removes the incentive structure underneath the decision. It takes the wide window to rule against the narrow one, and no narrow window will ever do that on its own.

Call the function enterprise architecture, technology strategy, or something else. The label is secondary. What matters is the work: holding the enterprise frame when decisions cross domains, exposing consequences individual teams cannot reasonably see, and arbitrating when local and enterprise interests diverge. That is also where architecture stops being primarily technical. Its strategic value begins when it operates on capital allocation, sequencing and enterprise risk, rather than on reviewing designs after the consequential decisions have been made.

By what authority

Which raises the uncomfortable question for architecture leaders. Not by mandate: architecture backed only by policy loses every time it meets a deadline. In practice I see three sources of standing, and any architecture leader reading this should check honestly how many they hold.

The first is owning the paved road, which means the governed path is also the easiest one. A default model-routing layer so no squad has to solve inference economics on its own. Data contracts on the small number of entities whose consistency genuinely matters, namely customer, account and transaction, rather than an ambition to govern all of them. Engineering templates that ship with observability, secrets handling, security controls and lineage already wired. Guardrails inside the delivery pipeline rather than comments in a review document three weeks later. Visibility into what is actually running in production, before an incident forces the organization to discover it. If going around your road is easier than using it, you do not have a road. You have a policy, and you will be routed around.

The second is a seat where capital is allocated. Architecture engaged after funding is approved is advisory. What not to build can only be answered while not building it is still an option, which means sitting in portfolio decisions before commitment rather than reviewing their consequences afterward.

The third is accountability that is actually signed. If you carry named risk, you earn a voice in the decision. If you carry none, you are offering an opinion, and opinions lose to quarterly commitments every time.

Most architecture organizations hold one of these three. Some hold none. That, far more than anything a model can now generate, is why the function feels replaceable.

What would change my mind

The decision in front of executive teams is therefore not whether to preserve today’s architecture organization. They should not preserve it merely because it exists, and architecture leaders should not defend work the technology has made unnecessary. The real question is where cross-domain arbitration will live once everything downstream of it has become cheap, and who is accountable when that arbitration simply does not happen. Left unanswered, the organization answers by default: fifty teams moving at machine speed, each locally rational, producing an enterprise architecture nobody deliberately chose.

I hold this position provisionally, and there is a clear test that would change it. If comparable institutions demonstrate that strong platforms, senior engineers embedded in domains, and policy-as-code produce enterprise coherence with no central architecture function, then the function should dissolve and I will say so. I remain skeptical for one reason: none of those mechanisms, on its own, has any mandate to rule against a business line’s incentives when the enterprise optimum requires it. But that is an empirical question, and it is worth testing rather than assuming.

Generating software is becoming a commodity. What is scarce is the hour spent on the question one level out before a locally rational decision becomes persistent enterprise state, and the standing to act on the answer. For decades, software organizations were constrained by how fast they could build. That constraint is disappearing, and a different one is taking its place: how well can the enterprise decide?

When almost anyone can build software, the organizations that win will not be the ones that build the most. They will be the ones that know what not to build.

Before dismissing the function, or defending it, I would ask both camps to sit with that question rather than answer it quickly. My own answer has changed twice in eighteen months.