Over the past few months, we've been asking people across Optimation one simple question: how has AI actually changed the way you work?
People in roles span testing, development, business analysis, project delivery, and operations answered. Their tools range from Claude to GitHub Copilot to Miro. What came back isn't a neat story - it is honest, specific, and sometimes contradictory, which is exactly why it's worth sharing.
Ask most people what they expected AI to change, and they'll say: speed. Do things faster. That's true, but it turns out speed is the least interesting part of what's actually happening.
For Aaron McLean, the shift was about where his effort goes. He's no longer the one creating test scenarios from scratch. He's reviewing them, adjusting them, making sure they're right. "I kind of use an 80/20 rule," he says. "80% is what Claude generates for me, with the other 20% being my input." He's also building automated test suites in Visual Studio Code - something he describes as impossible six months ago.
Yorick Canales had a similar experience on the BA side. Writing user stories used to be his job. Now he's validating and tweaking them. "It helps me get moving a lot quicker," he says. The work hasn't disappeared. It's moved upstream.
Jeshua Hertzke, Engineering Team Lead, put it plainly: "The biggest shift for me has been where I spend my thinking time." The heavy work now goes into articulating what needs to be built and why. AI handles execution well. But only when given the right context.
AI hasn't taken the thinking out of the work. It's relocated it.
Anthony Chan is more cautious, and he's clear about why. For systems with complex business requirements, he finds that letting AI design test scenarios independently can create more work, not less. Verifying output, checking for gaps, correcting errors. His approach is to draft scenarios himself first, then use AI to review for anything he's missed. "I'm still somewhat cautious about relying on it to independently design manual test scenarios," he says.
That's not a failure of AI adoption. That's good judgement. Domain expertise is what makes the 20% count. Without it, the 80% isn't worth shipping.
Neena D'Souza leads the test team and sees the same dynamic at scale. The team uses Claude and Copilot to generate test scripts, documentation, and wiki pages. Efficiency has improved significantly. But they validate everything. "AI can occasionally introduce invalid scenarios," she says. The efficiency gain is real. So is the need for human oversight.
Anthony Brandon works in legacy .NET codebases, which means GitHub Copilot rather than Claude Code. But Claude Sonnet is, in his words, "a must." His workflow is one of the most integrated we heard: Claude reads user stories from ADO, understands the issue, writes the code. He reviews it, tests it, and they iterate. Claude writes the unit and integration tests, documents the changes, updates the user story, and creates wiki documentation.
He's also working on MCP servers to let Claude test code in a browser autonomously, logging on as a test user, checking console output, taking screenshots. The goal is a self-correcting change loop where Claude iterates until the fix is confirmed.
"The work we do these days is far more complex than the past, because we can now do it with AI. Some of the stuff we're adding now would have been parked in the 'it would take too long or is too hard' basket. But not anymore."
AI isn't just making existing work faster. It's expanding what's possible.
One of the more unexpected insights came out of a group discussion at our Wellington office. Scarlett raised something that reframes how AI fits into teams: the freedom it gives you to be blunt.
When AI produces something that misses the mark, you can tell it exactly that. "This is a fail." "This is totally wrong." No hurt feelings. No navigating how someone will receive difficult feedback. No relationship to manage.
She made a further observation. If that same feedback went to an employee, the emotional weight of getting something significantly wrong is often what leads people to disengage or leave. AI removes that cost. You get the honesty without the human fallout.
That's not an argument for replacing people with AI. It's an argument for understanding what AI actually changes about how work gets done. Iteration speed goes up when the cost of critical feedback goes down.
Philippa McQuillan's description of her experience is probably the most transferable of everything we heard. AI has helped her collect her thoughts, work smarter, cut down on repetitive tasks, and "modernise processes." Sometimes it's simpler than that: "Just helping me better describe or word something when I don't have a lot of time."
At the Wellington lunch, she gave a concrete example. She'd done all the hard thinking and drafting herself, then put the document through AI to be reworded and expanded. It came back sharper and more detailed.
That's the model the group landed on. Not AI doing the work instead of you. AI making your work better after you've done the hard part.
Pranav Andhare sees AI as a similar kind of moment to the internet boom:
"What sets AI apart is how it makes learning about itself more accessible, AI is helping us learn AI, creating a full circle."
It's a simple observation, but it's true. The barrier to getting useful output from AI tools drops as you use them. The skill compounds.
Jeshua put the challenge most directly:
"People think adopting AI is the hard part. It's not. The real challenge is directing it with enough domain knowledge and governance to get correct outcomes, not just fast ones."
That's the thread that runs through all the conversations we had. AI is embedded across the full delivery lifecycle at Optimation — from Miro boards in discovery, through specification and code generation, to document pipelines in production. It's not a tool bolted on at one stage. It's woven through the process.
But in every case, a person is in the room. Asking the right questions. Reviewing the output. Deciding what's correct. Directing the work with knowledge the AI doesn't have and can't replicate.
The 20% that humans contribute isn't the smaller portion. It's the load-bearing one. It's the part that makes the 80% worth using.
Domain expertise isn't a nice-to-have when you're working with AI. It's the prerequisite. The thing that lets you know when the output is right, when it's close, and when it's a fail.
AI multiplies what experts can do. It doesn't replace what experts know.
That's how work is changing at Optimation. Not by removing judgement from the process, but by giving the people who have it more room to use it.
Thinking about how AI fits into your team's workflow? We'd love to talk. Get in touch with the Optimation team.
This post brings together perspectives from the Optimation team including Aaron McLean, Anthony Chan, Yorick Canales, Jeshua Hertzke, Anthony Brandon, Neena D'Souza, Philippa McQuillan, Pranav Andhare, and Scarlett Maddock.
Thank you to all our contributors.