跪拜 Guibai
← Back to the summary

Two Developers, 8,000 km Apart, Independently Built the Same AI Agent Architecture in the Same Month

He's 32, writing npm packages in Germany. I'm 21, looking for an internship in China. In the same month, starting from completely different points, we built something architecturally identical. This isn't collaboration. This is "parallel invention" in AI — two engineers on opposite sides of the world, facing the same mathematical constraint, arriving at the same engineering answer.


📖 Here's what happened

I published 5 technical articles on DEV.to about how I install "rule gates" on AI agents — using file-system checks, exit codes, and regular expressions to ensure an agent actually follows rules, instead of just saying "OK, got it" in the chat and then doing nothing.

Then a German developer named René Zander dropped a link in the comments: skillgate, an npm package (@reneza/skillgate), doing exactly the same thing.

I clicked through. And I froze.


🤝 Two people, one constraint, one answer

First, the architecture comparison:

Design dimension René's skillgate My paper-validator
Core idea "Model requests, framework owns the boundary" "Generation and verification share the same distribution P(token
Check method File-system pure functions File-system + regex + exit codes
Model involvement Zero — model is not in the check loop Zero — mechanical gate layer, model is not in the loop
Gate types file-exists, file-contains, absent, command, evidence, instruction-sync HealthChecker, QualityGate, WriteGuard, RegenerationValidator
Release form npm package, production-grade Python module, CLI+MCP+native import
Independent convergence date July 2026 July 2026

Note: in the same month, from completely different starting points (he was building an npm package in Germany, I was writing my graduation thesis in China), we arrived at architecturally identical solutions.

This cannot be just coincidence.


💡 Why would two people independently invent the same thing?

Because the constraint is structural, not a stylistic preference.

An LLM verifying its own output is like asking a student to grade their own exam — they're still using the same knowledge from the same brain. No external standard, no independent check. That's why "self-verification" is structurally unreliable — I call this the Prose Barrier.

René put it differently but meant the same thing: "A gate is only trustworthy if it runs in an independent process the agent cannot influence."

For both of us, the math pointed to the same engineering conclusion: rules must be written in code, not natural language, and must run outside the model's generation loop. If you can talk the model into breaking a rule, it's not a rule — it's a suggestion.

This isn't philosophy. Across the 200 trials I ran (P1-1, more on that later): wherever a mechanical gate could cover it, the violation rate was zero. Every single one.


🏗️ Where they differ (and why it matters)

skillgate is production-grade, static, shippable. It does one thing and does it well: run deterministic checks on an agent's output. René's instruction-sync gate — tracking drift between CLAUDE.md, AGENTS.md, and .cursor/rules — is something I hadn't thought of, and I plan to adopt it.

My system adds four more layers:

L0 Safety Layer      L1 Mechanical Layer   L2 Neural Layer      L3 Causal Layer          L4 Drift Layer
"Safe output?"        "Did the info land?"  "Did it penetrate?"  "Format routes attention?"  "When will it drift?"
───────────────────────────────────────────────────────────────────────────────────────────────
Pre-process generation  File-system checks    Token-probability fingerprint   Format→Attention          Trend→Prediction

Full 5-layer architecture; skillgate covers L1

🔒 L0 Safety Layer: Pre-process generation — if a model is rewarded for "sounding confident," uncertainty gets suppressed. An explicit safety prompt ("saying 'I don't know' won't be penalized") changes the preconditions before production.

L1 Mechanical Gates: The layer skillgate covers — file-system checks, exit codes, regex. Bypasses the Prose Barrier entirely. Doesn't read what the model wrote; only checks whether a file exists, whether a timestamp is recent, whether an exit code is zero.

🧠 L2 Neural Gates: skillgate checks the output. Neural gates check the internal processing. If you measure whether a constraint shifts the logprob distribution at decision tokens, you can see whether a rule genuinely changed the model's "thinking" or just changed the wording. d=+0.578, Bayes Factor=282,399. Measured on DeepSeek.

🔗 L3 Causal Encoding: For reasoning quality, which is better — syllogistic rules (IF-THEN-THEREFORE) or imperative rules (MUST DO)? Answer: neither — prose rules are better. Prose gives a constant ~0.25 SD reasoning advantage over code rules, independent of gate status. Code + gate = perfect compliance + shallowest reasoning. I call this the "checklist mindset."

🔮 L4 Drift Prediction: 12 features, baseline data from 34 sessions. Warns before behavioral degradation becomes visible. Built; predictive validation pending.

Whether these extra layers are "academically fun" or "practically useful" — still uncertain. But I won't pretend to know. That's why I made everything reproducible experiments, in paper-validator — one command runs the audit: python -m paper_validator claim --claim all --trials 30.


🔥 Why you should care

When two people independently invent the same thing without knowing each other's work, it says several things:

🔥 The problem is not imaginary. AI agents really do drift. They really do skip verification. They talk a great game and then don't act. I'm not the only one hitting this.

🔥 The solution is converging. Deterministic file-system checks, outside the model's control loop — this is the correct architecture. Not a matter of taste. Engineering necessity.

🔥 The whole field is still early. We're still debating whether agents should use [THINK]: tags. In five years, looking back will feel like debating whether HTML should use <table> for layout.

🔥 You can try it right now. skillgate is production-grade code on npm. paper-validator is reproducible research code (Python stdlib + requests, no other dependencies). Both run if you're willing to tolerate imperfect edge cases.


📬 The real situation

The DEV.to comment section — Mike Czerwinski, Dipankar Sarkar, Max Quimby, René Zander — wasn't the kind of "great post!" fluff. They asked things I genuinely hadn't thought to test.

So I tested them. 440 API calls. Two brand-new experiments. One hypothesis proven wrong. Both taught me something.

The paper, the data, and all supplementary analysis are here: github.com/YuhaoLin2005/hermes-workspace. The independent verification tool is here: github.com/YuhaoLin2005/paper-validator.

If you're working in this direction — deterministic verification, agent drift monitoring, format engineering — or if you think something in the data looks off, I genuinely want to hear about it. The P1-1 and P1-2 experiments exist because Mike asked questions I hadn't thought to ask.

💬 If this direction is also what you're working on, drop your approach in the comments. Are you using file-system checks or a different approach? Has your agent ever said "yes" and then done nothing? Leave a comment — I want to see everyone's solutions. A like and bookmark would be appreciated; I'll keep posting follow-up experiment data here.


50+ sessions of data. 13 experiments. One laptop. My thesis advisor is my own AI agent.

👋 Lin Yuhao — Junior, Spatial Information Science, FAFU. Looking for a Summer 2026 internship.

Comments

Top 2 from juejin.cn, machine-translated. The original thread is authoritative.

百万前端向前冲

Large models copy each other

jump_jump

So young, I'm so envious