What makes a company AI-native?

“AI-native” is one of those terms that gets tossed around a lot, but it means different things to different people and gets pulled and stretched to fit different purposes. (See also: software factory)

We taught the third cohort of our course this past weekend on AI transformation for execs, and someone asked us how we define AI-native. In the moment we defined an AI-native organization as one that designs everything through the lens of AI leverage from its founding (or a meaningful refounding) and treats AI as a partner in the business, rather than simply adding AI to existing work.

This is actually pretty good (better than I was expecting, to be honest, when I went back to find it in Granola). We’ll come back to the founding/refounding bit in a moment, but for now let’s set the working definition, forged with the benefit of a little time and space to think and wordsmith, as:

An AI-native organization designs how its business works around what people and AI can do together, and keeps revisiting that design as capabilities improve.

Let’s break that down into three parts.

First, designs how its business works around people and AI. There’s an intentionality here that is central to the definition. This is the same thing that “from its founding (or a meaningful refounding)” was doing in the original definition. This is a recurring theme here, but you can’t simply “apply” AI to existing workflows and expect magical results. For real leverage you need to reimagine, or redesign, your work with these new capabilities in mind. For existing companies the framing of “refounding” can be both powerful and intimidating, but we think it’s more realistic about the level of investment and change that’s required to truly transition to an AI-native organization.

Second, designs work around what people and AI can do together. This is my favorite tweak from the original definition we came up with during the course. AI-native doesn’t mean AI-everything. It’s about the intersection of people and AI, understanding where people provide leverage and where AI does, and importantly how to bring those things together to allow your ambition to reach new heights.

Finally, keeps revisiting as capabilities improve. AI-native isn’t an end state. A business that was designed around how AI and people worked together at the end of 2025, but failed to continue to adapt, wouldn’t be perceived as “AI-native” today. It’s not enough to redesign your business around today’s technologies; you also need to redesign your business to be flexible and adaptive enough to regularly reevaluate how to take advantage of advances in those technologies.

Very few companies are truly AI-native today, and most that are have been founded in the last few years. But understanding what AI-native means, and what it looks like, can help you envision what changes need to be put in place to make it possible for pockets of your org to start operating in AI-native ways.

Here’s what we’re reading this week.

The AI SDLC transformation playbook

Atlassian put out their take on what an AI-native software development lifecycle (SDLC) looks like, and how to get there. Atlassian of course wants you to literally buy into their POV on what an AI-native SDLC requires, so take it with the grain of salt it deserves. But there’s a lot of great content in here nonetheless, and we enthusiastically endorse their central thesis:

To successfully transform the entire SDLC, organizations must simultaneously invest in key platform foundations—context and measurement—while also shifting from traditional SDLC processes to AI-native ways of working.

We would suggest that while Atlassian’s designated platform investments (context and measurement) are necessary and important, the list and the approach are incomplete. Yes, your agents need access to context; no, it won’t all come from Atlassian, so you’ll need to solve connectors and permissions more broadly. Yes, you need telemetry, whether through DX or something else. But also: you need a background agent, you need multiplayer AI, you need automations.

The Dot and the Swarm

Ethan Mollick on his most recent encounter with The Bitter Lesson. Essentially he assumed it would be hard to manage agents at scale, but it turns out agents are pretty good at doing the managing themselves and humans often manage agents like they manage people, which is neither necessary nor particularly efficient.

Which tees up a larger meta-point: maybe you don’t need your complicated workflow to get high-quality results from AI? If we’re sharing secrets, neither of us are big skill people. Sure, skills have their place but skills as a way to encode process, rather than outcomes, are subject to the bitter lesson and likely destined for obsolescence. Instead we tend to prompt, without a lot of ceremony, and react, and steer, and iterate as necessary. Don’t just take our word for it though, other people agree.

How agent-ready is your codebase?

Lauren from SpaceXAI proposes a half-baked idea for how to think about how agent-ready your codebase is: time to rewrite (ttr), or how long it would take you to completely rewrite your codebase. For most sizable companies the answer, even with AI in the driver’s seat, is probably more than a year. But it’s an interesting thought experiment, as Lauren suggests:

the number itself isn’t that important, but it leads you to more questions that can help you directionally figure out how to make your codebase more legible and productive for agents.

Agent Memory Repo

Cognition, makers of Devin, open-sourced the spec for their memory management system, including dreaming. If you’re running your own agent of any kind, it’s at least worth a read. It’s not particularly detailed, but it’s interesting nonetheless. Devin has had persistent memories since we first started using it in early 2025, so the Cognition team has real experience.

What we’re talking about

Claire has been busy attributing token spend to actual investment areas, and she laid out how she did it on X.

I can tell you where every penny of token spend is going against my business, can you?

Zach created a Grok Bot to automatically find cringe-worthy UI inconsistencies in our website and other apps. Try it for yourself.

One thing to try this week

CI slowing you down? With a simple prompt and tens of dollars in tokens you can probably make some headway on your CI inefficiencies. Zach cut CI time on one of our projects by more than two-thirds this week using a goal in Codex. If you want something more plug-and-play try this skill for optimizing GitHub Actions.

Be nice to your agents. Or else.

— Claire + Zach