Just Because You Can Doesn’t Mean You Should

A headline in my newsfeed recently caught my eye. The post asked “Why are so many young professionals walking through airports with their laptops cracked open?” I laughed when I read it, because I know exactly why. It’s what you do when you have your AI tool chewing on something. If the tool is running on your laptop and you close it, it will get cut off and the task will not complete.

I stopped mid-thought and considered the implications a little more carefully; I wonder if we should be concerned.

Over the past eight months, telos has been working forward-deployed alongside the revenue management team at a top-five US carrier. We spent hours sitting with analysts to understand their workflows and their data, held regular meetings with managers to stay aligned, and worked through the architecture on whiteboards.

No AI was involved in those conversations.

What we built is a UI that surfaces distilled alerts to analysts and managers every morning. It replaces something that is familiar to anyone who has worked in airline commercial operations, and every airline has some version of this: one person spending an entire Monday assembling a hundred-page report that becomes gospel for the entire commercial team for the week, from analysts to executives. Upon receiving it, every person sorts and filters and sifts their way to the slice that matters to them, disregarding the rest.

We replaced the countless hours of rote data extraction and preparation with something that delivers the distilled version directly to each person, every day, in order of revenue importance. The agents will take no action on their own until they have earned that trust.

I will note that adoption has been an interesting challenge, one that deserves its own article. It turns out that when the information is already waiting for you every morning, the question of what to do with the extra time is not as simple as it sounds.

But that’s not the point I want to make today.

The Team Of Four

None of us on this team have the luxury of sticking to a confined job description. We don’t have a business analyst, a project manager, or a UX designer. The four of us wear all of those hats simultaneously, and the resulting product isn’t allowed to notice the difference.

I have no development background. My career was built in the airline commercial realm. My job at telos is mainly product and AI solutions architecture, yet over the past eight months I have been writing code. We don’t have an IT helpdesk, so I learned the tools the way a lot of people are learning them right now: by asking Claude to walk me through the setup, step by step, treating it like my own personal helpdesk that never tires of my (at times) incessant questions. We use Claude Design and Claude Code heavily to design the UI. We use Cursor and VS Code alongside Claude Code to write Python and SQL, along with the prompts, training documentation, and release notes that hold the whole thing together.

AI tools enabled us to build our product.

But there’s a big “BUT” here, and I want to make sure it’s crystal clear: we cannot simply hit the easy button and vibe code our way to a legitimate product for an airline to use to make decisions worth hundreds of millions of dollars per year. Full stop.

Running Away Fast

AI tools can run away from you. Anyone who has worked with them seriously knows this. You give a tool a task, you get an output, and the output is technically functional yet potentially wrong for the context in which it will be used. Claude, for all of its capabilities, can overengineer. It can produce something sophisticated and elegant that doesn’t quite understand the problem you’re trying to solve.

If no one on the team fully understands what just got built, you have lost track of your own product. This is extremely problematic when the product is being used by analysts making consequential commercial decisions. Or even more problematic if the agent is allowed to take action on behalf of the analysts.

Our rule is simple and non-negotiable: we only move at the speed it takes for us to understand precisely what lives in each pull request, how it will impact the data outputs, how it will affect the agent, and what the user will see in the UI. That is the pace of responsible AI-assisted development.

It is slower than the tools want you to go.

It requires humans to stay focused on what they are building while the instance is running, rather than making their way through a terminal with their laptop cracked open, attention split between the output and the gate’s information board and the journalist watching from across the concourse preparing to write an article on the young people with their open laptops.

I will admit I have found myself with three or four instances running simultaneously, each grinding on its own task, waiting to review the output. This is now a legitimate way to work, but carefully reviewing the output is not optional. Trusting the process without understanding the result is where things go wrong, credibility dissolves, and projects fail.

Domain Expertise

The current enthusiasm around AI-assisted engineering tends to gloss over a potential danger.

An engineer without domain expertise has no way to evaluate whether an agent output is good or bad. They can tell you why the pipeline failed, but they cannot tell you whether the output is commercially meaningful. They can tell if the agent is responding within its guardrails, but they can’t say whether the response makes sense to an analyst. This type of judgment requires someone who has done the analyst job: someone who knows what a booking curve anomaly means versus just how to identify one in the data.

Conversely, deep domain expertise without engineering depth produces its own danger. I can do things in Python and SQL now that I could not do eight months ago, but there needs to be someone on the team who fundamentally understands data engineering who is primarily responsible for the code. This person can see when something is being overbuilt or when a simpler structure would be more reliable or lower cost. Without that anchor, the AI tools will build something superficially impressive, but overengineered under the hood.

The ideal team would include one person who is both a domain expert and an engineer, but finding that person is like finding a unicorn.

The teams that get this right pair engineers with people who have done the analyst job, and put both in the room with the people who will use the tool.

Meanwhile Back At The Airport

The person walking through the terminal with their laptop open is not necessarily doing anything wrong. The tools are powerful, and using them while you move through the world is now something that can be done.

The product we built is being used to support decisions that matter. Revenue management at an airline is not an abstract exercise. The signals our agent surfaces inform decisions about inventory, pricing, and commercial response across a network. Getting those signals right requires the kind of attention that is risky if divided.

Building a system that does this reliably is not something you can do while you are looking for your gate. It is hard work. It requires the kind of focused, deliberate attention that the vibe coding conversation tends to skip. It requires a team that understands, collectively and completely, what they have built and why.

Just because you can does not mean you should, and just because the tool is running does not mean the work is done right.