Gemini workflow
Start with a narrow feature, ask Gemini for a runnable first pass, then inspect what it produces. Treat each response as a draft: run it, report the exact failure, and request one change at a time.
A useful Gemini coding session ends with something you can run and check, not just a convincing explanation. Choose a small outcome before asking for code.
You have an idea for a personal tracker but no project structure. Ask for a single page, its required files, and instructions for opening it locally.
You can add an entry, reload the page, and confirm whether the data persists. If the first draft fails, paste the error rather than requesting a complete rewrite.
You already have a repository and want a form added without changing unrelated files. Give Gemini the relevant component and describe the existing conventions.
You receive a limited patch to inspect against your project. Compare this chat-led approach with how to vibe code with copilot when suggestions appear inside an editor.
You need a modest app demo, such as a reading list with search. Specify the data fields, empty state, and behavior after refreshing the browser.
You have a testable slice rather than a feature wish list. A beginner tutorial can help you keep the first request small enough to verify.
| Initial Gemini response | Deliverable after review | |
|---|---|---|
| Scope | May interpret a broad request as several features at once. | Names one user task and states what is outside the first version. |
| Files | May show snippets without saying where they belong. | Lists every required file and identifies where each piece of code goes. |
| Dependencies | May assume a framework, package, or tool is already installed. | States the runtime and packages needed, or uses plain browser features. |
| Behavior | Describes what the interface should do. | Lets you perform the stated task and observe the result. |
| Data handling | May imply that entered information survives a reload. | Makes persistence explicit and includes a reload check. |
| Failure handling | May omit empty inputs and invalid values. | Shows a sensible response to blank, invalid, or missing data. |
| Review | Explains why the proposed code should work. | Includes steps you can execute to confirm that it does work. |
Gemini can help draft and revise code, but a plausible answer is not proof of a working app. Run the project, check the main task and an edge case, and read changes before accepting them.
Most rework comes from an underspecified request, a missing project assumption, or feedback that says only “it doesn't work.” These workflows make the next revision more precise.
Instead of asking Gemini to build an entire productivity app, describe one task: add a habit and mark it complete today. Request the files, setup steps, and the expected behavior after a reload.
Put the returned files in the stated locations and follow the setup instructions exactly. Test the normal path, an empty input, and a refresh before requesting visual polish; appearance can hide broken behavior.
If a button does nothing, share the relevant file, the exact error if there is one, and how to reproduce it. Ask for the smallest correction and an explanation of what changed, then rerun the failing check.
Describe one user action and its expected result. Build a first draft, run it yourself, and use what you observe to guide the next prompt.
Gemini can draft code and setup instructions from a description, but the result depends on how clearly you define the task and environment. Run the code yourself; a complete-looking response may still have missing files, incompatible dependencies, or behavior that differs from your request.
Name one user task, the inputs it needs, and what should happen when it succeeds. State your preferred language or framework if you have one, and ask for a file list and run instructions so the output is easier to check.
Copy the exact error, identify the command or action that produced it, and provide the relevant file. Ask for the smallest fix, then rerun both the failing action and anything that worked before.
No. Remove passwords, tokens, personal information, and confidential source material before sharing project context. A small sanitized example and the relevant error are usually more useful than an entire private repository.
Check the main task, invalid inputs, refresh behavior, and setup steps on a clean run. Review the generated code for unexpected dependencies or data handling, and describe any unfinished behavior honestly when sharing the prototype.