Working at AI speed
An autonomous assistant moves fast and acts with confidence. The four disciplines below are what turn that speed into something useful.
Without canonical sources, mechanical gates, sequenced PRs, and isolated worktrees in place, an autonomous assistant produces credible-looking commits faster than a human can catch them by reading. With those gates in place, the speed becomes useful.
Each of these disciplines is older than AI. What changes when an autonomous assistant joins the work is the stakes, not the methods.
Drift between synthesis and canon
Most documents I produce are derived. Folder indexes, project overviews, release notes, status rollups, README "what we use" lists. All of them are summaries of something else. The trouble is that they read with the same authority as the canonical artefacts they describe.
A marketing page that lists features is a synthesis of the product, not the product. The features live in the source code, the build configuration, the StoreKit setup. The page is whatever someone last typed about those, and what someone last typed can be six months old without looking it. When the canon changes and the synthesis doesn't, the synthesis starts lying. It keeps lying, because nobody taught it to listen.
A neglected canonical artefact has gaps, but its facts stay true. A neglected synthesis drifts silently while reading confidently. Reading authority is not the same as data authority. Once that distinction lands, a lot of documentation looks different: every overview, every "what we use" list, every public-facing claim is downstream of something. The discipline becomes asking what owns it.
Mechanical gates beat smarter humans
The fix that survives the next change is rarely "be more careful next time". It is wiring a small mechanism into the moment the work starts.
A claims manifest names every public claim about a product and the artefact that owns it. CI fails when an artefact stops exposing what a claim references. The gate is precise, runs every commit, and removes the human from the loop where the human would otherwise have to remember.
The shape of the question is the gate. Searching closed tickets before filing, not after, surfaces decisions to not do something. A grep against work already declined catches refactor proposals heading back into territory abandoned for a reason. The mechanism is small and the question is precise. It runs every time, not because anyone reminds it to, but because it is wired into the moment the work starts.
Recovery, then prevention
When something is wrong in production, two PRs go out, in this order. The first fixes the immediate symptom. It is narrow in scope and lands quickly. The second addresses the structural gap the symptom revealed, scoped properly and reviewed without the pressure of an active bug.
Bundling the two is the path most people take, and the one that consistently slows the work down. The narrow fix gets caught in the design discussion. The design gets compromised by the urgency. Splitting them respects both.
The pairing has a second virtue. The structural fix is much easier to scope after the wording fix has already shipped and landed cleanly. The first PR proves the symptom and rules out alternative causes. The second can then aim at the actual gap rather than at every plausible adjacent problem.
Holding four investigations at once
A single trunk is not enough when several independent investigations are open. Each gets its own git worktree.
Worktrees are not new. The shift is treating them as the default unit of work rather than the exception. One worktree per ticket, one branch per worktree, one mental context per worktree. The assistant can run inside any of them without leaking between investigations. Trunk stays clean. Switching from one thread to another takes a cd rather than a stash.
This matters more with an AI in the mix, not less. An autonomous assistant can produce a credible-looking commit in seconds. If four pieces of work share a checkout, the surface area for "wait, which thread did that come from" grows fast. Isolated worktrees turn that question into a non-question. The investigation is the directory.
The cost is being deliberate about the shape of a unit of work before starting it. The benefit is moving between four open questions without losing where each one was. A worked-out structure for one beats half-baked overlap on four.
The studio is a single-developer operation, run in personal time around a day job. The work output is apps. The writing here is the working notes. Methodology I am happy to share, patterns illustrated from inside the work, and lessons including the ones that came from getting it wrong.
The aim is to put a clear signal into the public record. A seasoned developer is going into AI deliberately and learning in the open.