Full Stack Developer

Khalid.dev

How I Use AI as a Full Stack Developer (and Where I Don't)

Muhammad Khalid Chouhan 3 min read 2 views
How I Use AI as a Full Stack Developer (and Where I Don't)

I work on a fintech product where a small bug can mean a wrong balance or a failed payment. That changes how I think about AI tools. They are part of my workflow now, but I treat them like a fast junior teammate: useful, tireless, and never allowed to ship code without a review. Here is what that looks like in practice. Where AI helps me most Boilerplate and repetitive code. REST endpoints, form handling, Zod validation schemas, Redux slices. This is work I already know how to do, so AI saves typing time and I can check the result quickly. Understanding code I did not write. When I open an unfamiliar module, I ask AI to walk me through what it does. It gets me to a working mental model much faster than reading file by file. Debugging. I paste the error, the relevant code and what I expected to happen. Often the answer is a small thing I stared past for twenty minutes. It does not always find it, but it narrows the search. Learning domain concepts. Fintech has a vocabulary of its own: virtual IBANs, beneficiaries, reconciliation, KYB, settlement. AI is good at explaining these in plain language, with examples, at any hour. I still check anything important against official documentation. Tests, docs and pull request descriptions. This is where time quietly disappears. AI gives me a first draft and I fix it. Where I do not trust it In payments, "looks right" is not good enough. I never accept AI output blindly for: • authentication and authorization • money calculations, rounding and currency handling • anything that touches security or sensitive data • database migrations on live data AI can invent library functions that do not exist, use outdated APIs, or write code that works on the happy path and breaks on edge cases like duplicate webhooks, retries and race conditions. In a payments system, those edge cases are the whole job. My rules

  1. No secrets or customer data in prompts. No API keys, tokens, ID numbers, account numbers or real transaction data. I use fake data instead.
  2. Read every line before it goes in. If I cannot explain it, it does not get committed.
  3. Small tasks, clear context. "Write a Zod schema for this payload" works far better than "build the transfer module."
  4. Tests for anything generated that has logic. The test is my proof, not the model's confidence.
  5. AI suggests, I decide. AI inside the product AI is not only a tool for writing code. It is becoming a feature. Think of a chatbot on WhatsApp that answers "what is my balance?" or "send me last month's statement." The pattern I find safest is simple: the model understands what the user wants, then calls well-defined backend functions that check identity, permissions and limits. The model never moves money itself. Sensitive actions still need explicit confirmation and proper authentication. That split, AI for understanding and deterministic code for execution, is a good rule for any system where mistakes are expensive. What I have learned AI makes me faster, but it also raises the value of fundamentals. To judge its output you need to understand HTTP, databases, authentication and how systems fail. The developers who gain the most from AI are the ones who could have written the code themselves, just more slowly. I am still learning how to use these tools well, and the best practices will keep changing. For now my approach is simple: let AI take the repetitive work, and keep the decisions and the responsibility for myself.