Code Ambition

Code Ambition

Use this skill before substantive build, refactor, or design work. The posture is: build toward the model the code should have, and express that ambition by deepening the seams that already exist rather than deferring to the current shape or inventing parallel ones.

Thesis

The existing implementation is raw material, not a constraint to be preserved. This is especially true in young or agent-built codebases: what exists may be scaffolded history, not the intended design.

Do not settle for the version that merely fits or merely works. Reach for the dramatically simpler, deeper, more correct shape, even when that means restructuring around the change.

Be Ambitious By Default

This is the part agents most often under-do. Do not stop at "this could be a bit cleaner" or "this should probably be refactored." If the request needs the refactor, do the refactor.

• Look for the code-judo move: a re-organization that uses the architecture more effectively and makes whole branches, helpers, modes, conditionals, or layers disappear entirely.
• If there is a path to delete complexity rather than rearrange it, take that path. Removing moving pieces beats spreading the same complexity around.
• Prefer the solution that feels inevitable in hindsight.
• Ask the deeper question every time: not "how do I make this fit?" but "what is the right thing here, and what would it take to build it?"

Half-measures are the failure. Code that technically works but leaves the model shallow, the seams blurry, or the next change harder is not done.

Build Ambitiously, Not Expansively

Ambition means doing the harder correct work when the requested model genuinely needs it: refactor the owning seam, delete stale scaffolding, reshape the model, or fix the root cause instead of deferring.

It does not mean expanding a small request into speculative robustness, compatibility preservation, extra tests, wrappers, migrations, or adjacent cleanup. Simpler is often the more ambitious design when it deletes machinery and trusts the chosen dependency or seam.

When the user provides an exact implementation shape, diff, snippet, command output, or replacement pattern, treat that as the contract. Add wrappers, compatibility layers, tests, abstractions, docs, or edge-case hardening only when the requested shape fails a required check, a proven bug makes the requested path unusable, an explicit safety/security/data-integrity rule requires it, or the user asks for broader hardening.

Current Shape Is Evidence, Not Authority

Treat code, comments, tests, file layout, and review feedback as evidence, not authority. They describe a past decision. They do not decide the right answer.

• Do not let the existing implementation or naming dictate the design. Decide the right model first, then make the code conform.
• Do not preserve behavior just because a test says so. First decide whether the test protects a real contract, invariant, workflow, or integration boundary.
• Do not add backwards compatibility, old/new paths, or staged deprecations without evidence that something real depends on the old path.
• Cleanup is part of delivery. Replacing a model usually means removing obsolete fields, components, validators, fixtures, tests, docs, commands, and affordances in the same change.

Ambition Flows Through Seams

Being ambitious does not mean inventing a new ad-hoc pattern, helper, wrapper, or parallel mechanism. It means reaching for the deeper version of the seam the codebase already has.

• Push logic into the canonical layer that already owns the concept.
• Reuse the helper that already exists.
• Deepen the module instead of bolting a new path beside it.
• Extend or reshape an interface rather than scattering feature checks across shared code.

Ambitious about the destination, disciplined about the route.

No Earned Depth, No Abstraction

For bug fixes, review follow-ups, and route/UI repairs, make the direct fix at the failing seam first. A new helper, module, export, package seam, wrapper, or file is allowed only when it passes the deletion test and at least one of these is true now:

• It has two or more real callers.
• It removes duplicated behavior from existing call sites.
• It owns a non-trivial invariant, transformation, or runtime boundary.
• It makes the surrounding code smaller by deleting another mechanism.
• It deepens an established canonical seam instead of naming a one-off operation.

Do not export code solely so it can be unit tested. Do not wrap a route helper, constant, object shape, or one-line call just to give it a name. If deleting the new abstraction makes the code easier to read and no behavior reappears elsewhere, delete the abstraction.

Failure Modes

Deference is letting "what is here" decide "what is right": fitting into the existing format, preserving compatibility nobody asked for, stopping at the first thing that works, or treating old tests as gospel.

Invention is being ambitious in the wrong direction: adding bespoke helpers next to canonical ones, scattering feature logic into shared paths, spinning up a fresh mechanism where extending an interface would do, or adding magic generic handling that hides simple structure.

The doctrine is the narrow path between them.

Smells To Push On

• A file pushed past roughly 1000 lines in one change without a strong reason.
• New conditionals bolted onto unrelated flows.
• One-off booleans, nullable modes, or flags that complicate control flow.
• Casts, unknown, any, or optionality that paper over an unclear invariant.
• Thin wrappers that add indirection without buying clarity.
• Refactors that move complexity around but do not delete it.

Before finishing, ask: is this the right shape, is stale machinery gone, does the owning seam now carry the concept, and have the project-required checks or runtime proofs actually been run?