The Great Clearing · Article 3 · Welcome to the Slop Economy: Executive Discretion Is Now a Core Competency
Somewhere in automotive right now, someone discovered Claude on Tuesday, connected it to a spreadsheet on Wednesday, built an agent on Thursday, and will be explaining their proprietary artificial intelligence architecture to a dealer group by Monday.
I want to be careful here.
That person may be onto something.
Seriously.
One of the most exciting consequences of this technology is that people with genuine operating insight can suddenly build things that would have required a product team, engineering budget, six months of meetings, and an enterprise software company to ignore them only a few years ago. Small teams can move extraordinarily fast. Domain experts can prototype their own ideas. Developers can delegate meaningful amounts of implementation work to coding agents. Entrepreneurs who previously lacked access to capital or engineering resources can test whether an insight has value before spending a year asking permission to build it.
We should want more of that.
But the collapse in the cost of creating software also collapses the cost of creating bad software. It lowers the cost of producing useful content and meaningless content. It makes extraordinary experimentation possible while simultaneously making it remarkably easy to put a polished interface over a poorly understood problem.
That means the AI economy does not merely create more innovation.
It creates more of everything.
AI is amplifying the supply of capability faster than it is amplifying the supply of judgment.
For automotive executives, that changes the job.
The scarce resource is no longer access to someone who can build an AI product. It is the organizational discretion required to distinguish a useful experiment from a durable system, an impressive demo from a trustworthy operating layer, a genuine builder from a persuasive opportunist, and innovation from an expensive new form of dependency.
Welcome to the slop economy.
The answer is not to stop building.
It is to get much better at knowing what deserves to survive.
There was a time when building enterprise software required enough capital, time, engineering talent, infrastructure, and organizational commitment that the cost itself functioned as a filter.
It was not a particularly good filter. Plenty of terrible software survived it.
Automotive has several archaeological layers available for inspection.
But building something substantial was difficult enough that an idea usually had to survive a meaningful amount of scrutiny before somebody created a company around it.
That constraint is disappearing.
Modern coding agents can plan work, write and modify code, run tests, inspect repositories, delegate subtasks, research problems, and operate across increasingly complex workflows. GitHub has described the developer’s role in this environment as increasingly shifting away from simply producing code and toward orchestration, delegation, and verification.
That is a profound democratization of creation.
It also means the distance between I have an idea and I have a product demo is becoming very short.
Automotive should celebrate that.
Our industry has no shortage of operational problems that have survived precisely because solving them historically required persuading a large technology provider that the problem was economically interesting enough to enter its roadmap.
A fixed-ops director who understands an ugly scheduling problem should be able to prototype a better solution. A salesperson who sees a recurring inventory merchandising failure should be able to test an automation. An agency with deep knowledge of an OEM program should be able to build workflow around that knowledge. A dealer group should be able to create internal tools without waiting eighteen months for a vendor feature request.
This is builder leverage.
It can be transformative.
But abundance has a second-order effect that executives should understand.
When almost everyone can build, the existence of software stops being evidence that the software should exist.
That sounds obvious until the demo starts.
“Vibe coding” has become a convenient punchline because it captures something genuinely strange about this moment: people can increasingly describe what they want software to do, collaborate with an AI system, iterate quickly, and arrive at functioning code without interacting with the development process the way software teams traditionally did.
I don’t think automotive executives should be afraid of that.
I think they should be afraid of confusing speed of creation with quality of architecture.
Those are different things.
A prototype is supposed to be fast.
An experiment is supposed to tolerate uncertainty.
A proof of concept exists to answer a question.
There is enormous value in a technically imperfect tool that allows a team to discover whether an operating idea has merit before investing heavily in it.
The problem begins when experimental velocity gets promoted directly into production authority.
Vibe coding is an extraordinary way to discover what might be possible. It is not a substitute for deciding what should be trusted.
A tool that helps one manager organize internal notes carries one level of consequence. A system writing customer-facing pricing language carries another. An agent that can alter inventory records, publish content, communicate with customers, access first-party data, interpret financial terms, or initiate commercial actions carries another level entirely.
The quality bar should rise with the blast radius.
This is not a uniquely AI principle. It is basic engineering and governance.
CISA’s Secure by Design guidance argues that security should be treated as a core business requirement throughout product design rather than shifted downstream to customers after software ships. CISA applies that same principle directly to AI systems: capable software should be designed with security considered across the lifecycle, not sprinkled on after the demo works.
That becomes increasingly important as AI accelerates development because the speed at which something can be created does not eliminate the work required to make it trustworthy. Security, data architecture, permissions, testing, observability, failure recovery, customer experience, and economic durability still require deliberate thought. Coding agents can compress implementation time dramatically; they cannot decide on behalf of leadership what level of consequence the resulting system should be allowed to carry.
No model update has made thinking obsolete yet.
The most dangerous enterprise technology demos are not the bad ones.
Bad demos are helpful. Everybody knows what to do with them.
The dangerous demos are spectacular.
A prospect describes a problem. The agent understands the request instantly. It pulls information from three places, generates a thoughtful answer, updates something, sends something else, and presents a clean summary. The room looks at one another.
Holy shit.
That reaction is justified. Current AI systems can do things that would have looked ridiculous in a dealership technology demonstration a few years ago.
The executive discipline begins immediately after that moment.
Ask what happened underneath it.
Where did the information come from?
Was the data real?
What happens when two systems disagree?
How does identity resolve?
What permissions did the agent have?
Where are credentials stored?
What actions are logged?
Can an action be reversed?
What happens when the model misunderstands the request?
What happens when a tool invocation fails halfway through a workflow?
What happens when the API changes?
What happens when the model provider changes?
Who reviews the output?
How is performance evaluated beyond “look, it worked?”
What does the customer experience when it doesn’t?
Anthropic’s own engineering guidance around agents is useful precisely because it is considerably less magical than most agent marketing. Its work on agent evaluations emphasizes testing real outcomes and failure modes. Its engineering teams discuss context limitations, orchestration, containment, and the need to control the potential blast radius as increasingly capable agents receive access to tools and systems.
In other words, the people building some of the world’s most capable agent infrastructure appear quite interested in the boring parts.
Automotive should be too.
The distance between a compelling AI demo and a trustworthy enterprise system is where most of the work still lives.
This is especially important in an industry with sensitive customer information, regulated financial activity, rapidly changing inventory, complex OEM requirements, fragmented identity, multiple systems of record, and a customer journey that routinely crosses digital and physical environments.
A brilliant agent sitting on top of unreliable inputs does not become reliable because its answer is elegantly formatted.
A beautiful interface cannot compensate for unclear authority.
A system that works perfectly in the happy path is not enterprise-ready merely because the happy path fits nicely into a LinkedIn video.
Executives need to develop comfort asking the questions that ruin the demo.
That’s the job.
Historically, dealerships have often evaluated technology relatively late in the chain.
Does it generate leads?
Does it improve response time?
Does it save labor?
Does it increase conversion?
Does it rank?
Can my team use it?
Those are still important questions.
But as software becomes more autonomous and more deeply connected to operational systems, leadership has to move trust evaluation farther upstream.
Before asking what the system produces, ask what the system is built on.
This is where provenance becomes strategically important.
If an AI system tells a customer a vehicle can tow 11,000 pounds, where did that number come from?
If it says a rebate applies, which source establishes eligibility?
If it publishes content about a service procedure, what technical information informed the explanation?
If it recommends a vehicle, what factors influenced the recommendation?
If it claims a store policy exists, which system owns the authoritative version?
If it knows something about the customer, how did the system obtain that information and is it authorized to use it in this context?
As AI moves from content generation toward operational action, “the model said so” becomes an increasingly unacceptable answer.
NIST’s AI Risk Management Framework emphasizes governance, contextual risk mapping, measurement, and ongoing management because trustworthy AI is not a property leadership can infer from the model name. It is an organizational outcome created through the way a system is designed, deployed, evaluated, monitored, and governed.
That distinction is critical for automotive buyers.
Two vendors can use the same underlying model and produce radically different levels of enterprise risk.
One may ground outputs in validated dealer and OEM data, preserve source provenance, constrain available actions, maintain audit logs, implement human review where appropriate, and test known failure modes.
Another may send a prompt to the same model and hope everybody has a great afternoon.
Both can put “Powered by AI” on the booth.
The model is not the product. The architecture around the model is the product.
That is one of the most important distinctions executives can carry into the next few years.
This is where I think discretion itself becomes a core competency.
Not skepticism.
Discretion.
There is a difference.
The skeptic’s default position is no.
The enthusiast’s default position is yes.
The operator’s responsibility is to understand where, why, under what conditions, and with what consequences.
That skill becomes more valuable when executive teams face an expanding universe of options: incumbent vendors adding AI functionality, startups attacking individual workflows, agencies building proprietary systems, OEM initiatives, open-source projects, internal prototypes, standalone agents, model-native applications, point solutions, and platforms claiming to consolidate all of the above.
The correct evaluation will vary by use case, but leadership can develop a consistent set of questions.
Not what feature does it add.
What meaningful business or customer problem becomes smaller?
Understand the difference between retrieved data, inferred information, generated language, employee knowledge, third-party data, and validated operational truth.
There is an enormous difference between an application that suggests an action and an application authorized to execute it.
Every system fails. Mature products are distinguished partly by what failure looks like.
A misspelled internal summary is annoying. An incorrect customer communication, altered financial representation, exposed credential, corrupted inventory record, or autonomous action across thousands of records is different.
Logging, auditability, attribution, and observability become increasingly important as software acts more autonomously.
Who owns the data, knowledge, configurations, content, workflows, and institutional learning created inside the system?
Does the product participate in a modern architecture through documented APIs, webhooks, appropriate authentication, structured exports, MCP or other relevant standards?
A delightful $500 prototype can become a very different proposition when it is executing millions of model calls, storing enterprise data, supporting hundreds of rooftops, meeting uptime expectations, undergoing security review, and carrying contractual responsibility.
This may be the most overlooked question.
Does the system help the organization learn?
Does the knowledge generated by use become reusable?
Does customer behavior improve future decisions?
Does the business become smarter because the technology exists?
Or are we renting another output surface?
The goal of executive vetting is not to eliminate risk. It is to make sure the organization understands what kind of risk it is taking in exchange for what kind of advantage.
That is a grown-up technology strategy.
There is a particular irony executives should work hard to avoid.
The industry can spend the next five years escaping legacy technology by purchasing dozens of AI products that become the next generation of legacy technology.
It is easier than it sounds.
A useful point solution solves a real problem. Adoption grows. The product stores more data. Workflows accumulate inside it. Employees depend on it. Integrations are built around it. Proprietary logic becomes difficult to extract. The company changes pricing. The roadmap changes. The original team gets acquired. An API never quite arrives.
Congratulations.
We have successfully reinvented 2014 with a gradient.
This does not mean every product has to be an all-encompassing platform. Quite the opposite.
Specialization can be incredibly valuable.
The architectural requirement is that specialized systems participate in an environment where the dealer can maintain control over its own knowledge, identity, data, content, and customer relationships.
A great point solution should be able to contribute intelligence without becoming the only place that intelligence can live.
An agency should be able to create value without becoming permanent middleware.
An internal tool should be allowed to evolve without forcing the business to rebuild every connection around it.
An AI model should be replaceable as models improve.
A dealership should be capable of granting and revoking access.
Customer data should not need to become the ransom paid for convenience.
Content should remain portable.
Institutional knowledge should accumulate for the business, not disappear when the contract does.
This is why interoperability is not a technical side conversation.
It is a hedge against tomorrow’s lock-in.
Open APIs, documented interfaces, modern authentication, webhooks, structured data, portable content, audit controls, and emerging agent protocols create optionality.
Optionality gives executives the ability to adopt better tools as they emerge without rebuilding the company around each one.
In a period when the technology itself is changing monthly, that may be one of the most valuable architectural characteristics an enterprise can buy.
There is a temptation in moments like this to divide the world into established companies and startups, as though age confers seriousness and novelty implies risk.
Automotive executives should know better.
We have legacy technology with extraordinarily expensive flaws, and we have young companies solving difficult problems remarkably well. A two-person team with deep domain knowledge, rigorous engineering discipline, strong security practices, and an interoperable architecture may be a substantially better bet than a thirty-year incumbent that added an AI assistant to a closed platform. Conversely, a charismatic founder with a working demo does not become enterprise-ready merely because the incumbent is annoying.
The useful dividing line is not old versus new, venture-backed versus bootstrapped, human-coded versus AI-assisted, or platform versus point solution.
The question is whether the team understands the problem deeply enough to build something trustworthy, durable, interoperable, economically rational, and genuinely useful to the humans affected by it.
That standard should apply equally to incumbents, startups, agencies, internal teams—and to Hrizn. Any company asking a dealer, OEM, agency, or partner to place increasingly important parts of its operating environment inside that company’s technology should expect sophisticated questions about architecture, data fidelity, security, provenance, economics, permissions, portability, and failure modes.
Serious builders should welcome serious buyers.
The relationship gets healthier when technology is evaluated less through familiarity, conference visibility, fear of missing out, or the quality of the steak dinner preceding the contract and more through the durable value the architecture creates.
Builders have responsibilities on their side too. We should distinguish prototypes from platforms, ordinary automation from genuine intelligence, and retrieval from reasoning. We should understand failure before granting customer-facing authority. Security, provenance, accessibility, and interoperability should not be treated as boring enterprise requirements to address after the demo gets enough applause.
None of that requires slowing the creative energy of this moment.
Quite the opposite.
Build quickly. Experiment aggressively. Challenge incumbents. Prototype strange ideas. Let domain experts create things they could never have built before.
Then apply a different standard when the experiment asks to become infrastructure.
Speed earns the opportunity to test an idea. Trust earns the right to scale it.
Those ideas can coexist.
The Great Clearing is not an argument for slowing down. The opportunity in front of automotive is too large for that.
Software is becoming easier to create, intelligence easier to access, and agents more capable. Domain experts can build. Agencies can create their own operating leverage. Dealerships can solve problems internally that previously required waiting on somebody else’s roadmap. OEMs can rethink how knowledge and activation move across networks. This should be one of the most creative periods automotive technology has ever experienced.
It will also produce an extraordinary amount of noise.
Some of it will come from established companies. Some from well-funded startups. Some from tiny teams with extraordinary insight. Some from tiny teams with extraordinary confidence. Products will arrive labeled copilots, agents, operating systems, intelligence platforms, orchestration layers, and probably several categories we have not invented yet.
The label settles almost nothing.
When creation becomes abundant, discernment becomes infrastructure.
The strongest organizations will be capable of experimenting aggressively without surrendering architectural discipline. They will know when a prototype should remain a prototype and when an idea has earned the right to scale. They will understand the provenance of the intelligence they deploy, distinguish model capability from product quality, demand security proportional to consequence, preserve control of their own data and knowledge, and favor systems capable of participating in the rest of the business.
Most importantly, they will resist letting a flood of exciting new tools recreate the same fragmented operating environment we finally have the technical capability to escape.
Because once leadership clears away the noise, the next question becomes architectural.
If the answer is not another pile of disconnected point solutions, what should sit above them? What becomes the durable intelligence layer capable of understanding inventory, people, customers, content, policies, expertise, provenance, and performance—and then activating that knowledge wherever the business needs it?
That is where we go next.
Next: Clear the Desk: The Next Automotive Stack Is an Intelligence Layer. →
Previous: AI Doesn’t Fix Broken Processes. It Industrializes Them. →
Return to the series hub: The Great Clearing: AI Is About to Amplify Everything. Choose Carefully.
NIST AI Risk Management Framework →
A practical foundation for thinking about governance, context, measurement, and risk as AI becomes part of consequential operating systems.
CISA Secure by Design →
Why security needs to be treated as a core product requirement rather than responsibility transferred downstream after software ships.
Stop Chasing LMNOPEO →
A practical companion to the series argument: stop treating every new AI-search acronym as a replacement for sound information architecture and useful customer content.
How to Evaluate an SEO Vendor →
A useful starting point for bringing more rigor to vendor evaluation, measurable outcomes, ownership, transparency, and strategy.
AI is dramatically expanding the number of tools dealers can use. That makes the right to connect those tools more important, not less.
Dealers should be able to authorize the employees, agencies, builders, applications, and AI systems they choose to securely interact with the infrastructure and dealership-owned knowledge they already pay to maintain.
Open APIs. Webhooks. Authorized third-party access. Real documentation. Modern authentication. MCP and emerging agent standards where appropriate. Portability. Auditability. Dealer choice.
Interoperability gives good builders a path in, gives dealers a path out, and keeps innovation from becoming another generation of lock-in.
Read and sign the Open Interoperability Demand →
Build freely. Vet rigorously. Let dealers plug in.
Hrizn v6 helps dealership marketing teams move from fragmented activity toward a connected operating advantage—bringing intelligence, creation, human participation, distribution, proof and improvement into a more coherent system.
We’re building that system with the same standard we’re asking the industry to apply elsewhere: trustworthy inputs, human judgment where it creates value, increasingly interoperable infrastructure, purposeful automation, and intelligence designed to make capable people more capable.
We Rise Together.
