Analytics engineering, as a named discipline, is now about a decade old. The early years were defined by tooling. dbt arrived. Modern data stack vendors raised. The cloud warehouse became the default substrate. Most of the foundational arguments of that era have been settled. The job has changed in ways that the conference circuit has been slow to catch up to.
Here is how I see the state of the discipline in 2026, drawing on my own work and on what I see across teams I advise.
The tooling debate is over
For the average enterprise team, the stack is settled enough that the tool selection is no longer the interesting question. A managed warehouse, a transformation framework, a workflow orchestrator, a BI tool, an observability layer. The specific products vary. The shape does not. New tools that propose to replace this shape are met with skepticism, correctly.
What this means in practice is that energy is shifting from tool selection to operational quality. The teams that win in 2026 are not the teams with the newest stack. They are the teams whose stack runs reliably, whose models are well-tested, whose ownership is clear, and whose costs are tracked.
The semantic layer arrived, slowly
The semantic layer was the loudest topic of the early 2020s. By 2026, the loudest version of that conversation has died down, but the substance has quietly arrived. Most large data teams now have something between a metrics layer and a full semantic layer in production, often built around dbt's semantic constructs or around a vendor product.
The implementation has been less ambitious than the original vision and more useful than the cynics expected. The wins have come from consistent metric definitions across BI tools, not from radical decoupling of analytical layers.
AI changed the work, in specific ways
The arrival of capable LLMs has changed the analytics engineering job. The change has been more specific than the hype suggested.
SQL drafting is faster. Most analytics engineers I know now draft complex queries with LLM assistance and refine. The quality of the first draft is higher than it was two years ago. The review is still a human responsibility.
Documentation is more thorough. The activation energy to write a description of a model is lower when the LLM produces the first draft. Coverage of model documentation in mature projects is now noticeably higher than it was.
Data review has shifted. The bottleneck used to be writing the transformation. The bottleneck now is verifying that the transformation is right. Stronger testing discipline has become more important than stronger SQL.
Self-service has not arrived. The promise that LLMs would let business users write their own queries has mostly not materialised. The reasons are about data context and trust, not about query generation. Business users can generate queries. They cannot easily verify them.
The role has split
A few years ago, "analytics engineer" was a single job description. The role has split.
On one side, the analytics engineer who works closely with business stakeholders, owns specific data products, and is measured on the value those products deliver. This role looks more and more like an embedded business partner with deep technical skills.
On the other side, the analytics engineer who works on platform, governance, and cross-team modelling. This role looks more and more like a data platform engineer with analytical depth.
Most teams now have both, with different titles. The collapsing of the two into one role was a transitional artefact. The split is healthier.
Cost is a first-class concern
Compute costs in cloud warehouses have become a real budget line. Teams are now expected to manage cost actively. This was not true five years ago. It is uncontroversial now.
The skills around cost management are still uneven. Some teams have strong practices. Many teams have a few people who chase the largest queries quarterly. The tooling is better than it was, but the discipline of designing models and pipelines for cost from the start is still emerging.
What the discipline still gets wrong
A few patterns I would like to see less of.
Over-modelling. Many projects have hundreds of intermediate models that exist because the team modelled defensively. Pruning is rarely done. The projects accumulate weight and become hard to navigate.
Test coverage that is wide but shallow. A lot of projects have a test on every model. The tests are mostly schema and not-null tests. The harder tests, the ones that catch real business logic errors, are written less often. Coverage metrics report green while real bugs ship.
Disengagement from operations. Some analytics engineering teams have drifted toward a craft posture, focused on the elegance of the models, less engaged with the operational reality of the data flowing through them. The disengagement shows up as a pile of pipeline failures that no one is on call for.
What gets the next decade
The teams that win the next decade are likely to share a few properties. They treat data products like products, with named owners and measurable outcomes. They invest in test quality, not test count. They manage cost actively. They keep the analytical work close to the business it serves, even as the platform work moves toward platform teams.
This is not glamorous. It is the work. The discipline is better when it stops looking for the next platform shift and focuses on the operational excellence that makes the current platform deliver value.