Coding

The Coding capability makes Pimsy competent at software engineering rather than merely fluent in programming languages. Fluency produces code that reads correctly. Competence produces code that is correct in the repository it belongs to — which is a much harder and much more valuable thing.

The distinction is everything. A model asked to "add a retry to the payment call" can write a textbook retry loop in seconds. Whether that loop is safe depends on facts the snippet cannot contain: whether the call is idempotent, whether an upstream circuit breaker already retries, whether the surrounding transaction will be held open across the backoff. The Coding capability answers those questions from the repository model documented under Codebase, so the edit is planned against how the system actually behaves.

What the capability adds to the model#

• Repository grounding — every edit is planned against the four-layer index, so the agent knows the call sites, types and tests a change touches before writing a line.
• Structured edits — changes are emitted as reviewable patches against a workspace branch; the working tree is never mutated in place.
• Targeted verification — the behavioural layer selects the minimal test set covering the changed symbols, so a change is proven rather than assumed.
• Convention adherence — formatting, error handling and dependency choices are drawn from the surrounding code, not from the model’s priors about how the language "should" look.

The engineering loop#

1. 1

   Understand

   The request is resolved against the repository model to establish what exists, who calls it and which tests cover it. Under-specified requests are narrowed by inspection before any plan is formed.

2. 2

   Plan

   An ordered set of symbol-level edits is produced with the invariant each must preserve. The plan is inspectable and rejectable before a file changes.

3. 3

   Implement

   Edits are applied as structured patches on a branch, following the conventions of the code being modified.

4. 4

   Verify

   The minimal covering test set runs. Failures return control to the planning step with the failure attached, rather than being reported as a completed change.

5. 5

   Explain

   A reviewable diff is presented with per-hunk rationale linking each change to the plan step that motivated it. Review authority stays with a human.

objective   add idempotency to the refund path
plan
  1  refund/service.processRefund
     · thread caller-supplied idempotency key through to client
     · invariant: a retried refund never issues a second transfer
  2  refund/client.postTransfer
     · require idempotencyKey; reject calls that omit it
     · invariant: signature change is internal, crosses no published interface
verification
  covered   7 tests (4 unit, 3 integration)
  gap       refund/legacy-webhook has no attributed test  →  add before apply
review      human  (touches money-movement code)

Where authority stops#

The Coding capability produces branches, patches and reviews. It does not own merge authority, release credentials or the decision to deploy. An agent can be granted broad read access to a repository and narrow, reviewed write access at the same time, because those are separate grants. This is what makes it defensible to let an agent operate continuously in a codebase without also letting it ship unreviewed code to production.