Hex is a notebook platform built around a complaint that anyone who has worked in data will recognise: Jupyter notebooks are excellent for exploration and terrible for everything after it. They do not share well, they run cells in whatever order you happened to execute them, they break when someone else opens them, and the analysis you did three months ago cannot be rerun because the state it depended on is gone. Hex's answer is a notebook with a proper dependency graph between cells, real collaboration, and a publish step that turns the notebook into an interactive app with input controls that a non-technical colleague can use without seeing any code. The documentation teaches this workflow well, and the workflow is the product's best idea.
The transition from exploratory analysis to published app is the part I would point a new user at first, because it is where Hex differs meaningfully from the alternatives. You do your messy investigation, you decide which parameters a reader should be able to change, you add input components, you publish, and the thing your stakeholder receives is a controlled interface rather than a notebook full of code they will scroll past nervously. That is a real improvement over emailing a screenshot, and the guides cover it properly. The SQL and Python interleaving is also well documented.
Query the warehouse, get a dataframe, manipulate it in pandas, feed it back into another query, chart the result. The guidance on which tool to reach for is sensible: push aggregation into the warehouse where the data lives, pull into Python for the things SQL is bad at. That is the right instinct and it is worth stating explicitly, because a lot of analysts default to pulling everything into pandas and then wonder why their notebook takes four minutes to run. The dependency graph deserves specific praise as a design decision.
Hidden state is the original sin of notebooks, and a platform that tracks which cells depend on which and reruns accordingly removes an entire category of quiet wrongness where a result on screen was produced by code that no longer exists in the document. The AI material is the newest and the most provisional. Threads, the notebook agent, AI-generated SQL. It is competently written and I expect a meaningful portion of it to be obsolete within a year, because this part of every data tool is being rebuilt continuously.
My reservation about AI-generated SQL in an analytics context is not that the SQL is wrong, it is usually syntactically fine, but that a plausible query against a schema you do not understand produces a plausible number that nobody can validate. The documentation encourages review of generated queries, which is right, and does not really confront how rarely that review happens once people trust the feature. The general limitation is the same one I keep writing about tool documentation: it teaches the tool. There is nothing here about choosing an appropriate statistical test, about the difference between a correlation worth investigating and one worth ignoring, about survivorship bias in your dataset, or about how to tell a stakeholder that their question cannot be answered with the data you have.
A competent analyst with Hex will do better work. An inexperienced one with Hex will produce confident-looking apps faster, which is not obviously an improvement. That is not Hex's job to fix, but it is worth being clear that this is documentation rather than education. Three point five.
Clear, useful, honest about its scope, and covering the easier half of the problem.