AI for Data Analysis

Start by seeing how much analysable data a design practice actually sits on. Post-occupancy evaluation (POE) data - surveys and measurements of how finished buildings really perform and feel - is gold for learning what works, yet it is often filed and forgotten. Sensor and BMS data from operating buildings logs temperature, humidity, CO2, occupancy and energy at fine resolution, holding the real story of comfort and consumption. Cost data across projects reveals where budgets blow out and which decisions drive spend. And ordinary project data - timelines, RFIs, change orders, material schedules - carries patterns about how your practice actually works.

The reason all of this stays unread is not lack of value; it is lack of time and, often, statistical skill. Cleaning a messy CSV, computing the right summary, testing whether a pattern is real rather than noise, and drawing a clear chart is real work that few designers have training or hours for. This is precisely the gap AI closes. It does not need the data to be tidy or the question to be perfectly framed - you can hand it a raw export and a plain-English question and iterate from there. That connects directly to the data skills in the companion Python course: the AI is, in effect, writing the pandas and matplotlib code you would otherwise write by hand, and you can ask to see it.

The capability behind this has a few names - code interpreter, advanced data analysis, or simply a data/analysis mode - but the mechanism is consistent. You upload a file (CSV, Excel, sometimes JSON) into the chat. When you ask a question, the assistant does not guess the answer from the numbers in its head; it writes actual code (usually Python with libraries like pandas for tables and matplotlib for charts), runs that code in a sandbox on your real data, and reports what the code produced - tables, statistics, and images of charts.

This distinction matters enormously for trust. A plain language model asked to 'average this column' might hallucinate a number. A code-interpreter tool computes the average by running code, so the arithmetic is real. The AI's judgement is still fallible - it might write code that misreads a column or drops rows - but the numbers it reports are genuinely calculated, not invented. That is why, for anything quantitative, you want the tool that runs code, not a chat that merely talks about your data.

A typical exchange is conversational and iterative:

You:  Here is our post-occupancy survey (CSV). What are the
      top complaints, and do they differ by floor?
AI:   [writes + runs code] Most common: thermal comfort (38%),
      then acoustics (24%). Complaints cluster on floors 4-6...
      [shows a bar chart by floor]
You:  Interesting - is the thermal complaint linked to the
      west-facing offices? Chart it against orientation.
AI:   [writes + runs code, shows the breakdown]

You steer with questions; it does the coding and charting. Crucially, you can always say 'show me the code you ran' - and you should, because reading it is how you catch mistakes.

As with every LLM workflow in this course, the quality of what you get back tracks the quality of how you ask. A vague 'analyse this data' produces a shapeless summary; a framed request produces something you can act on. The move is to give the AI context, a role, and a specific question - and to ask for its uncertainty, not just its answer.

Weak:  "analyse this spreadsheet"
Better: "This is a post-occupancy survey of a 6-storey office
         (one row per respondent). Summarise the top 5 complaints,
         show how they vary by floor as a chart, and tell me the
         sample size and how confident I should be. Show your code."

The stronger prompt does four things: it explains what the data is (so the AI reads columns correctly), it asks a precise question, it demands a visual, and it invites honesty about confidence. That last part matters - left to itself, the AI reports a weak, small-sample pattern with the same breezy confidence as a rock-solid one. Asking 'how sure should I be, and could this be coincidence?' is how you pull the caveats into the open.

A few reusable habits sharpen the whole exchange. Ask it to describe the data first ('list the columns, row count, and any missing or odd values') before any analysis, so you both start from the same picture. Work one question at a time and build on the answers rather than firing a paragraph of requests. And treat the conversation as iterative interrogation, not a single query: the real insight usually surfaces on the third or fourth follow-up, once you have seen the shape of the data and know the sharper question to ask. Good data analysis with AI feels less like commanding a machine and more like interviewing a fast, literal-minded analyst who will answer exactly what you asked - so asking well is most of the skill.

Beyond simple summaries, these tools are genuinely good at the exploratory work that surfaces insight. Ask for distributions ('what's the spread of response times?'), correlations ('does energy use track floor area or occupancy more strongly?'), outliers ('which months are abnormal?'), groupings ('cluster the rooms by their comfort profile'), and time trends ('plot CO2 through the day'). You can ask for a chart in the same breath, and refine it - 'make it a stacked bar, colour by zone, and sort descending' - until it communicates clearly.

The value is twofold. First, speed of exploration: you can ask ten questions of a dataset in the time it once took to set up one, which changes what questions you even think to ask. Second, accessibility: you do not need to remember pandas syntax or which chart suits which data - you describe what you want to understand and the AI translates it into analysis. For a designer, that lowers the barrier to being genuinely data-informed rather than data-rich but insight-poor.

One honest caution on interpretation: the AI will happily report that two things correlate, but correlation is not causation, and it has no real-world context to know the difference. If west-facing rooms and thermal complaints rise together, the AI sees two columns moving; you know west sun is the likely mechanism - or that both might trace to a third cause. The pattern-finding is the AI's job; the meaning is yours.

Sample size deserves the same wariness. An AI will find and chart a 'pattern' in twelve responses as readily as in twelve thousand, and present both with equal polish - but a pattern in a tiny sample is often just noise wearing a convincing shape. Ask how many records actually underpin each finding, and treat a strong-looking result from a thin dataset as a hypothesis to test, not a conclusion to act on. This is exactly where your judgement outranks the tool: you know when a finding is too good, too clean, or too thinly supported to trust, and you know which patterns are worth chasing because they connect to something real about how buildings and people behave. The AI surfaces candidates at speed; deciding which ones matter is design intelligence the tool does not have.

A clean-looking chart is one of the most persuasive objects there is, which makes an AI data tool as good at producing convincing errors as convincing truths. Several failures are common and quiet. It may silently drop rows it could not parse - a stray text value in a numeric column - and analyse a subset without telling you. It may misread units or columns, treating a code as a quantity or millimetres as metres. It may misinterpret your question, answering a slightly different one. And it can read correlation as if it were cause in its written summary. None of these announce themselves; the output looks just as polished either way.

So verification is not optional, and it is not hard. Three habits catch most trouble. Check the counts: ask how many rows it loaded and how many it used, and confirm they match your file. Read the code it ran, not just the chart - the code is the truth of what happened, and even a non-programmer can often spot a wrong column name or a dropped filter. Spot-check one number by hand - recompute a single total or average yourself and see if it agrees. If the stakes are high - the analysis will drive a design decision or go to a client - do all three, and be especially wary of any causal claim.

The framing is the same one running through this whole course: the AI is a fast, tireless analyst whose work you read before you trust. It closes the skills-and-time gap that kept your data unread, but it does not close the judgement gap. That stays yours - which is exactly as it should be, because you are the one who will act on what the data says.