Faster code, same bottlenecks: notes from DevOps Summit Sydney

I went to DevOps Summit NSW 2026 at ICC Sydney on 21 October. Reading back through my notes, the thread isn't a tool. It's the gap between making one task faster and getting something useful to a customer sooner.

AI makes that gap hard to ignore. I can generate code, tests and PRs faster, but the change still needs review, representative test data, an environment, and a path through the approval process.

That's the distinction I kept coming back to. Automating a task doesn't necessarily improve the system it has to pass through.

The painful middle

One session was "The 'Painful Middle' of DevOps Maturity". That name stuck, because it's exactly the thing I keep hitting.

You can have pipelines, infrastructure as code and automation everywhere, and still have developers who can't ship without someone else doing it for them.

Say a deploy used to take an engineer an hour and you automate it down to five minutes. Good. But if a developer still raises a ticket and waits two days for that engineer to press the button, you've saved some work and kept the main bottleneck. The waiting is the constraint.

The real win is letting the developer deploy safely themselves. That takes clear ownership, the right permissions and feedback they can act on. A script helps, but it doesn't remove the dependency if I'm still the person who has to run it.

The platform is the product

I wrote five words in my notes: "The platform is the product."

Easy to nod at, then measure a platform by the infra it runs or the tools it ships. The harder question is what developers can actually get done with it.

Can they get an environment when they need one? Test with data that represents the scenarios they need to check? Work out why a deploy failed without hunting down the one person who understands the pipeline?

Those are product questions. Idea-to-customer time keeps them honest. A tool people love can still sit inside a slow delivery process, so you want both: the experience and the outcome.

Guardrails that change how work flows

Another note: "guardrails over gates."

I work in financial services, so I don't read that as "stop checking things." I read it as being deliberate about where the checking belongs and what it's meant to prove.

My notes have risk-based PR review: automate the low-risk path, require a human for changes with significant compliance or customer impact. And CODEOWNERS to route important changes to the right people.

One catch: CODEOWNERS names reviewers, but required approval has to be enforced by repo rules, not the file alone. That gets the right people involved. It doesn't assess the risk for me.

The hard work is drawing the lines. Which changes are genuinely low risk? What evidence should the pipeline collect?

AI review might help, but it doesn't answer that for me. If every change still waits on the same person, I've added an AI reviewer and kept the bottleneck.

When the agent gets it wrong, look at the spec

An idea I keep chewing on: when an agent goes down the wrong path, fix the spec, not just its output.

Not a hard rule. Agents fail even with clear instructions. But it's a good first place to look.

Did I write down the business rule? Explain the exception? Give the agent the context a colleague would've picked up over months?

If that only lives in someone's head, the agent can write something technically fine that's still wrong for the business. Patching the code fixes one case. Improving the spec and turning the missing rule into a test gives you something reusable, and hands the requirement to the next engineer, not just the next agent.

This ties back to what I've written before about skills and steering files. Better instructions matter, but they have to carry the context that explains what "correct" means in this system, not just coding conventions.

More code needs somewhere real to be tested

There was a Perforce session on why data is still a constraint when AI speeds everything else up. My test-data notes were some of the longest of the day.

The line I keep coming back to: generating data from rules is fast. Working out the rules is the hard part.

A dataset can look realistic and still miss the relationships, exceptions and ugly historical states that surface bugs. More rows doesn't mean more useful.

I noted a mix: masked production-derived data for existing behaviour, generated data for new scenarios. Masking has to protect sensitive information without losing the relationships that matter. Generated data has to cover the awkward edge cases.

If a test fails, I need to recreate the state that broke it. Per-PR environments are much more useful when the data inside them is as reproducible as the app.

That's what makes intent-based testing useful: say what has to be true, then work out how to test it. If the business rule isn't clear, what are the automated tests actually checking?

What I wanted more of

The vendor conversations were a bit of a bust. I came away feeling that once they heard how small our team was, there wasn't much interest in going further.

Our team isn't 100-plus engineers. Fair enough if that's their market, but I still wanted to understand what their products would actually do for a team like ours.

I was looking forward to the campfire-style chats with other engineers too. That's a chance to hear what people have tried, what went wrong and what actually helped. But my group stayed mostly quiet, so that was disappointing as well.

The panels and the conversations that did get going were the most useful parts of the day. Even then, I wanted more actual DevOps and platform engineering and less AI.

I kept hearing the same buzzwords. My impression was that plenty of people were still trying things and working out what the best practices might become.

That's where I am with some of this too. I'm using these tools, but I'm happy to let the big companies with big wallets work through some of the expensive experiments. I'll learn from what comes out of them.

For anything I adopt, I want evidence that it saves work or solves a problem I have. Another platform also means something else to integrate and maintain. That cost matters in a small team.

The org work doesn't go away

Next to all the technical notes, I wrote about psychological safety and passing decisions to the people closest to the problem.

Those belong in the same conversation as pipelines and review policies. People need to be able to say a process is slowing them down, or that an automated check isn't giving the confidence everyone assumes it does.

Giving someone responsibility without the authority or context to act doesn't give them autonomy. Neither does making every failed experiment personally costly.

My takeaway is a question I want to use more deliberately:

Where does a change spend its time waiting, and what would let it move safely?

Sometimes the answer is better automation. Sometimes it's test data, clearer business rules, or moving a decision closer to the people doing the work. Before I reach for another tool, I want to be able to say which of those it'll actually fix.