Forem: J.S_Falcon

What Operations Discipline Brings to AI-Assisted Coding: A Cross-Domain Field Guide

J.S_Falcon — Wed, 29 Apr 2026 13:13:13 +0000

TL;DR

I moved from operations / systems engineering into the software side via AI collaboration. Part 1 of this series (the entity resolution case study) is the build; this is the methodology.
Five practices and five anti-patterns, filtered through an ops lens — but the lessons generalize.
Not "AI tips you've heard." Patterns that fall out naturally if you treat AI sessions like config reviews, runbooks, and validation procedures.
Each piece is paired with a real misstep I made building Part 1.
Each part of this series stands alone. Read in any order.

Why an "Operations Discipline" Lens

Operations engineers spend their careers internalizing four habits:

Plan before you build — designs, runbooks, change requests.
Verify before you declare done — validation procedures, post-change checks.
Document state — configs, design docs, postmortems.
Suspect numbers — every monitoring datapoint hides an artifact.

These habits transfer directly to working with AI coding assistants. The disciplines you learned debugging routers, filing change requests, and reviewing configs are the same ones that prevent AI sessions from sliding off the rails.

I'm framing this through ops because that's the lens I learned from. Most of these patterns generalize beyond ops — software engineers, data engineers, and SREs will recognize them. The ops version just happens to package them tightly.

Part 1: Five Practices

Practice 1 — Treat your CLAUDE.md (or system prompt) as a design-spec preamble

In ops, every change procedure has a preamble: prerequisites, scope, rollback steps, validation checks. Same energy in AI work.

CLAUDE.md is Claude Code's persistent instruction file. (Other assistants have equivalents — system prompts, custom instructions, etc.) Use it the way you'd use a runbook preamble:

## Operating principles
- Always plan before implementing.
- Confirm ambiguous instructions before coding.
- Always provide a counter-argument when proposing a design.
- Never report a metric without showing how it was measured.
- Distinguish "should work" from "actually verified to work."

Once written, every future session inherits these rules. You stop re-explaining yourself. This is the same template-then-reuse pattern that saves you from rewriting a runbook for every change window.

Practice 2 — Demand a Devil's Advocate, every time

Design reviews exist because group-think kills production systems. Force the AI to argue against itself in every proposal.

Three asks I bake into every meaningful design conversation:

What's the worst-case failure mode of this design?
What use case did you not consider?
Give me three reasons to reject this design.

Bake this requirement into your CLAUDE.md and you stop seeing pure agreement. An AI that only agrees with you is a single point of failure.

Practice 3 — Force ambiguous instructions to be confirmed before implementation

In ops requirements gathering, "implement loose specs" is a known disaster pattern. The same is true for AI sessions, where ambiguity gets resolved silently — and usually wrong.

Real example from Part 1: I said "treat the ID and the display name as a pair, match if either is present." The AI interpreted that as two independent search keys. Half the matcher had to be rebuilt.

Lesson, written into CLAUDE.md: if an instruction has two valid readings, ask which one I mean before writing code.

This is the same habit as a senior network engineer asking "do you mean inbound or outbound?" before touching the firewall.

Practice 4 — Separate "theoretical evaluation" from "real-world evaluation"

Ops engineers know the gap between "the spec says it works" and "I've watched the LED light up." The same gap exists in AI work, and it's wider than you'd think.

Real example from Part 1: the AI claimed about 99.2% recall based on past-data pattern analysis. I asked for an actual run on the real dataset. The actual recall came back at 55%.

The lesson is not "the AI lied." The lesson is that pattern-analysis predictions are not the same as a real execution result. Every claim that sounds like a measurement deserves the question: was this measured, or estimated? If estimated, label it that way and move on; if measured, show the run.

Practice 5 — Have the AI write its own verification scripts

If the AI says "this code achieves 99% recall," ask it to write the script that measures that recall. Then run it.

This converts:

A claim → a script.
A script → an audit trail.
An audit trail → reproducibility.

It is the same pattern as runbooks: a change procedure and a validation procedure, always paired. The validation script becomes a permanent artifact you can hand to the next person — or to your future self when something regresses.

Part 2: Five Anti-Patterns

Anti-Pattern 1 — "Just build me a tool"

The AI equivalent of "fix the network." Without scope, the AI invents one. Worse, it pursues the invented scope confidently, so the wrong direction is pursued aggressively.

Treat session start like requirements gathering: rough goal, key constraints, what's explicitly out of scope. Five minutes of scoping saves five hours of rework.

Anti-Pattern 2 — Trusting headline numbers without verifying composition

"99% recall" sounds great until you discover it was measured on cherry-picked rows, with the test set leaking into training data, on a metric that doesn't reflect the actual user experience.

Before reporting any number, ask:

How was this measured?
On what data?
Under what conditions?
With what biases?

This is the same suspicion you apply to a monitoring dashboard reporting zero alerts: is the agent actually reporting, or is it dead?

Anti-Pattern 3 — Throwing raw error text at the AI without context

"It doesn't work" → "Why?"

In ops you'd never debug a router by saying "it's down." You'd attach: configuration, status output, syslog excerpts, behavior of connected devices.

Same here. The AI cannot infer your environment. Show the command, the actual output, the expected behavior, and the deviation. Treat each interaction like a bug report you'd file with a vendor.

Anti-Pattern 4 — Sending business data to an AI without compliance review

Default assumption: any data you put into a prompt may be retained, indexed, or used in training, regardless of what the vendor's marketing copy says.

The operational habit is straightforward — redact, mask, or synthesize. The same instinct that keeps you from posting customer IPs to Stack Overflow should stop you from pasting customer rows into a prompt.

(Part 1 covers this pattern in depth as it applied to the entity resolution build. The short version: deterministic logic touches the data; the AI touches only code, design notes, and synthetic samples.)

