James Menzies is a great example of a software engineer who has really embraced AI. Not as a side experiment. Not as a productivity hack. As a different way of working.
“About 80% of what I do now involves AI.” He’s moved from doing the work step by step to orchestrating how it runs.
That’s why I wanted to speak to him. DiUS is full of engineers that have embraced AI, but James has pushed further than most. He’s often brought in to help set technical direction, lead delivery and lift capability across a team. Right now, he is working as an individual contributor inside a client environment that is heavily regulated, but unusually committed to AI adoption.
I had hoped to get more of a team view from him, because that is where many of the bigger operating model questions sit. But the individual view turned out to be just as revealing.
His first comment made that clear. “About 80% of what I do now involves AI.” He’s moved from doing the work step by step to orchestrating how it runs.
He defines the task, lets it move across systems, and comes back to review the outcome. A feature might start as a conversation, become a Jira ticket with acceptance criteria, then move through implementation, testing and build checks with minimal intervention. When something doesn’t work, he doesn’t just step in and fix it. He adjusts how the task was set up so the workflow runs better next time.
The result is that much of his own constraint has been removed. What remains is everything around him. “The frustration is when there’s a gap. You have all this context, you know exactly what to do, but you can’t because you can’t connect to a specific tool or product.
In practice, that means the agent already understands the task and has often completed the steps leading up to it. The workflow stops, not because the work is unclear, but because the system it needs to interact with doesn’t support agent access.
How the work moves with AI
James didn’t describe AI as something he uses in one part of the job. It moves with him from the moment a task starts. “It’s not just coding anymore. It’s generating tickets, refining them in Jira, and coming up with implementation plans.”
It reflects his background as an engineer: understand the system, remove what’s unnecessary, connect what matters and keep the dangerous permissions out of reach.
Before anything is written, the task is already taking shape. By the time he gets to implementation, most of the thinking has already been done. “If I know what needs to be done, I define the task, review the plan, set it off, then come back and approve it.”
That shift shows up most clearly in how he has set up his environment. When I asked what tools he uses, the answer wasn’t a list of products. “I’ve gone the other way. I’ve kept things very minimal and built my own extensions where I need them.”
He does use a harness, currently Pi, which plays a similar role to tools like Claude Code or Copilot. But the interface isn’t the point. “I use the tools to write code, but that’s only part of it.”
He described Pi as closer to a control room than a coding tool. There’s an agent inside it, already holding context about the task and the surrounding systems.
Writing code is part of it, but only part. In his case, it probably makes up about half of the usage.
The rest is guiding the agent: shaping tasks, connecting systems, checking outputs and deciding what happens next.
The harness is simply the way he steers that process. What sits around that control layer matters more. In practice, that looks something like:
- command line tools for build pipelines, infrastructure and observability
- organisation-approved access to LLMs
- custom skills to capture repeatable workflows
- APIs and MCP servers to connect systemsA lot of this work is read-heavy. Investigating failures, analysing logs, checking infrastructure. Access is deliberately constrained, often read-only, so the agent can explore safely without changing things it shouldn’t.
It’s a minimal setup, but not a casual one. It reflects his background as an engineer: understand the system, remove what’s unnecessary, connect what matters and keep the dangerous permissions out of reach.
Pi suits that approach because it gives James a lightweight harness he can shape around his own workflows, rather than forcing the work through a single interface. That flexibility is what makes the setup work.
A lot of it is built around the command line. “With things like the AWS CLI, there are hundreds of arguments. You can do almost anything with it.”
The systems haven’t become simpler. But AI can move through them quickly. “I need to check not just the logs, but the security policies around the resources. The CLI lets the AI do all of that.”
That’s where the work starts to look different. He’s not asking for suggestions inside an editor. He’s moving across the delivery system.
“You can take a problem from the board, look into the code with one AI, and the logs with another. Connecting that end to end is really where the power comes from.”
Over time, those patterns get captured. “Whenever I run a repeatable workflow manually, I try to codify it as a skill.” The most useful ones aren’t generic. They reflect how a specific system or organisation works, the naming conventions, the tools, the way problems are investigated.
Model choice still matters, but less than you might expect. James leans towards GPT-style models and tools like Codex, but he’s not fixed on any one option. Simpler tasks go to cheaper models. More ambiguous work gets a stronger one. In some cases, he’ll deliberately split the work across models, one to plan, another to review, so he’s not relying on the same system to validate its own output. But the bigger difference isn’t the model. It’s how the work is shaped.
That same discipline shows up in how he manages context. James keeps tasks small, even when larger context windows are available. If a skill can carry the repeated instructions, he does not need to rebuild that context every time. It keeps the work cleaner, and it also keeps usage under control.
A small feature, before and after
The clearest way to understand the setup is to watch a small feature move through it.
“It goes from about eight hours to 30 minutes.”
Not long ago, the process was familiar. Define the task, write the ticket, implement the code, test it manually, merge it, deploy it, monitor it. In a clean run, that might take a day.
Now it starts with the agent. James talks through the task, lets it ask clarifying questions, then has it create the Jira ticket and acceptance criteria. From there, it branches the code, implements the change, creates the PR, monitors the build pipeline and responds to failures.
Once the change is in the development environment, the agent can test it too, provided it has the right skills and enough context to know which endpoints to call. “That’s the Jira ticket, the code, pushing into dev, testing in dev. It goes from about eight hours to 30 minutes.”
That doesn’t remove approvals or governance. It changes what happens before them. It also changes the shape of the day. When people hear that a task that used to take a day can now take 30 minutes, James says they sometimes assume the rest of the day opens up. His experience is the opposite. “The more you can do, the more you take on.”
There is something addictive about that pace. When a workflow runs cleanly from end to end, it feels good. The flip side is that when something worked yesterday and the agent struggles today, the frustration is sharper. James still sees the net positive as huge, but the experience is not frictionless.
Where review starts to strain
Improved productivity from AI doesn’t remove approvals or governance. It changes what happens before them. James is no longer spending the same time writing code, but he’s still accountable for what goes through.“I tend to review everything manually.”
James described the current development cycle as “showing its age”. The work can be done quickly, but getting it merged can still take the rest of the day.
I asked if that was about trust. It didn’t feel like it. When the task is clear, the output is often good. But he still checks it. Where it gets harder is volume. “If you’re fixing or implementing ten things, it’s very hard to review ten PRs in a day.”
That’s where pull requests start to show their age. “I think pull requests, in their current form, will go.”
Small PRs still make sense. They’re easier to review and easier to reason about. “If you want to do it properly, you often open small ones because it’s easier, it’s less cognitive load for the reviewer.”
But once the volume rises, the review itself becomes the work. People need time and context, and both are in short supply. James described the current development cycle as “showing its age”. The work can be done quickly, but getting it merged can still take the rest of the day.
He sees the same pattern outside of code review. “I’m in Melbourne working with a Sydney team. When I message them, they reply when they have time.” Those delays were always there. They just matter more now. “Because I’m moving so fast now through everything else, these human friction points are what slows me down.”
If one person can move this quickly, the rest of the system has to keep up.
What James would push further
When I asked what he would change if there were fewer limits, James did not talk about novelty. He talked about the work most teams recognise: legacy.
“I think AI could be used to tackle large-scale modernisation. If it can handle 90 per cent of the work, the workload drops significantly.”
“There’s a lot of legacy and a lot of debt. Most of it is just manual labour, not technically difficult work.”
That distinction matters. He was not talking about handing difficult architectural decisions to AI, or pushing untested changes into production. He was talking about the long tail of work that sits around systems because it is tedious, repetitive or too expensive to prioritise.
He gave a simple example of how that is starting to change. Code that is already working, but could be cleaner or more efficient, would normally be left alone. The effort to rewrite it is hard to justify.
Now he approaches it differently. He can set the work off in the background, see what comes back, and decide whether it is worth pursuing. “If I can set an agent on it and see promising results, I can decide whether to focus on it. I’ve only invested five minutes.”
That changes the economics of the work. Exploration is no longer a large upfront commitment. It becomes something you can try, observe and either continue or discard. “I think AI could be used to tackle large-scale modernisation. If it can handle 90 per cent of the work, the workload drops significantly.”
He pointed to examples like Cloudflare using AI to rewrite Next.js, relying on strong test coverage to validate the changes as they go. The point for James was not Cloudflare itself. It was the role of tests. If you have enough validation around the work, you can afford to try bigger changes earlier.
That is the condition underneath his optimism. Not just speed, but confidence. The ability to try changes quickly and know whether they hold. “I’d be a bit more willing to test things out, just not push them to production.”
Where others can start
James does not suggest copying his whole setup. His advice is simpler than that.
The habit of turning repeated work into something the system can understand next time.
Pick a harness. Pick one system you already use. If you are working in an observability platform, a build tool or an API, check whether it has a CLI, API or MCP server. Work through the authentication, command line arguments or query patterns with the agent. Let the conversation get messy.
Then, when it works, ask the agent to document what it learned as a skill. “So that when I say to you, check the logs for service X, you know what to do.”
That is the part others can take from James’ approach. Not the exact tools, but the habit of turning repeated work into something the system can understand next time.
What carries across
There’s a lot to take from the way James works: how he shapes tasks, connects systems and takes responsibility for the output.
But the bigger point sits beyond James. Once individual engineers start working this way, the constraints show up across the delivery lifecycle: in review, release, system access, context sharing and how teams work together.
