AI Coding Tools: Work With Intent, Not Vibes

AI coding tools are most useful when you give them a defined job, enough relevant context, and a way to check the result. This workflow helps you turn a vague request into a small, reviewable change, whether you are asking for an explanation, a test, or an implementation.

What You’ll Need

• A code editor or development environment and an AI coding assistant you are permitted to use.
• A project you can run or inspect, plus its relevant files, tests, and setup instructions.
• A clear description of the desired outcome and a way to verify it, such as a test command or a reproducible manual check.
• A clean version-control checkpoint, such as a Git commit or saved copy, so you can review and undo changes.

Step-by-Step

1. Choose one concrete outcome. State what should be true when the task is finished. “Make the account page better” is broad; “Show an inline message when the email field is empty, and leave the rest of the form unchanged” is testable. If you do not yet know the solution, make the first task investigation rather than implementation.
2. Set a baseline before asking for changes. Check the working tree for existing edits and note which files are already modified. Run the relevant existing tests or reproduce the behavior yourself. Save the output, including failures. This distinguishes new problems from problems that were already present.
3. Give the assistant bounded context. Include the relevant file paths, the behavior you observe, the behavior you want, and any project conventions it should follow. Point it toward the appropriate tests or documentation. Avoid pasting the entire repository when a few files will do; irrelevant context can distract the tool. Do not provide passwords, access tokens, private customer data, or other secrets. Follow your organization’s rules for sharing code.
4. Ask for a plan when the task is unclear or cross-cutting. Request a short diagnosis, proposed files to change, assumptions, and verification steps before code. Review the plan for scope and missing requirements. Correct misunderstandings early. For a tiny, well-defined edit, asking for a plan may add little; use judgment.
5. Make the change in small increments. Ask for one coherent change at a time, such as adding a validation rule and its test. Specify constraints: public interfaces to preserve, supported runtimes, style conventions, and behavior that must not change. Prefer a focused patch over a broad rewrite. If the tool can edit files directly, inspect the diff after each meaningful change rather than accepting a large batch blindly.
6. Ask for tests that express the requirement. A useful test checks observable behavior, including a relevant edge case. Tell the tool what should happen for valid and invalid input, or what should remain unchanged. Tests generated alongside code can help, but they are not proof by themselves: make sure they actually fail when the requirement is broken and do not merely repeat the implementation’s assumptions.
7. Run the project’s real checks. Use the commands documented by the project for tests, linting, type checking, or building. Do not assume a command or dependency exists because the assistant suggested it. Read the output and compare it with the baseline; investigate new warnings or failures rather than treating a successful-looking summary as enough.
8. Review the diff as the responsible maintainer. Check every changed line for correctness, scope, unintended file edits, insecure handling of input, accidental logging, unnecessary dependencies, and compatibility with nearby code. Verify that the implementation meets the original acceptance criteria. Ask the assistant to explain unfamiliar code, but confirm the explanation against the code and project documentation.
9. Close the loop. If a check fails, give the assistant the exact error and the command that produced it, then request a diagnosis before another edit. Once the change passes review, summarize what changed, what checks ran, and any remaining limitations. Keep or discard the work through your normal version-control process.

Common Mistakes

• Starting with “build something good.” Vague goals invite guesses. Define the user-visible behavior and what is out of scope.
• Asking for a large rewrite in one prompt. It is harder to catch incorrect assumptions and easier to introduce regressions. Break the work into reviewable slices.
• Trusting confident explanations or invented APIs. Assistants can produce plausible but incorrect details. Check function names, dependencies, and behavior against the project and authoritative documentation.
• Accepting code without running checks. A patch that looks tidy can still fail to build or break an edge case. Run relevant checks and inspect their full results.
• Providing sensitive or unnecessary context. Share only what the task needs, and follow the tool’s data-handling settings and your organization’s policy.
• Letting the task drift. New requirements may appear during implementation. Record them separately or revise the acceptance criteria before expanding the patch.

Tips

• Use a compact prompt structure: goal, current behavior, desired behavior, constraints, relevant files, and verification.
• Include exact error messages and steps to reproduce a bug; paraphrases can hide the important detail.
• Ask the assistant to identify assumptions and unknowns instead of filling gaps silently.
• Keep an acceptance checklist beside the task, and check each item against the implementation and tests.
• For unfamiliar code, ask for an explanation or a minimal diagnostic first. Separate learning from changing production behavior.
• Use version control to compare the result with the starting point. A small, understandable diff is easier to validate and reverse.

Troubleshooting

The assistant changes the wrong thing: Stop and restate the desired behavior, name the files or interfaces that must remain untouched, and ask for a plan or a smaller patch. Revert unrelated edits if appropriate.

The output does not fit the project: Share the relevant convention, dependency version, or neighboring example, then ask for a revision that follows it. Verify uncertain details in project documentation rather than repeatedly prompting for guesses.

Tests fail after the change: Compare failures with your baseline. Provide the exact command, complete relevant error, and reproduction steps. Ask for a diagnosis and one targeted fix; do not suppress or weaken a test just to get a green run.

The tool keeps producing broad or incomplete answers: Narrow the request to one file or behavior, state the expected output, and ask it to list any missing information before editing. If the task depends on context the tool cannot access, inspect that context yourself and provide a concise excerpt.

You cannot tell whether the result is safe to merge: Pause. Review the diff, run project checks, and get an appropriate human review for changes whose correctness or impact you cannot assess. Do not treat generated tests or a tool’s assurance as a substitute for review.

Frequently Asked Questions

Should I ask the tool to plan first every time?
No. Plan first for ambiguous, multi-file, or high-impact work. For a small, clear edit, a direct request with constraints and checks may be enough.

How much code should I include in a prompt?
Provide the smallest relevant context that explains the behavior: key files, nearby examples, errors, and project instructions. Add more only when the assistant identifies a specific gap.

Can I trust code that passes its tests?
Passing tests is useful evidence, not a guarantee. Tests may miss cases or encode the wrong requirement, so review the code and check it against the actual acceptance criteria.

What should I do if I do not understand the generated change?
Ask for a plain-language explanation of the changed lines and their effects, then verify it yourself. If you still cannot assess the change, do not merge it without qualified review.

Is it okay to give an assistant private project code?
Only when the tool and your organization’s policies permit it. Check data-handling requirements first, and never include credentials or sensitive data that the task does not need.

What is the best way to undo a bad edit?
Use your editor or version-control workflow to restore the affected changes, taking care not to discard unrelated work. A clean starting checkpoint makes this safer.

Related

• Missed Rights Issue Deadline? UK Investor Guide
• All Fisch Second Sea Locations Bestiary
• Mobile Security Threats You Need to Know