Skip to content
Mahesh Kadambala

How I Engineer with AI

I use AI heavily and deliberately — as an engineering accelerator, not a substitute for engineering thinking. This page is the actual workflow, from business problem to production: where AI is in the loop, where it deliberately isn't, and who is responsible at every step. (Spoiler: me.)

The workflow

  1. Understand the business problem

    No AI — deliberately

    No AI here on purpose. Requirements, stakeholders, constraints, and success metrics come from people and context — asking AI before understanding the problem just produces confident answers to the wrong question.

    • Gather requirements from the people who feel the pain
    • Identify stakeholders and what each one calls 'done'
    • Clarify constraints: compliance, tenancy, budget, deadlines
    • Define success metrics before proposing solutions

  2. System thinking

    No AI — deliberately

    The design is mine. I break the problem into domains, sketch the architecture, and choose the trade-offs — because owning the trade-offs is the job.

    • Break the problem into domains and boundaries
    • Design the architecture and data flow
    • Define APIs and contracts
    • Identify edge cases and failure scenarios
    • Choose trade-offs explicitly, in writing

  3. AI-assisted research

    AI assists

    AI compresses days of reading into hours. I use it to map the option space fast — then verify anything that matters against primary sources and my own benchmarks.

    • Explore approaches and compare architectures
    • Learn unfamiliar technologies quickly
    • Research best practices and known failure modes
    • Validate assumptions before they harden into design
    • Discover performance techniques worth measuring

  4. AI pair programming

    AI as pair

    AI is my pair for generation, refactoring, tests, SQL optimization, debugging, and documentation. I never accept a suggestion blindly: every one is reviewed for correctness, maintainability, performance, security, scalability, and fit to the business requirement.

    • Code generation for well-specified transformations
    • Refactoring with the invariants stated up front
    • Unit test generation and integration test ideas
    • SQL optimization and debugging sessions
    • Naming, documentation, and API ergonomics

  5. Architecture validation

    AI as pair

    I use AI to attack my designs before production does. It's a tireless reviewer with no ego — and its occasional confident nonsense is itself a test of whether I understand my own design.

    • Is this API future-proof, or just current-shaped?
    • New service or new module? Event or REST call?
    • Caching strategy and invalidation story
    • Multi-tenancy and isolation guarantees
    • Failure scenarios: what breaks first under load?

  6. Development

    AI assists

    AI accelerates implementation. I remain responsible for the business logic, the final design, code quality, testing, and production readiness — responsibility doesn't delegate.

    • AI drafts, I decide what ships
    • Anything touching money, auth, or tenancy gets human-written or line-by-line review
    • Codebase conventions are written down so the AI follows them too

  7. Quality engineering

    AI assists

    A second review pass with different eyes: AI is good at breadth — scanning for the categories of problems humans get tired of looking for.

    • Code review and security analysis
    • Performance analysis and N+1 detection
    • Dead code and duplicate logic detection
    • Technical debt and accessibility review
    • Documentation accuracy review

  8. Learning

    AI assists

    A patient tutor for going deep: Spring internals, React Server Components, Kubernetes, distributed systems theory. I test what I learn by building — references beat summaries.

    • Deep dives on Spring Boot, React, TypeScript, Kubernetes, AWS
    • System design and distributed systems study
    • Learning by building runnable references, not reading alone

  9. Content creation

    AI assists

    AI helps me edit and structure blogs, LinkedIn posts, and documentation. The experiences, opinions, and mistakes are mine — that's the part worth reading.

    • Technical blogs and architecture articles
    • Engineering documentation and design decision records
    • LinkedIn posts distilled from real production lessons

  10. Continuous improvement

    AI assists

    After every project: what went well, what failed, what could be automated, what should be documented, what should become reusable. Several answers became the open-source projects on this site.

    • Retrospect honestly, in writing
    • Extract reusable modules from repeated patterns
    • Turn hard-won lessons into published references

AI doesn't replace engineering

The rules that keep the leverage pointed in the right direction.

Judgment stays essential

AI accelerates development; it does not decide what should be built, what correct means, or which trade-off the business can afford. Those calls remain mine.

Understand before you ask

AI answers the question you ask, not the question you should have asked. Problem understanding comes first, always.

Verify everything

Every AI suggestion is reviewed like a PR from a brilliant engineer who has never seen production: skip the syntax, interrogate the transaction boundaries, retries, and tenant scopes.

Readability over cleverness

Generated or hand-written, code is read far more often than written. If the next engineer can't follow it, it isn't done.

Design for evolution

AI makes producing code cheap; that raises, not lowers, the value of architecture that can absorb change without rewrites.

Automate repetition, not thinking

Migrations, scaffolding, boilerplate — delegate freely. Invariants, failure modes, and design decisions — never.

Real examples

Not hypotheticals — work from the projects on this site, with the division of labor spelled out.

Refactoring a legacy filtering API

