I got myself a Strix Halo system and a GLM coding plan. The qs to self was: what can I do when tokens are essentially unlimited? The opaque-ness of what my harness is, and how it grows over time & use, when using projects out there, makes it hard to know what is helping and what isn't.

Clearly, the harness, together with LLMs has utility. Yet, I can't help but feel that ... at times, I am struggling with the classic "explore-exploit" problem. Or one between having the system be deterministic and when it should be less so. When is my system in a local minima (and needs a good kick out of it, automated if possible), and when it is at a good place in the "global" state-action space.

But obviously if you tell somebody "make a boiled egg. To boil an egg you have to crack it into the pan first." That's a lot worse than "make a boiled egg." Especially when you have an infinitely trusting, 0 common sense executor like an agentic model.

A lot of my projects are built with platform versions from the last 12 months which had zero or very small amounts in the core training for the LLM, so they'll tend to avoid using the latest language options unless you prescribe them in AGENTS.

I haven't been able to do without an `.MD` - no agent (CC, Codex, OpenHands) was smart enough to figure out my layout unguided. So much so, a few weeks ago, I had Claude write the guideline below to document the way I like to lay out my tests and modules. I make extensive use of uv workspaces and don't ship tests to production deployments:

```

- uv Workspace Architecture (`uv` v0.11.8+, `packages/` members):

  **Build tool:** Exclusively `uv_build`. Never `hatchling` or any other build backend.
  Pin as `uv_build>=0.6` in every `[build-system]` block.

  **Naming convention — flat, distinct package names (NOT a shared namespace):**
  Each workspace member uses a *flat* Python package name that is unique across the workspace.
  The `uv_build` backend auto-discovers the module by converting the project name (hyphens → underscores):
  `base-constants` → `src/base_constants/__init__.py`
  `base-domain`    → `src/base_domain/__init__.py`
  `base-geometry`  → `src/base_geometry/__init__.py`
  etc.
  No `[tool.uv.build-backend] module-name` override is needed because the project name already maps directly.

  **Why NOT a `base.*` namespace package:**
  `uv_build` cannot support PEP 420-style namespace packages across workspace members.
  It maps each project name to exactly one module root; only one member can own `base/__init__.py`.
  Attempting `module-name = "base.constants"` treats the dotted name as a nested directory,
  not a namespace — it looks for `src/base/constants/__init__.py`. Confirmed by binary string
  inspection of the `uv` binary. NEVER attempt namespace packages with this build backend.

  **Import style (locked, never change):**
  `from base_constants import CONSTANT_A`        
  `from base.constants import CONSTANT_A`          (namespace layout — abandoned)

  **Tests member:** `package = false` in `[tool.uv]`, no `[build-system]` block at all.
  Tests are never shipped in production; the member exists solely to isolate test dependencies.

  **Microservice split story:** When a member needs to become a standalone repository,
  only the `[tool.uv.sources]` entry in the consuming `pyproject.toml` changes
  (workspace source → PyPI or VCS source). The package code itself is unchanged.

  BAD:

  ```python
  # The f-string is evaluated BEFORE the logging level is checked.
  # This:
  # - wastes CPU cycles if the log level is higher than INFO
  # - increases the caridinality for Structured Logging rendering observability useless!
  log.info(f"denominator {denominator} is negative!")
  ```

  GOOD:

  ```python
  # The ONLY right way - logging module only merges the variable into the string if 
  # the INFO level is actually enabled.
  log.info("denominator %s is negative!", denominator)
  ```

  Note: Using this "Good" pattern ALSO helps with Structured Logging. Tools like Sentry or ELK can group logs by the template string ("denominator %s is negative!") rather than seeing every unique f-string as a completely different error type.

    model: foo-model
    max_tokens: 32000
    top_p: 1
    messages:
      - role: system
        content: |
          You are opencode, an interactive CLI tool that helps users with software engineering tasks.
          Use the instructions below and the tools available to you
          # ... snip ...
          Here is some useful information about the environment you are running in:
          <env>
            Working directory: /home/user/dir
            Workspace root folder: /
            Is directory a git repo: no
            Platform: linux
            Today's date: Tue Apr 28 2026
          </env>
          Skills provide specialized instructions and workflows for specific tasks.
          Use the skill tool to load a skill when a task matches its description.
          No skills are currently available.
          Instructions from: /home/user/dir/AGENTS.md
          # Overview
          This directory holds the entirety of the code for the <dayjob> company. All code lives in Github
          under the `<dayjob>` organization, and beneath that Organization is a wide-and-flat set of all
          the Git repositories of all source code at <dayjob>. That Github repo structure is replicated in
          this directory via `ghorg`.

Notice that the harness is just unceremoniously dumping the AGENTS.md file into the exact same text stream as the system prompt, barely contextualizing that hey, starting now, this text is from AGENTS.md and not from the harness.

If you want AGENTS.md to work (likewise, if you want skills or anything else to work) you have to know how the harness is handling/feeding them to the LLM, because no LLM will reliably look on their own.