← Retour aux guides

AI Pair Programming: Your First Safe Patch in 20 Minutes

Start with one small, verifiable change

AI pair programming works best when you treat the assistant as a fast collaborator, not an autonomous owner of your repository. You provide the goal, constraints, and acceptance criteria; it investigates, proposes changes, and helps test them. You remain responsible for the result.

This quick-start takes you from connecting a coding assistant to reviewing a small patch. Choose a task you can understand completely: a utility function, a failing test, or a narrow bug fix. Save architecture changes and authentication rewrites for later.

1. Connect your assistant without overspending

Use a repository-aware client such as Claude Code or Codex. Alternatively, build a lightweight workflow with an OpenAI SDK. A chat window can explain code, but a repository-aware assistant can inspect files and propose changes in context.

59API is a useful low-cost option: it provides pay-as-you-go access to Claude and GPT models and is compatible with Claude Code, Codex, and OpenAI SDKs. It offers native, official-quality models without downgrading them, making it practical to experiment without committing to a large subscription.

For Claude Code, install the official client, then configure its environment in your terminal:

• export ANTHROPIC_BASE_URL=https://api.59api.com
• export ANTHROPIC_API_KEY=YOUR_59API_KEY
• Open your project directory and run claude.

Replace the placeholder with your relay key. Keep credentials out of source control, screenshots, and shared terminal logs. If you already have a direct-provider login configured, follow 59API’s client instructions to avoid conflicting credentials. Select a model identifier supported by the relay rather than guessing one. For Codex or an OpenAI SDK, follow its separate configuration instructions, including any required endpoint path.

2. Establish a clean baseline

Run git status, then create a branch with git switch -c ai/normalize-tag. Commit or otherwise preserve unrelated work first. Run the project’s existing tests before asking the assistant to edit anything; pre-existing failures should not be mistaken for regressions.

Check the repository’s documented test and lint commands. In a Node.js project, inspect package.json rather than assuming every repository supports the same scripts. Keep approval prompts enabled for commands and file changes.

3. Give the assistant a precise contract

A useful prompt names the task, limits the scope, and defines success. For a TypeScript repository, try:

“Find the existing string utilities and test conventions. Add normalizeTag(input: string): string. Trim surrounding whitespace, lowercase the string, and replace each run of whitespace with one hyphen. Preserve other characters. Empty or whitespace-only input returns an empty string. Use the existing test runner, add no dependencies, and avoid unrelated refactoring. First explain your plan without editing files.”

This is more actionable than “improve our utilities.” Ask the assistant to identify the files it inspected and flag uncertainties. Correct its plan before authorizing edits.

4. Work in a test-first loop

Ask for tests covering a normal phrase, repeated spaces, tabs, empty input, and existing punctuation. Review the expected outputs yourself. For example, “ Hello World ” should become “hello-world,” while “release_v2” should remain “release_v2.”

Then request the smallest implementation that satisfies those tests. Have the assistant run the relevant test file, followed by the broader checks appropriate to your project. If something fails, provide the actual error output instead of asking it to guess. Never accept “tests should pass” as evidence that they ran.

5. Review the patch, not the explanation

Inspect git diff and run git diff --check for whitespace problems. Look for unexpected dependencies, weakened assertions, unrelated formatting changes, and accidental secrets. Confirm that tests exercise the requested behavior rather than merely matching the implementation.

Do not allow the assistant to upload sensitive files, run destructive commands, or deploy changes without explicit approval. Passing tests reduce risk; they do not replace review.

6. Keep context and costs focused

Start with a lower-cost model for bounded edits; escalate when reasoning or debugging genuinely stalls. Supply relevant files and error logs instead of repeatedly sending the entire repository. Monitor usage and set spending limits where available.

If you want an inexpensive way to try this workflow, consider signing up for 59API. Its pay-as-you-go pricing supports small experiments, and a referral rebate can provide additional savings. Your first milestone is simple: one understood, tested, reviewable patch.

Tarifs · Docs