By Karl Lehnert, Director, DevProStudio
Published 30 July 2026 | Last reviewed 30 July 2026
Karl Lehnert is Director of DevProStudio, an Australian AI engineering studio focused on practical software delivery and business automation. This article reflects DevProStudio's operator approach; no client outcome is claimed.
AI can produce a plausible software change before the coffee machine has warmed up. Getting that change safely into production is still the hard bit.
That gap matters for Australian SMEs, from Sydney to regional operators. A coding agent can modify dozens of files and confidently explain its work. None of that proves the change matches the requirement, protects customer data or will survive Monday morning. Speed at the keyboard is not the same as delivery.
The data backs the tension. The 2025 Stack Overflow Developer Survey found 84% of respondents were using or planning to use AI tools in development, yet 46% distrusted the accuracy of AI output and only 33% trusted it. Google's summary of the 2025 DORA report says AI adoption among software professionals reached 90%; more than 80% reported productivity gains, while greater AI adoption was also associated with increased delivery instability.
The practical response is an evidence-driven path to production:
Acceptance contract → isolated change → tests and scans → human review → staged release → monitoring and rollback
1. Write the acceptance contract first
Before Claude Code, OpenAI Codex or a human developer touches the repository, describe what “done” means.
An acceptance contract should cover user-visible behaviour, failure cases, systems that may and must not change, and release evidence. For customer intake, include validation, duplicate handling, accessibility, audit events and the destination for submitted data.
Keep the change small enough to review. “Improve onboarding” is not a useful unit of work. “Add server-side validation for these four fields, with these error states and tests” is.
2. Constrain the agent's working area
A coding agent should receive only the repository, tools and credentials needed for the task.
Use a separate branch or isolated worktree. Block production credentials. Keep secrets in an approved secret store. If the agent can call MCP servers or other tools, allow-list operations and treat tool output as untrusted.
3. Demand a reviewable change
Large diffs hide mistakes. Ask the agent to separate mechanical changes, behavioural changes and dependency updates where practical. Require a short explanation of:
- what changed and why;
- assumptions made;
- tests added or changed;
- security or data-handling implications;
- migrations, configuration changes and rollback steps.
The explanation is a navigation aid, not proof. Review the diff, especially authentication, authorisation, billing, personal information, logging and dependencies.
4. Test behaviour, not just syntax
A green type-check is useful, but it does not show that the feature works.
Match tests to risk: unit tests for business rules, integration tests at boundaries, and a few end-to-end tests for critical journeys. Add a regression test for the failure that prompted the change. Run static analysis, dependency checks and secret scanning in CI.
The NIST Secure Software Development Framework is a sound baseline because it integrates security throughout the lifecycle. An SME does not need enterprise ceremony around every patch, but it does need repeatable evidence.
5. Put a human on the release decision
AI can prepare a pull request. Accountability cannot be delegated to the pull request.
Name the person who accepts the requirement, the person who reviews technical risk and the person authorised to release. In a small business, one person may fill more than one role; the roles should still be explicit.
Peer review and passing CI may suit a low-risk internal tool. Payments, identity, health information or customer records warrant specialist review and staged release. Review depth follows consequence, not the apparent simplicity of generated code.
6. Make rollback part of the feature
Use feature flags where they genuinely reduce release risk. Take backups before destructive migrations, test restore procedures, and define the signals that trigger rollback. Log the deployed version and configuration so the team can reconstruct what happened.
A production checklist should include monitoring for the behaviour that changed: error rate, latency, failed jobs, unusual access patterns or a business-specific measure such as abandoned submissions. “The deployment succeeded” only means the deployment command finished.
7. Protect Australian customer data
If the codebase, logs, test fixtures or connected tools contain personal information, privacy is an engineering constraint.
The Privacy Act 1988 and the OAIC's APP 11 guidance shape the obligations of covered entities. APP 11 requires reasonable steps to protect personal information and addresses destroying or de-identifying it when no longer needed. Teams should also plan for the OAIC's Notifiable Data Breaches scheme and use the Australian Government's AI Ethics Principles as a practical design reference.
In practice: use synthetic test data; remove personal information from prompts and logs; verify processing and retention; enforce least privilege; record material changes; and revoke temporary access. Check obligations for your situation. This is engineering guidance, not legal advice.
The cost test: price accepted changes, not tokens
Tool pricing is only one line in the delivery budget. Anthropic reports that Claude Code averages about USD $6 per developer per day and that 90% of users stay below USD $12, while warning that usage varies substantially by codebase and workflow; see its live cost guidance. OpenAI documents current Codex plan inclusion and credit usage on its pricing page.
For a useful comparison, calculate:
(tool and compute cost + review time + failed runs + CI/security + rework + support) ÷ accepted production changes
That measure exposes cheap-looking workflows that create expensive rework.
A common implementation pattern
This is a pattern, not a claimed client case study.
A small SaaS team starts with a scoped ticket and acceptance examples. The agent works in an isolated branch and opens a pull request. CI runs tests and scans. A human reviews the diff, then releases behind a feature flag. The team records whether it was accepted, reworked or rolled back.
Copyable acceptance-contract starter:
- Behaviour: Given [state], when [action], then [observable result].
- Boundaries: May change [components]; must not change [components/data].
- Evidence: Tests, scans and reviewer required.
- Release: Flag, monitoring signal, rollback trigger and owner.
If generated changes repeatedly fail at the same boundary—migrations, permissions or flaky tests—fix the delivery system and its context, not merely the next prompt.
At DevProStudio, this production path is the centre of AI-assisted software delivery. For a related architecture decision, see open weights versus closed APIs. The useful question is not “How much code did the agent write?” It is “What evidence lets us accept this change?”
FAQ
Is AI-generated code safe for production?
It can be, but origin is not evidence of safety. For example, a four-field validation change still needs boundary tests, a reviewed diff and a rollback path. Apply the same controls used for human-written code, with extra attention to agent permissions and confident but incorrect assumptions.
Which coding agent should an SME choose?
Choose against your repository, security constraints and delivery workflow. Run at least three small, representative tasks through shortlisted tools, then compare accepted changes, review effort, failure modes and total cost—not demo speed alone. Three tasks are a starting sample, not a benchmark.
Does every AI-assisted change need human review?
Production changes should have accountable human oversight. The depth can vary: a low-risk documentation edit needs less scrutiny than authentication, payments or personal-data handling. Automate checks, but keep release authority explicit.
How should we measure AI coding ROI?
Track lead time to an accepted change, review time, rework, escaped defects, tool and compute cost, and operational support. Compare a stable baseline over several similar tasks; token counts and generated lines of code are weak business measures.
If you want a delivery workflow built around reviewable changes, reliable tests and controlled releases, talk to DevProStudio. We can help turn coding-agent speed into software your business can responsibly operate.