Commitmaxxing & Tokenminimizing: The New Discipline for AI-Native Builders

TL;DR

AI-native work has a strange failure mode: it feels fast right up until nobody can explain what happened. A model writes code, another agent patches the build, a third summarizes the branch, and suddenly the project has motion without memory. The work moved, but the system did not learn.

That is why I keep coming back to two paired disciplines: commitmaxxing and tokenminimizing.

• Commitmaxxing: Making progress durable as soon as it is coherent.
• Tokenminimizing: Reducing how much context an AI agent needs to do the next useful thing.

The smaller the context surface, the less the model has to guess. The more the human can keep the real shape of the work in view. If we want to build robust systems alongside AI, we have to stop treating agents like magic and start treating them like highly capable, easily distracted collaborators who desperately need clear boundaries.

The Physician-Builder Perspective

I am writing this as a physician-builder, not as someone trying to sell a benchmark result. My days move between nephrology, operations, software, infrastructure, and the practical question of how a small team can use AI without becoming sloppy.

In medicine, systems matter because missed details turn into real downstream consequences. A missing lab value or a misunderstood handoff can derail a patient’s care plan. In software, missed details turn into broken builds, stale docs, and confusing handoffs.

Different stakes, same pattern: if the system depends on one person’s memory, it is already fragile.

AI makes that fragility easier to hide. A strong model can absorb a huge prompt, infer missing structure, and produce something plausible. That can be useful. It can also train the team to tolerate messy state. The agent becomes a very expensive broom, always sweeping clutter into the next context window. Over time, that clutter accumulates into a cognitive debt that neither the human nor the machine can fully untangle.

The Hidden Cost of Steps

The public DeepSWE v1.1 benchmark made this more concrete for me. DeepSWE v1.1, published at https://deepswe.datacurve.ai, is a software-engineering benchmark with 113 tasks across 91 repositories as of July 2026.

I do not treat any one leaderboard as a complete map of real-world engineering ability. But I do treat it as useful pressure on vague claims. It gives us a public way to ask: what did the system solve, how much did it cost, and how many steps did it need to get there?

The step count is the part more builders should stare at. Here are the public benchmark observations I am comfortable carrying forward:

Model	Approx. success	Approx. cost	Why it matters
fable-5 max	~70%	~$22	Strong result, but not free.
gpt-5.5 xhigh	~67%	~$7	Similar ballpark at lower observed cost.
sonnet-5 max	~54%	~$26	The run I noted also showed about 214k tokens and 268 steps.

Note: These are public benchmark observations, not private operational claims.

The lesson is not simply that one model is better or cheaper forever. The useful lesson is that steps are a hidden time and token bill. It is not just tokens per second. It is how many times the system has to inspect, decide, patch, re-run, and recover. Every step is a chance for the agent to drift, hallucinate, or lose the thread.

Structuring the Public Harness

If a coding harness takes 268 steps to finish a task, every confused file boundary, stale instruction, missing test, and ambiguous handoff becomes expensive. If the repo already expresses the contract, the next agent does not need to rediscover it.

If the commits are shaped like trail markers, an orchestrator can route work without asking the fixer to read the whole project history. If exploration is separated from implementation, the explorer can map uncertainty while the fixer makes bounded edits.

In my public harness thinking, I like a chain that is explicit about roles. It leaves out private plumbing and focuses on the design principle: route expensive reasoning to the moments that need it, and make routine execution as bounded as possible.

• Orchestrator: Decide what needs doing and define the boundary. (e.g., using GPT-5.5 high)
• Explorer: Gather exact context when context is missing. Map uncertainty. (e.g., using GPT-5.5 medium)
• Fixer: Implement the bounded change and validate it. (e.g., using GPT-5.5 high)

Other roles might include planning with Fable 5 xhigh, running an oracle or model-review high-reasoning chain for a second pass, and using compaction with Fable 5 low to compress state.

oh-my-opencode-slim is the same idea in a working harness. The point is not to make agents sound like an org chart. The point is to protect attention. If everyone is allowed to do everything, the system burns steps on wandering. If each role has a clear contract, the work becomes easier to resume, review, and repeat.

Commitmaxxing: Compounding Over Ceremony

