How exactly do you apply AI in your work?
Short answer
I apply AI throughout the development lifecycle: shaping designs, scaffolding code, writing and maintaining tests, refactoring, debugging, and documenting, always with me validating and integrating the results.
Concrete examples
-
Requirements to design sketches
- I start from a user story or ticket and ask the agent to outline possible designs (APIs, data models, module boundaries).
- I then refine the design, constrain it to our architecture, and use that as the blueprint for implementation.
-
Scaffolding new features
- For a new endpoint, service, or component, I ask AI to generate an initial implementation aligned with our patterns (e.g. “controller → service → repository”, or “React component with hooks and tests”).
- I then enforce domain rules, performance constraints, and security checks manually and with tests.
-
Test-first or test-parallel development
- I either write tests first, or define them together with the feature.
- I use AI to generate additional edge-case tests and to update test suites when refactoring.
-
Refactoring and pay-down of tech debt
- I ask AI to perform local, well-bounded refactors (rename, extract, split modules, adopt a pattern) while I run tests and check diffs.
- For larger refactors, I do them in multiple small PRs, each supported by tests.
-
Debugging and incident response
- I paste logs, stack traces, and relevant code, and ask the agent to propose hypotheses and instrumented fixes.
- I choose the best approach, implement it, and then have the agent help create regression tests.
-
Documentation and knowledge sharing
- I use AI to turn implementation details into clear documentation, ADRs, or onboarding notes.
- This makes it easier for the rest of the team to understand and safely extend AI-touched areas later.
The common theme is that I use AI to speed up the mechanics of coding while I stay focused on domain understanding, architecture, and correctness.
Interview angle
- “Where has AI actually changed your output?” - be concrete and bounded: scaffolding a new service, generating edge-case tests, translating between languages or API styles, and orienting in an unfamiliar codebase. Claiming a blanket productivity multiplier is not credible.
- “Where do you deliberately not use it?” - architecture and data modelling, security-sensitive code, production debugging, and performance work. All four need context the model doesn’t have, and in debugging it produces confident, plausible, wrong hypotheses under time pressure.
- “What changed about your process, not just your speed?” - tests written first more often (they become the specification the generated code is reviewed against), smaller diffs because review is now the bottleneck, and asking for the approach before the implementation.
- “How do you handle the review burden?” - it grew. You read more code than you write, so review skill matters more than it did, and small reviewable changes matter more than fast large ones.