Observations
Australian organisations tend to follow a predictable path when it comes to AI coding tools. It starts with a developer quietly adopting an AI tool, often using a personal licence on a work device.
Development productivity jumps for narrowly scoped vibe projects, word spreads, and leadership greenlights a wider rollout. A short acceptable use policy is tacked onto the developer standards and sent out by email. Adoption accelerates. Within a few months, a security review or code audit uncovers exactly the risks the policy was meant to prevent: proprietary code sent to public AI models, AI-generated code in production without proper review, and agentic tools running with permissions no one signed off on.
The post-mortem is always the same. The policy was there, but the mechanisms to enforce it were missing. Paper policies do not govern technology.
An acceptable use policy tells developers what is expected. It does not create the conditions for them to meet those expectations. The gap between policy and practice is where AI coding governance stands or falls.
Effective modern coding governance is built on four pillars that will largely be AI:
- Code Classification: Every codebase must be categorised by sensitivity. At a minimum, use a three-tier model: public or internal tools, sensitive or business-critical systems, and regulated or security-restricted code. Each tier must have explicit rules for which AI tools are permitted. If classification exists only in a document and not in the tooling, it is not governance. It is just guidance.
- CI/CD Pipeline Integration: Automated gates must check that AI coding governance requirements are met before code is merged or deployed. At a baseline, this means secret detection and static analysis on every pull request with AI-assisted code. Mature organisations go further: they detect when AI generates an unusually high proportion of new code without matching test coverage and flag these for human review. Automation is the only way to scale governance.
- Human-in-the-Loop Policy: Set explicit rules for when human review is mandatory, who must conduct it, and which criteria apply. Oversight must be proportional to code risk. A junior developer’s AI-assisted tweak to an internal analytics tool does not need the same scrutiny as an AI-generated change to a payment system. Blanket review policies are a mistake. They create compliance fatigue and encourage workarounds. Focus review where it matters.
- Governance Committee: This group must own the AI coding policy, the tool approval list, the code classification scheme, and the CI/CD controls. Three things are non-negotiable: technical literacy about AI coding tools and their risks, a review cadence that matches the pace of tool change (quarterly, not annually), and the authority to withdraw tool approvals when risk emerges. If your committee reviews AI coding tools once a year, it is not governing. It is archiving.
Some argue that detailed governance slows development. This is true in the short term, but false at the programme level. IBRS observes that organisations that rush into AI coding with minimal governance are not, overall, faster. They produce code quickly, but maintenance, security, and compliance slow them down later. The cost of governance is paid up front. The cost of skipping it is paid with interest.
Australian policy is clear. The Australian Signal Directorate’s (ASD’s) DevSecOps guidance, the Digital Transformation Agency’s (DTA’s) AI in Government policy, and new AI-specific obligations under the Protective Security Policy Framework all point the same way. For Commonwealth agencies, governing AI developer tools is not optional. The real question is not whether to govern AI-assisted development. It is whether to do it well from the start, or pay for remediation later.
Next Steps
- Establish a formal code classification scheme for your development environment. Use at least three tiers based on data sensitivity and system criticality. Document which AI tool categories are approved for each tier before expanding AI coding beyond early adopters.
- Implement CI/CD pipeline gates to enforce baseline security for AI-assisted code. This includes secret detection, static analysis, and anomaly flagging for pull requests with high AI contribution and no matching test coverage.
- Define your human-in-the-loop policy explicitly. Make review requirements proportional to code risk, not a blanket rule. Configure tooling to enforce the policy, not just document it.
- Establish an AI coding governance committee with a quarterly review cadence. Give it clear ownership of the tool approval list and the authority to restrict or revoke approvals when risk emerges.
- Review the ASD’s DevSecOps guidance and the DTA’s AI in Government policy as your baseline for governance. This is especially important for organisations with Commonwealth or regulated industry obligations.