Anti-Pattern 5 — Stopping at "it works"

"The code runs" is not the same as "I understand why it runs."

The ops version of this is: a configuration that worked once but I can't explain is a future incident.

Make the AI explain why the working solution actually works. If neither of you can defend the design after one cycle of follow-up questions, treat it as a yellow flag — not a green light. Ship explainable code; the unexplained kind owns you on the day it breaks.

Wrap-Up

The pattern across all ten:

Apply ops discipline to AI sessions.
Treat AI claims like vendor claims — verify them in your environment.
Treat AI conversations like change windows — preamble, scope, verification, postmortem.
Treat AI outputs like config diffs — explain them or reject them.

What I'm explicitly not claiming:

These are not unique to operations engineers. They generalize. They just happen to package tightly through the ops lens because the discipline is already there.
These are not the only practices. Five is a lossy compression. The ten you'd build for your environment may differ in detail.
These cover the build phase of AI-assisted work — the session-time discipline. Day 2 operations (monitoring AI-generated code in production, detecting silent drift, incident response when AI-assisted changes break) is its own discipline and deserves its own article. The patterns here are necessary but not sufficient for production AI usage.

The big idea: AI doesn't replace engineering judgment — it amplifies it. Amplifying lazy judgment produces more bad code, faster. Amplifying disciplined judgment produces clear, audited, defensible work.

What's Next

A future part of this series will cover how the design review for these articles actually happened — a Multi-AI Adversarial Review (MAAR) loop where Claude and a second AI argued against each other under human routing. That's the meta-process behind both Part 1 and this one.

If you came in via this article, Part 1 is the concrete build that produced these lessons.

Comments welcome — particularly:

The five practices or anti-patterns you'd add.
Cross-domain engineering experiences (any technical background → another).
Cases where ops discipline did not transfer cleanly to AI work.
Rollback strategies when an AI-assisted change corrupts your codebase or repo state.
Day 2 operations practices for AI-generated code in production (monitoring, drift detection, incident response).

Beating 250,000 Mental Comparisons: A Cross-Domain Engineer's Entity Resolution Case Study

J.S_Falcon — Wed, 29 Apr 2026 11:13:41 +0000

TL;DR

Operations/Systems engineer recently moved to the software side via AI collaboration.
Built a domain-specific entity resolution tool in a handful of evening sessions with Claude Code.
Caught about 99.2% of human-detected reconciliation errors when replayed against 8 weeks of historical data.
Turned a "skilled-veterans-only" weekly task into something anyone on the team can run.
Design retrofitted unexpectedly well to dual process theory, Gestalt psychology, and anchoring-bias defense.
Source business records never reached an LLM. Deterministic pipeline + human review only.

1. The Hidden Problem: When 500 × 500 Becomes a Cognitive Wall

Many companies maintain the same business entities across multiple systems.

A retailer tracks SKUs in an internal master AND on Amazon / Rakuten / Shopify exports.
A clinic carries patient records in both an EMR and an insurance billing system.
A manufacturer holds internal inventory but also receives partner inventory feeds.
An accounting team reconciles general ledger entries against bank statements.

These pairs need periodic reconciliation. In the technical literature this is Entity Resolution or Data Reconciliation — a universal problem that nearly every mid-to-large business hits eventually.

The case study here uses the retail SKU vs marketplace listing framing. (The actual industry I work in is intentionally abstracted, but the structure transfers cleanly.) Two systems, ~500 rows each, weekly reconciliation. Skilled humans needed about 3 hours per week. Newcomers, half a day to a full day. Hidden detail: the small row count masks the real difficulty.

Why is 500 × 500 hard?

The 250,000 problem

Manually reconciling 500 × 500 pairs forces a person to evaluate up to 250,000 combinations in their head. Not 1,000 — 250,000. Plus typo tolerance, format variation (full-width vs half-width, mixed scripts, abbreviations, punctuation), and partial matches. Each pairwise judgment is not O(1).

Brute-forcing this is computationally similar to running a 1,000-node full-mesh ping check vs a flat 1,000-node liveness check. Order-of-magnitude different load.

Working memory overflow

Miller's "magical number" puts our short-term memory at 7 ± 2 chunks (Miller, 1956). Hunting matches across 1,000 candidates with format drift continuously overflows working memory and pegs System 2 (slow thinking) for the entire session. The 3-hour exhaustion experienced by veterans isn't a complaint — it's a neurological inevitability.

"Short to do" doesn't equal "easy to do" for cognitive labor.

Reproducibility decay

A one-off reconciliation can be brute-forced. But when the task repeats weekly across 10+ weeks, judgment drift becomes unavoidable:

"Last week I matched 'A Co.' and 'A. Company' as the same entity. This week I treated them as different."
"Last week I tolerated typo X. This week I rejected it."

This drift is what really breaks data quality long-term. It's the same structural failure mode as "config review standards differ by reviewer" in infrastructure operations.

The actual target

So the real problem the tool solved was not "shorten 3 hours per week" but:

250,000 judgments × 10 weeks of consistent reproducibility — a quality bar humans can't physically sustain — backed by a deterministic machine.

Plus removing the skill dependency. "Only one veteran can do this in 3 hours" is a single point of failure. After the tool: anyone could run it with consistent quality.

2. Background: Who I Am and What I Was Solving

I'm an Operations/Systems engineer. Configuration, validation, runbook authoring, monitoring, troubleshooting — that side of the house. Software development was not my primary craft, though scripting was always part of the job.

I'd recently moved into a new business domain (about 2 months in) and the tooling target system was something I'd only been touching for ~1 month. From the user side I'd seen the workflow longer, but not as a developer.

Translation: design / validation / runbook discipline solid. Python and application development essentially unfamiliar.

