More Tools, More Code, But Are We Delivering Faster?

We recently attended the 2nd TechIsland TechPro Community Meetup at Warehouse by IT Quarter in Cyprus, where five engineering leaders debated whether we're over-engineering DevOps, and when complexity enables better outcomes versus when it becomes a burden.

Halfway through the panel, Dmitry asked the room to raise their hands if AI makes them deliver code faster. Most hands went up. He kept his down. "We generate a lot of code, yes, but I don't think the amount of releases increased dramatically."

The room wasn't wrong. They probably are coding faster. But the conversation that followed, moderated by Liza Charalambous across five panelists with very different contexts, kept surfacing the same gap: the speed is real, but it might be in the wrong place.

Faster at what, exactly?

When each panelist was asked specifically what AI does in their delivery process, the answers were revealing. When Ruslan asked his developers what AI could do inside a CI/CD pipeline, they didn't have an obvious answer. Alex said he didn't want AI DevOps. He wanted better versions of what he already wanted: faster deploys, easier rollbacks, better monitoring. Nikita explained that his engineers use AI agents across the workflow but enforce one hard rule: read-only access to production. No exceptions.

The most concrete AI win on the panel came from Dmitry himself, the one who'd kept his hand down. He explained that his team gets fast, accurate root cause analysis during incidents. But it works, he said, because they spent years building a structured configuration management database before AI was part of the conversation. "When you feed correct data to AI, you get a response very fast."

There's something important in that. The team with the most concrete AI results is the one that invested in boring, unglamorous data discipline for years before the models arrived. AI didn't replace that work. It rewarded it. The implication is worth sitting with: the organisations that benefit most from AI will be the ones that already maintained shared understanding of their systems. Messy data, drifted configs, and undocumented systems don't get better just because you point a model at them.

Creation got cheap. The consequences didn't.

Alex told a story about a service his team built during the microservices era. Two people shipped it in a quarter. It was designed to be reusable across the company. Nobody else ever used it. It still pages on-call engineers at 2am who have no context on how it works. As Alex put it, "Features shouldn't be services, for the most part."

It's easy to hear that as a microservices cautionary tale. But the pattern underneath it is the one that matters now. When the cost of creating something drops to near zero and the feedback about whether it's valuable takes months or years, you get proliferation. That was microservices in 2018. It's AI-generated code in 2026. The creation cost has dropped again. The feedback loops haven't shortened.

Nikita described a similar dynamic from the infrastructure side. His team built internal tooling without a product owner, gathering requirements from the most enthusiastic teams. They got adoption from the willing and got stuck with everyone else. The tooling wasn't bad. There just wasn't enough demand to justify it.

The teams that struggle most aren't short of capability. They're short of shared principles about when to build and when to stop. Implementation speed has stopped being the bottleneck. The bottleneck is knowing what's worth implementing.

The drift is in the culture, not the config

Configuration drift came up repeatedly. Every panelist had war stories about the gap between what's declared in code and what's running in production. Nikita shared how he'd built drift detection for network hardware over a decade ago. Dmitry shared that his team monitors database configs against infrastructure-as-code. Ruslan described running quarterly reconciliation cycles.

But in every story, the trigger was the same: someone fixed something directly in production during an emergency and didn't commit it back. That's the right call in the moment. As Dmitry put it: "If players are not happy right now, we must do anything to make them happy, and then follow the processes."

The problem isn't the emergency fix. It's whether the organisation has a mechanism to close the loop afterwards. Dmitry explained that his team built monitoring that detects when production configs drift from their infrastructure-as-code. That's culture doing its job. Without that kind of closing mechanism, tactical fixes quietly become the permanent state, and the gap between what's declared and what's running compounds. It's one reason the path to production needs to be designed and maintained as a product, not left to accumulate.

Design the system, not the meeting

Ruslan described something he called a "fighting deck." Instead of acting as the sole referee for infrastructure requests, he created a biweekly meeting where every stakeholder who wants something argues their case against everyone else's. They see each other's requests, understand the trade-offs, and self-organise.

It sounds like a meeting format. It's actually a piece of organisational architecture. He explained how he stopped being the bottleneck by designing conditions where the demand side prioritises itself. That's the kind of invisible structural work that never shows up in a sprint review but changes how an entire department operates.

The advice nobody had to think about

Asked what they'd tell a small team starting out, the panelists converged instantly:

Define engineering principles early. Stop re-debating the same decisions.
Don't build custom tooling. Use standard, community-supported instruments.
Start with things that make your team happy now, not in a year.
Don't try to be Google. Don't spin up Kubernetes because everyone else is doing it.

Every answer resists the same pull: engineering for engineering's sake. The organisations scaling without slowing down are the ones disciplined enough to build only what they need.

Our takeaways from TechIsland TechPro Community Meetup #2, 11 June 2026, Limassol. Thanks to Liza, Dmitry, Alex, Nikita, and Ruslan for a great conversation.

This article is provided as a general guide for general information purposes only. It does not constitute advice. CECG disclaims liability for actions taken based on the materials.

More Tools, More Code, But Are We Delivering Faster?

More Tools, More Code, But Are We Delivering Faster?

Faster at what, exactly?

Creation got cheap. The consequences didn't.

The drift is in the culture, not the config

Design the system, not the meeting

The advice nobody had to think about

Turn More Tools, More Code, But Are We Delivering Faster? Into A Strategic Advantage

Continue Reading