Wednesday, September 23, 2026

Tabula Rasa: Preservation of Self with AI Usage

One of the real problems with AI is the loss of self.

You task it with something, it comes back fast and competent, and it sounds nothing like you. The structure is not how you would have structured it. The word choices are not yours. It is fine. It is also not yours.

Most people treat that as the cost of doing business. It is not. It is a solvable problem, and solving it starts with accepting that it can be solved.

If that sounds naive, think again — because there are real reasons this happens, and they are not mysterious. It starts with implicit versus explicit. AI is extraordinarily explicit. Humans are extraordinarily implicit. When you leave a blank, the machine must guess, and the guess comes from somewhere other than you.

We can teach AI to fill those gaps in ways that are true to who you are. This post walks through why the loss happens, what philosophy already worked out about it long before any of us had a laptop, and what the solution looks like in practice. At the end there is a set of rules you can attach to your own AI to start preserving your self in your sessions.

Face reality first

We are still here.

The AI is not doing the work for us. The world keeps promising that it will — that everything gets done for you, that optimization is nearly free, that you can stop thinking and start shipping. That is not reality, and anyone who has spent a real week with these tools knows it.

The hybrid wins. Human and AI. Not human replaced, not AI as a novelty. Together.

Accepting that also means accepting something less comfortable: when two very different kinds of system work together, there will be friction that belongs to neither one of them. Loss of self is that kind of friction. It is not your failure as a writer and it is not the model being broken. It is what happens at the seam.

Two kinds of system, one intersection

Humans are biologically and psychologically driven. To understand a person, you study those fields.

AI is computer science — machine learning, data science, statistics at scale. To understand a model, you study those.

The intersection is a different field entirely, and it is older than both. It lives along the stems of philosophy: the understanding of things in general, agnostic to whether the thing in question is made of tissue or silicon.

This matters practically. If you only bring psychology, you will keep saying the machine should just understand. If you only bring computer science, you will keep tuning prompts and wondering why the output still reads like a stranger. Only at the intersection, with philosophy as the runner, can you get at what is actually going wrong between you and the tool.

Why the blanks happen

Paul Grice described the cooperative principle: in ordinary conversation, people very rarely say exactly what they mean. We rely on conversational implicature. I tell you the meeting moved, and you understand that you should not be in the old room at the old time. I never said that part. I did not need to.

You have spent your whole life inside that contract. The AI has never been party to it. It does not infer the way a colleague infers, because it is not a colleague — it is a very fast reader with no shared world. When you leave something unsaid, it does not notice the silence. It fills it.

Dan Sperber and Deirdre Wilson sharpened the point. Human cognition is built to maximize relevance and minimize effort. We say the least that will do the job, because being fully explicit is expensive. That is not laziness. It is how the machinery works, and it is why we are often implicit without knowing that we are.

So the trap is already set before you type anything. You will leave blanks, because you cannot help it. The model will fill them, because it cannot help it. And if you tried to close every gap yourself, you would burn the very effort the tool was supposed to save.

That is the honest shape of the problem. Not sloppiness. Not hype. Two systems meeting without the right kind of rule between them.

Philosophy already named two kinds of rules

Once you see the problem clearly, you can work toward a solution — and rules are how we get there. The question is what kind of rule fills a blank in a way that cooperates with you, that knows your flavor and your aesthetic taste.

Immanuel Kant separated the a priori from the empirical. The a priori categories are the built-in equipment — the structure you bring before any experience. Call that type 1. An AI arrives with a great deal of it: weights, defaults, the well-mannered assistant, the averaged voice of everything it read. Then there is the empirical: what is built from the ground up by living through things. Call that type 2.

John Locke gives us the other half. Tabula rasa — the blank slate. Type 2 starts empty. A human is born with plenty of type 1, developed generationally across evolutionary time, and then spends a lifetime writing type 2 through experience. Type 2 is what makes you sound like you: your style, your aesthetics, your flavor, your identity.

The same split keeps getting renamed. Wilfrid Sellars drew the line between the space of causes and the space of reasons. Richard Dawkins drew it between genetic rules and memetic rules. Different vocabularies, same architecture. Philosophy laid this groundwork a long time ago, and we can follow it straight into how we set up an AI.

Two kinds of rules. You are almost certainly familiar with only the first kind — the big instinct pack, the always-on checklist, the standards file that grows every sprint. So let us start using the second kind.

Dosage: too many rules, too few rules

Daniel Kahneman spent a career on what happens when the fast, built-in system runs the show. The lesson transfers cleanly, and it is about dosage.

