The Post-AI Organization

"Post-AI" doesn't mean "no-AI." It means ready to outcompete an AI-first world.

A post-AI strategy is necessary because AI has already saturated the strategic field. With almost every organization in the world deploying — and often over-deploying — AI, and with investors and media looking at the technology as a basic threshold rather than a differentiator, it's no longer a way to leapfrog competitors or innovate past market expectations.

Because we now live in what's directionally an AI-everywhere world, the question for any organization isn't "how do we use AI?" but "how do we beat AI?" The answer hinges on the structural weaknesses of the technology portfolio we currently call AI — specially the dominant LLMs that are used, with various degrees of prompting, context, and tools, as plug-in brains in business processes, external applications, etc.

The core weakness of this approach is cognitive commoditification. Very few organizations are in the business of building software; most are in the business of providing financial advice, recommending books, helping organize house renovations, etc. They might build software to do it — that is, they might teach computers how to do it — but while the value they provide customers would be handicapped by bad software, this value doesn't come from the quality of the software infrastructure but from the knowledge about the activity itself inscribed in it.

Renaissance Technologies is a classic example of this. Yes, they have — they need — good computer technology, but throwing a lot of money at infrastructure and generic developers wouldn't get you anywhere near them. They know more than most about investing and they have very good internal processes to learn faster than most, and this is how they made their money.

It's currently easy to use a big LLM to build a system offering financial advice or guidance in interior design. What you can't do is use a big LLM to build a better financial advice or interior design guidance app than your competitors, for the simple reason that it's just as easy for anybody else to use them. AI can be cheaper but, on account of its universal accessibility, it can't be better; you can use it to attempt to reinforce a dominant position but not to overcome an incumbent.

That last point is worth emphasizing. Incumbents and new entrants with significant resources don't need to be the best at what they do. A mediocre service with lock-in advantages or VC money to burn during the scaling phase can and often does do very well as a business. Everybody else has to compete on price or quality, and as AI helps stoke an already generalized race to the bottom, being the best can be the most direct path for an organization with long-term ambitions. Specially in specialized B2B and prosumer markets, which are often driven by very particular and self-reinforcing forms of reputation. (The Stradivarius is the most famous and "valuable" "brand" of violins. Can you name the second one?)

In a mass-cognition economy, the only way to win is to think better than your competitors.

To think better than your competitors, you can't use the same brains they are.

Implementing strategies of cognitive differentiation isn't particularly expensive although it does require a radical rethinking of hiring, processes, and tech, and most of all in the relationship between them.

Let's say you're building an interior design app that helps pick colors, assists with purchases, etc. A competent development team will do a more or less reasonable job of it: pretty much the same app as every other competent development team - and there are plenty of them going around. "I know," you might be thinking, "we'll use AI." And maybe it helps! The problem is that every one of the other teams is doing the same at the same time.

Having one or two people knowledgeable or interested in interior design will definitely help prevent your developers from having to reinvent the wheel. But having wheels isn't enough to make something a luxury car. Do your developers know what's hot this week in interior design? Can they name the legends, have strong positions in abstruse aesthetic controversies, listen to design podcasts, automatically judge every room they walk into?

Chances are they don't. In most startups there's at best one and generally no person with that profile. It's mostly people who know about this week's hot agentic framework, they can name coding legends, have strong positions about strongly typed languages, listen to podcasts about AI, automatically judge every piece of code they read. They can develop whatever they can design, but how can they design something that can fascinate an entire discipline — which is always both industry and subculture — they are just tourists in?

The easier it becomes to develop powerful software, the less it functions as a competitive advantage. Coding freaks are no longer enough and perhaps not even necessary. To develop the sort of app that will catch the eye of the star designers whose Word of Mouth is the Word of God, to get raving reviews rather than pushback, the sort of fierce loyalty that can last a generation, you need an organization that thinks like they do, which isn't something you can fake but is something you can hire: you need the interior design freaks (the logistics freaks, the travel freaks, etc).

The difficulty isn't their cost but your culture. You won't find the best ones in any of the places you use to look for developers, and they won't think of applying to your organization. You have to go to their colleges and blogs, read their magazines and have coffee with them, not until you "learn enough to disrupt the industry" (no industry worth "disrupting" is that simple) but enough to figure out who to ask where to look for and who to get.

That's the easy step. The second step is much harder because there's a deep structural cultural hierarchy in the IT industry with "knowing how to code" at the top and everything else underneath. Which sort-of works if your organization sells compilers. It definitely doesn't if it's interior design, media recommendation, or financial advice. You don't just need to hire people who are passionate about it — not "passionate" as in "a passion for learning and generating value" but "passionate" as in "has had fights with friends about color theory" &madsh you need to hire enough of them, and give them enough influence and, yes, power, that your organization becomes an interior design group with a very competent development team attached rather than a tech organization with an in-house designer or two.