Commitmaxxing pushes against drift. When a change works, I want it committed with a message that explains the unit of progress. When a decision is made, I want it written in the spec, issue, or code where the next worker will look. When a test captures a contract, I want it in the repository, not buried in a chat transcript.

The goal is not ceremony. The goal is compounding.

Every durable checkpoint lowers the cognitive cost of the next step.

• A clean commit says, “This happened, and here is the boundary.”
• A passing test says, “This behavior matters.”
• A short design note says, “Do not relitigate this unless the facts change.”
• A good README says, “Start here instead of asking the model to rediscover the project.”

That is not documentation for its own sake. It is operational memory. It is how we ensure that yesterday’s hard-won progress does not become tomorrow’s confusing legacy.

Tokenminimizing: Context as a Liability

Tokenminimizing is the other side of the same discipline. Most AI workflow advice focuses on better prompting. Better prompting matters, but it is incomplete. The best prompt is often the one you do not need because the repository already contains the answer.

If an agent must read twelve files, three stale plans, and a long chat summary to know what to do, the project is leaking tokens. If the next task can be expressed as “implement this checked contract and run the existing tests,” the system is healthier.

I do not mean starving the model of context. I mean structuring work so the right context is small, local, and current.

• A content schema should define article shape.
• A route test should define pages that must exist.
• A deploy script should describe the deployment path without exposing sensitive details.
• A Dockerfile should make the runtime obvious.

These artifacts are compressed operational memory. They reduce re-reading, re-asking, and re-discovering. They keep the agent focused on the actual problem instead of forcing it to reverse-engineer the environment.

The Practical Loop

My practical loop is simple. It is designed to keep the human in control of the boundaries while the AI handles the execution.

1. Define the contract. I like specs, issues, and checklists because they force the work to become inspectable before implementation starts. The contract does not need to be a novel. It needs to say what will be true when the work is done, what is out of scope, and how we will verify it.
2. Give the agent a bounded task. “Build the whole platform” is a fog machine. “Revise this article to satisfy these content contracts, touch only these two files, then run this one test” is work the system can hold. Bounded tasks reduce hallucination because the agent has fewer blank spaces to fill.
3. Commit when the increment is coherent. I want commits to be shaped like trail markers. If I come back after clinic, a meeting, or a night of sleep, I should be able to read the log and rebuild the story. If another agent picks up the branch, it should not need folklore.
4. Remove context debt. Delete stale notes. Update checkboxes. Move decisions into files. Replace a long explanation with a test. Replace a repeated instruction with a script. Replace a private explanation with public-safe documentation when appropriate. This is tokenminimizing in practice: not saying less, but making less necessary.

Motion Into Memory

There is also a trust component. AI agents are powerful, but they are not accountable. The human and the repository are accountable. Commitmaxxing creates review points where accountability can attach. Tokenminimizing reduces the chance that the model invents connective tissue between vague instructions. The more disciplined the artifact trail, the less we rely on vibes.

This has changed how I think about speed. Speed is not how quickly an agent can produce a diff. Speed is how quickly the whole system can move without losing truth. A messy branch with a heroic final summary is slower than a clean sequence of small, understandable steps. A giant prompt that only one model can survive is slower than a repo that any competent agent can navigate.

The best AI-native builders I know are not just prompting harder. They are designing work surfaces. They make the next action obvious. They write tests for the boring contracts. They make deployment paths explicit. They distinguish public artifacts from private systems. They do not ask the model to remember what git, specs, and CI are better suited to remember.

Commitmaxxing and tokenminimizing are names for that posture. One maximizes durable progress. The other minimizes unnecessary context. One asks, “What should be saved now?” The other asks, “What can the next worker avoid rereading, re-asking, or rediscovering?”

I am still refining the practice. Exploration needs messiness, and over-structuring can kill momentum. But for production work, especially work that touches real people, operational systems, or public identity, the discipline pays back quickly. The project becomes easier to resume. The agent becomes easier to steer. The human has fewer invisible assumptions to carry.

That is the craft line for me: not human versus AI, but human judgment shaping AI-readable systems. The builder’s job is to turn motion into memory, and memory into leverage. Commitmaxxing and tokenminimizing are how I keep that loop honest.