Keep the solution small

Make the code easy for the next teammate to understand and change. Prefer clear names, explicit data and direct control flow. Put a decision in one place when several callers need to agree on it.

For example, an interface and a server can share the rule for editing a draft. The actor here comes from an authenticated session with current workspace membership, not from the request body:

function canEditDraft(actor, draft) {
  return actor.workspaceId === draft.workspaceId
    && draft.status === "draft"
    && (actor.id === draft.createdBy || actor.role === "owner");
}

The interface uses this decision to explain which actions are available. The server must enforce it too. Sharing a rule reduces disagreement; hiding a button does not prevent a request.

Understand what you ship

Be able to explain a shipped system at a whiteboard without reading its code: how data moves, why this design was chosen over the alternatives, what must remain true, what a malicious actor could do, and where it fails. Explain the important data structures and tradeoffs in terms another teammate can follow.

Using an agent does not transfer responsibility for understanding the result. Tests support that understanding; passing them does not replace it. Disposable experiments can prioritize learning quickly. Before their code becomes part of a shipped product, understand and verify it to the same standard.

Earn each extra part

Use the product’s existing components, tests and libraries when they fit. Add an abstraction when it removes a real source of complexity. A wrapper that hides a single obvious call may make the code harder to follow.

Keep responsibilities focused. Remove dead code and obsolete paths as part of the change that replaces them. Explain intent or a surprising constraint in a comment when the code cannot express it clearly. Avoid comments that merely repeat the next line.

The same restraint applies to this handbook, skills and process. Repeated work may deserve a tool. An isolated task may need only a direct check. A new folder, skill or document should make future work easier, not give the current task an appearance of rigor.

Measure what people wait for

Treat latency and resource use as part of the experience. Measure the paths a change could make slower, using conditions that resemble actual use. Record the dataset, environment and whether the run was cold or warm so the comparison means something.

Remove unnecessary work before adding machinery to make it faster. Fetching, polling or rendering unused data still has a cost. When a tradeoff is worth that cost, explain it with evidence.