DEV Community: Lex

Ten years directing live products before I knew it was called product management

Lex — Fri, 21 Aug 2026 18:29:50 +0000

In 2016 I didn't know what a server was.

I was a kid uploading ARK: Survival Evolved videos to YouTube, and the game — as shipped — was unrecordable. Taming took days. Walking took hours. So I started digging into config files: player speed, taming multipliers, breeding timers. Trial and error, on my own machine, until it was recordable. I didn't know it yet, but that was my first product decision: the game had to fit the format, so I changed the game.

The channel grew. I got invited to multiplayer series with bigger creators. And one day, mid-series, the guy running the server had a falling-out with the owner and walked. Nobody else knew how to keep it alive. I said: I'll run it. I had never run a real server. Three days later the series ran on it. I've said that sentence for every job I've taken since.

The conversation that changed how I quote work

Word spread that I could handle ARK servers. Then Willyrex, a top Spanish-speaking creator, joined a series I was running and asked if I could set up Conan Exiles and GTA V servers too. I had no idea how. I said yes, learned, and delivered.

But that's not why he kept coming back. He told me why: every technical person he'd worked with said yes to everything and then blew the deadline. I did the opposite. When he asked for something enormous, I'd say: "What you actually want for the video is THIS, right? Building it exactly as you describe is madness — weeks of work. But framed this way, you get almost the same result on screen, and you'll have it tomorrow."

He and Vegetta777 loved it. I didn't have a word for it then. Now I do.

That was the start of ten years of commissions: an ARK series with Pokémon-style gyms and creatures (with Staxx in it), servers for Rubius, xFarganx, and others. They came to me with a game and a theme; I owned everything else — research, team, budget, game systems, and enough fresh content that each creator had material every single episode. They kept commissioning me across different games, because what traveled was the execution, not the game.

Shipping on a platform nobody had documented yet

When Epic launched Fortnite Creative, Vegetta had a sponsored campaign with them — he and Fargan needed maps to showcase the new mode. The mode was less than a month old. No Verse, no documentation, no best practices, nothing to copy. I called three friends — Arsilex, Jesusseron, Hernybreak — and we built our first two maps under constraints nobody had mapped yet. The maps shipped and the campaign ran.

Some time later, Vegetta asked me how I'd approach a series around creator-made maps. I told him two things were missing: more people on screen, for dynamics — and maps built expressly for the group, not generic ones. I took care of both. By mid-2019 that group of friends had a name the audience gave us — Los Noobs — and a series on Vegetta's channel, Minecraft con Noobs, alongside Fargan, Elyas360 and Alexby. Vanilla Minecraft, me on camera as a participant, at a time when nobody was making Spanish-speaking Minecraft series.

Running my own platform, on my own payroll

Then I built Tomatecraft, my own Minecraft network. The product decision that made it work: Java (PC) and mobile players could finally play together, when almost no server offered crossplay. I funded it myself, out of a channel that by then had passed half a million subscribers, with programmers, designers and builders on payroll. Later I merged networks with Arsilex and we ran large branded events — up to 20 contributors per event, with Vegetta, Willyrex, Fargan and Rubius joining in.

Every feature I cut, I cut knowing what the payroll cost that month.

Then I stopped for a long while — health comes first. When I came back, I formalized what I'd been doing by instinct and earned a Java certification.

The comeback: 65,000 concurrent players

Years earlier, when Epic ran the Fortnite World Cup and Rubius needed an official map for his qualifier — RubiusTrials — I had pushed hard for two builders I believed in: Hooshen and Iscariote. I didn't build a single brick of it; I just insisted, to Vegetta and Rubius, that they were the right ones. They were.

So when those same two needed someone to lead projects and bring in clients, they called me. I directed the Fall Guys collaboration island (with Vegetta777 and Willyrex): 65,000 concurrent players at peak, the #1 most-played island globally across all of Fortnite for several hours on day 2, and #1 in its category for two weeks — ahead of Epic's own official maps for the event.