This article is not a "look what I shipped" piece. It's a record of how operations-side disciplines transferred unchanged into AI-assisted software work in an unfamiliar domain.

Who this article is for

Reader	Useful sections
Operations / SRE engineers exploring AI assistance	Everything
Mid-career engineers moving across technical domains	Background, Architecture, Cognitive Design
Engineers new to AI-assisted development	Architecture, Cognitive Design, PII
Managers thinking about AI for their teams	Results and the cognitive-load argument

3. PII / Compliance Considerations

A question that always comes up in comments on entity-resolution articles: where does the data go? Worth answering up front.

In this implementation:

Source business records never reach any LLM. Both input files (internal master + external system export) are read locally by a Python script.
Matching is fully deterministic. Pandas, openpyxl, and difflib.SequenceMatcher for similarity. No embedding API. No remote inference at runtime.
The LLM's role is code-side, not data-side. Claude Code helped write the matching logic, the validation scripts, the design review, and the documentation. None of the actual records were ever sent.
For testing only, masked synthetic data was used in prompts. Real names, amounts, and addresses were replaced with synthetic equivalents before any prompt left the local environment.
Edge cases stay with humans. When the deterministic pipeline can't decide, it surfaces a flagged row for human review — not for LLM second opinion.

This separation is intentional. The matching task is well-suited to deterministic logic. LLMs would only add cost, latency, and compliance exposure for no quality gain.

If your team has even a soft "no business data into external AI" policy, this pattern is fully compatible.

4. Architecture: Two-Stage Matching + Cognitive Gates

Stack

Python 3.11
pandas + openpyxl (Excel I/O, color-coded output)
difflib.SequenceMatcher for fuzzy similarity
Rule-based throughout. No machine learning.
~1,100 lines, single script.

Phases

Phase 1: Match by exact stakeholder name (or alias group)
Phase 2: Cross-match by name similarity ≥ 0.6 (rescue typos)
Phase 3: Last-name-only + structural match (single-typo tolerance)
Phase 4: Duplicate-registration detection (same stakeholder + similarity ≥ 0.8)
Phase 5: Rescue rows with no stakeholder name (attribute match)
Phase 5.5: Attribute-mismatch pair rescue (identifier similarity ≥ 0.7, stage 2)
Phase 6: Row generation + color decision

The score function (key gates)

def compute_score(row_a, row_b):
    # Hard gate: region must match — kills cross-region false positives
    if region_a != region_b:
        return 0.0
    # Hard gate: numeric attribute must be close enough
    if abs(value_a - value_b) > THRESHOLD:
        return 0.0
    # Identifier gate: row_b's identifier must be embeddable in row_a's identifier
    if not is_identifier_match(addr_a, identifier_b):
        return 0.0
    # Sub-identifier gate: anchoring-bias defense
    if sub_id not in addr_a:
        return 0.0
    # Soft scoring (only after every hard gate passed)
    score = max(identifier_match_score, similarity, value_fallback)
    return score if score >= 0.6 else 0.0

Why this shape?

The retail SKU framing helps here. The same product on a marketplace might appear as iPhone15 in your master and iPhone 15 Pro Max on the marketplace. Same item family, different surface form. Two key insights:

Hard gates first. "Different region" or "value difference > N" are absolute disqualifiers. Run them before any expensive similarity computation.
Soft scoring last. Once hard gates pass, compute similarity — but cap below 0.6 as "uncertain, surface to human."

Why not ML / Vector DB / embeddings?

Deterministic rule-based was chosen on purpose. Auditability was the requirement. When a flagged row is wrong, the operations team has to be able to trace exactly which gate fired and why. A black-box similarity score of 0.81 with no explanation cannot be reviewed, cannot be unit-tested, and cannot be defended in a compliance audit.

ML is a fine choice when you have labeled training data, training infrastructure, and a continuous evaluation pipeline. None of these applied here. The operating constraint was: "anyone on the team should be able to read the code and know why it decided what it decided." That constraint forces deterministic logic.

Abstracted structure

Domain-specific term	Abstract concept
Item / SKU	Entity
Stakeholder (vendor / agent)	Stakeholder attribute
Price / Amount	Primary numeric attribute
Address / Location	Identifier (multi-attribute)
Building / SKU name	Auxiliary identifier
Detail number / barcode	Sub-identifier
Format variation (kana/latin/case)	Data quality issue
Domain judgment	Tacit knowledge

This is a universal "match entities across two systems with format drift" problem. The pattern reappears in EC, healthcare, HR, accounting, manufacturing, publishing — anywhere two systems represent the same business object differently.

5. Cognitive-Science Design Principles (the Twist)

I didn't design this thinking about cognitive science. I built it, it worked, and only afterwards in a structured Gemini conversation did the underlying principles surface. The retrofit fits unsettlingly well.

5.1 Dual process theory (Daniel Kahneman)

The two phases map onto two thinking modes:

System 1 (fast) = Phases 1–5. Fuzzy "is this roughly the same thing?" — similarity scores, identifier matching, attribute closeness.
System 2 (slow) = determine_color(). Strict checks for value mismatch, format inconsistency, identifier mixing.

Color-coded human review gets the System 1 fuzzy pass plus the System 2 strictness annotation, which is exactly the input shape humans need to make a final call.

5.2 Gestalt psychology

Humans recognize "wholes," not character sequences. iPhone15 and iPhone 15 Pro Max feel like the same product family even though strict string equality fails. So:

def is_identifier_match(addr_a, identifier_b):
    """Recognize chunked identity even with mixed scripts and separators."""
    chunks = re.split(r'[A-Za-z0-9\s\-_]+', identifier_b)
    return all(chunk in addr_a for chunk in chunks if len(chunk) >= 2)

Matching by chunks survives whitespace, separator, and script variation.

5.3 Anchoring & confirmation bias defenses

