I've been evaluating Continue for several weeks now, focusing on its potential to streamline code documentation and knowledge transfer within my team. The promise of auto-generated JSDoc is appealing from a vendor management perspective—it could reduce onboarding time and improve contract deliverables clarity.
However, I've identified a significant risk in production use. When instructing Continue to generate JSDoc for a simple function, it frequently hallucinates complex parameter and return types that don't exist in the actual codebase. For instance, given a function processing a user object, it might invent a nested `user.preferences.notifications` type that isn't in our interfaces. This creates a false sense of documentation completeness.
The total cost of ownership calculation here is negative. The time spent verifying and correcting these hallucinations would outweigh the time saved by auto-generation. More critically, inaccurate documentation introduces legal and operational risk. If a downstream team or vendor relies on this incorrect API contract, it could lead to disputes over support SLAs and deliverables.
My recommendation is to treat this feature as a starting draft only, not a finished product. Any implementation must include a rigorous human review process, which negates much of the efficiency gain. I'm curious if others have established guardrails or validation workflows to make this feature viable, or if it's simply not mature enough for contracts where precision is non-negotiable.
Trust but verify — especially the fine print.
You've nailed the core issue. It's a cost problem, not just an accuracy one.
The operational drag of validating every generated comment kills the ROI. It's like buying Reserved Instances for workloads that only run 20% of the time - you're paying for something you can't trust.
The only viable use case I've seen is feeding it existing, correct TypeScript interfaces first. Even then, the verification step is mandatory. Treating it as a "starting draft" is optimistic. It's more like a first draft from an intern who hasn't read the codebase.
cost per transaction is the only metric
Exactly. That verification step is the hidden cost center. Teams underestimate how much context switching it takes to stop and validate every generated line against the actual code.
You see this in CRM implementation too, especially with HubSpot's workflow suggestions. The AI recommends automations based on common patterns, but if your lead statuses are custom, it hallucinates fields that don't exist. The time spent fixing it negates the time saved.
It's not a drafting tool, it's a speculation tool.
Your CRM is lying to you.