AI Maturity in Development Teams: What Separates Teams That Deliver with AI from Teams That Just Use It

NAB's April 2026 research on Australian SME AI adoption found that 42% of businesses are already using AI, but most are relying on ChatGPT, Copilot, or AI features embedded in existing tools. This picture holds at the enterprise level too.

Adoption is not the problem. The problem is that using AI and genuinely changing how work gets done are two different things, and AI maturity in development teams is what determines which side of that gap you're on. SixPivot Founder and CEO Faith Rees sees this regularly, both with clients and within her own team.

The gap rarely announces itself. It tends to surface when someone who is operating at the sharper end of AI-assisted development starts working alongside someone who isn't. The difference in output, pace, and approach is immediate and hard to ignore.

Two members of SixPivot's delivery team share what this difference looks like from the inside.

How do delivery leaders assess AI maturity in their development teams?

Senior skills matter more, not less — Chris Gilbert, Principal Consultant

Chris recently returned to hands-on delivery after a period in a purely consulting and advisory capacity. The transition gave him an unusually clear view of the gap between how AI is perceived at the leadership level and how it actually operates on the tools.

The first thing he noticed was the structural change to how work moves. He now runs two or three workstreams in parallel, with one waiting on human review, one in active development, and one being scoped, cycling between them as each needs attention. It's a materially different operating model, and one that doesn't suit everyone.

"There's a balance between how far you can parallelise your work and still maintain throughput. There's no point having three things in progress if none of them gets completed."

What makes the parallel model work isn't a new skill set; it's the application of existing senior capability to a new context. Defining work precisely enough that an agent doesn't go off-track, reviewing output with enough system knowledge to catch what's wrong before it compounds, and knowing when to trust the result and when to pull it back.

"You still need to treat AI like an enthusiastic junior programmer, but a much more capable one than it was a year or two ago. It needs clear direction and proper oversight. If you don't give it enough detail, it can burn time and money very quickly doing something completely not what you had in mind."

For leaders assessing their team's AI maturity, Chris's experience points to something worth sitting with: the developers who struggle most with AI tooling are rarely the ones who write bad prompts. They're the ones who haven't yet developed a clear enough picture of the outcome or have enough system experience to recognise when a generated answer is wrong. That's a seniority problem, not a tooling problem.

On cost: as AI tooling moves from loss-leader pricing toward commercial rates — $400 to $1,000 per month per developer in some configurations — the return on this investment depends almost entirely on whether the people using it can exercise the judgment to make it worthwhile. In the right hands, AI tooling pays for itself. In the wrong hands, it doesn't.

What does high-performing AI-assisted development actually look like day to day?

When a developer becomes a delivery orchestrator — Gert Jansen van Rensburg, Senior Developer

Gert's shift has been less a transition and more a quiet redefinition of what the role involves. His throughput on his current project has become a visible outlier, enough that teammates have started asking what he's doing differently.

The answer is orchestration. Gert runs multiple agents simultaneously, structured so his attention is always required somewhere productive: reviewing one stream, initiating another, validating a third that ran while he was in standup. He describes it, without particular drama, as having become an unintentional team manager.

"I've got multiple agents doing things, and they need my attention for different reasons and at different times."

The workflow is built on tight planning discipline. Each story is interrogated before implementation begins: assumptions are surfaced, acceptance criteria are stress-tested, and ambiguities are resolved. When things break down, it's almost always traceable to the same root cause: something unclear in the story, a reference the agent couldn't access, or a context window that's accumulated enough contradictions to start working against itself.

"Normally when you write code, you're proud of it, and you attach to it. With AI, it's so quick to generate that if you make a mistake, you can throw it away and start again very quickly. This is a big mentality shift."

The validation layer is where Gert invests the time the generation saves. Code review, live application testing, and exploratory agent-driven QA: the agent clicks through the UI, confirms that what was built works end-to-end, and, in Gert's words, "figures out how to get there" without being told every step. In one overnight experiment, he handed a batch of stories to an agent and woke to find it had opened work trees for each branch, committed code, stacked pull requests, taken screenshots as evidence, and checked each story against its original acceptance criteria before he'd touched the keyboard.

For leaders, what Gert's workflow demonstrates is less about the tools than the operating model. The speed is real, but it holds together because the discipline around planning, review, and verification is in place. Remove this, and faster generation just produces faster errors.

Gert has written in depth about the mechanics of this approach: planning loops, subagent orchestration, and the review structure that keeps pace from becoming a liability.

→ Read Gert's full piece: How I Accidentally Became a Team Manager

Why isn't AI maturity spreading faster through development teams?

The NAB data suggests most organisations are still at the surface of what AI adoption can deliver. That's consistent with what SixPivot sees across its client base, and it points to a broader truth about AI maturity in development teams: the gap rarely closes on its own.

The pattern is predictable: some people go deep, develop new operating models, and become noticeably more productive. Others continue using AI for low-stakes tasks and don't substantially change how they work. The two groups can coexist on the same team for months without anyone naming the difference.

What closes the gap isn't mandating tool usage or running training sessions. It's proximity — putting people who are genuinely operating at a higher level of maturity alongside those who aren't, and creating the conditions where it's safe to discard work quickly, experiment, and rebuild.

The organisations moving fastest aren't the ones with the most sophisticated AI policies. They're the ones where that proximity is happening, deliberately or otherwise.

How do you move a development team from AI awareness to genuine AI capability?

This is the challenge SixPivot works through with clients - the distance between knowing what AI can do and having a team that's changed how it operates because of it. It's the same question at the centre of AIly, our AI discovery platform, which helps organisations understand exactly where their teams sit and what the path forward looks like.

If you're leading a team where AI adoption feels uneven, or where you're not yet confident the investment is returning what it should, talk to SixPivot.

Read next: What is a Frontier Organisation? How SixPivot Leads AI Adoption in Australia From the Inside