Hard gates exist to deny human-style intuitive shortcuts:

"Same price, must be the same item" — rejected by sub-identifier gate.
"Same name, must be the same person" — rejected by region gate.

The machine's job is to be coldly skeptical exactly where humans get over-confident.

5.4 Reducing human cognitive load (Human-in-the-Loop)

When a human is asked to confirm a flagged row, they don't get an opaque "match score 0.62". They get a one-line annotation:

Same entity matched | [Value mismatch] diff ¥2,000,000 (5.4%)
(A: ¥34,900,000 / B: ¥36,900,000) · identifier format inconsistent

The human doesn't waste cycles re-deriving why the row was flagged. Cognitive load drops sharply.

5.5 Don't automate the ghost

This part borrows from Ghost in the Shell. Some judgments depend on tacit business knowledge that can't be reduced to rules. Don't build heuristics that pretend to encode them. Surface the row as a caution signal and let a human apply the tacit layer.

Tightening the logic isn't a path to recreating the ghost.
It's a path to revealing where the ghost is needed.

Mapping summary

Cognitive concept	Implementation
System 1 (fast)	Phases 1–5 (fuzzy matching)
System 2 (slow)	`determine_color()` strict checks
Two-stage / dual-pass	Stage 1 + Stage 2 (Phase 5.5)
Gestalt grouping	`similarity` / `is_identifier_match`
Anchoring defense	Sub-identifier gate, identifier gate
Cognitive load reduction	Aggregated `[reason] diff X` annotations
Human-in-the-Loop	Caution signals for tacit-knowledge zones

6. Results

Recall on 8 weeks of historical data

Metric	Value
Errors flagged by humans (excluding outlier weeks)	~130
Errors caught by the tool	~129
Recall	~99.2%

The single missed case was annotated by the human reviewer as "even a human couldn't decide here." Effectively the tool catches every case where a human commits a confident verdict.

