More AI Code, Same Release Pace? AI for Technology and Software Companies, Measured on Delivery

What AI for Technology and Software Companies Delivers Across the Lifecycle

Every figure in the “Where the gain shows” column is a measure agreed for each engagement against the company’s own baseline, not a published result.

Why More AI-Written Code Does Not Mean Faster Delivery

The Operational View: Review and Testing Become the Constraint

Once AI drafts code faster, the constraint can move to the reviewers and the test pipeline, and the queue in front of them then sets the release pace. A team that doubles its pull-request volume without changing review capacity waits longer for every merge. Smaller changes, clear ownership of review and automated checks that run before a person looks keep the queue short.

The Financial View: Rework and Token Spend Hide in the Budget

The cost of AI in engineering sits in rework and model usage as well as in licences, and neither appears on a seat-count invoice. Code that is almost right costs review time, then fix time, then sometimes an incident. Agentic coding tools that run long tasks consume model tokens per run, so usage-based spend grows with adoption and needs its own budget line and alert.

The Risk View: DORA Links AI Adoption to Lower Delivery Stability

The 2025 DORA report observed that AI adoption continues to have a negative relationship with software delivery stability, and explains that without strong automated testing, mature version control and fast feedback loops, an increase in change volume leads to instability. That is an observed relationship across respondents, not a rule for every team, so each team tracks its own stability as change volume grows. Feature flags, staged rollouts, automated rollback and a change failure rate tracked per team absorb the extra volume. Security review stays on the same footing, because generated code reflects patterns from its training data and prompt context, insecure ones included.

Measuring AI in Software Engineering: The Numbers That Matter

Why Self-Reported Productivity Misleads

Self-reported productivity misleads because developers judge speed by how a task feels, and the METR trial found the feeling and the stopwatch pointing in opposite directions. A tool that removes boring typing feels fast even when review and debugging absorb the saving. Survey answers stay useful for adoption and satisfaction, and delivery data carries the productivity claim.

The “Almost Right” Problem and Developer Trust

Code that is almost right can be harder to catch in review than code that is plainly wrong, because it passes a quick read and fails later. Two-thirds of developers in the 2025 Stack Overflow survey named this their biggest frustration with AI tools. Tests written before the AI drafts the implementation, and reviewers who check behaviour rather than style, catch the near-misses before they reach customers.

Setting a Baseline Before the Rollout

A baseline taken before the rollout is what shows later that AI changed delivery, so measurement starts in the first weeks of the engagement. Four to six weeks (illustrative) of lead time, review wait, change failure rate and rework data per team gives a starting point. The engagement agrees targets and tolerances for each measure after that baseline exists, not before.

AI Features Inside the Product: Evaluation, Cost per Request and Data Boundaries

Evaluation Before Every Release

Every change to a prompt, model version, retrieval policy, schema or pipeline goes through the same evaluation set before it ships, just as code goes through tests, while routine corpus updates, such as authorised content being added, corrected or deleted, run under scheduled, sampled or risk-triggered evaluation. A frozen set of real, anonymised requests with expected outcomes catches regressions that a demo misses. Model providers update their models on their own schedule, so the evaluation also runs when the provider changes, not only when the company does.

Customer Data, the PDPA and Multi-Tenant Boundaries

Tenant-scoped retrieval queries, stored embeddings and model calls are components of customer-data separation in a multi-tenant product, alongside segregated storage, authorisation enforced on every request and cross-tenant security testing, so one tenant’s records stay out of another tenant’s answers. The OWASP entry on vector and embedding weaknesses (LLM08:2025) names context leakage between users who share a vector database as a risk and recommends permission-aware stores with strict logical and access partitioning. Customer records that concern an identifiable individual are personal data, so an LLM feature in a Singapore product takes account of the PDPA for what it reads, stores and sends to a model provider. The Personal Data Protection Act 2012 and its subsidiary legislation set the binding obligations, and the PDPC’s Advisory Guidelines on the Use of Personal Data in AI Recommendation and Decision Systems (1 March 2024), which are advisory rather than binding, explain how the Act applies within their scope. Which obligations fall on the software company depends on its role, for example when it processes data on a business customer’s behalf. As an implementation control in Synthesised.ai’s builds, rather than a format the PDPA prescribes, each data flow records the consent, deemed consent or applicable exception it relies on and its notified purpose, and a flow that sends personal data outside Singapore also records the transfer safeguards that give it protection comparable to the PDPA. The PDPC’s Advisory Guidelines on Key Concepts in the PDPA (revised 29 April 2026) cover deemed consent and the exceptions to consent, and state that the Transfer Limitation Obligation requires personal data transferred overseas to be protected to a standard comparable with the Act, including when a data intermediary makes the transfer. For generative features, the PDPC’s Advisory Guidelines on Use of Personal Data in Generative AI (20 July 2026) set out the allocation of data protection responsibilities across the generative AI lifecycle.

Agents Inside the Product

An agent inside a product needs limits on what it touches, an approval step for anything outside those limits and a log a reviewer reads. Singapore’s Model AI Governance Framework for Agentic AI (IMDA, launched 22 January 2026 and updated on 20 May 2026 with case studies and further practices), published as guidance for organisations, recommends placing limits on agents’ autonomy and access to tools and data, with humans meaningfully accountable at defined checkpoints. The service that controls agentic AI for enterprise with action limits and approval gates covers multi-agent builds in depth.

Building an AI-First Engineering Operating Model That Lasts

Scaling From One Team to the Whole Engineering Organisation

AI scales across an engineering organisation through shared context and a shared platform, so the tenth team starts from the same approved tools, prompts, repository context and evaluation sets as the first. A pilot team’s lessons live in the internal platform rather than in one engineer’s head. New teams inherit the policy, the inventory entry and the delivery dashboard on day one.

Adapting When Models, Prices and Vendors Change

A software company stays adaptable when its product code talks to models through one internal interface, which reduces the effort of switching a model or provider. A provider change can still need integration, security, data-governance and evaluation work, because providers differ in authentication, tool schemas, context limits, safety behaviour, data terms and regional availability, so an evaluation run gates every switch. Model quality, pricing and terms shift several times a year. A company locked to one provider’s API across dozens of call sites pays for every change in engineering time.

Protecting the Codebase and the Customer

AI governance protects the codebase and the customer when it runs as part of the engineering system, with an owner, an inventory and release checks, rather than as a separate document. Synthesised.ai’s delivery builds to ISO/IEC 42001 and the NIST AI RMF, both voluntary references, and the page that authenticates AI certifications and partnerships status states where that stands. NIST’s Generative AI Profile, NIST AI 600-1 (26 July 2024), and IMDA’s Model AI Governance Framework for Generative AI (30 May 2024) supply the risk lists that release checks draw on.

Software Services Firms That Bill by the Hour

A software services firm or agency that bills by the hour faces a pricing question as well as an engineering one, because AI-assisted delivery shrinks the hours the invoice rests on. Product companies keep the saving as margin or speed, while services firms reconsider how fees reflect value, through fixed fees, retainers, added capacity or outcome-based pricing, which is one option among several. The page that optimises AI for professional services firms around outcome-based pricing covers that shift.

Scope Your Engineering and Product AI Build