AI-Augmented Development: A Solo Engineer's Workflow

If a developer tells you they're AI-augmented, ask to see their tests and their review steps before you ask about tools. The tool list tells you what they type into. The tests and review steps tell you what happens when the AI is wrong, and on a paid product that's the part you're buying.

I'm Dusko Licanin, an AI-augmented full-stack engineer. In practice, AI-augmented development means using AI tools to draft code, tests and refactors while a named human stays accountable for every decision, review and release. This post explains the idea, shows what my own project records support, and lists the checks I'd demand from any developer, including me. The studies and docs linked here were last checked on 30 September 2026.

What does AI-augmented development mean, and is it the same as vibe coding?

AI-augmented development keeps a human accountable for design, review and release while AI drafts the mechanical parts. Vibe coding, by contrast, means accepting generated code without reading or testing it.

The difference shows up at the first failure. When a human owns the result, a wrong answer from the model becomes a bug report. When nobody owns it, the same wrong answer ships. My own workflow sits on the accountable side, and the rest of this post is about what that looks like in records you can check.

Does AI make developers faster?

The evidence is mixed, and I have no controlled measurement of my own, so I won't quote a speed-up figure for my projects.

Read both with care. METR randomly assigned 246 issues, averaging about two hours each, to either allow or restrict AI use. It tested experienced developers working on large, mature repositories with early-2025 tools, which differs from a solo engineer building a new product. This suggests perceived speed and measured speed can diverge, and it's a reason to verify output instead of trusting the feeling of progress. The survey reports what developers think about productivity rather than measuring it. It also shows how early the agent stage still is: only 31% of respondents use or plan to use AI agents, and among those who do, 52.7% agree the tools improved their productivity. Those are self-reported views from one survey year, so treat them as a snapshot of sentiment, not a verdict on the tools.

What does the workflow look like on real projects?

The clearest evidence is the case studies, where the stack, scope and verification records are public. Here is what each one records, and nothing beyond it.

Callidus's own case study concludes that a solo developer with "AI-augmented tooling" can ship a multi-tenant SaaS in ten weeks. I'd read that as a claim about this one project, not a general rule.

What do these records not prove?

They don't prove that AI made the work faster or better. The timelines and test counts come from my own projects, there is no control group, and a solo build has no comparison against a team doing the same work. What the records do show is a verification trail: tests, versioned changes and selective merging. That trail is what lets a client or a second engineer check the work, which is why I lead with it instead of a speed claim.

How are AI-generated contributions handled?

BookBed's case study documents the process. Path-scoped code rules live in .claude/rules/, with per-directory guidance for calendar, widget, admin, auth, Stripe, Firestore, FCM and hosting code. AI-branch audits from Jules, Sentinel and Bolt were integrated selectively: real fixes were cherry-picked and regressions were rejected.

That last detail is the point. AI output arrived as proposals on separate branches, and a human decided what merged. Versioned changelogs across more than 66 entries give a record of what changed and when. If a developer can't show you an equivalent trail, the phrase "AI-augmented" has no evidence behind it.

Which decisions should stay with a human?

Anything close to money, data or identity deserves line-by-line human review, and that is my recommendation rather than a finding. A mistake in those areas is expensive or invisible until production.

Callidus shows why. The case study describes everything living under tenants/{tenantId} in Firestore, JWT claims carrying the tenant and role, and mutations gated by an archived-tenant guard in the security rules. During a billing grace period, writes are blocked at both the route and the rules layer, so there is no single-layer bypass. A loose rule in that design could let one clinic read another's data. The wider pattern is in multi-tenant SaaS architecture, and the compliance side is in SaaS security and compliance.

Which checks should you demand before trusting AI-written code?

Demand checks that run whether or not a human feels confident: automated tests against local emulators, verified payment webhooks, and a real production build. Each item below is a recommendation, tied to a primary source where one exists.

1. Security rules tested against an emulator. Firebase's documentation says its rules unit testing library "is always aware of the emulators and never touches your production resources", so you can test hostile access patterns safely.
2. Webhook signature verification. Stripe's webhook documentation says to verify every event with the Stripe-Signature header, and warns that without verification an attacker could send fake events to trigger actions such as fulfilling orders.
3. Duplicate and out-of-order events handled. The same Stripe page says endpoints can receive the same event more than once, and that Stripe doesn't guarantee delivery order. Log processed event IDs instead of trusting timestamps.
4. A real production build of the whole app. A snippet can pass in isolation and still fail when wired into the project.
5. A scope check against the client's goal. AI optimizes for the prompt. Someone has to ask whether the change does what the customer needs.

Consider a hypothetical webhook handler that an assistant drafts in a minute. It parses the payload, marks an order paid and returns 200. It reads well and passes a happy-path demo. It also skips signature verification and processes a duplicate delivery twice, which are the two failures the Stripe page warns about. No amount of reading for style finds that; a checklist and a test do.

Stack Overflow's finding that 66% of developers are frustrated by solutions that are "almost right, but not quite" is the argument for items 1 to 4. Plausible code that fails an edge case is exactly what tests catch. The money side of these checks is covered in SaaS billing and payments, and the review discipline for solo developers in AI code review and quality gates.

How should you evaluate an AI-augmented developer before hiring?

Ask for evidence of the process, not the tools: shipped products you can use, tests you can read, and a clear account of what the developer reviews by hand.

• How do you verify tenant isolation, and can I see the tests? A good answer names the rules or policies and how they are exercised, for example allowed and denied cases for each role run against an emulator before any change reaches production. If the answer is "I read them carefully", ask what would catch the mistake on a tired day.
• What happens to AI-generated changes before they merge? Look for branches, review and rejected changes, as in BookBed's record.
• Which parts of this project would you not hand to an AI? An answer of "none" is a warning.
• Can one person build this? The honest answer is sometimes no. A developer who says so is worth more than one who agrees to everything.

A practical test is to ask the developer to walk you through one merged change from end to end: the task, what the AI produced, what they changed by hand, and which test failed before it passed. Specifics are hard to improvise. A developer who has a real trail will usually reach for the commit history and the test output without being asked, and you can judge the answer even if you don't read code.

If you're not technical, ask a second engineer to sit in on that conversation for an hour. The cost is small next to shipping a payment flow nobody has questioned.

For the wider decision between agencies, freelancers and solo engineers, read hiring SaaS developers. On pricing, my work is project-based and quoted per project rather than hourly, and software development cost and pricing explains how to compare quotes. For my longer notes on the daily routine, see the AI-augmented development workflow.

Your next step: pick one product you're considering building, and write the three decisions in it that involve money, data or identity. Which of those would you want reviewed line by line before launch?