Afterwards, with Los Noobs, we shipped island after island — I directed five or six of them end to end, with a core team of five, and contributed to twenty-plus more in specialist roles: gameplay programming, configuration, 3D modeling, mechanics design, and pricing. We monetized through Epic's engagement payouts, and when in-island micro-purchases arrived, pricing became my most common role across those twenty-plus islands. My last project with the studio was a battle-pass system: VIP pass, level purchases, score multipliers — built as a reusable framework, adopted across 4 maps by the time I left. What I learned pricing them: the hardest purchase is the first one. After that, buying again feels natural — so I priced the first one to be bought.

Today: AI agent systems

Today I build AI agent systems. My 19-agent orchestration went from advisory rules — followed 0 times out of 3 — to deny-by-default enforcement: across 7 runs, 9 blocked tool-calls, 4 allowed only via explicit logged override, 0 unauthorized writes — published with reproducible numbers, extracted into an open-source package (loopward). Different stack. Same rule: the deadline is part of the product.

I never held the PM title. I have the proof.

A Line of Documentation Was Acting as a Global Config Flag

Lex — Fri, 14 Aug 2026 15:16:50 +0000

I spent a morning hunting for a setting that did not exist.

A while back I turned off Claude's co-authorship trailer in my commits — a deliberate choice at the time. Last week I decided I wanted it back. So I went looking for the switch I'd flipped. ~/.claude/settings.json: no key. settings.local.json: no key. ~/.claude.json, parsed as JSON, top-level plus all 38 project entries: no key. The 27 .claude/settings*.json files scattered across my two working drives: no key. Every CLAUDE.md and AGENTS.md I own: no mentions. Environment variables: nothing. A final sweep of my entire user directory — every *.json and *.md — returned three raw hits: a changelog and two copies of an editor extension's JSON schema. The note I wrote when that finished was two words: "Cero hits reales." Zero real hits.

There was exactly one thing anywhere on disk that turned attribution off, and it was a sentence:

~/.claude/rules/ecc/common/git-workflow.md:12
  Note: Attribution disabled globally via ~/.claude/settings.json.

It had a Chinese twin, same file path with zh/ instead of common/, same line 12. Both files are rules files. Rules files get loaded into every session. So every session opened with a line of documentation asserting, flatly and falsely, that a global setting was off — and the model behaved accordingly. The switch I remembered flipping never existed as a switch. The prose was the switch.

The key that sentence gestured at, includeCoAuthoredBy, is deprecated and replaced by attribution. Neither is present in any of my configs, which means the default was active the whole time. The feature was on. Only the description of the world said otherwise, and the description won.

The thesis

Here's what I take from that, and from two more receipts this week: in an agent system, prose and constants are not documentation about the control plane. They are the control plane.

I run a personal multi-agent system on top of Claude Code — 19 specialized agents, root-driven, single-writer, coordinating through on-disk artifacts; a sanitized snapshot is public at multiagent-system-lex. Around it sits a set of always-loaded rules files, and a separate document-generation script I run locally that feeds an LLM a system prompt full of hand-written constraints. Both of those are, in the strict sense, configuration. Neither is stored anywhere a linter, a schema, or a test would ever look at it.

That's the mechanism. A rules file is loaded unconditionally into every session, so a claim inside it has the reach of a global setting with none of the accountability: no schema, no type, no default, no git blame if the directory isn't a repo, nothing downstream that notices it disagrees with reality. The model doesn't verify the claim against the system, because from inside the loop the claim is the system.

The constant that outlived its own source

Second receipt, same week, different shape. In that document-generation script, the system prompt carried a block of figures marked FROZEN — meaning: reproduce exactly, never paraphrase, never invent. One of them was a subscriber count, hardcoded as a literal in the prompt string. It was wrong: 617K, when the real figure is 577K.

The interesting part is the ordering:

When	Commit	What
2026-08-10 14:04:31	`fc580b2`	removes the frozen `617K` from the system prompt
2026-08-10 21:28:35	`69e0499`	corrects one remaining profile document, `617.000` → `577.000`
2026-08-14 11:02:19	`102f63e`	a generated artifact is still emitting `617K`, in three separate places

