The real brake on your dev velocity? Your IT governance

IT governance, meaning the set of rules that decide who approves what in technology, has never mattered more than it does today. An agent like Claude Code maps a 100,000-line repository and submits a verified merge request in 180 seconds, then that same request sits three days in a human's queue waiting to be reviewed. The problem is no longer how fast code gets written, it is how fast decisions get made around that code.

Plenty of executives still treat IT governance as a compliance topic, reserved for large corporates going through COBIT or ISO 27001 audits. That stopped being true the moment AI agents started writing most of a team's code: without a clear decision framework, every gain in speed upstream turns into a slowdown downstream.

Your agents code in 3 minutes, human review takes 3 days

The figure comes from a field report filmed by the TechWithLalit-PM channel on Claude Code: a terminal agent like Claude Code reads an entire repository, writes the changes, runs the test suite and submits a verified pull request (the code proposal a human has to approve before it reaches production) in roughly 180 seconds. A senior engineer, meanwhile, cannot review ten times faster than before.

That gap creates what the video calls verification latency: a feature coded in 3 minutes then waits 3 days in the repository before it gets merged. The KPI that mattered yesterday, lines of code produced, no longer means anything: the metric that counts now is the time between opening a merge request and getting it approved.

How do you measure this new bottleneck?

Two indicators replace the line count: verification latency (the delay between opening and merging a code request) and AI rework rate (the share of agent-generated code that fails quality checks and has to be redone). On a recent engagement, I watched a team fall back to a flow of 4 merges per week because nobody had redefined who approved what once the agent was introduced. Without that recalibration, faster code never translates into faster delivery.

What is IT governance, in plain decision-maker terms?

IT governance means the set of rules that define who decides, who approves and who is accountable for a company's technology choices. It is not a layer of bureaucracy stacked on top of the work: it is what stops a finance director from launching a technical project in parallel with the CIO without the two ever talking, a scenario the Bridge & Co. channel describes as the number one source of architecture conflicts in mid-sized companies.

The most widely cited framework worldwide is COBIT, created in 1996 by ISACA, a professional association specialising in information systems audit and control. Its latest major overhaul, COBIT 2019, structures governance around 40 objectives spread across six governance systems, with one simple takeaway for a non-technical reader: decentralise day-to-day decisions, but keep strict convergence on security and quality standards.

What are the concrete pillars of an IT governance framework?

The Starti channel identifies five, all transposable to any small or mid-sized company: service management (who answers incidents and within what timeframe), project management, development maturity (does the code shipped hold a consistent quality level), information security and risk management. For a team coding with AI agents, those five pillars boil down to a single operational question: who decides when an agent can merge code into production, and against what objective criteria?

Without a framework, AI speed gets paid for in technical debt

That question is not theoretical. The TechWithLalit-PM video is explicit: "execution speed without control, in the absence of strict limits, accelerates the accumulation of technical debt". Technical debt (the hidden cost of code that is badly written or badly verified, which slows every future change) grows all the faster when code volume rises without a matching quality filter.

I believe a good software production system built around AI rests on short, testable units of work with precise acceptance criteria, not on a vague prompt followed by an automatic merge. That is exactly what the Accelerate research documents, conducted since 2014 by Nicole Forsgren, Jez Humble and Gene Kim across more than 30,000 organisations: according to the write-up published by OCTO Technology, a company's software performance is measured by its ability to ship often, in small batches, with automated tests and a decoupled architecture. Those are the same levers you need in place before you turn an agent loose on a production repository.

Without clear architecture, AI-generated code quickly becomes unmanageable. That is the limit I see most often in founders who adopt a terminal agent without first writing down a conventions file (often named CLAUDE.md or ARCHITECTURE.md) that sets the rules of the game. Without that safety net, the agent optimises for making tests pass, not for keeping the product coherent over twelve months.

"The real advantage of an AI agent is not that it codes fast, it is that it finally forces the company to write down in black and white what it expects from its software production system."

Vincent, September 2026

Why does technical debt explode faster with AI agents?

Because an autonomous agent writes code that passes naive tests without necessarily preserving the overall architecture. Under the COBIT 2019 framework described by the Sprinto channel, governance and operational management must stay distinct and clearly separated: that separation is precisely what goes missing when an agent validates the quality of its own code with no independent control grid. The professional ITIL 4 Specialist High Velocity IT course, priced at 2,350 € excluding tax over 3 days according to Global Knowledge, answers the same observation: speed is not managed without a framework, it is framed.

Hire, delegate or set the rules: the real decision math

At this point the question is no longer "do we need IT governance", it is "who owns it in your organisation". Three options exist, and they do not cost the same in implementation time or in technical debt risk.

Useful disclosure here: Extra Dev sells senior contract developers at 180 €/day, so I have an obvious bias towards that option. That bias also comes from watching, engagement after engagement, where governance breaks when it rests on a prompt alone and no written rule.

Should you hire a senior dev full-time or bring one in on contract?

The math depends mostly on who has to own governance day to day. A permanent hire is expensive to unwind if the fit does not work, but it anchors governance for the long run. A senior contract dev, with 8 years of experience minimum, can put the framework in place (conventions files, acceptance criteria, systematic code review) within days and with no long commitment, which suits a startup testing its first agentic system before committing to a hire. I laid out the full 12-month math in a numbers-based comparison of permanent hire versus contract if you want to dig into the figures.

On extradev.fr, the article on the steering ritual for a remote contract dev sets out how that framing holds together in 30 minutes a week, with no heavy meetings. According to my own Search Console figures for extradev.fr in September 2026, that lightweight format is one of the few topics where the site is genuinely gaining average position (9.9, up 70 % over the period), proof that the question interests decision-makers looking for a concrete answer rather than a lecture on audit frameworks.

According to research published by Gartner on information technology governance, organisations that clearly separate governance from operational management significantly reduce incidents tied to uncontrolled deployments. That is exactly the risk an unsupervised AI agent creates for a team that has never formalised who approves what.

The verdict: govern before you delegate, not after

The promise in the headline closes here: the real brake on your dev velocity is no longer how fast code gets written, it is how fast your organisation can verify that code with confidence. An agent that ships in 3 minutes with no governance framework saves you no time at all, it moves the bottleneck to a review queue nobody has sized.

My verdict is clear-cut: set the rules before you delegate to an agent, never the other way round. In practice, before you let an AI agent touch a production repository, put in writing who approves merges, what level of test coverage is non-negotiable, and what API budget must never be exceeded. If you have neither the time nor the in-house expertise to set that framework, a senior contract dev can do it in one to two weeks, well before a permanent hire would be finalised. If your team already exists and has been coding for years with no major debt, formalise your internal conventions first before adding an agent to the flow, and the return on that effort is measured in weeks of technical debt avoided. To go further on the tools themselves, the GoLive Software blog covers the practical side of steering an AI-augmented team on the contract side.