(Caveat: this is recall against 8 weeks of one team's data, not a benchmark claim. Different domains will need their own measurement.)

Time and skill load

Item	Before	After
Skilled veteran throughput	~3 hrs/week	~30 min/week (review only)
Newcomer throughput	half a day to full day	~30 min/week
Skill dependency	Yes (single point of failure)	No (anyone can run it)

The time number understates the value. The real shift is breaking the skill SPOF. Veteran out sick, leaves, or buried in another priority — work continues at the same quality.

A note on false positives

Recall is 99.2%, but the tool is intentionally tuned for higher recall over higher precision. False positives — pairs flagged for human review that turn out to be fine — are accepted as the trade-off. The ~30 min/week of human review handles them without strain.

In a no-human-in-the-loop deployment this trade-off would be very different. Here, false positives are cheap (a glance from a human reviewer) and false negatives (missed reconciliation errors) are expensive (data drift propagates into business reports).

7. The Flowchart

Drawing the judgment flow as diagrams surfaced things the code review didn't. Below are the four phases as separate figures, in execution order.

7.1 Phase 1: Hard Gates (sequential disqualifiers)

Region → numeric value → auxiliary identifier → sub-identifier. Each gate is an absolute disqualifier: any "No" drops the pair. The order matters — cheapest disqualifiers run first.

7.2 Phase 2: Soft Match

Once a pair clears all hard gates, compute_score evaluates a soft similarity. Below 0.6 → drop. At or above → lock the pair as the same entity.

7.3 Phase 3: Parallel Flag Checks

For confirmed matches, six independent checks fire in parallel. Each surfaces a "this matched, but here's a discrepancy" signal. Tags are aggregated; there is no early-return contamination between checks.

7.4 Phase 4: Final Verdict and Drop Aggregation

Aggregate the tags into a color verdict. Drops from Phase 1 and Phase 2 converge into the "Unmatched" lane, surfaced standalone in the human-review output.

Things visible only after rendering as a diagram

These were invisible while reading code, only obvious once drawn:

Phase 1 hard gates are ordered by computational cost. Region → numeric → auxiliary → sub-identifier. I placed them by intuition; the diagram showed they were already optimal — cheapest disqualifiers first.
Phase 3 parallel flag checks are genuinely independent. Six checks fire in parallel with no early-return contamination. The diagram confirmed there was no silent dependency between them.
All Drop1–Drop5 paths converge to the same Unmatched node. I was throwing away the drop reason. Re-running "why was this pair rejected?" was impossible. Fix: log the drop reason in the row annotation.

Drawing the flowchart is roughly the same act as drawing an infrastructure topology before going live. The diagram is the rubber duck.

8. Wrap-up

Three transferable lessons from this build:

Cognitive load is the hidden cost of "short" repetitive judgment tasks. Headcount-hour math undersells the burnout reality and skill-SPOF risk.
Cognitive science principles fall out of good design retroactively. I didn't design with them in mind; the principles became visible only through structured review (with a second AI). If your design retrofits to known principles, that's confirmation. If it doesn't, that's a smell.
LLMs do NOT have to touch your data. Most entity resolution work doesn't need them at all. Use them for code, design review, and documentation. Keep the business records local and deterministic.

The implementation itself is internal-use only and won't be open-sourced. The patterns generalize cleanly to any two-system entity reconciliation: EC, healthcare, HR, accounting, manufacturing, publishing.

9. What's Next

Coming in Part 2: how this whole thing got built in the first place — the AI collaboration patterns, the anti-patterns I hit, and the cross-domain disciplines that transferred from operations to software development. (Link to A2 once published.)

Comments on entity resolution, cognitive load in repetitive tasks, or cross-domain engineering experiences are welcome.

Field Notes from a Cross-Domain Engineer Working with AI

J.S_Falcon — Wed, 29 Apr 2026 01:36:50 +0000

I run two AI assistants from different vendors against each other on every non-trivial decision, with a human (me) sitting in the middle as the routing authority. What's surprised me most is not that they disagree — it's how they disagree. They drift toward agreeing with me too quickly, then with each other too quickly, and I've had to design specific friction into the workflow to keep their disagreement productive.

Writing this down because I think the friction patterns might be useful to other people running similar setups.

What this is

I've been working as an operations / systems engineer for about twenty years. Networks first, then servers, then config management, then incident response. The kind of role where the job is mostly making sure nothing breaks, and where every change request comes with a runbook, a verification step, and a rollback plan.

In the last year and a half, AI coding assistants pulled me into the software side of the house. Not because I wanted a career change — because the boundary between "writes code" and "runs systems" got thin enough that ignoring it stopped being an option.

This series is a running log of what I've been finding, written as I go. The disciplines I pulled in from operations turned out to map onto AI collaboration unexpectedly well. The places where they didn't, I've had to invent something for myself. Observation-heavy and prescription-light. I don't think I've discovered anything new; I've stumbled into the same territory a lot of practitioners and researchers are mapping right now, and I'm writing down my coordinates while they're fresh.

What this is not

A few things I want to flag up front.

This is not a survey. I haven't done an exhaustive review of the literature, the toolchain ecosystem, or the practitioner community. I'm certain there are people who've been running similar disciplines longer than me and writing them up better. If you find one, please send me the link — I'll learn from it, and I'd rather correct the record than defend a stale draft.

This is dated material. Anything you read here is a snapshot from early 2026, written from one specific vantage point: a Japanese operations engineer transitioning into AI-assisted software work, with paid Claude / ChatGPT / Gemini subscriptions and no team-scale deployment. If your context differs significantly, the disciplines may transfer poorly or not at all.

The five disciplines this series circles around

A set of operating principles I keep coming back to in my own daily work. Each earns its own article (or several) in the series. The short version, in a "simple to compose" → "complex to compose" order:

1. TTL Satisficing

I cap the number of back-and-forth rounds in any AI-assisted decision. Three is a good default. The point is not to find the perfect answer — it's to converge on a good-enough answer before the next round costs more than the marginal improvement is worth. If three rounds don't converge, I treat that as a signal that the problem is the problem, not the round count.

This is essentially timeout / retry-budget design from network operations, applied to a conversation with an AI.

2. The Karpathy Rule (Simplicity First, Surgical Changes)

Andrej Karpathy's framing, adapted to my workflow: I don't let the AI add what wasn't asked for, and I don't let it edit what wasn't in scope. Speculative additions are how technical debt grows at AI speed. Keeping the diff small and the proposal narrow is a discipline I have to actively enforce.

This maps cleanly onto YAGNI ("You Aren't Gonna Need It") and minimal-diff code review culture — pre-AI principles, applied to a faster-moving collaborator.

3. Fail-Fast (Tolerance for Contradiction)

When a problem doesn't converge across multiple attempts and multiple AIs, I want the AI to declare it unfeasible and hand me a graceful-degradation path. The AI's job is not to grind itself into the ground trying to solve everything. Its job is to return judgment to the human when judgment is what's actually needed. "I can't solve this, here's how to amputate it cleanly" is a better answer than "I'm trying again, please wait."

This is circuit-breaker behavior from distributed systems, applied to AI reasoning loops.

4. Adversarial Review (the Devil's Advocate, made standing)

For any non-trivial proposal, I force the AI to argue against itself. Standing instructions — in CLAUDE.md, in custom instructions, in the system prompt — so I don't have to remember to ask. An assistant that only agrees with me is a single point of failure, not a colleague.

This is red-team review and RFC-style structured criticism, made automatic instead of episodic.

5. The Human Router (Multi-AI Adversarial Review)

For decisions with real trade-offs, I run two AIs from different vendors against each other and stay in the loop as the routing authority. Not as supervisor, not as referee — as the operator who decides which output goes where, and which conflicts get escalated. The cross-vendor part matters in my experience: same-vendor "multi-agent" setups still share a worldview. Cross-vendor (e.g., Claude vs. Gemini) actually surfaces disagreement.

This is human-in-the-loop control plane thinking, where the data plane is "AIs argue" and the control plane is "human decides which arguments matter."

I want to be clear: none of these are inventions of mine. The literature has Multi-Agent Debate, Self-Refine, Reflexion, Constitutional AI, and a growing body of human-in-the-loop research. I'm describing how I personally compose these ideas into a daily workflow, and writing down the specifics in case the composition is useful to someone.

Why "Cross-Domain"

I keep using this word and I should explain it.

The AI engineering conversation I see is heavily centered on the programmer's lens — code generation, dev tools, IDE integrations, prompt-to-PR workflows. That lens is real and valuable, and I'm not arguing against it.

But I came in from operations, and operations has its own logic. Change management. Verification gates. Runbooks. Rollback procedures. Skepticism toward dashboards that are too green. The instinct to ask "how would I know if this is silently broken?" before celebrating a green build.

When you bring those instincts to AI collaboration, you get a different shape of practice than you'd get if you came in from the dev side. Not better. Different. And I think the differences are worth writing down, because operations engineers, SREs, data engineers, business systems people, and infrastructure folks are all about to find themselves doing AI-assisted work — and the dev-centric playbook isn't going to fit them perfectly.

That's what "cross-domain" is pointing at. Not crossing one specific bridge, but recognizing that there are many bridges, and that each engineering discipline brings its own toolkit to the AI collaboration table.

What's coming in this series

(Links will appear as articles are published. Each piece is designed to stand alone — you don't need to have read this anchor page to follow any of them. This index is just here for the curious.)

Entity Resolution case study — A practical build: deterministic two-system reconciliation with AI assistance, no business data leaving the local environment, ~99.2% recall on historical replay. Where I learned that operations discipline transfers cleanly to software work in unfamiliar domains.
AI Collaboration Patterns — Five practices and five anti-patterns I picked up running AI-assisted operations work day to day. The kind of thing you only learn by getting burned.
Alchemy Essay — A late-night thought experiment mapping AI coding onto the principles of Fullmetal Alchemist. The most polemical piece in the series; also the most personal.
Domain-Native Governance — The architectural argument: why dev-centric AI governance feels insufficient from where I sit, and what a domain-native alternative might look like. The most theoretical piece in the series.
Domain Logic First — A position piece: each engineering discipline has its own logic, and there might be value in adapting AI to it rather than the other way around.
Field-Note Tips (ongoing) — Short pieces on individual operating habits: the CLAUDE.md preamble template, three-tier tool routing, telling fast evaluation from real evaluation, etc.

A note on tone

The Japanese versions of these articles tend to land in a softer register than the English ones. That's a translation choice; the underlying observations are the same. If you read both, the English will feel more direct and the Japanese more reflective. Neither is the "real" version — both are. I'm a different writer in each language, and I've stopped trying to flatten that.

A note on the time-shift

If you're reading this in 2027 or 2028 and any of these disciplines feel obvious by now, good. That means the field moved. The reason these notes exist is that I was figuring this out in early 2026 and wanted a record. I'd rather have written them down too early and looked dated than written them down too late and lost the messy details.

If you're reading this in 2026 and any of these disciplines feel new: I'm right there with you. We're figuring this out together.

Comments welcome. Particularly from:

Engineers from non-dev domains who've started AI-assisted work
Researchers working on multi-agent debate / adversarial review / human-in-the-loop systems
Anyone running multi-AI cross-vendor protocols and willing to share what's worked or broken
Anyone who thinks one of these five disciplines is wrong and wants to argue
Anyone who has prior art (papers, blog posts, internal write-ups) for any of this — I'd genuinely like to read them

"AI Coding Is Alchemy: A Late-Night Reflection from Fullmetal Alchemist"

J.S_Falcon — Mon, 27 Apr 2026 17:47:25 +0000

Late at night, writing code, I had a sudden realization: the experience of building with AI (LLMs) maps almost perfectly onto the foundational principle of alchemy from Fullmetal Alchemist — Comprehension, Deconstruction, Reconstruction. The current paradigm shift in AI development can be told as the evolution of these three steps.

1. Traditional Programming = Drawing Transmutation Circles by Hand

Software engineering, until recently, was traditional alchemy.

We read requirements and business logic (Comprehension), broke them down into algorithms and function designs (Deconstruction), and then drew the transmutation circle — the actual code, with exact syntax — by hand to bring the system to life (Reconstruction).

If even one chalk line wavered (a syntax error, a typo), the transmutation failed and the error blew back at us. We had to draw the circle on the ground by hand, every single time.

2. AI Coding = Hand-Clap Transmutation Through the Gate of Truth

Then ChatGPT, Claude, o1, and the rest arrived. It feels — at least to me — like we have collectively opened the Gate of Truth for infrastructure and coding.

Once we do the Comprehension and Deconstruction in our heads (requirements gathering through prompts, architecture design), we can outsource the most tedious step — Reconstruction (writing the code, drawing the transmutation circle) — to the Gate (the AI).

We clap our hands — well, hit Enter — and thousands of lines of boilerplate or a complex regex assemble in an instant, without ever drawing a circle.

3. The Equivalent Exchange Trap (An Operations View)

Hand-clap transmutation looks indistinguishable from magic. But here is the trap an operations engineer notices.

Outsourcing Reconstruction to the AI is conditional on the human side getting Comprehension and Deconstruction completely right.

What happens when domain knowledge (Comprehension) is shallow, or the logical structure of the prompt (Deconstruction) is broken, and you still hand the transmutation off to the AI? You ship a Chimera into production — undebuggable spaghetti code, or a quietly exploitable security hole.

Equivalent Exchange — the foundational law of alchemy — does not get repealed by AI. Whatever amount of human thought you skip, the system charges you back later, in the form of an incident.

4. "All Is One, One Is All" — Living Next to a Collective Intelligence

There is one more truth from the same series that has to be named: "All is One, One is All."

An LLM is the All — every line of code engineers have ever written, mixed with the cumulative knowledge of humanity, distilled into one model. Each of us, the engineer at the keyboard, is only one — a single point inside that enormous stream.

But if we hand everything over to the All and merely ship whatever it emits, we collapse into the All. We become a part of it — a downstream API endpoint of the AI's output, indistinguishable from the noise.

It is exactly because the One — the individual engineer — Comprehends the whole system and Deconstructs it with intent, that the All — the AI's collective intelligence — Reconstructs it as something with actual value.

Quality, security, the integrity of the larger system: all of these come back, finally, to the thought and judgment of the One.

5. Don't Become a Homunculus — Keep a Heart of Steel

As AI advances, the value of an engineer who is only a biological pair of hands — Reconstruction-only labor — is collapsing.

But the roles of Comprehending the system, Deconstructing its boundaries, and taking responsibility for what the AI emits — these will not be automated.

The survival strategy is not to outrun the AI. It is to resist being swept away by its overwhelming speed, to deliberately introduce the friction of thought — the small pain of slowing down — and to stay in that resistance.

That, I think, is the Heart of Steel that keeps us from sliding into Homunculi: dolls who have surrendered the act of thinking.

We are alchemists who have seen Truth. There is no going back to the world where every circle was drawn by hand. But the one thing we cannot afford to let go of is the act of thinking for ourselves and owning what we ship.

A quiet promise made to myself in front of a monitor, late at night.

The Japanese title of Fullmetal Alchemist is 鋼の錬金術師 (Hagane no Renkinjutsushi — "Steel Alchemist"). The "Heart of Steel" line above is a small wordplay on that title. It survives translation only partially.

"Beating 250,000 Mental Comparisons: A Cross-Domain Engineer's Entity Resolution Case Study"

J.S_Falcon — Sun, 26 Apr 2026 08:41:34 +0000

TL;DR

Operations/Systems engineer recently moved to the software side via AI collaboration.
Built a domain-specific entity resolution tool in a handful of evening sessions with Claude Code.
Caught about 99.2% of human-detected reconciliation errors when replayed against 8 weeks of historical data.
Turned a "skilled-veterans-only" weekly task into something anyone on the team can run.
Design retrofitted unexpectedly well to dual process theory, Gestalt psychology, and anchoring-bias defense.
Source business records never reached an LLM. Deterministic pipeline + human review only.

1. The Hidden Problem: When 500 × 500 Becomes a Cognitive Wall

Many companies maintain the same business entities across multiple systems.

A retailer tracks SKUs in an internal master AND on Amazon / Rakuten / Shopify exports.
A clinic carries patient records in both an EMR and an insurance billing system.
A manufacturer holds internal inventory but also receives partner inventory feeds.
An accounting team reconciles general ledger entries against bank statements.

Why is 500 × 500 hard?

The 250,000 problem

Brute-forcing this is computationally similar to running a 1,000-node full-mesh ping check vs a flat 1,000-node liveness check. Order-of-magnitude different load.

Working memory overflow

"Short to do" doesn't equal "easy to do" for cognitive labor.

Reproducibility decay

A one-off reconciliation can be brute-forced. But when the task repeats weekly across 10+ weeks, judgment drift becomes unavoidable:

"Last week I matched 'A Co.' and 'A. Company' as the same entity. This week I treated them as different."
"Last week I tolerated typo X. This week I rejected it."

This drift is what really breaks data quality long-term. It's the same structural failure mode as "config review standards differ by reviewer" in infrastructure operations.

The actual target

So the real problem the tool solved was not "shorten 3 hours per week" but:

250,000 judgments × 10 weeks of consistent reproducibility — a quality bar humans can't physically sustain — backed by a deterministic machine.

Plus removing the skill dependency. "Only one veteran can do this in 3 hours" is a single point of failure. After the tool: anyone could run it with consistent quality.

2. Background: Who I Am and What I Was Solving

Translation: design / validation / runbook discipline solid. Python and application development essentially unfamiliar.

This article is not a "look what I shipped" piece. It's a record of how operations-side disciplines transferred unchanged into AI-assisted software work in an unfamiliar domain.

Who this article is for

Reader	Useful sections
Operations / SRE engineers exploring AI assistance	Everything
Mid-career engineers moving across technical domains	Background, Architecture, Cognitive Design
Engineers new to AI-assisted development	Architecture, Cognitive Design, PII
Managers thinking about AI for their teams	Results and the cognitive-load argument

3. PII / Compliance Considerations

A question that always comes up in comments on entity-resolution articles: where does the data go? Worth answering up front.

In this implementation:

Source business records never reach any LLM. Both input files (internal master + external system export) are read locally by a Python script.
Matching is fully deterministic. Pandas, openpyxl, and difflib.SequenceMatcher for similarity. No embedding API. No remote inference at runtime.
The LLM's role is code-side, not data-side. Claude Code helped write the matching logic, the validation scripts, the design review, and the documentation. None of the actual records were ever sent.
For testing only, masked synthetic data was used in prompts. Real names, amounts, and addresses were replaced with synthetic equivalents before any prompt left the local environment.
Edge cases stay with humans. When the deterministic pipeline can't decide, it surfaces a flagged row for human review — not for LLM second opinion.

This separation is intentional. The matching task is well-suited to deterministic logic. LLMs would only add cost, latency, and compliance exposure for no quality gain.

If your team has even a soft "no business data into external AI" policy, this pattern is fully compatible.

4. Architecture: Two-Stage Matching + Cognitive Gates

Stack

Python 3.11
pandas + openpyxl (Excel I/O, color-coded output)
difflib.SequenceMatcher for fuzzy similarity
Rule-based throughout. No machine learning.
~1,100 lines, single script.

Phases

Phase 1: Match by exact stakeholder name (or alias group)
Phase 2: Cross-match by name similarity ≥ 0.6 (rescue typos)
Phase 3: Last-name-only + structural match (single-typo tolerance)
Phase 4: Duplicate-registration detection (same stakeholder + similarity ≥ 0.8)
Phase 5: Rescue rows with no stakeholder name (attribute match)
Phase 5.5: Attribute-mismatch pair rescue (identifier similarity ≥ 0.7, stage 2)
Phase 6: Row generation + color decision

The score function (key gates)

def compute_score(row_a, row_b):
    # Hard gate: region must match — kills cross-region false positives
    if region_a != region_b:
        return 0.0
    # Hard gate: numeric attribute must be close enough
    if abs(value_a - value_b) > THRESHOLD:
        return 0.0
    # Identifier gate: row_b's identifier must be embeddable in row_a's identifier
    if not is_identifier_match(addr_a, identifier_b):
        return 0.0
    # Sub-identifier gate: anchoring-bias defense
    if sub_id not in addr_a:
        return 0.0
    # Soft scoring (only after every hard gate passed)
    score = max(identifier_match_score, similarity, value_fallback)
    return score if score >= 0.6 else 0.0

Why this shape?

Hard gates first. "Different region" or "value difference > N" are absolute disqualifiers. Run them before any expensive similarity computation.
Soft scoring last. Once hard gates pass, compute similarity — but cap below 0.6 as "uncertain, surface to human."

Why not ML / Vector DB / embeddings?

Abstracted structure

Domain-specific term	Abstract concept
Item / SKU	Entity
Stakeholder (vendor / agent)	Stakeholder attribute
Price / Amount	Primary numeric attribute
Address / Location	Identifier (multi-attribute)
Building / SKU name	Auxiliary identifier
Detail number / barcode	Sub-identifier
Format variation (kana/latin/case)	Data quality issue
Domain judgment	Tacit knowledge

5. Cognitive-Science Design Principles (the Twist)

5.1 Dual process theory (Daniel Kahneman)

The two phases map onto two thinking modes:

System 1 (fast) = Phases 1–5. Fuzzy "is this roughly the same thing?" — similarity scores, identifier matching, attribute closeness.
System 2 (slow) = determine_color(). Strict checks for value mismatch, format inconsistency, identifier mixing.

Color-coded human review gets the System 1 fuzzy pass plus the System 2 strictness annotation, which is exactly the input shape humans need to make a final call.

5.2 Gestalt psychology

Humans recognize "wholes," not character sequences. iPhone15 and iPhone 15 Pro Max feel like the same product family even though strict string equality fails. So:

def is_identifier_match(addr_a, identifier_b):
    """Recognize chunked identity even with mixed scripts and separators."""
    chunks = re.split(r'[A-Za-z0-9\s\-_]+', identifier_b)
    return all(chunk in addr_a for chunk in chunks if len(chunk) >= 2)

Matching by chunks survives whitespace, separator, and script variation.

5.3 Anchoring & confirmation bias defenses

Hard gates exist to deny human-style intuitive shortcuts:

"Same price, must be the same item" — rejected by sub-identifier gate.
"Same name, must be the same person" — rejected by region gate.

The machine's job is to be coldly skeptical exactly where humans get over-confident.

5.4 Reducing human cognitive load (Human-in-the-Loop)

When a human is asked to confirm a flagged row, they don't get an opaque "match score 0.62". They get a one-line annotation:

Same entity matched | [Value mismatch] diff ¥2,000,000 (5.4%)
(A: ¥34,900,000 / B: ¥36,900,000) · identifier format inconsistent

The human doesn't waste cycles re-deriving why the row was flagged. Cognitive load drops sharply.

5.5 Don't automate the ghost

Tightening the logic isn't a path to recreating the ghost.
It's a path to revealing where the ghost is needed.

Mapping summary

Cognitive concept	Implementation
System 1 (fast)	Phases 1–5 (fuzzy matching)
System 2 (slow)	`determine_color()` strict checks
Two-stage / dual-pass	Stage 1 + Stage 2 (Phase 5.5)
Gestalt grouping	`similarity` / `is_identifier_match`
Anchoring defense	Sub-identifier gate, identifier gate
Cognitive load reduction	Aggregated `[reason] diff X` annotations
Human-in-the-Loop	Caution signals for tacit-knowledge zones

6. Results

Recall on 8 weeks of historical data

Metric	Value
Errors flagged by humans (excluding outlier weeks)	~130
Errors caught by the tool	~129
Recall	~99.2%

The single missed case was annotated by the human reviewer as "even a human couldn't decide here." Effectively the tool catches every case where a human commits a confident verdict.

(Caveat: this is recall against 8 weeks of one team's data, not a benchmark claim. Different domains will need their own measurement.)

Time and skill load

Item	Before	After
Skilled veteran throughput	~3 hrs/week	~30 min/week (review only)
Newcomer throughput	half a day to full day	~30 min/week
Skill dependency	Yes (single point of failure)	No (anyone can run it)

The time number understates the value. The real shift is breaking the skill SPOF. Veteran out sick, leaves, or buried in another priority — work continues at the same quality.

A note on false positives

7. The Flowchart

Drawing the judgment flow as diagrams surfaced things the code review didn't. Below are the four phases as separate figures, in execution order.

7.1 Phase 1: Hard Gates (sequential disqualifiers)

Region → numeric value → auxiliary identifier → sub-identifier. Each gate is an absolute disqualifier: any "No" drops the pair. The order matters — cheapest disqualifiers run first.

7.2 Phase 2: Soft Match

Once a pair clears all hard gates, compute_score evaluates a soft similarity. Below 0.6 → drop. At or above → lock the pair as the same entity.

7.3 Phase 3: Parallel Flag Checks

7.4 Phase 4: Final Verdict and Drop Aggregation

Aggregate the tags into a color verdict. Drops from Phase 1 and Phase 2 converge into the "Unmatched" lane, surfaced standalone in the human-review output.

Things visible only after rendering as a diagram

These were invisible while reading code, only obvious once drawn:

Phase 1 hard gates are ordered by computational cost. Region → numeric → auxiliary → sub-identifier. I placed them by intuition; the diagram showed they were already optimal — cheapest disqualifiers first.
Phase 3 parallel flag checks are genuinely independent. Six checks fire in parallel with no early-return contamination. The diagram confirmed there was no silent dependency between them.
All Drop1–Drop5 paths converge to the same Unmatched node. I was throwing away the drop reason. Re-running "why was this pair rejected?" was impossible. Fix: log the drop reason in the row annotation.

Drawing the flowchart is roughly the same act as drawing an infrastructure topology before going live. The diagram is the rubber duck.

8. Wrap-up

Three transferable lessons from this build:

Cognitive load is the hidden cost of "short" repetitive judgment tasks. Headcount-hour math undersells the burnout reality and skill-SPOF risk.
Cognitive science principles fall out of good design retroactively. I didn't design with them in mind; the principles became visible only through structured review (with a second AI). If your design retrofits to known principles, that's confirmation. If it doesn't, that's a smell.
LLMs do NOT have to touch your data. Most entity resolution work doesn't need them at all. Use them for code, design review, and documentation. Keep the business records local and deterministic.

9. What's Next

Comments on entity resolution, cognitive load in repetitive tasks, or cross-domain engineering experiences are welcome.