Opening an AI panel inside your code editor feels like a shortcut until the first bad rewrite lands in a pull request you cannot explain. An IDE assistant (code help that lives inside Visual Studio Code, JetBrains, or Android Studio) is a power tool. From zero, you need the right Google account, an extension your company already allows, a tiny first task, and a hard habit: read every diff before you accept it.
This guide walks that path for Google’s Gemini coding help in the editor. Menu names and plan names move, so re-check Google’s docs the week you onboard a teammate. The goal is one small, reviewed change you can defend, not an impressive demo you cannot explain.
How IDE help differs from chat
Chat in a browser is a conversation. You paste code, you get text back, and you copy it by hand. IDE help sits next to the file you already have open, so it can suggest the next line, explain a function in place, or propose an edit across a few files. That speed is useful. It is also how a wrong rename can touch twelve files before you notice.
Terminal agents (tools that run from a command line and can edit many files in one go) are a third shape. They are even more powerful and even easier to over-trust. Start in the editor with small, visible diffs. Graduate to agents only after your team already reviews AI edits the same way it reviews human ones.
A from-zero path that respects work accounts
Use your work Google account on a company laptop when policy says so. Personal accounts on company code are a common audit finding, and they are avoidable if you check before you install anything.

- Confirm personal vs work Google account. Company laptop policy wins.
- Install only the approved Gemini extension, or use the built-in Gemini feature in Android Studio if that is your stack.
- Open a toy repo, or a throwaway branch of a real repo. Do not practice on main.
- Ask for a one-function change. Read the full diff. Run the tests you already trust.
- Write three lines on what helped and what you rejected. That note is how the habit sticks.
What IDE AI is for (and what it is not)
Use it to finish boilerplate you already understand, explain unfamiliar code you own, suggest tests you will actually run, and rename with your confirmation. Do not accept huge unread diffs, paste production secrets into chat, skip review because a change “looks right,” or add dependencies you cannot justify in a pull request.

| Use | Avoid |
|---|---|
| Complete boilerplate you understand | Accepting huge diffs unread |
| Explain unfamiliar code you own | Pasting production secrets into chat |
| Suggest tests you will run | Skipping review because it “looks right” |
| Rename with confirmation | Drive-by dependency adds you cannot justify |
A first-week task menu
Pick one of these so the first week builds skill without wrecking the repo.
- Add a unit test for an existing pure function (a function with no network or database side effects).
- Ask the assistant to explain a legacy function, then write that explanation in your own notes, not only in chat history.
- Extract a small helper with identical behavior, and prove it with the same tests.
- Improve an error message without changing control flow.
After any AI edit, run this human checklist.
# Human checklist after any AI edit
# 1) Read the full diff
# 2) Run the tests you trust
# 3) Search for new network/file side effects
# 4) Confirm no secrets in logs or source
# 5) Request review if auth, payments, or migrations touchedAndroid Studio for mobile teams
If you ship Android apps, train in Android Studio, not only in generic VS Code demos. Gradle builds, manifests, and the emulator context matter, so the assistant sees a different world than a plain TypeScript repo. Start with “explain this” and small UI or test changes. You still own the merge.
Enterprise vs consumer reality
Consumer IDE paths and company licenses are not the same product. Individual Pro or free tiers may point you at one Google coding surface, while Standard or Enterprise Code Assist licenses often stay on another. If your extension suddenly refuses requests, diagnose the edition and any deprecation notice before you blame the model. Details live in the Gemini product map on this site and in Google’s current Code Assist docs.
Your first practice week
- Set up on an approved surface only.
- Complete one tiny task on a feature branch.
- Paste the diff summary into a pull request description in your own words.
- List one suggestion you rejected and why.
Mistakes that burn a sprint
- Installing three overlapping AI extensions so keybindings fight each other.
- Using a personal account on company code.
- Generating code and never running tests.
- Training juniors on full autonomy before a review culture exists.
What good looks like on a real squad
One squad banned multi-file AI edits until code owners could explain every accepted line. Throughput rose because review time fell. Another team installed every plugin after a conference and spent a sprint untangling conflicting formatters and secret leaks in chat history. The difference was not the model. It was whether the team treated the assistant like a junior who needs review.
Ship one small, reviewed change this week using only the habits from this part. Coding AI skills stick when they produce merges you can defend, not when they produce impressive demos you cannot explain.
Takeaways
- Right account, approved tooling, tiny task, read every diff.
- IDE assist is not a license to skip review.
- Next in this series: terminal agents and the Antigravity mental model.
Series notes
This is Part 1 of the Gemini coding surfaces tutorial (series code GM22). It pairs with the Gemini product map (Code Assist, Android Studio, Antigravity notes). Gemini is not one single app. Labels and eligibility change; re-check live docs the week you onboard a team.
Sources
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