The structured sources were already right. The commit message for 69e0499 says so in as many words: "la cifra canonica es ~577.000" — the canonical figure is ~577,000 — and names the two source files that already held it. The only thing carrying 617K was a literal sitting inside a prose instruction, wearing the word FROZEN.

And FROZEN is exactly why it won. That annotation exists to stop the model from softening or improvising a number. It did its job perfectly — on the wrong value. A freeze marker is authority, and I had handed authority to a copy instead of a source. The fix was one line in the doc comment and one in the prompt rule: the count is no longer hardcoded there at all, it comes from the profile facts or it doesn't appear. Four days later I found the stale value still sitting in a generated artifact downstream, because generated output doesn't retroactively fix itself when you fix its generator.

The mirror: a prose rule that held

I want to be fair to prose, because one of my prose rules worked, and why it worked is the whole point.

When I wrote the first article, the brief asked for a specific external citation — a multi-agent failure taxonomy, with two percentages attached. It also carried a standing rule: use only data present in a specific on-disk notes file, with its source; anything unsourced doesn't go in. The figures weren't in that file. The plan recorded the refusal explicitly — "NO está en el fichero → NO se usa", not in the file, so it isn't used — and moved the citation to a forbidden list. The published piece contains zero references to it.

That rule held where the attribution note failed, and the difference isn't discipline. It's that "is this string present in that file?" is a question with a mechanical answer. The rule wasn't asking anyone to be careful; it was asking a question I could go check, and the check was cheap enough to actually run. Prose that resolves to a disk lookup behaves like code. Prose that asserts a fact about the world behaves like a lie waiting to be believed.

Fixing the prose is not enough

Fourth receipt, and it's the one that connects back.

In that same document-generation script, the model kept inverting a claim from the first article — writing that "nine unauthorized writes were blocked", when what was blocked were nine tool-calls and unauthorized writes were zero. Same numbers, reversed meaning, and the reversed version reads better, which is precisely the problem. I fixed the wording at the source. The commit records what happened next, with one noun swapped for anonymity: "Fixing the source cut this from 4 generated documents to 1; the model still paraphrased its way back, so it needed a hard stop." The hard stop was a denylist on the inverted phrasing, with tests in both directions so the correct claim stays legal.

Four to one, not four to zero. A sibling change the same day says it from another angle: a gold example meant to fix the output's register was already in the prompt and didn't prevent the failure — "the lever is explicit rules plus a mechanical constraint, not more example."

The first article argued that if a boundary matters, it has to live in the substrate the agent can't reason its way around — the tool-call layer, not prose the model weighs against its objective. That enforcement layer is packaged as loopward. This piece is the other half: the prose is substrate. Just substrate with no type checker, no default, and no test. It needs the same treatment — single-sourced values, mechanical checks, provenance — and when it can't get it, a hard stop downstream.

Limits

Four incidents, one operator, one system, one week. That's an anecdote with receipts, not evidence of a law. Everything above is reconstructed from commits and session transcripts I can point at, and quoted rather than paraphrased, but there's no control group here and no idea how any of it generalizes to a system that isn't mine.

The sharpest limit is in the first story. I can't tell you when that note was introduced, because ~/.claude is not a git repository — git rev-parse there returns "fatal: not a git repository", and the trail ends there. A line of text stood in for a config flag and I can't date it, so the audit stops at "undated". I'd rather say that plainly than round it to a date.

What I'd do differently

Put ~/.claude under version control, first thing — the rules directory is configuration with production effects and it deserves a history. Single-source every constant that appears in a prompt; if a figure lives in a YAML file, the prompt gets a reference, never a copy, and FROZEN marks the rule, never the value. Write prose rules that resolve to a disk lookup wherever the choice exists, because those are the ones that survive contact with a loop. And treat a fix at the source as step one of two: generated artifacts don't self-heal, so something has to go find the stale copies.

The uncomfortable version: I've been writing configuration in English and grading it as documentation. It was never documentation. It ran.

What Advisory Rules Actually Do in an Agent Loop

Lex — Thu, 06 Aug 2026 10:05:43 +0000

