Does AI abundance undermine the engineering discipline that scarcity enforced?

Nielsen Norman Group's Tanner Kohler, studying a "growing crowd of vibe architects with little technical background" who build complex systems around "large context libraries," reports that these builders are recreating a decades-old software failure mode: the "big ball of mud" (Brian Foote and Joseph Yoder's 1997 term for "a system scraped together for short-term functionality, not architected for long-term durability"). The study finds AI has inverted the condition that used to force discipline. Where scarcity of time, money, or expertise once forced software teams to prioritize, "AI makes all these resources feel unlimited, and we saw the result: with nothing forcing them to prioritize, these vibe architects were building big balls of mud." One advanced participant describes the result as overengineering that "doesn't get you that much more value for the time you spend in it," because "AI makes it so easy for you to build something" that "people actually start overbuilding because it feels productive."

The mechanism Kohler traces runs through software history. Early "code-and-fix" teams built this way until complexity outgrew it, pushing the industry toward heavily planned waterfall development, then toward Agile once up-front planning proved impossible to get right. Kohler's participants are "retreading this history," minus the corrective pressure that originally ended each stage: a user has AI draft a first-pass rules.md file to restrain agent behavior, never revisits it, and workflows quietly adapt around the untested draft; one participant's throwaway Asana status widget, built by someone who "could not write code," grew through three stages into a "crossfunctional dashboard." Several participants could no longer locate files their own systems depended on without asking the AI to find and explain them, and described resulting dependency: "If I experience even a slight amount of challenge... I ask it to help me instead of actively thinking about it myself."

This extends Does easier tool-building actually solve enterprise adoption problems? down from the enterprise to the individual: Evans's claim that ease of building doesn't solve judgment about what a company needs has a mirror at the level of a single builder, whose ease of building outpaces judgment about architecture. It also gives concrete texture to Does granting agents more autonomy undermine human oversight?: Kohler's participants are the erosion in practice, unable to locate or explain their own systems and reporting frustration at the thought of losing the tool. Where Does agentic AI succeed through process redesign or workflow layering? names layering agents onto existing workflows as the enterprise failure mode, Kohler shows the same layering happening bottom-up inside individual builders' systems, without the redesign discipline Deloitte prescribes being available to them.

The excerpt gives no sample size, recruitment method, or count of "vibe architects" studied, so how representative this pattern is beyond the quoted participants is unclear, and it does not establish that AI-built systems fail at a different rate than human-built ones — only that, as the excerpt puts it, "eventually, many systems, AI-centric or not, are rebuilt or abandoned." What it supports, at the strength it allows, is narrower: removing the cost constraint that once forced architectural prioritization reproduces big-ball-of-mud fragility in individuals building with AI, now spreading to a population that mostly lacks the engineering vocabulary to recognize the problem as it forms.