How I Embedded AI Into Every Part of My Workflow

Let me be direct about something. When most people say they use AI, they mean they use ChatGPT to tidy up an email or summarise a document. That is level one. Useful. But it does not change how the work gets done.

I am not at level one.

Over the last two years, AI has been embedded into every stage of my workflow — from the first client conversation through to the deployed pipeline. Not as a shortcut. As infrastructure.

It Started With the Basics

I was an early adopter. I followed the trend closely as it evolved, starting with the obvious stuff — improving written communication, drafting documentation faster, summarising long requirements documents. That was the entry point for most people in data.

But I kept asking the same question: where else does the friction actually live?

Where the Real Friction Was

In analytics work, the friction is not writing emails. It is in the translation layer between a business problem and a working data model.

A client describes what they want — imprecisely, as humans do — and you have to translate that into a data model, a metric definition, a dbt pipeline, and eventually a dashboard. Each translation step is where things go wrong. Definitions drift. Requirements get lost. The final output does not quite match what the stakeholder had in their head.

AI compresses that translation layer dramatically when you use it right.

What My Workflow Actually Looks Like Now

Client discovery and requirements: I use AI to help me structure what I heard in a stakeholder meeting into a formal requirements document. Not to write it for me — to help me stress-test whether I understood the problem correctly. I will describe what I think the client wants and ask AI to identify gaps, ambiguities, or assumptions I have not validated. It catches things I miss.

Data modelling strategy: Before I write a single line of SQL, I describe the business logic to AI and talk through the modelling approach. Medallion architecture, grain decisions, how to handle slowly changing dimensions, where to put the business rules. AI is a fast sounding board that has read every dbt best practice document that exists.

dbt model generation: I maintain a context document that describes our data sources, naming conventions, metric definitions, and grain levels. When I need a new model, I describe the business logic and reference the context. AI produces a first draft that is right 80% of the time. The 20% that is not right always traces back to a gap in my context document — so fixing the context fixes future outputs too. The models improve over time as the context improves.

Executive commentary: Part of my role is turning query results into written analysis for senior stakeholders. I describe the story — what changed, what caused it, what the implication is — and AI drafts the language. I edit for accuracy and tone. What used to take 30 minutes now takes 5.

Documentation: dbt model documentation, metric definitions, data dictionaries. AI drafts, I validate and refine. The output is consistently better than what I would write from scratch in a hurry, and it actually gets written — which is the real win.

Then I Built Something With It

The logical next step was not just using AI in my workflow. It was building AI into the product itself.

I built a Speech-to-Dashboard tool using OpenAI and Claude APIs. The idea is simple: a user describes what they want to see, the tool translates that into SQL against our dbt semantic layer, executes it, and returns an interactive HTML dashboard with AI-generated narrative commentary.

That is not prompting. That is architecture. You have to understand how the LLM connects to the semantic model, how to give it enough context to generate reliable SQL, and how to handle the edge cases where the question does not map cleanly to the available data.

The clients who use the output genuinely love it. The dashboards look nothing like Tableau or Power BI because they are not Tableau or Power BI. They are purpose-built, rich, interactive, and specific to the business. The magic is the clean semantic layer underneath. Without that foundation, you are just generating bad SQL faster.

What I Have Learned

The quality of AI output is almost entirely determined by the quality of context you give it. Vague input gives mediocre output. Precise context with constraints and examples gives excellent output. Investing in good context documents pays back many times over.

The bottleneck moved. I used to be bottlenecked by implementation — how do I write this SQL, what is the right macro here. Those questions are largely gone. The bottleneck is now upstream: what is the right model design, what question is this stakeholder actually asking, what are the edge cases we have not thought of yet. These are harder, more interesting, and higher-value problems.

I also review everything. I do not trust AI output blindly. I understand where it hallucinates and where it is reliable. The value is not removing human judgement. It is compressing the time between having an idea and seeing it work — while keeping human judgement in the loop.

The Three Tiers

There are people who use AI tools. There are people who build with AI tools. And there are people who have shipped something real with AI that someone else's business depends on.

I am in the third group. That distinction matters.

The people who will do well in the next phase of analytics are not the ones who added AI to their LinkedIn headline. They are the ones who figured out where it actually fits into the work — and built something with it.