Skip to content

Junior frontend developer

Imani Brooks

Software

Problem

Imani Brooks is a junior frontend developer. When the build fails, the error message is long and she feels she should already know it. She sometimes pastes the whole company repository trail into a chat, which she now knows is a bad idea, or she waits until she is stuck for hours because asking in the team channel feels exposing. She wants a way to explain the error, try a small hypothesis, and arrive at a question a senior can answer quickly. Gemini can coach her reading. It should not silently rewrite the feature or invent a library that is not in the project.

Gemini strategy

Imani pastes only the error text and a tiny redacted snippet she is allowed to share, never secrets, tokens, or private customer data. She asks Gemini to explain the message in plain language, list likely causes ranked by what she can check first, and propose one small experiment. The prompt tells it not to dump a full rewrite. After she tries the experiment, she compares the result with the explanation. That is her verification step: if the model named an API her project does not use, she discards the advice. If she is still stuck, she posts a short question to a senior with what she already tried.

Prompts

Explain this error and give one experiment

You are coaching a junior frontend developer. I will paste an error message and a small snippet I am allowed to share. Do not ask me to paste secrets, tokens, or private repository code. Explain the error in plain language. List up to three likely causes, ordered by what I can check in a few minutes. Propose one small experiment, not a rewritten feature. Name any assumption you are making about the framework. If you are not sure, say so. Then draft the question I could ask a senior if the experiment fails, including what I already tried.

Review my fix before I ask for help

Here is what I changed and what the terminal shows now. Do not rewrite the file for me. Say whether the change matches the experiment we planned. Point out one risk, such as a case I did not test. If the error is different from before, explain the new message without inventing project APIs. Tell me if this is a reasonable moment to ask a senior, and tighten my question so it includes the error, the attempt, and the result. Remind me not to include secrets. If you are guessing, label the sentence as a guess.

Process

  1. 1. Paste the error and a small allowed snippet, not secrets.
  2. 2. Run one small experiment the explanation suggested.
  3. 3. Compare the result with the explanation and discard mismatches.
  4. 4. If still stuck, ask a senior with the attempt included.

Result

Imani's estimate is that she spends less time frozen and a bit more time trying one deliberate check. She still needs seniors for design questions, and she still hits errors the model explains badly. The useful change is her question quality: she can say what she tried. She stopped pasting environment files after a draft echoed a variable name she should not have shared. Her team has not measured a productivity score. She feels less afraid to ask, which she counts as the real result.

Lessons

  • Paste the error, not the secrets, and never the whole private repo.
  • One experiment is a better next step than a generated rewrite.
  • Verify the advice against the project, then ask a human with context.
All case studies