An enterprise architect with twenty years across several institutions argues that cheap generation removed the wrong part of the job. Software was never expensive because code was hard to write — it is expensive because you operate it, secure it, staff it, integrate it, govern its data, and live with its decisions for a decade. He concedes the other side first: much of what architecture groups produced was commodity artifact, and a function staffed to produce artifacts should get smaller.

The obvious rebuttal — if generation is cheap, rewriting is cheap, so why care about architectural debt — fails on one distinction:

  • Code is the disposable part; what accumulates is state
  • Data already written that other systems now depend on
  • Integrations other teams built against your interface while you were not looking
  • Contractual and regulatory obligations tied to where that data sits and how it moves
  • Operating processes and the habits of users who depend on current behaviour

None of that regenerates in an afternoon, and none of it is in the repository. Because building is cheaper, commitments get made faster than their consequences get discovered — so deciding what deserves to become permanent is now the scarce input.

His own cautionary tale: a homegrown BI tool bolted onto an internal CRM, built in two weeks against a three-month estimate. It shipped, cost nothing, users built their own reports, and he told the story for years. Years later he saw it for what it was — another silo. He had treated the spreadsheets it replaced as the problem and removed them without ever asking why they existed. It integrated with nothing and had to be rebuilt from scratch. Not a technical failure; a failure one frame up. He calls the fix the question one level out — a deliberate widening of the frame before commitment, worth nothing unless it happens before.

Then the pattern at scale. Every team performs well, every demo lands:

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

Enterprise incoherence does not require bad local decisions. It emerges from good local decisions taken independently — and cheap generation means more of them, faster.

The section that avoids the usual cliché is on models. Give a capable agent the systems, constraints, and a critique loop and it will reason architecturally; on volume alone we have already lost, since a well-instrumented agent ingests more documented context than any architect. The gap is organizational, not analytical. A model optimizes inside the frame it is handed, and whoever framed the request already decided it deserved to be built. Ask for a pipeline between two systems that disagree and you get an excellent, tested, observable, permanent pipeline that automates the symptom. Telling a funded sponsor that their request institutionalizes a dysfunction requires standing, not analysis.

He names three sources of that standing, and most architecture groups hold one or none:

  • Owning the paved road, so the governed path is also the easiest one — otherwise you have a policy, and you will be routed around
  • A seat where capital is allocated, because what not to build can only be answered while not building it is still an option
  • Accountability that is actually signed — named risk buys a voice; without it you are offering an opinion, and opinions lose to quarterly commitments

The piece is unusually fair to its opponents: it names the empirical test that would dissolve the function, and admits the author’s answer changed twice in eighteen months. The conclusion is the part worth keeping — the organisations that win will not be the ones that build the most, but the ones that know what not to build.