This is not a rant about AI. I use LLMs constantly. They are part of my day‑to‑day work as a data engineering consultant, whether I am writing code, documenting a platform, untangling someone else’s design decisions, or just getting a rough idea down on the page faster than I could on my own.
They are useful tools.
What they are not is a replacement for critical thinking or domain knowledge, and the more I work with teams who lean heavily on them, the more obvious that becomes.
There is a growing assumption that if the code runs and the tests pass, the job is done. That assumption is quietly doing a lot of damage.
Working code is a very low bar
In data engineering, plenty of things can “work” while still being bad engineering.
A pipeline can load data, meet the user story, and refresh on schedule while slowly creating problems elsewhere. Costs creep up because the solution is inefficient. Complexity builds because shortcuts were taken. Future changes become risky because the design only considered the immediate requirement and nothing beyond it.
None of that shows up in a sprint review or demo.
The bigger questions often go unasked. How does this fit into the wider data estate? What happens when volumes double? What happens when another domain wants to reuse this? What assumptions are being baked in that no one has written down?
Those questions are not answered by an LLM, because they are not coding questions. They are judgement calls that come from experience and an understanding of how data platforms behave over time, not just how they behave in a notebook today.
LLMs lag behind fast‑moving platforms
I spend a lot of time working with Fabric and Databricks features that are new, in preview, or recently changed. Anyone doing the same knows how quickly things move. Settings appear. Defaults change. Limitations get lifted or quietly introduced. Behaviour differs depending on capacity, SKU, region, or workspace configuration.
LLMs do not keep up with that pace.
They are often a few months behind, sometimes confidently so, and that matters when people start treating their output as authoritative. I have seen engineers told by ChatGPT that something is impossible, accept that as fact, and then start building ugly workarounds that should never have existed in the first place.
One example that still sticks with me involved a Power BI visual that people were trying to hardcode as a custom visual because they believed the platform could not do what was needed. It turned out to be a simple domain setting which needed enabling. The feature was there. The limitation was not technical, it was awareness.
This is where domain knowledge earns its keep. Not memorising every release note, but knowing how to challenge an answer, where to look next, and when a proposed workaround feels wrong.
When things break, understanding matters more than output
The biggest risk I see with over‑reliance on LLMs is not bad code. It is shallow ownership.
When something goes wrong, the engineers who have not really thought through the solution struggle to debug it. They struggle to explain why it was built the way it was. They struggle to answer basic questions about failure modes, assumptions, or trade‑offs.
They can show you that it runs. They can rerun the notebook. They can paste generated code.
What they cannot do is walk you through the logic in plain English, or explain how the design holds up under pressure. That erodes trust very quickly, especially with stakeholders who do not care how clever the code is but do care whether the platform is reliable.
If you cannot explain your own solution clearly, you do not truly own it.
The real value is in judgement, not generation
LLMs are excellent at accelerating the mechanical parts of the job. Boilerplate, scaffolding, repetitive patterns, documentation drafts, test generation. All of that is a good use of the tool, and pretending otherwise is just performative.
Where they fall down is where judgement is required.
Choosing the right tool instead of the familiar one. Deciding where logic should live. Designing for operability, not just correctness. Understanding the impact of a decision on cost, governance, lineage, and future change. Making sure the code actually feels at home in the codebase, written in a way that aligns with the organisation’s design principles, naming conventions, and documentation standards, rather than sticking out as something clearly “generated”.
Those are not problems you can prompt your way out of. They require someone to take responsibility for the outcome, not just the output.
How I try to use LLMs without outsourcing thinking
The approach I push, both for myself and for the teams I work with, is fairly simple.
I treat LLMs much like a junior analyst. They can do a lot of the basic work well if you give them clear, specific instructions, but that only works if you understand the design yourself. If you do not know what you are trying to build, you cannot delegate it effectively, whether to a person or a model.
That is how I use them in practice. I do the thinking. I make the design decisions. I decide what fits the platform, the organisation, and the level of data maturity. The LLM is there to help me implement my design faster, not to invent one for me.
That distinction matters, especially when you have built platforms across different industries and organisations. What works in one company does not necessarily work in another. A pattern that is sensible in a low‑maturity environment can be actively harmful in a highly governed one. Those trade‑offs are not something a model can infer from a prompt. They come from experience and judgement.
Because of that, I use LLMs to speed myself up, not to switch my brain off. Anything platform‑specific, architectural, or operational gets treated with caution until it has been verified against real documentation and real behaviour. If the model says something cannot be done, that is a reason to investigate further, not a reason to stop thinking.
Before anything ships, I also force myself to explain it clearly. What problem does this solve? How does it work at a high level? What are the limitations? What happens when something goes wrong?
If you cannot answer those questions comfortably, the solution is probably not finished, even if the code technically works.
Final Thought
AI is changing how quickly we can produce code. It is not changing what engineering is responsible for.
The people who will do well are not the ones who generate the most output, but the ones who can look at a working solution and still ask whether it is the right one.
Critical thinking and domain knowledge are not old‑fashioned skills. They are the difference between a system that survives and one that quietly becomes someone else’s problem.
This is simply my current thinking as of May 2026, and it looks very different to how I was thinking in May 2025. The tools will continue to improve, patterns will evolve, and LLMs will undoubtedly take on more of the work over time. What I do not see changing is the human side of data: judgement, communication, trust, and the ability to explain and stand behind decisions.
LLMs are powerful tools. Just do not confuse them with understanding.
BW