· Tools & AI · All posts
Why “just use the AI” is not enough
An AI-assisted IDE can suggest code, explain errors, and edit multiple files at once. That speed is useful only if you can steer it: narrow the task, judge the output, and verify behavior. Without that, you get plausible-looking changes that break edge cases, leak patterns from old tutorials, or drift from your project’s conventions.
Training here means practice—the same way you learned Git or a framework—not memorizing prompts. The goal is repeatable habits that work in Cursor, in editors with GitHub Copilot, in JetBrains AI Assistant, or whatever ships next.
Mindset: director, not passenger
Think of the model as a very fast teammate who has no memory of your stand-up and no stake in your deadline. You supply intent, constraints, and the final call on merges. If you accept every suggestion, you are not learning the codebase—you are decorating it.
- State the outcome first. “Add validation for empty email on submit” beats “fix the form” because it bounds the change.
- Ask for options, then choose. When unsure, request two approaches (e.g. client-only vs server validation) and pick the one that fits your architecture.
- Keep ownership of design. Let the tool draft; you decide names, error messages, and what belongs in which module.
Context hygiene (works in any AI IDE)
Models answer from what they see: open files, selections, @file-style references, or project rules. Sloppy context produces generic Stack Overflow answers dressed in your syntax.
- Point at the truth. Attach or reference the interface, type, or test that defines “correct” before asking for a fix.
- Trim noise. Close unrelated buffers and avoid pasting huge logs when the first twenty lines contain the stack trace.
- Encode team rules once. If your stack supports project-level instructions (skills, rules, or similar), document naming, test commands, and “never do X” there so you do not repeat them every chat.
Skills worth drilling deliberately
- Read the diff before you save. Scan imports, deleted guards, and renamed symbols. This one habit prevents most accidental regressions.
- Run the smallest verification loop. Single test, one route, or a typed build—whatever proves the change in under a minute.
- Challenge hallucinated APIs. If a suggestion imports a function you do not recognize, check your
package.jsonand docs. Models blend versions. - Refactor in slices. “Rename across the module” is safer than “modernize the whole service” in one shot.
- Explain it back. After a non-trivial edit, close the chat and write a one-sentence summary of why the change works. If you cannot, you do not own it yet.
A simple four-week practice plan
You do not need a new course—you need constrained reps on your repo or a toy project.
- Week 1 — Explain and locate. Use the AI only to navigate: “Where is X handled?” and “Trace this request.” No edits. Build a mental map.
- Week 2 — Micro-edits. Ten tasks under fifteen lines each: typings, a test case, a small bugfix. Always diff-first, always run one check.
- Week 3 — Constrained features. One small user-facing change with explicit acceptance criteria you wrote before opening the chat.
- Week 4 — Review mode. Paste your own PR-sized diff and ask for risks and missing tests—not for rewrites. Compare the list to what you would have caught alone.
Staying sharp as tools change
Vendors will rename features and models will update. The durable skills are scoping, verification, and reading code you did not type. Invest there and any AI IDE becomes leverage instead of a crutch.
At Gratiq we treat tools like this as part of delivery: learn the editor the same way you learn testing and Git—with structure, feedback, and real tasks—not endless feature tours.