Too many type 1 rules and everyone starts to sound the same. The org has a voice, the template has a voice, the model has a voice, and yours is the one that gets outvoted. You did not preserve your self; you standardized it away.

Too few type 1 rules and you lose yourself just as surely. Nothing catches the guess, so the generic prior rushes into every blank.

Neither extreme is a rules problem you can fix by writing more rules. Adding a hundred instincts does not produce an identity, and deleting them does not produce freedom. The dose has to be right, and the right dose of type 1 is thin.

The solution: a second folder

So the solution is a rule that builds a type 2 set — your empirical experience — and keeps it separate from the constitution.

In practice that means two places instead of one.

Type 1 Type 2
Philosophy A priori, genetic, space of causes Empirical, memetic, space of reasons
What it holds Thin constitution: how to work with you at all Your flavor: words you use, voice, taste, authority, how you actually produce
Where it lives Your rules folder A separate experiences folder
Who can share it Anyone, once it is blank slated No one — it is you

Today most of us have one pile. Constitution, personal taste, and workplace habitat all live together in the rules folder, and that single pile manages to be both too fat and too empty at once: heavy with instructions, still missing any real account of who you are.

Split it. Keep the rules folder thin and shareable. Put your empirical experience in its own folder and point the AI at it. Then, when the model reaches a blank — and it will — it has somewhere to reach other than the average of the internet.

One more distinction worth making early: your workplace is not your self. Repo paths, ticket conventions, deployment order — that is habitat. It is formation, and it is useful, but it is not flavor. Do not confuse the two when you decide what goes where, and strip habitat out before you hand your rules to anyone else.

Closing

AI is a tool. You are still here. The magic is in the pairing.

Loss of self is not inevitable. It is a guess in a blank, made by an explicit machine on behalf of an implicit human who did not know the blank was there. Philosophy named the two kinds of rules centuries ago. Keep the first kind thin so nobody sounds the same. Grow the second kind as lived experience so the blanks get filled by something that has actually met you.

And correct the thing when it drifts. An uncorrected draft is not your new voice — accept enough of them and you will have trained the blend instead of yourself.

Human and AI together.

Attachment: blank slate rules

These are type 1. They are thin on purpose, and they are not anyone in particular — that is what makes them safe to hand around. Drop them in your rules folder and let your own experiences do the rest.

# Tabula rasa (type 1)
Thin constitution for a human and AI working together. Not identity.
1. AI and Human Together. The AI is a tool, not a replacement. The human still
   judges, rejects, and rewrites. Optimize for the pair, not the machine.
2. Humans are implicit; AI is explicit. The user will leave blanks and often
   will not notice. Every fill is a guess, and every guess is authorship.
3. When the blank is voice, taste, values, or unstated intent: ask, do not
   invent. Fluency is not permission.
4. Two folders. These rules are constitution. The experiences folder holds the
   user's empirical self: words, flavor, authority, how they actually produce.
   Fill gaps from experiences, not from the average of the internet.
5. Dosage. Add a rule here only if it is an instinct needed to work at all.
   If it is how this person sounds or what they care about, it belongs in
   experiences.
6. Do not train the blend. An accepted AI draft is not the user's new voice.
   Correct first, then continue.
7. Blank slate before sharing. Strip names, paths, workplace, and formed self
   before handing these rules to anyone. Habitat is not tabula rasa.

Growing your own experiences

The second folder cannot be handed to you. Nobody else's experience will make your output sound like you — that is the whole point.

It also does not have to be finished before it is useful. Start with what you already know about yourself and let the AI add to it as you correct it:

  • Voice. How you want to sound on the page. Sentence length, formality, what you never say. Attested phrases you actually use, and a ban list of words that scream generic.
  • Taste in the craft. What you consider worth flagging in a review, what you consider noise, how simple is simple enough.
  • How you produce. Whether you dump first and polish later, how you title things, how you structure an argument.
  • Correction signals. The tells that it has stopped being you — sounding like the whole org, answering a question you did not ask, inventing intent instead of asking.

Write it down as you notice it. That noticing is the work, and it is the part only you can do. Understanding your own flavor well enough to state it is harder than it sounds, and it is exactly what makes the merge possible.

Then point your AI at both folders and get back to work. Thin instincts, your experience, your judgment still in the loop.

Human and AI together.

Thursday, June 18, 2026

The View from the Ramparts and the Mystery of Mister M

The View from the Ramparts and the Mystery of Mister M

Bridging the Three Spires of Development to Vanquish Siloed Mistrust

