Krish GeraProduct Designer Contact

krishgera0904@gmail.com

06 Stages

Method / AI

A multiplier, not an authority.

AI is part of how I engineer, from reading an unfamiliar repository to reviewing a release. The tools change often. The method changes much less: AI widens what I can investigate and build, and every conclusion still has to survive verification.

How I work AI in engineering

Stage by stage: what AI does, what stays with me, and how the result is checked.

  1. Repository understanding

    AI

    Map an unfamiliar codebase: entry points, data flow, where a behaviour is decided, which tests already cover it.

    Stays with me

    Decide which of those explanations to trust, and read the code that matters myself.

    Check

    Every claim about the code is traced to a file and line before it informs a decision.

  2. Planning

    AI

    Draft approaches, list affected surfaces, and surface questions I have not asked yet.

    Stays with me

    Scope, sequencing, and what deliberately stays out of the change.

    Check

    The plan names its assumptions, so each can be confirmed or broken early.

  3. Investigation & debugging

    AI

    Generate hypotheses, narrow reproductions, and read logs and traces faster than I can alone.

    Stays with me

    Choose which hypothesis to test, and when the evidence is sufficient.

    Check

    A cause is accepted only when a reproduction fails before the change and passes after it.

  4. Implementation

    AI

    Write and refactor code within the constraints I set, including repetitive and mechanical work.

    Stays with me

    Architecture, interfaces, and anything irreversible.

    Check

    I read every change as if a colleague wrote it: diff review, not trust.

  5. Test design & validation

    AI

    Propose cases, especially the unpleasant ones: missing data, permissions, concurrency, rollback.

    Stays with me

    Whether the tests exercise the real path or merely the mock.

    Check

    Where it matters, tests run against real dependencies, more than once, and are seen failing before the fix.

  6. Review & release

    AI

    A second reader for diffs, migrations, and release notes; a checklist that does not get tired.

    Stays with me

    Accountability for what ships, and for what happens after.

    Check

    Implementation success and release success are separate questions, checked separately.

Delivered capability AI in products

Judged by the system, not the model.

When AI is part of a product, the engineering questions widen: model behaviour, evaluation, latency, cost, failure modes, and what happens when the model is wrong.

Product AI work appears here once it can be documented publicly with evidence, the same standard as every other record.

Evidence first What the method protects

  1. Understand the existing system before changing it.

    Find where the behaviour is actually decided, then change it there.

    Seen in GROWIPeaceful Sevastopol

  2. The right small change can move the whole system.

    Leverage comes from placement, not from the size of the diff.

    Seen in Peaceful Sevastopol

  3. Good engineering includes knowing what not to change.

    Scope is a decision. What stays untouched is part of the design.

    Seen in Peaceful Sevastopol

  4. A fix is only correct if the rest of the system agrees.

    Clients, translations, and security properties depend on behaviour a single route cannot see.

    Seen in GROWI

  5. Prefer evidence over confidence.

    Tests that exercise the real path, run more than once, beat an argument that the change is right.

    Seen in GROWI

  6. Keep changes small enough to review honestly.

    Split the work so each review can be about the behaviour, not the size of the diff.

    Seen in GROWI

The engineering stories show the method in practice, including where review changed the answer.

Engineering stories