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

Generation is the cheap part. Deciding what deserves to become permanent is not.11 min read1 hour ago--Press enter or click to view image in full sizeThe 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 codeStart 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 outI 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.Get Younss’s stories in your inboxJoin Medium for free to get updates from this writer.Remember me for faster sign inThen 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 authorityThe 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