The AmplifierReal cases · IT · Junior developer
Nandini, 24: two years in, and every pull request comes back red
A legacy codebase nobody documented, a reviewer who rejects everything, and a coding assistant that makes it faster to be wrong.
Planned for release phase 2. The page is complete as a draft; interactive parts run in the browser and do not yet save to an account.
In brief
The situation. Nandini is a developer at a mid-sized IT services company in Hyderabad, on a team maintaining a twelve-year-old insurance system. Her pull requests come back with fifteen comments each. She has started using a coding assistant to move faster, and now the comments come back faster too. The senior reviewer, a taciturn man named Bhaskar, has said the same thing twice: "You're changing code you don't understand." She thinks he is right and does not know what to do about it.
Step 1 — Define the End State
"A pull request Bhaskar merges with fewer than three comments, on a module I can explain to a new joiner. I want to stop being afraid of the review and start being the person on the team who understands the claims module." Audience: Bhaskar, a future new joiner, and the on-call engineer at 2 a.m. who has to read her code when it breaks.
Step 2 — Map the Flow
Her list: map the claims module's actual behaviour, build a mental model, then make changes small. AI review adds: read Bhaskar's last thirty review comments and cluster them (the pattern would tell her what he actually cares about); write characterisation tests before touching anything, because a legacy module without tests cannot be changed safely. It suggests a full refactor. She declines — not her call, and the exact thing Bhaskar fears.
Step 3 — Assign Tasks
Clustering the review comments: AI, verifiable, low cost. Explaining what an undocumented function does: AI, then she confirms by reading and by running it. Writing characterisation tests: hybrid — AI drafts, she verifies each assertion against real behaviour. Deciding which change to make and how small: hers. The change itself: hers, with the assistant allowed to suggest but every line read.
Step 4 — Select the Tool
The coding assistant stays, with two rules: read every suggestion, and no Tab on anything she cannot explain. A conversational tool with a large context window for whole-file explanations. Frequency is daily, so a saved brief.
Step 5 — Prepare and Direct
Criteria: every function I touch has a test that fails before my change and passes after; I can explain the change in two sentences in the PR description without the words "refactored" or "cleaned up"; nothing in the diff is there because a tool suggested it.
Steps 6 and 7 — Execute and Evaluate
The comment clustering is the shock: sixty percent of Bhaskar's comments are about one thing — changing behaviour the callers depend on. Not style. Not speed. Her characterisation tests, drafted by the tool, fail her criterion in four places where the assertion tested what the code should do rather than what it does. She rewrites those by hand. Her first PR under the new criteria is small, has tests, and a two-sentence description.
Step 8 — Integrate and Stress-Test
Bhaskar leaves two comments. One is a small fix. One is structural: her change is right, but her tests reveal a second caller she did not know about, and the fix needs to be in a different place — a Step 2 gap, a dependency her map missed. She traces it, adds the caller to her map, moves the change. Merged.
What changed
The assistant did not get slower. She did — briefly — and then faster than before, because she was no longer redoing everything. Six months later she is the person who explains the claims module to new joiners.
Cluster your reviewer's comments; the pattern is the real brief. Characterisation tests before any change in legacy code. "No Tab on anything I can't explain" is a criterion, not a slogan.
A composite case, not a client engagement; the person is invented, the situation is not.