Problem
Four services had grown four slightly different ad-hoc filtering implementations — inconsistent pagination, injection-prone string building, and tenant scoping by convention.
My approach
I designed the target: one query DSL parsed to an AST, compiled to parameterized queries, with field whitelisting and mandatory tenant scoping. Then I treated the migration as a well-specified transformation.
How AI contributed
AI generated the mechanical migration of dozens of endpoints to the new DSL, drafted the parser test suite against my grammar spec, and caught two inconsistencies between services that humans had normalized.
Engineering decision
I wrote the parser and compiler by hand — they are the security boundary — and delegated the endpoint migrations and test scaffolding.
Outcome
All services on one safe-by-construction search path; the library was extracted as the open-source Spring Search DSL project.
Lesson
Split work by risk, not by size: the 10% that is a security boundary gets human hands; the 90% that is mechanical gets automated and reviewed.

Designing the workflow microservice

Problem
Per-tenant approval chains were hard-coded; every new customer meant a deployment. We needed a configurable workflow engine and had to choose between adopting a BPMN engine and building a lightweight one.
My approach
I drafted both architectures, then used AI as a sparring partner: steelman Camunda, attack my state-machine design, enumerate the failure scenarios each handles badly.
How AI contributed
The AI-generated comparison surfaced operational costs of the BPMN route (cluster ops, upgrade coupling) and pushed hard on my design's weak spot — what happens when a side-effect hook fails mid-transition.
Engineering decision
Built the lightweight declarative engine, but added transactional transition persistence with outbox-published events — a direct result of the failure-scenario interrogation.
Outcome
New tenant workflows became configuration instead of deployments; the engine has run in production since 2024.
Lesson
AI is most valuable as a critic, not an oracle: ask it to break your design, not to choose your design.

Cutting endpoint latency ~60%

Problem
Key list endpoints were slow under production load; the team's instinct was to add Redis caching in front of everything.
My approach
Measure first. I pulled EXPLAIN ANALYZE plans with production-sized parameters and worked through them systematically before touching any cache.
How AI contributed
AI acted as a plan-reading pair: interpreting 'Rows Removed by Filter', proposing composite index column orders to match real query shapes, and flagging an N+1 hidden behind lazy loading that per-query metrics made invisible.
Engineering decision
Composite indexes matched to query shapes, hand-written projections for read paths, connection pool sized down — caching deferred until the queries were right.
Outcome
~60% latency reduction on the worst endpoints with no new infrastructure and no invalidation bugs to maintain.
Lesson
AI made the measurement loop faster, but the discipline — fix the query before hiding it behind a cache — is an engineering decision no tool makes for you.

Test suite for the outbox implementation

Problem
The transactional outbox reference needed tests that prove delivery guarantees under failure — crash between commit and publish, consumer redelivery, poison messages — not just happy paths.
My approach
I enumerated the failure invariants that had to hold (no lost events, duplicates ignored, poison messages quarantined), then had AI generate Testcontainers-based scenarios against that list.
How AI contributed
Generated the integration harness and dozens of failure-injection cases, including redelivery orderings I hadn't listed. Its first draft also 'passed' by testing too little — the happy-path bias was visible and instructive.
Engineering decision
Kept the invariant list and chaos script as the source of truth; every generated test had to map to a stated invariant or it was deleted.
Outcome
A test suite that demonstrably catches lost-event regressions; the chaos script became part of the public repo's demo.
Lesson
AI-generated tests are only as good as the invariants you state. Specify what must never happen, not just what should happen.

Security review of the query parser

Problem
The search DSL accepts untrusted input from every client — the highest-risk surface in the platform. Human review alone had already missed one subtle issue.
My approach
Adversarial pass: I asked AI to attack the parser as an injection surface — malformed tokens, unicode tricks, deeply nested expressions, field-whitelist bypasses — and turned every plausible attack into a test.
How AI contributed
Produced attack payload categories systematically, found a stack-depth issue with pathologically nested groups (a denial-of-service vector), and reviewed the fix.
Engineering decision
Added expression depth limits and input size caps at the lexer, before any parsing — rejecting hostile input as early and cheaply as possible.
Outcome
Hardened parser with an adversarial regression suite; zero injection or DoS incidents in production.
Lesson
AI is genuinely strong at adversarial breadth — it doesn't get bored generating attack case #47. Use that where untrusted input meets your code.

Documentation that stays true

Problem
Platform module documentation drifted from reality within months; nobody trusted it, so nobody read it, so nobody fixed it.
My approach
Made AI-assisted doc review part of the definition of done: after each significant change, AI drafts the doc update from the diff and flags statements the code no longer supports.
How AI contributed
Drafts architecture notes and API docs from actual code, and — more valuable — catches stale claims in existing docs that a human skims past.
Engineering decision
Humans approve every doc change; AI proposes. Docs describe why, not just what — the why is the part AI can't know unless I write it down.
Outcome
Onboarding time for new engineers dropped noticeably; docs became trustworthy enough to be the first place people look.
Lesson
The failure mode of documentation is staleness, and staleness detection is exactly the tireless-breadth work AI is good at.

The toolkit

AI Coding

Claude / Claude Code · ChatGPT · GitHub Copilot

Development

IntelliJ IDEA · VS Code · Git · Docker · Postman

Backend

Java · Spring Boot · PostgreSQL · Redis · Kafka

Frontend

React · Next.js · TypeScript · Tailwind CSS

DevOps

GitHub Actions · CI/CD · Kubernetes · AWS

The longer-form version of this thinking — including where AI quietly creates debt and the review discipline that prevents it — is in AI-Assisted Engineering Without Losing the Plot.