Picture a boardroom on the fortieth floor. A dozen executives around the table, one more dialling in from another continent, a presentation that took weeks to prepare, and a screen that has just gone black. Nobody in that room cares how elegant the code behind the wall panel is. They care that it worked this morning and it does not work now. I have spent more than a decade building software for rooms like that, and it shaped how I think about every system I build today, including the AI systems I now design for businesses through Frontier Consulting.
Where I started
I’m Wayne George, a software engineer in London. I began my career at Row Seven, a company in the AV software industry, which merged with Lucid Partnership in 2016. I have been a software engineer at Lucid since April 2016, building bespoke control systems for corporate clients and working on Blueprint, the company’s control software platform. I also lead the QA team, which is where much of what follows was learnt.
Since January 2024 I have also run my own company, Frontier Consulting, doing custom software and AI work for UK businesses, and I publish iOS apps under my own name. The things I have built come out of the same habits, whatever the size of the room.
If you have never worked in AV, the short version is this. Modern meeting rooms, auditoriums and event spaces are full of equipment: displays, cameras, microphones, video conferencing codecs, audio processors, lighting, blinds, room booking panels. Somebody has to write the software that makes all of it behave as one system, so that a person walks in, taps “Start meeting” on a touch panel, and everything simply happens. For more than ten years, that somebody has been me.
The tools of that trade are specialised. Crestron processors are programmed in SIMPL and its extensions: SIMPL+, which will feel familiar to anyone who knows C, and SIMPL#, which bridges the processor to C# itself, because Crestron builds its control systems on the Microsoft .NET framework. Q-SYS audio and control platforms are scripted in Lua. I hold Crestron’s Certified Programmer (Masters) qualification from 2017, a Q-SYS advanced Lua scripting certification, and a Microsoft Certified Professional qualification in C# programming.
The clients I have built control systems for at Lucid include Google, Apple, UBS, JPMorgan Chase and Morgan Stanley. I will not go into specifics about any of them; that is not how this industry works. The point is what those environments demand.
Lesson one: the room is unforgiving
Software in most contexts gets a second chance. A web page can show a spinner. A mobile app can retry quietly in the background. A boardroom cannot. When the meeting starts at nine, the system either works at nine or it has failed, and the failure is public, immediate and expensive. There is no “refresh”. There is a room full of senior people looking at a facilities manager who is looking at you.
That shaped a habit I have never lost: I assume the worst moment is the one that will happen. The network will drop mid-call. A display will be switched off at the wall. Someone will press three buttons in an order nobody anticipated. If the system cannot survive that, it is not finished.
AI systems for businesses are the same, except that the failure is quieter and therefore more dangerous. A language model that invents a figure in a customer email, or confidently approves something it should have flagged, does not go black. It carries on. The people relying on it may not notice for weeks. So the discipline is the same: assume the worst input will arrive, and build for it before it does.
Lesson two: deterministic behaviour is the whole product
The most valuable property a control system can have is that pressing the same button produces the same result, every time, in every room. Not most of the time. Every time. Most of the engineering effort in a serious control system goes into exactly that: no way to drive the system into a state that should not exist, sequences that always complete or roll back cleanly, and interfaces that report what the equipment is actually doing rather than what we hope it is doing.
Large language models are, by design, not deterministic. The same prompt can produce a different answer on a different day. That is fine for brainstorming and a real problem for a business process. So the way I build AI systems now looks a lot like the way I build control systems: a deterministic shell around a probabilistic core.
The model does the part only a model can do, such as reading an unstructured document or drafting a reply. Ordinary, testable code does everything else. Validation, business rules, permissions, and anything that touches money or a customer record live in plain code, where they behave the same way every time. In AI circles these are called guardrails. To me they are simply the control layer, and the model is one more device on the network that cannot be fully trusted to report its own state.
Lesson three: test as if the room is full
Leading QA in AV has taught me that testing is not a phase; it is a protocol. Commissioning a room properly means exercising every function against a written plan: every source to every display, every failure path, power loss and recovery, what happens when a device is unplugged mid-sequence. You do not sign off because it worked when you tried it. You sign off because a documented set of checks passed and somebody put their name to it.
For AI systems the equivalent is an evaluation suite: a fixed set of realistic inputs, including the awkward ones, each with an expected outcome, run every time the prompt, the model or the surrounding code changes. Model providers update their models. A system that passed in March can drift by June without anyone touching it. If you cannot re-run your checks in an afternoon, you do not really know what you have shipped.
Lesson four: fail gracefully, and out loud
When a control system loses contact with a device, the wrong response is to pretend nothing happened, and the next-worst is to lock up entirely. The right response is to degrade: keep the parts that still work working, tell the user clearly what has failed, and give them a way forward, even if that way forward is “call this number”. A blank screen with no explanation is the worst outcome, because it leaves people guessing.
I apply the same rule to AI. Every step that calls a model needs a defined fallback. If the model is slow, unavailable, or returns something that fails validation, what happens next? Sometimes the answer is to retry with a stricter prompt. Sometimes it is to fall back to a simpler, rules-based path. Very often it is to stop and hand the item to a person, with the context they need to finish the job in seconds rather than minutes.
Keeping a human in the loop is not an admission of failure. It is the same instinct as putting a physical help button on a touch panel. The system should know the limits of its own competence and act on them.
Lesson five: if it is not written down, it does not exist
A control system can run for years. The person who maintains it in year four is rarely the person who wrote it. In AV, documentation is not a nicety; it is how a room gets fixed at seven in the morning by somebody who has never seen it before. Drawings, address schedules, the reasoning behind odd decisions, the exact order of a start-up routine: all of it needs to live somewhere other than one engineer’s head.
AI systems have an extra documentation problem. Much of the behaviour lives in prompts, which are easy to edit and easy to lose. I treat prompts as source code: versioned, reviewed, and tied to the tests that prove they work.
I also insist on observability. Every model call wants a record of its input, output, latency and cost, so that when someone asks “why did the system do that?” there is an answer. In a control room the equivalent is the device log that tells you the codec dropped at three minutes past nine. In AI it is the trace that tells you which document the model was actually looking at when it produced the wrong figure. That need only grows when several models are working at once, which is a subject in its own right and one I have written about separately.
Lesson six: “the touch of a button” is a promise you have to keep
The phrase every AV brochure uses is “at the touch of a button”. It is true, and it hides an enormous amount of work. Behind one button on a panel might sit a dozen devices from a dozen manufacturers, a handful of edge cases nobody documented, and a room design that changed twice during the build. The user experiences none of that, which is exactly the point. Simplicity on the surface is bought with complexity underneath, and somebody has to own the complexity.
AI has its own version: “just ask it”. Behind a genuinely useful business assistant sits retrieval from the right documents, permissions so that the model only sees what that user is allowed to see, integration with the systems that hold the real data, and the guardrails, fallbacks and logging described above. Anyone who tells you the model is the hard part has not shipped one. The model is the display. The integration is the control system.
What this means if you are buying an AI system
If you are weighing up AI for your business, here is the practical version of everything above. Ask the supplier what happens when the model is wrong. Ask how the system is tested when the model changes. Ask what you will be able to see when something goes wrong, and who gets told. Ask where a person can step in. If the answers are vague, you are being sold a demo, not a product.
That is the standard I hold myself to at Frontier Consulting, and it is the standard I learnt in rooms where there was no hiding from a failure. The tools have broadened: alongside SIMPL+ and Lua I now work in Swift, TypeScript and Python, and the devices include models and APIs. The job has not changed. Make it work every time, make it fail well when it cannot, and make sure somebody can understand it later.