How AI Coding Assistants Actually Fit Into My Day-to-Day

I get asked some version of the same question a lot, from engineers on my team and, recently, from an HR audience of 30-plus people I ran a Copilot/GenAI workshop for: what do you actually dowith these tools, day to day, beyond autocomplete? The honest answer is that autocomplete is the least interesting part. The useful part is compressing the distance between "I know exactly what I want" and "it's written, tested, and ready for review" — and knowing precisely which parts of that distance you should let the tool cover, and which parts you shouldn't.

Different tools, different jobs

I keep four tools in rotation, and I've stopped trying to make one of them do everything: Cursor for in-editor, tight-loop changes where I want to see and adjust every diff as it happens; Claude Code for anything that starts with exploring a codebase I don't fully hold in my head yet, or that spans enough files that a chat-only tool would lose the thread; GitHub Copilot for the genuinely boilerplate stretches — test scaffolding, repetitive CRUD, the parts of a PR nobody wants to write by hand; and Google Antigravity when I want a second, differently-trained opinion on an approach before committing to it. None of them is "the best one." They're suited to different shapes of problem, and part of using them well is recognizing which shape you're looking at before you open one.

Migrations: where AI assistance earns its keep

The clearest win I've seen was the MMSD Portal's JavaScript-to-TypeScript migration. A large legacy codebase doesn't convert file by file in isolation — a function's real parameter types are usually only inferable from how it's actually called across the codebase, which a human reviewing one file at a time will miss constantly. An AI assistant that can hold a wider slice of the codebase in context catches those call-site patterns far more consistently than a tired engineer three hours into mechanical conversion work. The judgment calls — is this any actually acceptable here, does this shape deserve a proper discriminated union — still need a human. But the first-pass typing, and especially catching the edge cases a human skims past on file 40 of 200, is exactly where these tools are strongest.

The same pattern held building UMA as a greenfield app: Claude Code exploring the existing DSP component library and the Portal's established patterns before writing new code against them, so new work matched existing conventions instead of quietly drifting from them the way greenfield code inside an established org often does.

A first-pass reviewer, not a merge button

I run AI review on my own PRs before a human ever sees them — not as a substitute for human review, as a filter in front of it. The obvious stuff (an unhandled promise rejection, a missing null check, an inconsistency with a pattern used three files over) gets caught and fixed before it costs a teammate their attention. That leaves human review time for the things that actually need human judgment: is this the right abstraction, does this change belong here at all, is there a simpler design we're missing. It's the same principle behind Snyk Auto-Fix at a system level — automate the mechanical so the humans in the loop spend their attention on the parts that need it.

Prototyping speed, when speed is the actual point

Some work genuinely rewards moving fast over moving carefully, at least at first. The AI-powered chatbot I built with Microsoft Copilot Studio at an internal hackathon had to go from idea to a demoable prototype in a couple of days, and the GenAI property concierge I later built for a startup's platform had a similar early phase — the goal wasn't production-hardened code, it was "does the interaction actually feel useful," and that question is best answered by getting something in front of people quickly. AI-assisted scaffolding is exactly the right tool for that phase. It stops being the right tool the moment the prototype needs to become the real thing, and that transition is a decision I make deliberately rather than one that happens by accretion.

Where I don't let it drive

The guardrail I'm least willing to bend on: anything touching auth, payments, or production data migrations gets built with AI assistance and reviewed line by line by a human before it ships, full stop. Building a payments system on Razorpay with a serverless webhook listener on AWS Lambda is a good example — an AI assistant is genuinely useful for scaffolding the Lambda handler structure and the retry logic, and genuinely dangerous if left to reason unsupervised about idempotency guarantees or how a webhook replay should behave, because a subtle mistake there doesn't show up as a bug report, it shows up as a customer's money in the wrong place. The rule I use is simple: the more expensive a mistake is to discover after the fact, the less unsupervised AI output I'm willing to accept in that path, no matter how good the tool has been elsewhere that week.

Teaching this, not just doing it

Running the Copilot/GenAI workshop for MassMutual's HR organization — 30-plus use cases, for an audience that doesn't write code — forced me to make this thinking explicit rather than intuitive. Non-engineers adopting these tools hit the same failure mode engineers do, just faster and with less instinct for when to be suspicious of confident-sounding output: they either under-trust the tool and get none of the speed benefit, or over-trust it and ship something wrong with total confidence. The useful thing I could hand them wasn't a list of prompts. It was the same guardrail logic above, translated: know what "expensive to get wrong" looks like in your own work, and calibrate how much you verify accordingly.

The actual skill

The discipline that matters here isn't using AI tools a lot. It's knowing, before you start a task, which of these three modes you're in: exploration, where getting a wrong first draft fast is more valuable than getting it right immediately; mechanical execution, where the tool should do most of the work and you're mainly checking it stayed consistent; or high-stakes correctness, where the tool is a drafting aid and every line still gets read by a human before it's trusted. Most of the bad outcomes I've seen with AI coding assistants come from applying mode one's trust level to mode three's stakes — not from the tools being bad at what they do.