AI-Native or AI-Naïve?

AI-native doesn’t mean forcing adoption of a tool. It means asking the right questions. Image: AdobeStock/accogliente

An organization can buy every AI tool on the market, require everyone to use a chatbot, launch an agent pilot, build a harness, and call themselves AI-native. Yet, those same practices can leave the company scrambling to deliver value.

Why? Because that company isn’t AI-native as it claims. It’s actually AI-naïve and the organizational practices it’s enforcing are known to create avoidable problems.

A naïve company asks: “How do we get everyone using AI?”

An organization that is truly AI-native asks: “What practices let people and AI reliably solve real business problems together?”

AI-naïve organizations treat AI adoption as a tooling problem. They assume that if people have access to powerful models, good outcomes will follow. But AI does not eliminate unclear processes, contradictory instructions, duplicated information, undocumented judgment, or fuzzy ownership. It often magnifies it.

If your process is unclear, AI can help you produce unclear work faster.

If your source of truth is scattered, AI can draw from the wrong version with extraordinary confidence.

If no one can inspect how a decision was made, AI can make that opacity feel more sophisticated.

The value that gets created with any technology doesn’t come from the technology itself. It always comes with how humans use those tools to solve problems. AI-naïvety comes from the belief that tools alone will solve the problems.

My Markdown Experiment

As I step down off my soapbox, let me tell you exactly why the concept of naïvety has been top of mind for me this week. For the past year, I’ve been using Claude Code fairly heavily to build out automations for my business. One place where I’ve invested a lot is in how I create client reports after my coaching calls.

It’s hard to describe the thrill that I get from being able to reliably produce a deliverable I’m proud of, with a level of accuracy and quality I couldn’t achieve without AI assistance, and have it happen in just 30-minutes of human review instead of 30+ hours of human analysis. Every time I generate a report for my clients, it feels like a minor miracle. And that makes me happy.

But, the tooling that I use to generate these outputs is, well, not very flashy at all. 95% of it is just Markdown files. Everything is plain English with no fancy syntax at all. I rely heavily on skills, which are also Markdown files, and split out the logic into tiny structured files that are linked together with pointers, similar to a wiki page.

Structured Markdown files like this one make up the bulk of my AI-enabled business automation systems.

Using as much Markdown as I possibly can has become a kind of game for me. This isn’t the right architecture choice for every problem, but for capturing business logic it’s perfect. Syntax related to programming language isn’t necessarily needed to describe the standards for a client deliverable, the decisions that distinguish a good outcome from a bad one, the sequence of work, the exceptions, and the things a human needs to review.

Because natural language is often the best first representation of that logic, I start there and only add more when it’s necessary. My Markdown-first approach has made everything really maintainable because it lets me define the workflow, capture the constraints, separate reusable rules from one-off instructions, and see whether the system even makes sense before I add complicating factors like databases, user interfaces, APIs, Cloudflare workers, or MCP servers.

For example, I do have code so that I can reliably convert Markdown output into a branded PDF, bring in the transcripts of Zoom calls so they can be processed, push the content to a client’s private Google Drive folder, etc. But surprisingly, I haven’t needed a database yet, so I don’t have one, which makes me question whether or not I’m doing things correctly. I would add one if I started bumping into performance problems. But I’m not there, so I’m not.

The habit I’ve developed is to only add complexity when it solves a real problem. The big surprise is how little complexity I’ve actually needed. My Markdown-first experiment means I’m not introducing problems by trying to solve problems that aren’t really problems yet.

Start with the Work, Not the Tool

When I posted about this on LinkedIn, I shared that “part of me feels like this is naïve, the other part of me feels like it’s genius” and asked if there was a better way. The people who regularly build with AI pointed out two things:

1. Markdown-first is very valuable because it prevents vendor lock in.
2. Even though the tooling isn’t sophisticated, the development practices are.

The boundary between AI-naïve and AI-native comes down to what software developers describe as “first principles,” an idea borrowed from ancient Greek philosophy where you start with the conditions required for a good result, then choose the simplest ways to fulfill those conditions.

In a modern business sense, this means instead putting pragmatics over popularity. Before adopting a tool, implementing a process, or just copying a solution because everyone else says it worked for them, you first ask what the problem is you’re actually solving and from that ask follow-up questions until the right solution emerges.

AI-naïve organizations start with the tool. AI-native organizations start with defining the conditions for good work.

AI-naïve organizations think about tools first. They start with, “We have AI now! What can we do with it?” Then they layer in new tools onto scattered information, unclear decisions, and undocumented processes.

AI-native organizations start with different questions: What problems are we solving? What are the conditions of success? What counts as complete? What is the risk tolerance? Who owns the decisions? What parts of the system need to be strictly enforced? What information stays the same and what needs to change? What are our goals and objectives?

Sure, the answers to those questions could lead to a popular app that has a lot of bells and whistles, but it could lead to something as dead simple as a markdown file. The AI-native companies recognize the difference and create the conditions for the right solution to be chosen for the right problem.

Some of the first principle mantras I find myself regularly invoking include:

• Separation of concerns: Keep different kinds of logic distinct. This means I can change the way the report is formatted or how the information is compiled without having to revise the entire workflow.
• Avoiding duplication: Copy and paste is easy in the moment and an absolute maintenance nightmare in the long-run. Make it so you can edit once and that change propagates across the system.
• Single source of truth: Make it obvious where the authoritative version of a rule, policy, or workflow lives.
• Executable proximity: Keep your authoritative source of truth as close to the code that executes it as you possibly can.
• Preserve for posterity: Capture a rich history of what happened and why so you can refer back to it when you need to.
• Small and modular: Make it easy to assemble many big things from a few small parts.
• Once, twice, automate: The more often I have to do something, the more investment I’ll get from automating it, so I pay attention to my processes and will explore automation early.
• Progressive complexity: do the simplest thing completely before you extend the functionality, add new tools, etc.
• Embrace constraints: Boundaries are essential, but hard to implement and enforce.

These are just a few, and for many of them, it’s just the language I’ve developed when I talk to myself. And if you want to dive into more sophisticated practices specifically for AI, I can’t recommend Lada Kesseler’s Augmented Coding Practices enough.

Beyond Chatbots, Agents, and LLMs

More than first principles, the way out of AI-naïvety is expanding our idea of what AI is. Your organization is not AI-native simply because you make your staff do their work with a chat interface. Agents are powerful, but they’re only as useful as the systems that they are a part of. LLMs can synthesize broad trends of the past really well but we have to remember that their outputs are mostly echoes of history.

When we think of AI, we need to think of systems, not chat interfaces, agents, or a fancy frontier model.

The Organisation for Economic Co-Operation and Development (OECD) defines an AI system as “a machine-based system that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. Different AI systems vary in their levels of autonomy and adaptiveness after deployment.”

The National Institute of Standards and Technology (NIST) adds another important layer: people. Their stance is that AI is inherently socio-technical. Responsible AI depends on human centricity, social responsibility, and sustainability, while trustworthy systems should be valid, reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

Being AI-native means thinking holistically, starting with the problem and the people before any technology choice is made.

Anything less is just faster path to organizational inefficiency.