Insights / AI coding agents
How should a scale-up use AI coding agents without building technical debt?
A scale-up should use AI coding agents where the work is well specified, well tested and easy to review, and keep humans firmly in charge of architecture, security and the final merge. The research shows near-universal adoption but mixed evidence on real productivity, and the gains tend to follow the quality of the engineering system the tools are dropped into. The practical question for a CTO is therefore not whether to adopt them, but which guardrails, team shape and metrics turn faster code into faster, safer delivery.

What are AI coding agents?
AI coding assistants suggest code inside the editor as a developer types. AI coding agents go further: given a task, they read the codebase, plan changes across several files, run commands and tests, and open a pull request for a human to review. GitHub Copilot, Cursor, Claude Code, OpenAI Codex and Google Jules all now offer some form of agentic mode alongside autocomplete.
An assistant speeds up a developer who stays in control of every line. An agent produces larger units of work with less human attention per line, which moves the bottleneck from writing code to specifying, reviewing and integrating it.
What does the research say about AI developer productivity?
The evidence points in different directions, depending on who is measured, on what work and how.
- Controlled task, large speed-up. In GitHub’s 2022 controlled experiment, 95 professional developers wrote an HTTP server in JavaScript, and the group using Copilot finished 55% faster than the group without it (GitHub, 2022). The task was small, self-contained and new, which is where these tools are strongest.
- Real work in mature codebases, measured slow-down. METR’s 2025 randomised study gave 16 experienced open-source developers 246 real issues in repositories they knew well. With AI tools allowed, they took 19% longer; beforehand they had expected a 24% speed-up, and afterwards they still believed AI had made them 20% faster (METR, 2025). The authors caution that the sample is small and the result may not generalise, and METR now marks the study as out of date and has published newer data on late-2025 tools. The lasting lesson is the gap between perceived and measured speed.
- Adoption is near-universal, trust is not. The DORA 2025 State of AI-assisted Software Development report, based on nearly 5,000 technology professionals, found that 90% use AI at work and more than 80% believe it has increased their productivity, while 30% report little or no trust in AI-generated code (Google Cloud, 2025). DORA found AI adoption now linked to higher delivery throughput, but still negatively related to delivery stability.
- Developers are frustrated by near misses. In the Stack Overflow Developer Survey 2025, 84% of respondents use or plan to use AI tools, yet 46% distrust the accuracy of their output against 33% who trust it, and 66% name “AI solutions that are almost right, but not quite” as their biggest frustration (Stack Overflow, 2025).
DORA’s central conclusion is the useful one for founders: AI acts as an amplifier. Teams with loosely coupled architecture, automated testing and fast feedback loops see gains; teams held back by tightly coupled systems and slow processes see little benefit, and their existing problems can intensify. The tool does not fix the engineering system. It magnifies it.
Where do AI coding agents genuinely speed delivery?
They speed delivery on work that is well defined, low in ambiguity and cheap to verify. In practice that tends to mean:
- Scaffolding and boilerplate. New services, API clients, data models, configuration and the repetitive code around them.
- Tests. Generating unit and integration test cases for existing behaviour, which a reviewer can check against the specification.
- Migrations and upgrades. Framework version bumps, deprecated API replacements and mechanical refactors across many files.
- Understanding unfamiliar code. Explaining a legacy module, tracing a data flow or summarising a repository for a new joiner.
- Prototypes and documentation. Throwaway code to test an idea, and first drafts of API documentation.
The common thread is that a human can quickly confirm whether the output is right. Where that confirmation is slow or uncertain, the time saved writing is often spent again in review and debugging.
Where do AI coding agents create risk?
The risks sit less in the code an agent writes than in the attention it removes from the people around it. Five deserve explicit owners.
- Security. Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found they introduced OWASP Top 10 vulnerabilities in 45% of cases (Veracode, 2025). The tasks were designed to expose known weaknesses, so this is a benchmark, not a production rate, but it shows that generated code cannot be assumed safe.
- Licence and intellectual property. Generated code can resemble public code under licences a company would not accept, and terms differ between tools and plans on how prompts and code are retained or used. The questions founders should ask their counsel are which tool terms apply, whether public-code matching filters are switched on, and how ownership of generated code is documented for due diligence.
- Review load. Agents produce more and larger pull requests. If review capacity does not grow with them, reviews become shallower, and defects reach production that a careful reader would have caught.
- Hidden technical debt. Technical debt is the future cost of shortcuts taken in code and design today. Agents optimise for the task in front of them, so they can duplicate logic, add dependencies and drift from the intended architecture in ways that each look reasonable alone.
- Skills atrophy in junior engineers. Developers learn by struggling with problems. Juniors who accept generated code without understanding it may ship faster in month one and debug far slower in month twelve.
How should a CTO set guardrails for AI-generated code?
Guardrails should make the safe path the default, so speed and quality do not depend on individual discipline. A practical set:
- Keep a human accountable for every merge. The engineer who opens the pull request owns the code, whoever or whatever wrote it. Label agent-authored changes so reviewers know what they are reading.
- Cap pull request size. Small, focused changes are reviewable; a 2,000-line agent diff is not. Ask agents to work in steps.
- Make tests the gate. No merge without passing automated tests, and treat coverage of new code as a requirement, not a target.
- Run security scanning on every change. Static analysis, dependency and secret scanning and licence checks belong in the pipeline, not in a quarterly audit.
- Own the architecture explicitly. Keep written architecture decision records and coding standards in the repository, where agents and humans both read them, and reserve design changes to named senior engineers.
- Approve tools and data flows. Decide which tools are permitted, on which plans, with what access to source code and production systems.
- Protect learning time. Pair juniors with seniors on reviews, and expect them to explain any generated code they submit.
This is the same discipline set out in AI adaptation and the new architecture of hyperscaling: the architecture has to be ready for AI before AI can safely accelerate it.
How do team shape and hiring change?
The work shifts from typing code towards specifying problems, reviewing output and owning systems. That changes what a scale-up should hire for.
- More weight on review and design skill. Senior engineers who can judge code quickly and hold an architecture in their heads become more valuable, not less.
- Clear specifications become an engineering skill. Writing a precise task, with acceptance criteria and constraints, is now part of the job.
- Platform and quality engineering grow in importance. DORA’s 2025 report links high-quality internal platforms to an organisation’s ability to realise value from AI.
- A deliberate junior pipeline. Cutting junior hiring because agents write simple code removes the seniors of the future. The question is how juniors learn, not whether to hire them.
What should a CTO measure?
Measure delivery outcomes, not AI activity. Lines of code generated, acceptance rates and seat counts show usage, not value, and METR’s finding on perceived speed is a reminder that self-reported gains are not evidence.
A useful dashboard combines:
- Delivery throughput. Lead time for changes and deployment frequency, the DORA throughput measures.
- Delivery stability. Change failure rate and time to restore service, the measures DORA found most exposed to AI-driven change volume.
- Review health. Pull request size, time to first review and how often reviews lead to substantive changes.
- Quality signals. Escaped defects, security findings per release and test coverage on new code.
- Maintainability. Duplication, dependency growth and the time new engineers take to make their first meaningful change.
- Team health. Developer satisfaction and the growth of junior engineers, tracked over quarters rather than sprints.
How does TGC Capital Partners approach engineering in the AI era?
TGC Capital Partners, your Growth Engineering Partner, is the strategic investment arm of Gateway Group of Companies, a software engineering company since 1997. Through 2X Software Engineering & Tech Excellence, TGC works with founders on the engineering system around AI tools: architecture, review and testing discipline, security practice and team design. Revenue is the outcome TGC measures; the engineering foundations are what make it repeatable.
AI coding agents reward teams that already engineer well, so the investment that matters most is in the system around them.
Frequently asked questions
- What is the difference between an AI coding assistant and an AI coding agent?
- An assistant suggests code inside the editor while a developer types and stays in control of each line. An agent takes a task, reads the codebase, changes several files, runs tests and proposes a pull request for human review.
- Do AI coding agents make developers more productive?
- The evidence is mixed. GitHub’s 2022 experiment found a 55% speed-up on a small self-contained task, while METR’s 2025 study of experienced developers in familiar codebases measured a 19% slow-down. DORA’s 2025 report found gains depend on the strength of the team’s existing engineering practices.
- Is AI-generated code secure?
- It cannot be assumed secure. Veracode’s 2025 benchmark found that models introduced OWASP Top 10 vulnerabilities in 45% of its test cases, so generated code needs the same automated scanning and human review as any other code.
- How can a scale-up avoid technical debt from AI coding tools?
- Keep pull requests small, make automated tests a merge requirement, record architecture decisions where agents and engineers both read them, and give named senior engineers ownership of design changes.
- Should scale-ups stop hiring junior developers because of AI?
- Removing junior hiring also removes the senior engineers of the future. The better question is how juniors learn when agents write simple code, for example through paired reviews.
- What metrics should a CTO track after rolling out AI coding agents?
- Track delivery outcomes rather than tool usage: lead time, deployment frequency, change failure rate, time to restore service, pull request size and review time, escaped defects, security findings and developer satisfaction.
Related reading
AI adaptation and the new architecture of hyperscaling · Beyond AI adoption: what will make a SaaS business defensible and valuable? · The execution gap: why companies start to struggle at scale · Embedded engineering investor: definition and mechanics · 2X Software Engineering & Tech Excellence
Speak with a partner 2X Software Engineering & Tech Excellence