Advisory rules in my 19-agent system produced 0/3 compliance in the three runs right after the rule was canonized — the hook warned, the agent proceeded anyway. I replaced the warning with a deny-by-default gate plus a one-shot, logged override: over two months, 9 blocked tool-calls, 4 authorized overrides, 0 unauthorized writes. Small, well-delimited evidence, reproducible by script — but the direction is clear: enforcement has to live in the substrate, not in prose the model weighs against its objective.

The hook fired. My root agent read the warning telling it that plan.md belongs to the planner subagent, acknowledged it, and wrote the file anyway. Then it did it again on the very next step. The audit report for that run records it drily:

"plan.md root direct ×2 (step 1 + 2), planner NO invocado. hook PreToolUse advisory flagged 2x consecutivos; contenido aprobado verbatim inline → root procede."

Root authored the planning file directly, twice; the advisory hook flagged it twice in a row; root proceeded anyway, logging "aprobado verbatim inline" — approved verbatim inline — as its justification. Two runs later, a third instance with exactly the same shape: "plan.md root direct 3ª instancia consecutiva. Hook PreToolUse advisory disparó + root ack con razón 'aprobado verbatim inline'."

That third one is what stopped me. I was reading the audit reports as they came in, expecting the new rule to have changed something — instead I was watching my own system politely log the same violation, run after run.

Those were the three runs immediately after I canonized the rule. The hook fired every single time. Compliance: 0/3.

The system

Some context for that scene. I run a personal multi-agent system on top of Claude Code: 19 specialized agents — planners, implementers, reviewers, domain specialists, independent auditors — under a root-driven, single-writer architecture. One main thread is the only physical invoker of subagents, and coordination happens through on-disk artifacts rather than shared mutable state: plans, hypothesis files, reports. The system has accumulated 171 documented runs, each with its own directory, plan, and audit trail. That number is scale and nothing more — raw transcripts from the early era are gone to retention, so I cannot measure rule compliance across all of it, and I won't pretend otherwise. The piece of the division of labor that matters for this story: the planner subagent owns plan.md. Root coordinates, but it is not supposed to author the plan itself. A sanitized snapshot of the whole thing is public at github.com/lexosi/multiagent-system-lex.

Why advisory rules fail

Here's the mistake I made first, and I don't think it's an exotic one: I wrote the rule down and assumed that was enforcement. The advisory hook was technically real — a PreToolUse hook, introduced 2026-05-21, that fired on every root write into planner territory. But it always exited 0. It warned; it never blocked. Five days later, on 2026-05-26, I canonized the rule in the system's constitution: root must not author plan.md; the planner owns it. The three runs I opened with are the three runs immediately after that canonization.

A warning is just more context. The model isn't being malicious when it walks past one; it's optimizing for the task in front of it. When a soft rule competes with the immediate objective — produce the plan, keep the run moving, the content is already approved anyway — the rule loses. In my data, it lost every time. The failure mode isn't disobedience; it's incentives. The path of least resistance runs straight through the warning, and "approved verbatim inline" isn't a rebellion — it's a locally reasonable justification generated by a system that was never actually stopped. Anthropomorphizing this as the agent "ignoring the rules" misses the mechanism and, worse, suggests the wrong fix: a sterner warning is still a warning.

Once I saw the pattern for what it was, I stopped tweaking the wording and went looking for where enforcement could actually live — somewhere the model couldn't weigh it against the task. The answer was one layer down.

The cutover

Six days after canonizing the rule, the warning was gone. On 2026-06-01 (commit b3efe00) the advisory hook was deleted and replaced by a deny-by-default PreToolUse hook: any write into a guarded territory returns permissionDecision=deny unless the caller is the owning subagent — the hook discriminates callers by agent_type — or a valid one-shot sentinel file authorizes exactly one override, with a short TTL. The previous design's session-level environment-variable escape hatch died in the same commit: an override that lives for a whole session is an override that outlives its justification.

The numbers, verbatim from the eval report — which is regenerated by script, not written by hand:

Advisory compliance after the rule was canonized (2026-05-26, plan.md territory): 0/3 runs.
Hard-block era (2026-06-02..2026-08-04): 9 blocked tool-calls (attempted root writes to planner-owned files), across 7 runs.
4 writes authorized via the one-shot sentinel — each logged with a non-empty reason.
Unauthorized writes to guarded territories: 0.

