Craig Nielsen: Why faster AI coding is exposing the limits of enterprise software delivery

AI coding tools are increasing the speed at which developers can generate code, but the rest of the software delivery lifecycle is proving harder to accelerate at the same pace. As output increases, pressure moves downstream to review, testing, security and deployment, where existing processes and infrastructure may struggle to absorb the additional workload.

Against this backdrop, GitLab’s research points to a widening gap between faster code generation and improvements across the full software lifecycle. The issue is becoming more pronounced as organisations move from individual AI coding assistants towards software agents capable of interacting with repositories, pipelines and other development systems.

As these agents take on more work, enterprises have to determine what information they can access, which actions they can perform independently and how those actions can be traced when something goes wrong. Infrastructure and governance designed around human workflows may also need to accommodate a growing volume of machine-initiated activity.

Across Asia Pacific and Japan, these decisions are further shaped by differences in data residency, regulation, deployment requirements and cost. In this editorial interview, Craig Nielsen, Vice President, Asia Pacific & Japan at GitLab, discusses where AI productivity gains are being lost, how organisations are approaching model selection and agent governance, and how engineering responsibilities are evolving as software development becomes increasingly automated.

AI is amplifying existing software fragmentation

Most enterprise software toolchains were assembled stage by stage long before AI agents became part of development workflows. From GitLab’s APJ customer engagements, what has materially changed as organisations begin connecting agents across repositories, pipelines and production environments?

Craig Nielsen: What has changed globally and across Asia Pacific is that AI coding tools arrived before the infrastructure to govern them did. Most organisations built their toolchains stage by stage over the past decade, and each stage now runs its own AI agent that cannot share context with the others. That fragmentation was already a drag on productivity, even before agents arrived. Our customer Airwallex, a fintech platform based in the region, saw exactly that when it consolidated its toolchain onto a single platform and started shipping customer-facing features four times faster.

Add agents on top of a fragmented stack instead of a consolidated one, and the fragmentation compounds instead of easing. Agents act by the hundreds, touching dependencies and triggering deployments faster than most governance processes can track, and infrastructure built for people committing code at human speed strains first. Reliability breaks under that volume, agents make changes that look right but miss context that only shows up in production, and cost climbs as agents work harder to reconstruct what they cannot see. In large, complex environments, that combination is where the hidden cost of adoption shows up.

Delivery speed matters more than coding speed

There is a widening gap between how fast code is written and how quickly it reaches production. Where are those gains being lost after code is generated, and what should enterprises measure to determine whether AI is improving delivery rather than simply increasing output?

Craig Nielsen: The gains are landing in the wrong place. Developers are coding faster with AI, but coding is a small slice of the full delivery cycle, so accelerating it can create a bottleneck when review, testing, security and deployment continue to run at their old pace. GitLab’s own research illustrates this gap. Some 78% of organisations report faster code output, but only 21% report productivity gains across the full lifecycle.

The fix is to stop measuring coding speed and start measuring delivery speed. Track how long it takes to go from idea to production, how long merge requests sit in review, how often deployments happen and how often they fail. If commit volume keeps climbing while none of those numbers moves, AI is adding activity rather than throughput. Leadership should treat that gap as a signal to invest in review and governance.

Model choice is becoming an infrastructure decision

Enterprises building AI into software delivery increasingly face a choice between frontier and open-weight models. Why does that matter particularly in APJ, and how are data residency and regulatory differences influencing the AI architectures enterprises adopt?

Craig Nielsen: Data residency is becoming a hard requirement for enterprise customers across the region. Regulators are asking for evidence that AI systems operate within stated policy, and no single deployment model satisfies every regulator a multinational organisation answers to.

That reality is why GitLab has built its platform to be model-agnostic rather than betting on one provider, and has backed that stance publicly, including by signing an industry letter supporting continued investment in open-weight models. Open-weight models give organisations more control over cost, deployment and data residency, while foundation models often lead on raw capability. Enterprises benefit from running frontier models where capability matters most and open-weight or self-hosted models where cost, latency or data sensitivity dominates, and sometimes both within the same organisation.

What determines whether that mix works is whether the platform around the models can turn every output into something governed, tested and auditable. That is a harder requirement than picking a model provider, and it is why model neutrality needs to be a platform property. Locking into a single provider trades short-term simplicity for exposure on cost, compliance and control further down the line.

Reliable agents need context without unrestricted access

Agents can produce changes that appear correct while lacking wider information about requirements, security findings, pipeline history and production behaviour. What context does an agent need to make a reliable software change, and how should enterprises determine what information it is allowed to access?

