Data analysts and AI in 2026: fundamentals for checking results

Is learning data analysis still worthwhile in 2026 when AI can write a query and prepare a summary? I would start with a practical check: can you recognise a wrong result when the code runs successfully and the explanation sounds convincing? In everyday analysis, that question quickly moves the discussion from labour-market predictions to the work in front of you.

I do not have a certain answer about the number of analyst jobs several years from now. Nor would I promise that knowing one tool guarantees employment. What I can show is a working method that uses a model’s help while preserving your ability to explain the result. Fundamentals are useful here: definitions, data modelling, calculations, validation and communicating limitations.

This article uses an original example with synthetic data. The code was checked in SQLite through node:sqlite in Node 24. The incorrect query is deliberately constructed, not a transcript of a particular model’s response. This is neither an AI benchmark nor a repeat of a tool test from the video. The focus is a method you can apply to your own assignment.

A fluent answer does not settle correctness

A model can produce a clear explanation containing a false statement or an unstated assumption. NIST describes confidently presented false or erroneous output as confabulation in section 2.2 of its Generative AI Profile. That is a reason to verify the content. The existence of the risk does not tell us how frequently a particular model will fail on your task.

In analysis, the error need not involve an invented function. Everything may look reasonable: real table names, valid syntax and a sensibly titled chart. The problem could be counting items instead of orders, excluding missing records or comparing an incomplete month with a complete one. People can overlook those details too. Validation should therefore address the result and its meaning, regardless of who wrote the code.

I do not treat “check again” as an independent test. It may prompt a model to notice a problem, but it may also produce another persuasive explanation of the same mistake. I need a reference outside that answer: a small dataset with a separately established expected result, documentation for the function or a different way to calculate the same quantity.

I am equally careful about repeatability. A query can return the same wrong number every time. A stable result helps reproduce the process, but does not validate its definition. Conversely, differently worded explanations need not imply different calculations. I separate the model’s text, the code, the input data and the execution result. Each calls for a different kind of check.

Decide what to delegate and who settles meaning

I can ask a model to draft a query, suggest test cases or explain a syntax error. Before doing so, I define the question and unit of analysis. If I want the total value of orders, I need to know how cancellations, returns, taxes and currencies are handled. The model should not silently invent a company definition because I omitted it from the request.

Our exercise has a narrow scope: three complete orders in one arbitrary unit, without taxes, adjustments or currency conversion. We want their total value. A separate table contains order items. This is enough to demonstrate a relationship error without pretending to represent a full sales model. The simplifications are explicit, so the reader knows what the example does not establish.

For a company assignment, I first check which data may be sent to the chosen tool. I use synthetic data and a minimal schema for practice. Removing a name from an export does not automatically establish that the whole file can be shared. When organisational data is necessary, I work in an approved environment according to the team’s arrangements.

I also separate proposing a change from executing it. Asking for a read-only query does not authorise modifications to source tables. During validation, I need a controlled example and reproducibility. When a result enters a recurring report, review, ownership and update rules become relevant too. Generating the first version is one step in that process.

Write a request that exposes assumptions

A sample request could be: “Prepare a SQLite query for the total value of orders. orders has one record per order, while items can contain several records for the same order. The amount field refers to the entire order. The data is synthetic. First list your assumptions and suggest a check that would detect duplicated values after a join.” That provides more context than “calculate sales”.

I would specify the output: one query, a brief explanation of the data grain and cases requiring an additional decision. If the engine or library version matters, I name it. Code written for another SQL dialect can look familiar and still fail in my environment. A clear declaration reduces the number of details left to a convenient guess.

I ask the model to identify gaps in the definition, rather than giving it authority to resolve them. If the response assumes that cancelled orders should be excluded, I return to the requirements. Even a plausible rule can conflict with the assignment. A prompt communicates context; it does not replace agreeing on that context with the person responsible for the result.

Build small data with a known answer

The following code creates two tables in an empty SQLite database. The order amounts are 100, 200 and 50, giving an expected total of 350. The first order has two items, while the others have one each. I record that difference in granularity before running a query. It will be the controlled point where a mistake is easy to make.

-- example: fixture
CREATE TABLE orders (order_id INTEGER PRIMARY KEY, amount INTEGER);
CREATE TABLE items (item_id INTEGER PRIMARY KEY, order_id INTEGER);
INSERT INTO orders VALUES (1, 100), (2, 200), (3, 50);
INSERT INTO items VALUES (11, 1), (12, 1), (21, 2), (31, 3);

The data should be small enough to trace by hand. If I begin with a million rows and no known expected result, it is easy to confuse execution with verification. A tiny example does not establish correctness for every production dataset. It does let me test a specific property and explain why the answer should have a particular value.

In a real assignment, I would also check source completeness, the period and the meaning of the amount. I deliberately leave those questions outside this exercise because we are examining duplication after a join. A useful test has a defined purpose. Mixing a dozen unknown rules into one example makes it difficult to identify which caused a discrepancy.

Find an error that syntax checks will miss

The deliberately incorrect proposal sums amounts after joining orders to items. It runs in SQLite and returns 450. The first order appears twice because it has two items, so its amount of 100 is added twice. The database raises no error: it performs the operation written in the query.

-- example: wrong-join
SELECT SUM(o.amount) AS total_amount
FROM orders AS o
JOIN items AS i ON i.order_id = o.order_id;

This is a useful point to ask a model for an explanation, but I already have an independent expectation: 350. I am not searching for a story that justifies 450. I am looking for where the number of representations of an order changed. We can inspect the joined records or count them for each order identifier.

