How I Use AI to Ship Code Without Cutting Corners

You're probably weighing one question: how much of your codebase can you hand to an AI assistant before the risk outweighs the speed? Start with a small first action. Pick the next feature on your list and write down its failure modes before you open any AI tool, because that list is what you'll review the output against.

This post is my working answer as an AI-augmented full-stack engineer. It covers what I let AI draft, what I keep in my own hands, and what the public evidence says about speed. For the broader picture, see the AI-augmented development guide, and for the review side in depth, AI code review quality gates for a solo developer.

What should AI write, and what should stay manual?

Let AI draft pattern-based code such as scaffolding, types, tests and one-off queries, and keep data isolation, payments, security paths and architecture decisions manual, because mistakes there look plausible and cost the most.

What AI drafts well

These tasks follow well-known patterns, and a wrong draft is cheap to spot in review:

• Boilerplate. Form handlers, CRUD endpoints, email templates and cron scaffolding.
• Type definitions. The shape of a database table, a webhook payload or an API response.
• Test structure. Describe blocks, mock setup and assertion skeletons. I write the assertions that check business rules myself.
• Documentation. README sections, inline comments and environment variable tables.
• One-off queries and scripts. A SQL query that lists records older than a cutoff, or a shell script that renames files. Both are easy to verify by running them on sample data.

What stays manual

Tenant data isolation. In a multi-tenant product, one customer must never see another customer's rows. Supabase's own documentation says a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that until you test policies you don't know whether they do what you intended. An AI model doesn't know your ownership model, so I write and test every policy myself. The same principle applies on Firebase with its own rules system. For the architecture side, see the multi-tenant SaaS architecture guide.

The same documentation gives two concrete testing and performance rules. Tests should cover allow and deny cases for select, insert, update and delete across both the anonymous and authenticated roles, and you should index every column a policy filters on, because an unindexed filter column turns a read into a sequential scan. Those are exactly the details a generic draft often misses, so they go on my review checklist.

Payments. Callidus routes patient deposits to each clinic's own Stripe account using Stripe Connect with Direct Charges, per the case study. Deciding who is the merchant of record is a legal and product decision, not a code-generation task.

Access rules. Callidus has six roles, and the codebase routes checks through shared helper functions so the matrix doesn't drift. A model can write one check. It can't know your whole matrix.

Architecture. Polling or webhooks? Trigger or application hook? An assistant will answer confidently. The right answer depends on load, budget and the next year of your roadmap, and that context lives with you.

Does AI-assisted coding actually make you faster?

The evidence is mixed and depends on context: METR measured experienced open-source developers taking 19 percent longer with AI in early 2025, while its 2026 update suspects larger speedups now. Measure your own work.

What the public data says

Read these carefully. The METR study covered 16 people working in repositories they already knew well, and METR itself says the result may not generalize. The survey measures adoption and attitude, not output. My inference is that speed depends on task type and on how much review you add. The gap between the 20 percent speedup developers felt and the 19 percent slowdown METR measured is the reason I treat my own impressions with suspicion.

What one of my own projects does and doesn't show

Callidus, a multi-tenant SaaS for UK aesthetic clinics, was built solo in roughly ten weeks between February and April 2026, according to its case study. That's one project with one builder, so treat it as context and not as a benchmark. It says nothing about how much of that time AI saved, and I won't claim a figure I didn't measure.

The DORA finding is the one I find most useful here. If AI amplifies what's already there, then a clear spec, tests and a review habit get amplified, and so do vague requirements and skipped reviews. That's my reading of the finding, not a direct quote from the report.

How I measure my own speed

I don't quote a multiplier, because I haven't run a controlled trial and won't pretend otherwise. What I do track is time from spec to a reviewed, merged change for the same kind of task, with and without an assistant. A scoped MVP with a clear spec benefits most, since there's less rework from wrong assumptions.

What does an AI-assisted development workflow look like in practice?

A reliable AI coding workflow has five steps: write the spec and failure modes first, generate a scaffold, write the business logic yourself, review every generated line, then test against real data.

1. Spec the feature. What must it do, how can it fail, what does the data model look like? Skipping this just makes the assistant produce the wrong thing faster.
2. Generate the scaffold. Middleware, migrations, handler structure. I read every line before it enters the codebase.
3. Write the product-specific logic by hand. Payment reconciliation, permission rules and sync logic are where your product is different from everyone else's.
4. Review like a pull request from a stranger. Look for wrong assumptions about data shape, missing error handling, security gaps and code that works but doesn't match the requirement. The quality gates post covers how to make this review repeatable.
5. Test against real data. Use real Stripe test events and real policies, not only mocks.

Example: where Pizzeria Bestek needs human decisions

Pizzeria Bestek runs on React and Supabase for a single restaurant. Per the case study, the owner confirms or declines orders from an email, three Supabase Edge Functions drive that flow, and the customer's email comes back in one of four languages. That's a good illustration of the split, and this is my recommendation rather than a record of how it was built: the functions' structure is pattern work an assistant can draft. The decline rules (what to suggest when pickup fails versus delivery), the delivery-zone check and the language branching are product decisions a person has to specify and test.

A review checklist for every generated change

Before anything merges, I ask five questions. Does the code assume a data shape that the real data doesn't have? What happens on the failure path, such as a timeout, a duplicate event or an empty result? Does it touch authentication, payments or tenant boundaries, in which case it gets a second, slower pass? Does it match the requirement or just compile? Could I explain this function to a client without opening the file?

If I can't answer the last one, I rewrite it until I can. A change I can't explain is a change I can't maintain, and maintenance is where the real cost of a codebase sits.

Why this matters when you hire

If you're evaluating a developer who uses AI, ask what the assistant writes, what they write, and whether they can explain every generated line. A developer who can't review their own AI output is carrying risk you'll pay for later. A practical test is to ask them to walk you through one recent generated change and to say what they rejected or rewrote in it. I work so that every change is something I can explain, defend and hand over.

Want to see how this would apply to your product? Start a chat, and bring one feature you'd like scoped, failure modes included.