Craig Nielsen: An agent is only as reliable as the context behind it. That context needs to connect code, work items, pipelines, security findings and production history into one picture, not just what a system looks like today but what changed, why and who approved it. Agents working off a fragment of that picture make changes that look right in isolation and fail the moment they touch something they could not see.

Access should follow the same principle organisations already apply to people. Give each agent the minimum visibility its task needs, and nothing more. The pattern that works best lets an agent see exactly what it needs to know rather than handing it a full copy of the codebase to work from. A single, consistent way of granting that access is what removes the friction that shows up where access controls tend to be the loosest.

Autonomy needs a defined stopping point

As agents gain access to repositories, development tools and production systems, how should enterprises distinguish between actions that can run autonomously, those requiring human approval and those that should remain prohibited? When an AI-assisted change causes an incident, where should accountability ultimately sit?

Craig Nielsen: Risk-based autonomy sets the boundary. Low-risk changes move on their own, medium-risk changes get flagged for review, and high-risk changes need a person to sign off before anything ships, with every decision leaving a trail back to who approved it.

Where most organisations fall short is the third tier, knowing where agents should stop acting altogether. GitLab’s research shows 80% of organisations say they adopted AI tools faster than they built the policies to govern them, and that gap widens every time a team adds a new agent without a matching control.

Accountability sits with whoever initiated the action and approved the policy it ran under. The clearest warning sign is a team that has deployed several agents but cannot say what those agents did last week, or whether they stayed inside policy. Closing that gap is an identity and governance problem, and it is cheaper to close before an incident forces the question.

AI investment has to be measured beyond token cost

Agentic AI products currently span generally available capabilities, public betas and private betas, while some performance claims remain based on internal testing. How should enterprise buyers assess product maturity and calculate value once infrastructure, token consumption, review, rework, governance and audit costs are included?

Craig Nielsen: Deployment maturity belongs in the evaluation stage. A feature in public beta carries different risk and support expectations from one that has been generally available for a year, and treating them the same in a rollout plan is how enterprises can encounter challenges. GitLab, for example, has agent orchestration capabilities that are generally available today alongside newer context-graph capabilities still in public beta. Buyers should ask any vendor for that same breakdown rather than taking a single “AI-powered” label at face value.

On cost, the useful question is not how much an organisation is spending on tokens. It is whether that spend is delivering outcomes that move a business metric. Our customer Agoda, the online travel platform, saw its platform consolidation return 3,000 hours of developer time per quarter. That result predates its AI adoption, but it illustrates the kind of measurable business outcome enterprises should expect their AI investments to deliver.

Review, rework, governance and audit belong in the cost calculation alongside tokens and infrastructure. Agents frequently produce changes teams end up reverting, which means the team spends more time fixing the agent’s work than the agent saved in the first place. Enterprises that track cost and return as closely as they track adoption are the ones separating AI initiatives that deliver lasting value from those that simply accumulate spend.

Engineering judgement becomes more important as agents multiply

As agents take on more code writing and related development tasks, how does the role of the software engineer shift towards architecture, design, customer value and orchestration? Which decisions still require human judgement, and how should organisations coordinate multiple internal and third-party agents without fragmenting policy and visibility?

Craig Nielsen: Agents are taking on code writing and a growing share of related tasks, which frees engineers to spend more time on architecture, design and customer value decisions, and there are more of those decisions to make than there were before. Ambition has always outpaced a team’s capacity to deliver, and AI has not changed that. It has raised capacity, but the backlog of software the world wants built is still larger than the ability to build it.

What engineers add is judgement agents cannot supply, whether a solution solves the right problem, which trade-offs to make, and whether the result fits what the business needs.

Alongside judgement comes orchestration, deciding which agents run, in what order, and how failures and handoffs get handled. Orchestration turns individual agents into a coordinated system rather than a collection of tools. In almost every vertical, there is now a vendor offering to be an organisation’s AI agent for some function, and each wants access to the same underlying data. Intentional orchestration is what keeps that from turning into dozens of vendors holding separate keys to the same systems.

Skills once expected only of senior or staff engineers are now baseline expectations for the whole team, and building that capability across a workforce is the harder problem for engineering leaders in this region to solve.

Software delivery is becoming the real test of enterprise AI

The challenge for enterprises is therefore becoming organisational as much as technical. As agents take on more development activity, organisations have to determine how that work is governed, coordinated and incorporated into existing engineering processes. The advantage will come from adapting those processes to a growing volume of AI-assisted work without allowing operational complexity to increase alongside it.

That places a different constraint on enterprise AI adoption. Model capability will continue to improve, but organisations still have to decide how much autonomy their development systems can support, where accountability sits and where human judgement remains necessary. As coding becomes easier to automate, the ability to manage what happens around that automation may ultimately determine how much value enterprises can gain from it.