Last week I opened my Wakapi dashboard out of curiosity and noticed something I hadn't paid attention to before: out of roughly 17 hours of tracked coding over the past month, more than 16 of them were logged under an "AI Coding" category. Most of that time was spent in TSX and TypeScript, rebuilding my personal portfolio and pushing PromptoShare, a React/Next.js/Node app for sharing prompts, closer to done. That number surprised me enough to actually think about how I was using these tools, instead of just using them. Two very different projects, two very different uses On the frontend side — my portfolio rewrite and PromptoShare — AI assistance is mostly about speed on things that are mechanically repetitive but still need my judgment: scaffolding a new TSX component, wiring up prop types that match a MongoDB schema, generating a first draft of a Tailwind layout I then tear apart and rebuild to match what I actually want. It's fast, but it's rarely "done" on the first pass. On the backend side, my biggest project by far is FinancialEvents, a Java/Spring Boot system I've been building for over a year (1,200+ commits). There, I lean on AI assistance much less for architecture and much more for the boring-but-necessary parts: DTOs, repository boilerplate, test fixtures for edge cases in event processing. The actual business logic — how financial events get validated, transformed, and reconciled — is something I still design and write by hand, because that's exactly where a plausible-looking but subtly wrong suggestion is most dangerous. What actually changed in my workflow A few habits stuck once I paid attention to them: 1. I write the spec or the test first, even a rough one. Letting an assistant guess at intent from scratch produces code that compiles but doesn't fit. Giving it a shape to fill in produces something closer to useful. 2. Every suggestion gets read, not skimmed. The failure mode isn't obviously broken code — it's code that looks right, passes a quick glance, and hides a wrong assumption about a null case or an off-by-one in pagination. 3. I reserve AI help for the layers I can verify quickly. UI components and data-shape boilerplate are easy to eyeball. Business rules in a financial system are not, so that's where I slow down deliberately. The honest takeaway The tools didn't make me code less — they changed 'what kind' of coding I spend my time on. Less time typing repetitive TSX or Spring Boot boilerplate, more time thinking about whether the component structure or the event-processing logic actually makes sense. That's a trade I'll keep making, but the Wakapi numbers were a useful reminder to stay deliberate about where I let the assistant lead and where I keep both hands on the wheel. If you're building something similar — a full-stack app where the frontend moves fast and the backend needs to be provably correct — I'd genuinely be curious how you draw that same line.