Good marketing analysts are stubborn about truth. Every time marketers dress up weak results, bury confidence intervals, or cheer for campaigns that underperformed, they begin spending down their most precious asset: trust. I have spent nearly 30 years reinforcing this with my teams, sometimes with the same phrases so often repeated they have become team lore.
“Every time marketers dress up weak results, bury confidence intervals, or cheer for campaigns that underperformed, they begin spending down their most precious asset: trust.”
When more capable large language models (LLMs) arrived on the scene around two years ago, the threat to that trust became both larger and more subtle. Artificial intelligence (AI) gives analysts extraordinary short-run capabilities, while at the same time introducing new ways to cut corners and obscure reasoning. Ultimately, the biggest danger is trading speed for quality. Throughout the past year, I have been building an AI operating system for my team: a set of concrete principles governing how we use AI as individuals and how we build AI-assisted systems.
Personal operating system: How humans should use AI
Keep exercising your brain. There is a seductive argument circulating online among a certain type of person that studying, learning, and reading are no longer necessary when AI can surface answers on demand. I find this exactly as persuasive as the argument that you don’t need to exercise because your car can run a 5K in two minutes.
Here’s the problem: The analysts who get the most out of AI are the ones who remain the sharpest independent thinkers. In my experience, this isn’t even close; brilliant people with good study habits create beautiful things with AI, while others create, well, slop. Brilliance comes from doing hard things without assistance: reading, writing, deriving formulas analytically, coding from scratch. Before automation, physical exercise was built into daily life; now people schedule it deliberately. Mental exercise requires the same intentionality.
Make AI push back. The leading consumer LLMs have been optimized to make users feel good. That is a reasonable product decision for a company driving engagement (addiction). It is a catastrophic default for analysts, whose job is to poke holes and surface uncomfortable findings.
The fix is simple: Add a standing instruction to the AI context file. Something like: Minimize sycophancy. Tell me what is wrong with my reasoning. Ask clarifying questions when requirements are unclear. Question assumptions that don’t hold up. This one change produces meaningfully better output, at the cost of more work — which is the point. Don’t use AI to write emails. AI-drafted emails are little betrayals masked as efficiency. When I receive a message with a colleague’s name on it, but the words, judgment, and voice are not theirs, I can tell, trust me. Every time AI is used for writing emails, personal trust is diminished.
Outsourcing communication also tends to generate more work, not less. AI-drafted emails are too long, too thorough, and tend to be skimmed or ignored. Awkward, direct, human emails are always better. A useful test: Would I be comfortable if my email displayed not my name but “[My Name]’s AI Assistant” in the “From” field?
Build in rest steps. Anyone who has spent a long session vibe-coding an application knows the feeling at the end: Something was built, but it is hard to explain what or why. AI enables a pace of work that outstrips human cognition. The human brain stops being an effective director of the tool you are using without a break.
The rest step is a concept from mountaineering: On steep terrain, a mountaineer pauses on each step, locks their back leg, and lets their skeleton bear the load rather than their muscles. Teams should apply the same idea to AI-assisted work. Pause for 30 minutes, an hour, or a weekend. Ask a colleague to review. Go for a long walk. The insights that emerge from stepping back are often the most important ones.
Architectural operating system: How AI systems should be built
Start with the use case, not the tool. AI is powerful enough that it tempts us to find problems for it to solve rather than the reverse. Projects that begin with a cool capability and work backwards to a use case tend to stall. Projects that begin with a well-documented need and then apply AI as the right tool for that job tend to succeed and scale.
This is not a novel principle. What is novel is how often it is violated in the current hype cycle that has seeped into almost every team, in which the pressure to “do something with AI” overrides sound design practice. Starting with the use case is, from my observations within the past two years, the single strongest predictor of whether an AI initiative will deliver durable value.
Enforce modularity. Vibe coding has made it too easy to spin up databases, functions, and services. This has started flooding organizations with redundant, inconsistent infrastructure: Multiple databases doing the same thing differently, taxonomies that almost match but don’t, and methods that work in isolation but fail when integrated.
Modularity is the antidote. The highest leverage place to apply it is data and taxonomy: a single canonical schema for accounts, contacts, campaigns, and promotions, stored centrally and used consistently across the enterprise. This creates friction in the short term but prevents the accumulation of technical debt that causes most AI projects to be quietly abandoned.
DevOps is now a front-line function. DevOps is version control, branching strategies, continuous deployment, testing, access management, and security. It has traditionally been the least sexy part of technology. However, AI-assisted development has elevated it from infrastructure concern to primary bottleneck and potential competitive differentiator.
The ratio of developers to DevOps has inverted: Where teams once needed one DevOps practitioner for every 10 engineers, they now need something closer to the opposite or, at a minimum, they need every team member to hold these disciplines as seriously as they hold their analytical craft. Organizations that treat DevOps as an afterthought in AI projects are discovering, painfully, that they cannot ship, integrate, or maintain what they build.
The right objective
One of my long-standing principles in analytics is that you can have only one objective, along with unlimited constraints. The objective that runs through all seven of these best practices that make up the “AI Operating System” is quality. Speed and volume are constraints.
AI can make us work 100 times faster. The question is whether that is the right use of the capability. My answer: Use AI to work 10 times faster, and invest the remainder in thinking more carefully, building more soundly, and communicating more honestly. That is how trust compounds and how analytics functions become indispensable rather than merely impressive.
This article originally appeared in the ANA Magazine (June 2026).
