How to code without AI when your skills feel rusty

If you feel like you cannot code without AI, deleting every tool is usually the wrong test. Claude, Copilot, and Codex can increase output while reducing how often you retrieve syntax, trace state, design tests, or hold a debugging model in working memory.

The useful question is not whether AI is good or bad. It is which engineering actions you can still perform when the model is unavailable, confidently wrong, or missing the context that matters.

• You can describe the feature but cannot name the first file or contract to inspect.
• You paste an error into a model before reproducing it or reading the failing test.
• You accept a patch because it looks plausible, then struggle to explain its state changes.
• You ask the model to write tests without first deciding which failure the tests must catch.
• You avoid small manual edits that you could previously make with confidence.

1. Scope for five minutes. Pick one non-sensitive task that can finish in a single function, test, or bounded patch. Write the expected behavior, the likely failure, and the command that will verify the result.
2. Work manually for fifteen minutes. Disable generated completions. Use the repository, documentation, compiler, debugger, and existing tests. Do not ask a model to propose or write the implementation.
3. Verify for five minutes. Run the narrowest relevant check. If it fails, read the actual output before changing code. Record whether your original assumption was correct.
4. Debrief for five minutes. Explain the contract, the change, and the evidence in plain language. Note exactly where you needed help.

Good practice is small enough to finish and useful enough to matter. In a JavaScript or TypeScript repository, that could be an async ordering bug, a missing validation branch, a flaky test, an unclear error boundary, or a small refactor with an existing test suite.

A broad course or a pile of algorithm puzzles may train something different from the work you are trying to retain. Start with the weakest observable signal in code you already understand.

• Did you reproduce the original behavior before editing?
• Could you name the broken assumption and the affected test?
• Did your first change make the result better, worse, or merely different?
• How many edits and test runs did the task require?
• Can you explain the final diff without asking AI to summarize it?

Getting stuck is part of the measurement. After the manual window, ask for one explanation, observation, or next action. Do not immediately hand over the implementation. The help you needed should determine the next practice task.

The goal is not less AI. The goal is retaining enough implementation and debugging judgment to verify what AI produces.

Start with one bounded rep. Repeat the protocol on a different failure mode only after reviewing the evidence from the first attempt. If you repeatedly struggle with async reasoning, testing, or state tracing, keep the next task focused on that skill instead of increasing the size.

ManualMode uses short Gym calibration reps to locate weak signals, then Project reps to reserve useful work from your own repository. The first three Gym reps and one Project rep are free.