How I Actually Use AI in My Development Workflow

A lot of the discussion around AI and software development is still stuck at two extremes: "it writes all my code now" or "it's a fancy autocomplete." Neither matches my day-to-day experience. After a couple of years of using AI tools as a working part of a full-stack engineering practice — not a novelty, a daily tool — here's where it actually earns its place.

Scaffolding, not architecture

The highest-leverage use I've found is API and service scaffolding. When I'm standing up a new Spring Boot controller, a set of DTOs, or a Next.js route handler, I already know the shape I want — the tedious part is typing it all out consistently. Describing the contract and letting the model generate the boilerplate, then reviewing and adjusting, is reliably faster than writing it by hand.

What it's not good at, unsupervised, is deciding the architecture in the first place. Decisions like where a bounded context ends, whether something belongs in a Lambda or a long-running service, how aggressively to denormalize a schema — those still require judgment shaped by the constraints of the system you're actually building. AI is excellent at implementing a decision quickly. It is not a substitute for making the decision.

Security review as a second pass

One habit that's paid off consistently: after a feature is functionally complete, running it back through an AI-assisted security review before it goes to a human reviewer. It's very good at catching the boring-but-dangerous stuff — unvalidated input reaching a query, a missing authorization check on an endpoint, a secret that shouldn't be logged. It won't replace a real security review, but it catches a meaningful fraction of issues before they ever reach a PR, which means the human reviewer spends their attention on the things that actually require judgment.

Test coverage, with a caveat

Generating test coverage for existing code is another strong use case — especially for the unglamorous work of covering edge cases in legacy code that predates good test hygiene. The caveat: AI-generated tests have a tendency to assert on the code's current behavior rather than its intended behavior. If a function has a subtle bug, a generated test will happily codify that bug as "correct." I always read generated tests as if I wrote them myself, because eventually I'm the one debugging why they pass.

Documentation that actually gets written

Technical documentation is the task most likely to get skipped under deadline pressure, and it's one of the areas where AI assistance has the highest ROI relative to effort. Turning a finished PR into a clear README section, an architecture decision record, or onboarding notes for the next developer takes minutes instead of the hour it usually doesn't get budgeted.

Where I keep the human fully in the loop

• Architecture and system boundaries. The tradeoffs are contextual and long-lived; getting them wrong is expensive.
• Anything touching production data migrations. I want a human reasoning through every step of an irreversible operation.
• Final code review. AI-assisted first passes are useful, but a human still needs to own the decision to merge.

The pattern that's worked best for me isn't "let AI write the code" or "use AI for nothing important." It's giving it the well-defined, high-volume, low-ambiguity work — scaffolding, first-pass review, test generation, documentation — and keeping the ambiguous, high-consequence decisions with the engineer who has full context on the system. That division of labor is what's actually changed how fast a small team can move.