Joe Reis wrote about the death of data engineering. He’s right—but he undersold it. The entire analytics intermediary layer is collapsing. What replaces it isn’t more tools or rebranded roles. It’s context engineering, AI-leveraged services, and custom software that actually fits the business.
Joe Reis recently published “2028: The Great Data Reckoning,” a speculative scenario about AI gutting the data industry within two years. He maps out how AI agents writing code collapse the justification for most data engineering roles, how the Modern Data Stack’s 37-tool sprawl implodes, and how the conference circuit evaporates when vendor money dries up.
I respect Joe’s work. His framing of the data industry as three overlapping sectors—tooling, practitioners, and theater—is sharp. His survival formula (“learn what a business is”) is exactly right. But I think he undersold the scope of the disruption.
I have some standing to say this. Before Ultrathink, I founded a data and analytics consultancy that became a Snowflake Elite Services Partner and sold to private equity. I spent over 15 years in data engineering, analytics, and BI. I’ve lived the world Reis is describing—and I left it because I saw where it was heading.
The reckoning isn’t limited to data engineering. It’s the entire analytics intermediary layer—data engineers, analysts, BI developers, analytics engineers—every role that existed to shuttle information from systems to humans. Those roles are all go-betweens, and go-betweens are the first casualties of AI agents.
Reis focuses on data engineering roles—the people writing pipelines, managing warehouses, configuring orchestration tools. His central catalyst is AI agents writing production SQL. I’ll push back on that specific claim: I don’t think LLMs can reliably write production analytical SQL. The fundamental tension between deterministic systems (where a query must return the correct answer every time) and probabilistic models (which approximate) is real. That’s exactly why semantic layers exist—to give AI agents a governed, well-defined interface to data instead of asking them to freestyle SQL against a raw warehouse.
But let’s set that aside, because the broader point still holds: AI agents can write code. Integration code, pipeline orchestration, API connectors, data transformations—the kind of glue work that employed a huge percentage of data engineers. And AI is replacing the SaaS tools those engineers configured. That’s where the real disruption lands. Not in analytical SQL, but in the integration and tooling layer. And the disruption doesn’t stop at the pipeline.
Think about what analytics actually is. Strip away the tools, the titles, the methodologies. At its core, analytics was always this: provide information to humans who then thought about it and took some action in some system.
A data engineer extracts data from source systems, transforms it, and loads it into a warehouse. An analyst queries that warehouse, builds a dashboard, and presents findings to a VP. The VP looks at the dashboard, decides to adjust pricing in a region, and updates the pricing system.
That’s a five-step chain: extract → transform → visualize → decide → act. The data engineer handles steps 1-2. The analyst handles step 3. The VP handles steps 4-5. Two of the three people in this chain are go-betweens.
In the world of AI agents, an agent can:
The five-step chain becomes one step with a human checkpoint. The VP sets strategy and reviews outcomes. The go-betweens—the data engineer moving data around, the analyst making it consumable—are structurally unnecessary.
This isn’t a timeline prediction. I’m not saying every analyst role disappears by 2028. But the direction is clear, and the roles closest to the “information shuttle” function are the most exposed. If your job is to be the layer between a system and a decision-maker, an agent can do that faster, cheaper, and at 3 AM without complaining.
Here’s a point Reis didn’t fully explore: the data warehouse was a centralization strategy optimized for human consumers.
Humans need clean, modeled, well-documented data in one place because they can only look at one thing at a time through one interface. Snowflake, BigQuery, Redshift—these platforms became the “single source of truth” because humans needed a single place to look. The entire Modern Data Stack was built to feed, organize, and serve that central warehouse.
AI agents don’t have that constraint. They can pull context from dozens of systems simultaneously. Protocols like the Model Context Protocol (MCP) mean agents can access structured and unstructured data directly from source systems—your CRM, your ERP, your document stores, your APIs—without routing everything through a central warehouse first.
The AI agent becomes the convergence layer where all enterprise data—structured and unstructured—meets. The warehouse doesn’t disappear entirely. It still serves regulatory, audit, and batch analytics purposes. But it loses its position as the mandatory center of gravity. And with it goes a significant chunk of traditional data engineering work.
We’ve seen this firsthand. Our MCP Gateway connects AI agents to 10+ enterprise services—Apollo, HubSpot, Ahrefs, Google Analytics, SEC EDGAR, Snowflake, Google Docs—through a single progressive discovery interface. The agent doesn’t need a warehouse to unify this data. It needs the right context at the right time, pulled from whatever system holds it. That’s a fundamentally different architecture than the extract-load-transform-serve pattern that employed hundreds of thousands of data engineers.
Think of what’s emerging: the agentic layer becomes a control plane across your entire business. It’s an application that sits across your operational systems—your CRM, ERP, ticketing, finance, supply chain—and takes action across them via APIs, MCP, and direct integrations. Augmented by humans, governed by human-in-the-loop workflows where they matter, but fundamentally operating as the orchestration layer.
What makes this control plane unique to each business isn’t the AI model—everyone has access to the same frontier models. It’s three things:
Feed your unique context and workflows into the agentic control plane, and it can take action across your operational systems based on business logic that no off-the-shelf SaaS tool could replicate. That’s the architecture that replaces the warehouse-centric world Reis is eulogizing.
Reis identifies business acumen as the survival factor, and he’s right. But I’m surprised he didn’t mention the specific discipline that emerges from the ashes: context engineering.
Context engineering is the practice of curating, structuring, and maintaining the right context for AI systems. It means deciding what knowledge an agent needs for a given workflow, how that knowledge should be organized, when it should be retrieved versus embedded, and how to keep it current as the business evolves.
Sound familiar? It should. That’s what good data engineers and analysts always did—just for human consumers instead of AI ones. Understand the business domain. Model information for consumption. Build reliable pipelines for delivery. Maintain quality over time. The consumer changed. The discipline didn’t.
Context engineering requires two things that resist automation:
We built exactly this into our OpenClaw deployment—semantic search over a corporate knowledge base that gives agents rich business context for every interaction. The technical implementation (vector stores, retrieval pipelines, embedding strategies) is the easy part. The hard part is deciding what goes in, how it’s structured, and keeping it aligned with how the business actually operates. That’s context engineering. And it’s a natural next career for data professionals who understand that the valuable skill was never writing the SQL—it was knowing which question to ask.
One of the most revealing details in Reis’s piece: the people who survived the reckoning weren’t the best engineers. They were the ones who understood the organizational context that made the data meaningful. Reis frames this as “tribal knowledge hoarders” who documented nothing and became indispensable by hoarding context. That’s a cynical read.
Here’s a better one: the people who survived were the ones who knew how to collaborate cross-functionally, understand different business domains, and translate that understanding into an architecture or process that could be baked into a technical solution that moved business outcomes. They didn’t hoard knowledge—they were the connective tissue between business teams and technical teams. They understood the messy human side of the problem.
Ask any engineer: they’d rather write code than talk to people. And it’s obvious why. Code is easy to reason about. It either works or it doesn’t. It’s functionally driven, testable, deterministic. People are messy. Stakeholders have competing priorities. Business processes are undocumented and contradictory. Getting alignment across three departments on what a “customer” means is harder than building the data model. It was always harder. The code was never the hard part.
This is why I’ve always called Ultrathink a consulting firm, not an IT services firm. An IT services firm sells technical solutions. But technical solutions are a means to an end. If I put all your data in Snowflake—who cares? If I put it in a dashboard—still, who cares? Nobody in the business wakes up wanting a warehouse or a dashboard. They want more customers, more revenue, lower costs, better efficiencies. The whole point is owning the business outcomes—in alignment with the client—not selling the technical plumbing.
The Execution Gap we talk about—the distance between “we can demo it” and “we can run it inside a real workflow”—is a people-and-process gap, not a technology gap. And maybe it gets easier with fewer people in the loop. Fewer stakeholders to align. Fewer handoffs to manage. Fewer meetings about meetings. AI-augmented teams of 5 doing what used to require 30 means you spend less time on coordination and more time on the actual problem. That’s the operating model we built Ultrathink around: small, fast, AI-augmented teams that eat their own dog food.
Reis frames the disruption as a labor-market story: roles eliminated, roles created, roles downgraded. That’s one lens. Here’s another: the services model itself is being rewritten.
I’m betting my company on two convictions:
Enterprises still run on decades-old ERP systems, custom databases with undocumented business logic, and integration patterns that no AI agent can fully automate without human guidance. Reis himself notes this: “AI struggled with undocumented business logic embedded in 15-year-old architectures.” This work is irreducibly human. Someone has to sit with the business, understand the legacy system, and architect the integration. That doesn’t go away.
The $2M integration project doesn’t become a $0 project. But it can become a $700K project done in a third of the time—without a bench of 30 junior consultants writing boilerplate. AI handles the code generation, the documentation, the testing scaffolding. Humans handle the architecture decisions, the stakeholder alignment, the organizational change management. That means higher margins, higher revenue per employee, and faster delivery.
The traditional services model—large teams, long timelines, hourly billing—is structurally disadvantaged against AI-native firms. When your competitor delivers the same outcome with 5 people in 6 weeks instead of 30 people in 6 months, and their fee is tied to the business outcome rather than hours burned, the math doesn’t work for the traditional model anymore. That’s the Outcome Partnership thesis: shared risk, shared reward, AI-augmented delivery.
Here’s the ripple effect Reis doesn’t explore: when the cost of software development approaches zero, the economics of SaaS invert. And the market is already pricing this in.
Between January and February 2026, roughly $2 trillion in market capitalization evaporated from the software sector. Atlassian dropped 35%. Salesforce dropped 28%. TechCrunch is calling it the “SaaS-pocalypse.” The per-seat pricing model that powered SaaS for two decades is under existential threat: if AI agents do the work instead of humans, who’s logging into the seat?
But the deeper issue isn’t just pricing models. It’s the build-vs-buy calculus itself. Why pay $500K/year for a SaaS platform that does 60% of what you need—with the other 40% requiring workarounds, custom integrations, and a dedicated admin—when you can build exactly what you need for less? AI doesn’t just reduce the cost of building custom software. It reduces the maintenance burden that historically made custom software expensive to own. Automated testing, AI-assisted debugging, self-documenting codebases—the total cost of ownership for custom software is collapsing.
Outside of a few key operational systems of record—your ERP, your HRIS, your core financial systems—the SaaS-pocalypse is real. The 37-tool Modern Data Stack that Reis describes collapsing? That’s just one instance of a broader pattern. Every category of enterprise software that isn’t a core system of record is vulnerable to custom replacements built faster and cheaper with AI.
But here’s the catch—and this is the part that matters for the displaced data professionals reading this post: the bottleneck shifts from building to deciding what to build.
When code is cheap, the scarce resource is judgment. Which workflows should be automated? What’s the right architecture for an AI system that fits this specific business context? How do you design something that moves the P&L versus producing demos and theater? We’ve written about this before: the build-vs-buy question is a trap when the real question is “what should we build, and will it actually move a KPI?”
That’s what the Synapse Cycle™ exists to solve. Not “can we build it?” but “should we build it, for whom, against which KPI, and in what order?” The Action Potential Index™ scores and ranks every candidate workflow against feasibility, business impact, and organizational readiness. That kind of disciplined prioritization is what separates companies that ship AI into production from companies that produce impressive demos that never move the P&L.
Reis’s advice to “learn what a business is” is correct but incomplete. Here’s a more specific playbook for data professionals and the enterprise leaders who employ them:
Reis frames his scenario as a crisis. I see it as a structural rewrite of how enterprises create value from data and software. The roles change. The tools collapse. The conference circuit evaporates. But the underlying work—understanding a business, identifying the right workflows, designing the architecture to govern and observe AI systems in production, integrating into legacy environments—that work doesn’t disappear. It just requires different skills and a different operating model.
That’s the bet I’m making with Ultrathink. I built a data consultancy in the data era. I built Ultrathink for the AI era. The lesson from both: the technology was never the moat. The moat is governance, workflow architecture, and business context—understanding a business deeply enough to know what to build, designing the workflows and guardrails to make it safe, and having the operational discipline to ship it into production where it actually moves the P&L.
Everything else is theater.
Take the next step from insight to action.
No sales pitches. No buzzwords. Just a straightforward discussion about your challenges.