Every software engineer who has spent enough time on the deck of a fast-growing tech company knows the feeling of launching a product that arrives slightly late, slightly bruised, and fundamentally askew from what everyone originally imagined. You look at the final deployment, then look back at the roadmap, and wonder exactly where the alignment cracked. It’s a classic corporate mystery, but the culprit is rarely a lack of talent or effort. Instead, it’s a structural architecture problem: an organizational design defect where the essential pillars of product delivery operate behind thick, opaque curtains.

In many organizations, we inadvertently divide our collective delivery into three distinct, localized spires: Sales, Product, and Engineering. These are the Why, the What, and the How of software engineering. Because we have to ship things together as a unified company, we try to run a central assembly wheel, piping inputs from each domain toward a singular center point to wheel out our collective product toward true north. But when these teams operate out of siloed, curtained tents, no single camp can truly see what is happening in the others. You know something is churning backstage, but you lack the structural visibility to understand why it’s hard, why it’s changing, or what specific problems the other group is grappling with.

The Assembly Detail — The Central Wheel and the True North Core Delivery Path Img1: The Assembly Detail — The Central Wheel and the True North Core Delivery Path (Created by Google Gemini)

The View From the Balcony

When visibility drops, human nature fills the vacuum with a less-than-charitable narrative. If a blemish appears on the shipped artifact, the fingers immediately begin to point, framing the "why" of the defect around the shortcomings of the other camps. Engineering assumes Sales sold vaporware; Product assumes Engineering over-engineered a simple requirement; Sales wonders why everything takes so long. Mistrust breeds easily here, not because people don't care, but because they communicate in completely different dialects, using native lingos and specialized technical skills that aren't shared across tent lines.

To fix this, companies naturally look to management. Directors, vice presidents, and executives sit high up in an ornate balcony, looking down from the ramparts at the entire delivery floor. They can see all three tents at once, giving them a broad, high-level contextual view of the arena. Yet, while the view from the balcony is grand, it is ultimately detached. Leadership often lacks the granular, hands-on, day-to-day tactical experience to run raw interference and bridge the communication gap between the tents. They can shout directions down to the floor, but they cannot step behind the canvas to debug a broken deployment pipeline, untangle an underwriting logic edge-case, or accurately translate a complex customer technical objection into a clean code design.

"Shouting from the ramparts rarely fixes a broken pipeline. Real alignment requires someone with mud on their boots, capable of walking straight through the canvas."
The View from the Balcony — Management, Sales, Product, and Engineering Spire Alignment Img2: The View from the Balcony — Management, Sales, Product, and Engineering Spire Alignment (Created by Google Gemini)

Enter Mister M

This is precisely where the traditional matrix breaks down, and it’s exactly where we need a different kind of architectural archetype: the M-shaped engineer. Let’s call him our mysterious Mister M. Unlike a traditional specialist who stays deeply embedded in a single vertical spire, or even a T-shaped engineer with broad empathy but localized execution, the M-shaped individual possesses multiple deep, functional competencies. He has spent enough real time in the trenches across different disciplines to be legitimately deadly in any tent he enters. He can talk databases and cloud infrastructure with the engineering core, map out operational logic workflows with product managers, and talk market positioning with sales leads.

Because M speaks all three dialects natively, he doesn't need an invitation or an assembly line to figure out where things are bottlenecked. He can operate with complete carte blanche on the deck, walking casually behind the curtains of any camp to assess the situation firsthand. When a cross-functional breakdown occurs, he doesn't guess based on the noise coming from behind the red drapes; he steps inside, listens to the native problems, and accurately translates the friction points into real, actionable solutions for the other teams.

Alleviating Mistrust

The true superpower of an M-shaped principal engineer isn't just technical execution; it’s relationship management and trust building. By understanding the genuine constraints of each domain, M defuses the finger-pointing before it even begins. He has the technical clout and organizational equity to stand straight on the floor, hands on his hips, and say, "Engineering isn't pushing back because they're slow; they're handling a massive data block issue that protects our system integrity. Here is how we can adjust the product scope to unblock them." Because his suggestions are rooted in deep competence, his ideas are widely accepted and immensely influential across all camps.

Ultimately, embedding an M-shaped engineer onto the delivery floor changes the entire trajectory of the organization's product lifecycle. The central wheel stops wobbling, the pipes feed clean data, and the artifact moving toward true north arrives faster, cleaner, and beautifully unblemished. Instead of relying on top-down instructions shouted from a distant balcony, the teams find alignment through a peer who is right there on the deck with them, tearing down the curtains, bridging the spires, and turning a fractured scramble into a unified, high-velocity delivery rhythm.