Taking an AI prototype built with Claude or Claude Code to production means hardening it: an evaluation set that measures accuracy, structured outputs your code can trust, a human review step for anything that matters, observability on every model call, and a staged rollout. With a focused team, a single AI feature can usually move from demo to controlled production in about 30 days.
Key takeaways
- A working demo proves the idea. Most of the remaining work is edge cases, cost control, security and testing.
- Build evaluations before changing production code, so every prompt or model change is measured.
- Force structured outputs (JSON schemas) instead of parsing free text.
- Design for failure: a person reviews, edits or rejects AI output before it reaches a customer or system of record.
- Trace every model call and tool step so you can explain and fix wrong answers.
Why do AI prototypes stall before production?
Most AI projects start with a promising demo. Someone writes a prompt, adds context in Claude or another model, or builds a quick app with an AI coding tool such as Claude Code, and the result looks remarkable. It feels nearly finished.
It usually is not. Between demo and production sit:
- Edge cases: empty inputs, oversized documents, unexpected formats, languages and scanned images.
- Cost and rate limits: what happens at a hundred times the demo volume.
- Latency: acceptable response times under real load.
- Security and privacy: prompt injection, access control, and personal information handling under the Privacy Act 1988.
- Regression: knowing that a prompt change did not quietly break something else.
- Ownership: who monitors and fixes it after launch.
For prototypes built with AI coding tools specifically, see our guide on taking AI-coded prototypes to production.
What does a production hardening process involve?
We apply a four-part hardening process to AI features before they go live.
- 1. Evaluations firstA test set of real examples with expected outputs, run on every change
- 2. Human reviewAccept, edit or reject states before output takes effect
- 3. Structured outputsJSON schemas validated in code
- 4. ObservabilityEvery call and tool step traced and logged
1. Evaluations first, code second
Before touching production code, build an evaluation set: 50 or more representative inputs with the outputs you expect, including the awkward cases. Tools such as Promptfoo, or your own test harness, run prompts against the set and score the results.
Run evaluations on every prompt change, model version change and code change that touches the AI path. When the model provider releases a new version, the evaluation set tells you in minutes whether to switch. Our AI model selection guide explains how the same test set drives model choice.
2. Human review by design
AI is probabilistic, so design the interface assuming it will sometimes be wrong. Instead of applying AI output automatically, show a review state where a person can accept, edit or reject it.
This builds trust, catches errors before they reach customers, and creates labelled data showing where the model struggles. Over time, low-risk outputs that are consistently accepted can move to lighter review, based on evidence.
3. Structured outputs
Never parse free text if you can avoid it. Ask the model for output that matches a JSON schema, use the provider's structured output or tool-calling features where available, and validate the result in code. Reject and retry anything that does not match.
This stops conversational filler breaking downstream code and makes outputs testable field by field.
4. Observability
You cannot fix what you cannot see. Trace every model call, prompt version, retrieved document and tool step, along with latency, cost and the human decision that followed. Tools such as LangSmith, Langfuse or OpenTelemetry-based tracing make this practical.
When an agent takes a wrong turn, the trace shows exactly where, and gives you the example to add to the evaluation set. Keep logs where your data rules require, often in Australia, because traces contain the same sensitive data as the inputs.
What else must be in place before go-live?
| Prototype | Production-ready | Impact | |
|---|---|---|---|
| Accuracy | Looks right on a few examples | Measured against an evaluation set on every change | Evidence |
| Output format | Free text | Validated JSON schema | Reliable |
| Errors | Unhandled | Retries, fallbacks and clear user messages | Resilient |
| Cost | Unknown at scale | Budgets, caching and per-request limits | Controlled |
| Security | Open prompts | Input checks, least-privilege tool access, prompt injection tests | Hardened |
| Data handling | Wherever the API runs | Hosting and logging that match data rules | Compliant |
| Oversight | None | Human review and full tracing | Accountable |
Data residency and privacy. If the feature handles personal or confidential information, decide where the model runs: an Australian cloud region under your own account, or your own servers. Check that logs and traces follow the same rule. Our AI data sovereignty guide covers the options.
Access control. Give AI agents the minimum permissions they need, read-only by default, and require human approval before writing to systems of record. See AI agent governance and human override.
Fallbacks. Decide what happens when the model API is slow or down: queue, degrade gracefully or hand to a person.
What does a 30-day path to production look like?
- Week 1Evaluation setupBuild the test set, measure baseline accuracy, agree the accuracy bar for go-live
- Week 2HardeningStructured outputs, error handling, rate and cost limits, security review
- Week 3IntegrationHuman review interface, tracing, staging tests with real data
- Week 4Staged rolloutRun alongside the existing process, then release to a small group, monitor and widen
Thirty days assumes one well-scoped feature, available data and a decision-maker who can approve quickly. Integrations with legacy systems or strict security reviews add time, so plan for them up front.
How do you keep an AI feature healthy after launch?
- Re-run evaluations whenever prompts, models or data sources change.
- Review traces weekly for failures and add them to the evaluation set.
- Track acceptance rates in the human review step. Falling rates signal drift.
- Watch cost per request as volume grows.
- Name an owner responsible for the feature in production.
Our guide to operating AI agents in production covers ongoing operations in depth.
How Solve8 can help
Our engineers harden AI prototypes into production systems through our custom AI development service, running on your infrastructure in Australia with a person approving before anything reaches a customer or system of record. Once live, our managed AI services keep evaluations, monitoring and updates running. Talk to us about your prototype.
