AI-Assisted Work

AI assistance works best as a short feedback loop. The engineer defines the outcome and constraints; the tool proposes; the engineer checks reality.

A useful workflow

1. Frame the task. State the user outcome, current behavior, constraints, and what must not change.
2. Gather evidence. Read the relevant code, tests, logs, documentation, and recent decisions.
3. Ask narrowly. Request one explanation, plan, test, or small change at a time.
4. Inspect the proposal. Check assumptions, dependencies, error paths, security boundaries, and unnecessary changes.
5. Verify behavior. Run focused tests, type checks, static analysis, and a real user path where appropriate.
6. Own the result. Simplify the diff, update documentation, and explain the decision in your own words.

Goal: Add retry handling to the payment status poller.
Current behavior: One timeout ends the poll.
Constraints: No duplicate charge requests; keep the existing API contract.
Relevant files: poller.ts, poller.test.ts, payment-client.ts
Non-goals: Changing the provider SDK or checkout UI.
Done when: Transient failures retry with a bound; permanent failures stop;
existing and new tests pass.

Vibe coding has a boundary

“Vibe coding” usually means steering from prompts and visible results without understanding every implementation detail. It can be useful for disposable prototypes, learning, or testing an idea in an isolated environment.

It is not a production acceptance standard. Before code reaches a shared branch, an engineer must understand its behavior, dependencies, failure modes, data access, and rollback. If nobody can explain the change, the change is not ready.

Good uses

• explain an unfamiliar module and identify where to verify the explanation;
• draft table-driven tests or edge cases for an understood contract;
• compare two designs with explicit constraints and trade-offs;
• perform a bounded refactor while preserving tests;
• summarize a diff for review, then check the summary against the diff; and
• draft documentation from verified behavior.

Weak uses

• choosing an architecture before the problem is understood;
• diagnosing production from a partial screenshot or one log line;
• generating a large feature across unfamiliar systems in one request;
• replacing a security, privacy, legal, or domain review; and
• writing more code or documentation only to make work appear complete.

Keep the diff reviewable

Ask the tool to preserve local conventions, avoid unrelated cleanup, state assumptions, and list verification commands. Reject generated abstractions that serve one call site, comments that repeat the code, and tests that only mirror the implementation.