How AI knows me · strharsky.dev

Ever read a message from an AI and immediately know it wasn’t written by a human?

That reaction is the whole problem in one sentence. Not that the output is wrong, but that it is generically correct: technically fine, tonally nobody, and useless the moment it has to go out under your name.

I work across four roles in a week. Writing infrastructure and pipelines, running operations and investigations, leading a DevOps team, and doing architecture work. A general-purpose assistant is a poor fit for all four at once, because “helpful” means something different in each.

This is the configuration that fixed that. Four layers, built over four months, each solving a distinct failure.

Layer 1: instincts, learned across sessions

The first gap is memory. Every session starts from zero, so every correction has to be re-issued forever. You explain your branch naming convention on Monday and again on Thursday.

The fix is a loop that watches for corrections and writes them down as durable instincts, so a lesson learned once persists into every later session. The important part is the guardrail, not the capture: an instinct is a candidate until it is reviewed, because an assistant that automatically generalizes from one offhand comment becomes confidently wrong in a way that is much harder to debug than forgetfulness.

Forgetting is annoying. Remembering the wrong rule is expensive.

Layer 2: voice, from 300 real messages

Instincts cover how I work. They cannot cover how I write, because writing style is not something you can infer from watching someone approve pull requests.

A colleague’s idea: scrape your real messages and teach the AI your actual writing style. So I did. Around 300 Slack messages across twelve months, direct messages, group chats, public channels, fed in and distilled into a brand-voice.md register guide.

Not a prompt. A profile: how I open messages, how direct I am, which emoji I actually use, how I push back, how I behave during an incident, down to the verbal tics.

It is wired into the global config so it loads whenever something is drafted on my behalf:

## Brand Voice
Read ~/.claude/brand-voice.md when drafting text on Martin's behalf
(Slack, PRs, Jira, announcements). Apply register guide from that file.

The difference is not subtle. Same model, same information, same request.

Without the profile:

Hello team, I have created a pull request that adds Infracost integration to our Terraform pipelines. This will allow us to estimate cloud costs before merging infrastructure changes. I have tested it on the DEV environment and everything appears to be working correctly. Could you please take a moment to review the PR when you get a chance? Please don’t hesitate to reach out if you have any questions. Thank you!

With it:

[Review]

PR: [link] - Infracost integration for Terraform pipelines (estimates cloud costs before merge)

Tested on DEV, looks good. Review appreciated when you get a chance :slightly_smiling_face:

One sounds like a corporate template. The other sounds like me. 300 messages, one file, every message afterwards in my own register.

Layer 3: four modes, auto-detected

Does your AI know whether you need a quick code fix or a design discussion?

Mine does, because the global config defines four operating modes and picks one from the first message:

Dev: writing infrastructure, pipelines, scripts. Concise, follow existing patterns.
Ops: operations and investigations. Triage first, most likely cause up front.
Lead: team leadership, 1:1 preparation, goals. Quantitative, direct about gaps.
Arch: architecture and design work. Tradeoff tables, challenge the assumptions.

“Fix this tflint warning on main.tf” resolves to Dev. “Prep for tomorrow’s 1:1” resolves to Lead.

I used to do this with explicit commands, a /lead before a 1:1, an /ops when a pipeline broke. That worked and I dropped it anyway, because the mode is almost always unambiguous from the request itself. Now specialized skills load on demand instead: design review for architecture work, cloud inspection for pipeline triage, team analytics for 1:1 prep.

Now I just ask the question.

Layer 4: the ten boring sections

Here is the part that gets left out of posts like this one.

Only three sections of that global config are about me. The other ten are guardrails, and they are the reason the whole arrangement is safe to leave running.

The file stays under 200 lines. Only universal rules live in it; project specifics and specialized skills load on demand.

Before it acts

Talk first, act on a green light. No file changes until I say go.
Never push without explicit review.
Pre-task setup: check out main, pull, branch per our naming conventions.

During the work

Terraform: fmt → init → validate → tflint. Every change, no exceptions.
YAML: lint the pipelines and workflows.
Three-fix stop rule: three failed attempts at the same problem means an architectural misunderstanding, not a hypothesis problem. Stop and talk to me.
Never self-review. Reviews go to a fresh agent with no authoring context.
Verify before claiming done. Red, green, revert, must fail, restore, green.

What it reaches for

Live sources over training data, for anything version-dependent.
CLI for reads, structured tool calls for writes. CLI output is compact on tokens; structured calls skip parameter discovery, so writes land with fewer flag mistakes.
Containers for local runtimes. No host installs.
Knowledge capture into a dated file, so a decision survives the session it was made in.

The first three layers make the output sound like me. The fourth is why it does not blow up a repository.

What actually made the difference

If I had to keep one of the four, it would be the guardrails, which is not the answer I expected when I started.

The personalization layers are what make the tool pleasant. The guardrails are what make it trustable, and trust is the thing that decides whether you delegate real work or spend your day supervising. An assistant that sounds exactly like me and occasionally force-pushes to main is strictly worse than a generic one I have to copy-edit.

Three sections about me. Ten about not making a mess. One file, under 200 lines.

Originally published on LinkedIn as a four-post series, April 2026. Consolidated here.