You'll know this worked out by paying attention to what people talk about during informal chats. Are they reading Hacker News or interior design blogs? Are bug reports only about code or about things the software is getting wrong design-wise? Are the trade magazines around the office being read, and if you invited one of the writers to the office, could everybody have a mutually interesting talk with them? Could your organization write an article that'd be published in an industry magazine?

Once you achieve this you'll have built your moat even if you haven't released any software yet. You'll have an organizational culture that can distinguish innovation from "innovation" — that knows what would wow the most important voices and customers in the industry because they talk, think, and see the world like them — and, because they were into design before they were building an app for design, they will make sure what you build works.

(If you find this sort of team hard to imagine or difficult to leverage, congratulations: you've hit the thought at the edge of the moat.)

Once you've hired enough non-coding freaks [/affectionate] you are probably set for a while. The main risk becomes cultural drift: you've deliberately built a culture that cares more about, say, book recommendations than about AI frameworks — you have more people with opinions about Moby Dick than about scalable database architectures — but the day-to-day work, reasonably, focuses on the business. That's fair and necessary as far as it goes yet it will inevitably try to go too far. The way tools, business processes, even management culture is currently set up most organizations tend to settle back into a common set of behavioral patterns. Never quite the same — environments can be more or less toxic, the ranges and types of pressure will vary, etc — but over time organizations "normalize" and become intellectually conservative except in very specific ways.

For example, lots of organizations building software that does entirely different things will eventually, if big enough, have some sort of hackathon where somebody will try the latest front-end library, AI framework, etc. but it's unlikely that somebody will write a short report on "versions of our software in sci-fi universes." Trying out software is a culturally accepted form of "hacking," thinking and writing (or just reading!) about alternative futures isn't. Which is exactly the wrong way around. A better library or framework might help implement a new idea about what the organization does, but it is not in itself that new idea.

The best way to keep an organizational culture not just productively obsessed but also obsessed about the right things is to engage actively with its domain beyond the immediate necessities of the business. This means research. Not just reading or watching educational materials but writing, teaching, recording, or building things about what your company does. If it's book recommendations, writing an article about the internal experience of reading and what of that translates or doesn't to observable traces. If it's architectural software, recording a video about the challenges of architectural software when spaces can be larger on the inside.

If you're strategically careless — if you demand quality but give absolute freedom on topic — one of those materials might well be what raises the profile of your organization not by going viral but by reaching the people with the combination of expertise and influence that becomes the bedrock of an organization's long-term reputation.

But that's not really why you're doing this. It's not marketing, it's training. You want your freaks to remain freaks, to dig deep and think creatively about what they are doing, and the only way to do that is to make it part of their work lives. If you don't, the risk is that they will learn to keep that part of themselves away from the office. That's how organizations lose their edge.

(If you don't think your people can write or record something about what your organization does that would intrigue an expert — not their coworkers, not the non-specialist press — you haven't hired the right people. This is a way to keep yourself honest too.)

When everybody has access to the same code assistants, libraries, and infrastructure as a service, what matters the most is what you're building, and that's not a function of the smarts of your developers but of the expertise and influence of your freaks [/affectionate]. In that sense, the organizational approach described above works as a way to obtain and hold competitive advantage by an oblique approach that leverages deep domain-specific expertise rather than universally accessible technologies like AI.

There's another aspect to this, though. If you look at the state of AI deployments at the beginning of 2026, you will see that the truly transformative ones haven't been generalized plug-in smarts but rather as components of highly specialized projects driven not by AI developers but rather by domain experts - specialized coding assistants, game theory engines, maths research tools, etc. This article began with the observation that standard LLMs cannot provide a cognitive advantage — they are too easily accessible, and are themselves built at best as unreliable replicators of existent common skills — but it's equally true that AIs built and controlled by experts — not AI experts but experts on what the AIs will be used for — can, and are probably the only way, for an organization to build a cognitive edge.

Somewhere in your organization, of course, you need developers to teach computers to do what your freaks [/affectionate] have figured out. Chances are you are going to need very good developers because what they have in mind isn't shaped by what developers are posting about but come from entirely different worlds. They will need to build interfaces for ways of working they are unfamiliar with, architect AIs that think in strange — to them — ways, consider constraints and optimize metrics with arcane definitions and opaque goals.

And that's what will make each of them more useful than the mythical "10x" generalist. Whatever they build, quickly or not, with or without AIs, will be something that their peers will not, because they have around, and in fact they work for, people with a deeper and more creative understanding of the problem than either set of developers.

And if you're lucky in your choice of developers, not in their skills but in the width and depth of their curiosity and ability to think outside the computer box, you will over time build the rarest and most valuable of development teams: people who know a domain so intimately that they can code circles around larger or better-equipped teams not just because they understand in their bones what they are doing in a way the others don't but also because they care about it not as a story in a sprint but on its own.

(Don't put this in your pitch deck, your podcast, your LinkedIn post, or your company blog, and maybe don't even say it aloud except when you're alone: the strongest competitive advantage is a deep understanding of the domain and the root of any deep understanding is love.)

(Originally posted on my blog.)