TL;DR: Social media is full of big AI talk from people who have never shipped a line of it. The real work – requirements, architecture, prompt engineering, cost, governance, and actually getting users to trust the thing – is where AI either delivers or doesn’t. Until real users are using it every day and you’re closing the feedback loop, it’s just marketing. Go build something.
There is a particular kind of LinkedIn post that has become so common it practically writes itself. It goes something like this: “AI is going to fundamentally transform everything we know about [insert industry here]. The organisations that don’t adapt will be left behind. Exciting times ahead! #AI #Innovation #FutureOfWork.”
Twelve hundred likes. Two hundred comments, mostly people tagging colleagues and writing “so true!” Nobody has shipped a single line of code.
And honestly? That is fine. We all start somewhere. The enthusiasm is real, the technology genuinely is extraordinary, and getting excited about what AI could do is a perfectly reasonable first step. But it is only a first step. And right now, social media is absolutely packed with people who have not taken the second one yet.
There is a growing gap between the volume of noise being made about AI and the number of people who have actually built something real with it. Something that end users open on a Monday morning because they have to, not because they are humoring a demo. That gap is where reality lives. And reality, as it turns out, is considerably more interesting than the LinkedIn version.
The Bit Nobody Posts About: Actually Building the Thing
I have spent the last four years designing and delivering production AI solutions across a range of industries and use cases. Not proof of concepts that live forever in a PowerPoint deck, but real solutions with real users, real feedback loops, and real consequences when something breaks, halts, or starts confidently telling people things that are completely wrong.
That experience has been genuinely exciting, and it has taught me more about what good AI delivery actually looks like than any amount of reading about it ever could. Here is some of what I have learned.
It starts with requirements. Or rather, it starts with what you think are requirements, which turn out to be about forty percent of the actual requirements once a real human being sits in front of the thing. Strong stakeholder engagement and iterative discovery are not optional extras on an AI project. They are the foundation everything else rests on. Getting this right early saves enormous amounts of time and cost downstream, and the teams that invest here consistently produce better outcomes.
Then there is the architecture. Choosing the right approach is not a small decision. Do you need Retrieval Augmented Generation? Almost certainly yes, if you want the model to work with your organisation’s own data rather than hallucinating its way through answers. That means Azure AI Search, indexing strategies, chunking decisions, embedding models, and understanding why your semantic search is returning irrelevant documents with a confidence score of 0.94. Getting this right requires genuine technical depth and careful design thinking, and when it comes together it is one of the most satisfying problems to solve.
Are you orchestrating multiple agents? Then you are probably looking at Semantic Kernel or something equivalent, and the work involves thinking carefully about which agent should own which responsibility, how they hand off to each other, and how you handle edge cases gracefully. Agent orchestration sounds exciting in a conference talk. Delivered well, it absolutely is. But it requires rigour, planning, and a healthy respect for how quickly complexity compounds.
Prompt Engineering is a Discipline Worth Taking Seriously
One of the things that gets underestimated in the broader AI conversation is prompt engineering. It is easy to frame it as a shortcut. In practice it is an iterative discipline that rewards patience, structured thinking, and proper version control.
You write a system prompt. You test it across a wide range of inputs. You find the edge cases, adjust, retest, and document every decision so that six months later the reasoning is still clear. You build regression tests so that model updates do not silently change behaviour you were depending on. You treat your prompts like code, because in every meaningful sense they are.
This connects directly to one of the more underappreciated challenges in production AI: drift. Models are updated. Behaviour changes. What worked reliably in one version may behave differently in the next, sometimes subtly, sometimes not so subtly. Building in proper governance, version pinning where possible, and ongoing output monitoring is not overhead. It is what separates solutions that remain trustworthy over time from ones that quietly degrade while everyone wonders why users are losing confidence in the system.
Cost is a Design Constraint, Not an Afterthought
Something that does not come up enough in the AI conversation is cost. Azure AI Search is not cheap. Running embedding pipelines over large document sets is not cheap. If cost is not treated as a first-class concern from the start of a project, you will eventually be explaining to a client why their Azure bill looks the way it does.
Token costs, retrieval costs, context window usage, caching strategies: these all need deliberate attention. The good news is that thinking carefully about cost almost always leads to thinking more carefully about architecture, and that discipline consistently produces better, more efficient solutions. FinOps is simply part of the delivery skillset now, and the teams that embrace it build things that scale sustainably.
The Metric That Actually Matters
Here is the honest truth about AI solutions: until your end users are actively using the thing, day in and day out, you have not built a product. You have built a very impressive demo.
A demo can look extraordinary. It can impress a room, win a contract, and generate genuine excitement. But a product is something real people rely on to do their jobs. Something they get frustrated with when it is slow, find workarounds for when it surprises them, and come back to anyway because it genuinely helps. That transition, from demo to relied-upon product, is where the real work happens and where the real value is created.
User adoption surfaces assumptions you did not know you were making. The feature you expected users to love is sometimes the one they find unnecessary. The one you were least excited about becomes indispensable. The retrieval approach that performed beautifully on curated test data meets the reality of documents that are inconsistently formatted, poorly named, and scattered across seventeen different locations.
Closing that loop is everything. Capturing what users are actually asking, understanding where the model is getting things wrong, and feeding that back into your evaluation and iteration cycle: this is where AI solutions go from good to genuinely excellent. It is unglamorous, methodical work, and it is the most valuable work on the project.
What This All Adds Up To
I am not arguing against enthusiasm for AI. The technology is remarkable and we are at a genuinely exciting moment in what it can do. The pace of change is extraordinary and the possibilities are real.
What I am arguing for is execution. The professionals who will create lasting value in this space are the ones building things people actually use. The ones navigating chunking strategies and prompt regression and governance frameworks and change management and the mid-project pivot to a completely different solution architecture. The ones whose users are opening the product on a Monday morning, relying on it, pushing it, and trusting it a little more each week.
That is where AI genuinely transforms organisations. Not in the post, not in the deck, not in the keynote. In the product. In the feedback. In the iteration. In the moment a user stops thinking about the AI and just gets their job done.
That is what good looks like. Everything else is still the warm-up.
Go build something.
