Skip to content
Prathamesh Kasar
Resume

How I work

Spec first. Test alongside. Own it in production.

I use Claude Code as a fast pair, with me as the engineer who decides and verifies. Every change goes through the same steps, from understanding the ask to handing it over. On the bbSlate In-Person module, that is how I delivered 9 changes in about 3 weeks to a VP release deadline.

  1. 01Requirement

    Start from the business ask, even when it is one line.

  2. 02Spec

    Write down rules, edge cases and acceptance criteria before code.

  3. 03Build

    Implement against the approved design, with tests alongside.

  4. 04Verify

    Prove it works: tests, regression runs, and checking the real data.

  5. 05Release

    Ship with QA and mobile teams briefed on exactly what changed.

  6. 06Own in production

    Watch the logs, triage defects, and fix the root cause.

The method

Ten steps, every change

Decisions are written down before code exists. Reviews happen on a one-page spec, not 800 lines of diff, and the spec stays true after release.

Decide

  1. 01

    Understand

    The requirement and the current behaviour. I read the code and the real data, not just the ticket.

  2. 02

    Check feasibility and impact

    What else touches this, and what could break.

  3. 03

    Write the change request

    Rules, edge cases and acceptance criteria with exact values. Claude drafts; I iterate until it's right.

  4. 04

    Approve the design

    The proposed spec is agreed before any code exists.

Build

  1. 05

    Implement

    Against the approved design, nothing more.

  2. 06

    Verify against the spec

    I check the code against the spec, line by line.

  3. 07

    Update the spec

    So it matches what was actually built.

  4. 08

    Test

    The full unit suite, manual API testing, and mutation testing where it matters.

Ship

  1. 09

    Release

    Merge and deploy.

  2. 10

    Hand over

    Brief the mobile and QA teams on exactly what changed.

AI-assisted

Where AI fits, and where it doesn't

  • AI drafts, I decide

    AI drafts specs and code fast. I own the decisions, the verification and the result.

  • The spec is the contract

    Claude works against an approved spec. Without one, it produces plausible code for the wrong problem, fast.

  • My name is on it

    When something is wrong, it's my responsibility, not the tool's.

Debugging production

How I find the root cause

Five steps that came out of real incidents. Where there's a case study, it's linked.
  1. 01

    Reproduce it first

    Reproduce the bug, or find it in the logs, before touching code.

  2. 02

    Prove the hypothesis

    Form a theory and prove it. For example, a Playwright script that makes two requests race on purpose.

    Proving a race condition with Playwright
  3. 03

    Find the root cause

    Not the nearest symptom. "The job stopped" became "a blocking gateway call with no timeout".

    The payment batch that stopped at 10 of 42
  4. 04

    Fix narrowly, test, look around

    Fix it narrowly, add a test that would have caught it, and check what else has the same pattern.

    The feature that had never worked
  5. 05

    Explain it plainly

    Tell the team what happened and why, in plain words.

With other people

Owning a module means owning the handoffs

  • I triage defects to the right owner: backend, frontend, mobile or data.
  • I train QA on what I build and walk mobile teams through API contracts.
  • I give short, impact-first updates to managers and business teams.

Toolbox

  • Claude Code
  • xUnit
  • Mutation testing
  • Playwright
  • Swagger
  • Postman
  • Serilog
  • GitHub Actions