-- example: cardinality
SELECT o.order_id, COUNT(*) AS joined_rows
FROM orders AS o
JOIN items AS i ON i.order_id = o.order_id
GROUP BY o.order_id
ORDER BY o.order_id;

The resulting pairs are 1, 2, 2, 1 and 3, 1: the first order has two rows after the join. This check identifies a cause rather than merely reporting a difference in totals. I explain relationships and join behaviour further in the SQL JOIN guide. Understanding that mechanism lets you assess a proposal independently of its author.

Correct the rule, then try to break it

The items table is unnecessary for the total value of all orders. I calculate at the level where the amount is stored. The following query returns 350 and answers our narrow question. If I later need a breakdown by product, I will need an appropriate item-level amount. That is a different calculation with additional requirements.

-- example: total
SELECT SUM(amount) AS total_amount FROM orders;

I would not fix the problem with SUM(DISTINCT amount). That removes repeated amount values, not repeated orders. Two different orders can have the same amount. After adding a fourth order worth 100, the correct total becomes 450, while the sum of distinct amounts remains 350. The SQLite aggregate documentation explains how DISTINCT affects aggregate inputs.

I therefore add a case with an equal amount and an order without items. I also check an empty table and a missing amount. In SQLite, SUM ignores NULL values and returns NULL when there are no values to sum. That is technical behaviour, not business permission to disregard missing amounts. If complete amounts are required, a separate check should detect the gap before the result is delivered.

Check the limits of your own test

A passing test may still omit the main risk. If our example contained only orders with one item, the incorrect join would return the expected total. I therefore choose cases according to the property being checked. I need an order with several items, two equal amounts and a missing match. The differences between those cases reveal whether the solution preserves the correct data grain.

I also examine where the expectation came from. If a model wrote the query and then generated the expected number from the same reasoning, both may repeat one false assumption. For small data, I calculate separately and explain the rule in ordinary language. For larger results, I seek an agreed control total or independent review. A second file labelled “test” does not by itself make the validation independent.

When comparing methods, I check that they cover the same population. A difference may come from a different period, filter or extraction time. Matching totals also do not establish that every record is correct: two errors can cancel each other out. Alongside the sum, I inspect counts, keys and selected cases. I choose the checks according to the consequences of a mistake and record what remains untested.

Separate calculation from interpretation

A verified total still does not automatically give me a business recommendation. In the example, I know that three orders have a combined value of 350 in the chosen unit. I do not know whether the shop is performing better, whether customers are happier or what caused a sales change. Those questions require comparisons, additional data and agreed criteria. A polished paragraph cannot supply the missing evidence.

When asking AI to describe a result, I provide checked numbers, definitions and limitations. I then inspect whether the wording adds a cause we have not established. Words such as “because”, “caused” or “proves” can turn a careful observation into a much stronger claim. I keep the calculation, possible explanation and proposed next check separate in the report.

The recipient should receive the result, source, period, verification method and remaining uncertainty. They do not need the entire conversation with a model. They do need evidence that makes the calculation reproducible. In my working method, AI assistance does not remove that obligation. If I cannot explain a key step, I hold publication and return to the check.

Practise fundamentals by predicting the result

I do not need a claim that AI inevitably damages memory or intelligence to justify independent practice. I can examine my own ability: can I predict the row count after a join, explain a denominator and identify a missing rule? If the answer is no, I have a specific learning target. That is an observation about a skill, without a psychological diagnosis.

During practice, I first write down an expectation without model assistance. I then use AI to compare approaches or suggest a counterexample. Finally, I close the response and explain the solution myself with changed data. That last step matters: recognising a familiar piece of code can be much easier than applying the principle independently to a new case.

There is no need to learn every tool simultaneously. This example requires tables, relationships and aggregation. In a spreadsheet, a similar issue may concern formula ranges; in Python, the grouping level. I choose the tool relevant to the assignment and practise the principle that lets me check the result. I discuss selecting an approach more broadly in the article on data analysis methods.

Assess the full cost of automation

A quickly generated draft can be useful, but the time to first response is not the complete task cost. Checking assumptions, correcting mistakes, executing the code and maintaining it also take work. To assess an improvement, I compare similar assignments with the same quality requirement. Without that comparison, I do not report a percentage productivity gain simply because code appeared on screen within seconds.

For a recurring analysis, I record the code version, environment and checks. A new export may change a column type or introduce a case not previously present. If I update a library or the way proposals are generated, I repeat the relevant tests. I do not need to rebuild every part of the project each time, but I need to know which assumptions a change could affect.

A failed check also needs a response. A report can wait for investigation instead of publishing an uncertain number. The team should agree on who investigates and what the recipient sees meanwhile. Automation that only produces output has a narrower scope than a process ready for regular use. That distinction deserves a clear explanation when presenting a prototype.

Run your own small trial

Execute the example in an empty SQLite database. Before running the queries, write down the joined rows and expected total by hand. Then add an order with the same value as an existing order, and an order without items. Check which queries change as expected. Explain why removing duplicate amount values does not solve duplicate representations of orders.

For the second part, ask a model to suggest tests, but determine the expected results yourself. Add a missing amount and an empty dataset, then decide how the report should represent those situations. You may receive a useful suggestion, but the meaning of missing data still needs an explicit decision. Separate the technical case from the rule adopted for your application.

Finish with a short record: question, data, expectation, actual result, correction and limitation. If you used AI, add where it helped and what you checked independently. That record says more than “I use AI for analysis”. It shows that you can move from a proposal to a result you understand and can defend against concrete data.