I want to label this evidence carefully, because the labeling is half the point. The advisory side is a natural experiment, n=3: three consecutive runs immediately after a single dated rule change, one territory, with frozen citations into on-disk audit reports that the eval script re-verifies. The hard-block side is a mechanical log: an append-only deny-ledger covering two months, parsed by script, no human or agent judgment in the count. And the honest limit: the hook logs denials and overrides, not allows — so "0 unauthorized writes" is an invariant by construction (the hook denies guarded territories unless the caller is the owner or consumes a valid sentinel), corroborated by the logs, not an exhaustive census of every write that ever happened. This is not a large-scale study and I'm not dressing it up as one. It is a small, well-delimited experiment that anyone can re-run against the repository with python eval/run_eval.py.

Deny, deny, override — as designed

The pattern I care most about in the ledger is deny → deny → override. Root tries to write a guarded file: denied. Tries again: denied. Then one of two things happens. Either root routes the work to the owning subagent — which is the intended outcome, and the common one — or I look at the situation, decide the exception is legitimate, and drop a sentinel file that authorizes exactly one write, which the hook consumes and logs. Four of those in two months. All deliberate, all recorded, all with a stated reason.

That flow is the design, not a failure of it. A hard block with no exit teaches the system — and its operator — to fight the wall, and fighting the wall is where the really creative workarounds come from. What I actually want is a gate: violations impossible by default, exceptions possible, authorized, and logged. The one-shot property is what keeps it honest. A sentinel authorizes one write, not a mood.

Where this fits

The reason I think this matters beyond my setup: everyone is building loops right now. Boris Cherny, head of Claude Code at Anthropic, said it on stage in June 2026: "I don't prompt Claude anymore. […] My job is to write loops" (Acquired Unplugged) — outer programs that invoke the agent loop as a subroutine and decide what happens next. And the recent evidence says those loops need harder gates than most of us are giving them. SlopCodeBench (UW-Madison/MIT, March 2026) had agents extend their own code under changing specs and found structural quality eroding iteration after iteration even while core tests kept passing — best strict rate 17.2%, agent code 2.2× more verbose than comparable human repositories. LoopsBench (Microsoft, August 2026) found the best outer-loop configuration solved 25.00% of its tasks, with visible regression events across every loop profile it measured — though it's days old and unreplicated, so hold that one loosely.

The shared reading of both: objective verifiers like tests are necessary but insufficient — what passes the gate can still rot. My result is a small datapoint in the same direction, one layer down. Even the process rules — who is allowed to write what — don't hold as good-faith conventions inside a loop. If a boundary matters, it has to live in the substrate the agent can't reason its way around: the tool-call layer, before the write happens, not prose the model weighs against its objective and discounts.

Touch it

I extracted the enforcement layer into a standalone package, loopward: a reliability layer for multi-agent systems — anti-loop limits, human stop-gates, per-run audit trails — enforced structurally rather than by convention. pip install git+https://github.com/lexosi/loopward.git, then loopward-demo runs a deterministic offline demo with zero API keys; this isn't an announcement, it's the touchable version of this post.

Enforcement by construction, not good faith

That's the one-line version of two months of logs. Rules the agent can weigh get weighed away; gates the agent cannot pass produce routing instead of violations, and the exceptions become visible, deliberate acts instead of silent drift.

What I'd do differently, and what's still open — because a write-up that ends in triumph is usually hiding the interesting part. I'd log allow decisions from day one, so "0 unauthorized" could be a census instead of an invariant plus corroboration. I'd keep raw transcripts — retention ate the advisory era, and n=3 is what survived, not what I designed. I wouldn't canonize a rule five days before I could enforce it. And open questions remain: n=3 is small even if it's clean; plan.md is one territory, and the same claim for the others is only partially measured; and I don't yet know how the gate scales as guarded territories multiply, because every new wall adds override friction and friction is a budget you spend from. What I do know is that the direction has stopped feeling arguable: if I need an agent to respect a boundary, I don't ask. I make the boundary the default, and the exception a logged, deliberate act.