Claude Code now writes roughly two-thirds of the AI-assisted production code shipped at Datadog, the US-listed observability company whose engineers use it for jobs ranging from small bug fixes to full system rebuilds. The team has used Claude Code to replace MongoDB with Postgres, rebuild a metrics control plane, and stand up new ingestion pipelines from scratch. That's a big claim for any engineering leader to sit with, and the story behind how Datadog got there is worth reading closely if your Sydney or Melbourne team is working out how much autonomy to hand an AI coding agent, and when to pull it back. The short version: the constraint was never how fast Claude Code could generate code. It was how quickly a human could trust what it produced.
Building a machine tool for agents
Datadog's VP of engineering, Sesh Nalla, describes the shift in blunt terms. Engineers are no longer writing code line by line, they're shaping the work an agent does: deciding what it can see, what tools it has access to, and how success gets measured. As Claude Code sessions run longer, sometimes for days at a stretch under Claude Managed Agents, the gap between what an agent can build and what a human can verify by hand keeps widening. That gap is the real governance problem. It has nothing to do with whether the agent is capable. It has everything to do with whether the output can be checked before it reaches customers.
Datadog's answer was to build what Nalla calls a "machine tool": a small, verified kernel that agents use to build everything else, in the same way a manufacturing jig produces consistent, inspectable parts instead of one-off pieces. The current version is called Temper. Getting there took three earlier attempts: a distributed queuing project, an evolutionary code-optimisation harness, and a Kafka-style streaming service. Each one taught the team something about where trust broke down. The pattern that kept repeating was never a failure to generate a working system. Claude Code could do that reliably. The failure mode was a human losing track of what had changed, why, and whether it was safe to ship. Building a fixed, well-understood core that every agent-built system has to pass through turned that open-ended trust problem into something a team could actually review.
Three questions worth asking before scaling up
For an Australian business considering handing more of its software backlog to Claude Code, the Datadog experience breaks down into a short checklist worth working through before adding a second or third agent to the pipeline.
What is the smallest, most inspectable unit of work your agent should produce, rather than one large, unreviewable change that's hard to unwind if something's wrong?
Where does verification actually happen, and who owns it? Datadog's lesson was that generation speed stopped being the constraint long before verification did.
Who signs off before something reaches production, and how much of that review can genuinely be automated versus still needs a person reading the diff?
The AU angle
A senior software engineer in Sydney or Melbourne now costs a business somewhere between $180,000 and $220,000 AUD a year once on-costs are included. Datadog's experience suggests the real return from Claude Code isn't just writing code faster, it's building the verification layer that lets a smaller team responsibly hand over larger, longer-running chunks of work. Businesses that skip that step tend to get fast output followed by a slow, expensive cleanup, which usually costs more in engineer hours than the agent ever saved.
Most Australian businesses don't need their own version of Temper. They need a much smaller equivalent: a written policy on what Claude Code can touch unattended, what gets automated review, and what a person checks before it ships. That's worth settling before adding more agents to a development pipeline, not after something's gone wrong in production. It doesn't need to be complicated. It needs to exist, be specific, and be something your team actually follows rather than a document that sits in a wiki nobody reads.
Where this starts
A useful first exercise for any Australian team scaling up Claude Code is to write down, in one page, the three or four categories of change Datadog identified: small targeted fixes, larger refactors, replacing whole components, and building new systems from scratch. Then agree, as a team, which of those categories your business is comfortable handing over unsupervised today, and which still need a person watching every step. That single page tends to surface more real risk, and more real opportunity, than any general AI policy document written in the abstract. It also gives you a starting point for the next conversation, which is usually about what tooling or review process needs to change to move a category from watched to unsupervised.
If your engineering team is already running Claude Code in production and you're not sure where the governance line should sit, that's exactly the conversation we have with Australian businesses most weeks. Automata AI helps Sydney and Melbourne teams turn this kind of one-page policy into something workable before it becomes an expensive lesson learned in production. Book a brainstorm session or head to our contact page to set up a time.
