How I use AI coding tools
A short, honest account of where these tools sit in my workflow — what I hand them, what I keep for myself, and one thing they kept getting wrong.
The project
Over summer 2026 I was one of two engineering interns on a full-stack product team at IndeVets, building a veterinarian-only community platform — a Reddit-style app for a professional audience. I owned the entire frontend: a cross-platform mobile client in React Native, Expo, and TypeScript, taken from nothing to a functional MVP in five weeks.
That meant building the core of the app end to end — home feed, post composer, threaded case discussions, a moderation queue, inbox, and user profiles — on a component-based design system, with Redux Toolkit for state and React Hook Form plus Zod for validation. The frontend talked to a teammate's REST backend (Express, Prisma, PostgreSQL), so a lot of the work was coordinating a shared Firebase authentication flow and matching validation schemas across two repositories. Everything shipped through feature branches, pull request review, and weekly releases.
Where the tools fit, and where they don't
Day to day I work with Claude Code and Gemini, through both their command-line tools and their editor extensions in VS Code, plus the browser when I'm sketching something out.
What I hand them: syntax checks, project-structure brainstorming, routine git and file housekeeping, and modeling — turning a rough idea or a Figma sketch into a concrete draft I can put in front of product engineers or the marketing team, so we're reacting to something real instead of a description.
What I don't hand them: the codebase itself. I wrote the feature code for this app. The model was an assistant, not the author, and I kept it there on purpose. If I let it write the code that ships, I lose the familiarity with the system that lets me catch it when it's confidently wrong — and on this project it was wrong often enough that that familiarity was the whole point.
The part it kept getting wrong
The clearest example was mockups. I'd give a model one of my Figma sketches and ask it to turn it into a working draft of a screen. It would come back looking roughly right and wrong in the details: buttons in colors that weren't anywhere in the company's palette, button sizes that didn't match the pixel values in the spec, and — more than once — logos belonging to entirely different companies dropped in where ours should have been.
None of that is a disaster on its own. It becomes one if it reaches a colleague, because then you're presenting some other company's brand as your team's work. I caught it because I already knew the design system and the codebase well enough to see the mismatches straight away — the colors were simply not ones we used, the proportions were off, the logo wasn't ours. So the fix was manual: I corrected the colors, resized the components to spec, and swapped the real assets back in by hand before the mockup went to anyone. The model got me to a draft faster; it did not get me to something I could show.
What I'd do differently
I'd generate more drafts, not fewer. The value was never in one output being correct — it was in having something concrete to hold up against a standard I already carried, and pick apart. The most useful thing I took from that internship was how much criticism is worth: those drafts were only useful because I could criticize them hard and specifically. Next time I'd lean into that and treat the model as a way to produce more things to react to, earlier.