Imagine a leadership team approves an important customer experience change on Monday. The requirement appears straightforward. An engineering team uses AI assisted development tools. By Tuesday, most of the implementation exists.

It looks fast. Then the real enterprise environment appears. One integration behaves differently from the documentation. Security needs clarification. A legacy service has an undocumented dependency. Test data is incomplete. Another team owns part of the release. User acceptance testing cannot begin until the environment is ready. The production window is next week.

The code took a day. The change took three weeks.

That distinction is becoming increasingly important as AI enters software engineering. The ability to generate software is accelerating faster than many organisations can safely absorb, validate and release it.

AI code assistants are evolving into systems that can support planning, development, testing and other parts of the software lifecycle. Gartner’s current research argues that organisations should not limit AI in software engineering to coding because the larger productivity opportunity sits across the full software development lifecycle.

That matters because accelerating one activity does not automatically accelerate the entire value stream. If code generation becomes dramatically faster while requirements, architecture, testing, review and release continue at their previous speed, the constraint simply moves somewhere else.

The engineering team may feel faster. The business may not.

Google’s 2025 DORA research makes the same broader point
from a systems perspective

successful AI adoption is not only a tools problem. The surrounding capabilities, platform quality and value stream design determine whether local productivity gains translate into measurable product performance rather than downstream congestion.

Within SEE. ACT. BUILD., BUILD is the capability that turns business intent into technology that can actually operate.

A useful BUILD flow is:

Intent → Context → Create → Verify → Release → Learn

1. Intent: defines what the business actually needs and why it matters.
2. Context: gives engineers and AI systems the architecture, dependencies, business rules, data boundaries and constraints required to make the right change.
3. Create: produces or modifies the software.
4. Verify: proves that the change works, is secure and behaves correctly within the wider environment.
5. Release: moves the capability safely into production.
6. Learn: observes what happened and feeds real operating evidence back into the next change.

AI can support every stage. That is much more powerful than putting an AI assistant beside a developer and measuring how quickly code appears.

One of the biggest misunderstandings around AI software development is that its main job is writing code. Code generation is useful, but software teams also spend substantial effort understanding what should be built, finding how existing systems behave, tracing dependencies, documenting business rules, preparing tests, reviewing changes and resolving defects.

Current Gartner research on AI across the software development lifecycle covers planning, design, testing, maintenance and context aware tooling alongside code generation. The opportunity is therefore broader than typing code faster.

This matters particularly for established companies. A developer changing a payments process, customer platform, policy engine, ERP integration or operational system is entering years of business logic, interfaces and accumulated decisions.

The difficult question is often not

“Can AI write this function?” It is “Does the organization understand enough about the surrounding system to know what should safely change?”

Legacy technology does not automatically need to be replaced.

AI creates another temptation: if building software is becoming easier, perhaps companies should simply rebuild their old systems. That is often the wrong conclusion.

Stable core systems may contain years of tested business rules, controls, integrations and operational knowledge. Replacing them without a clear business reason can introduce cost and risk.

The more useful question is where existing technology is genuinely preventing the business from changing. AI can help teams understand complex estates, document dependencies, analyze code, generate tests and support selective modernization before a replacement decision is made.

BCG’s 2026 research on AI in the technology function identifies legacy modernization as an emerging value creating use case alongside software development, testing and release automation. The strategic implication is simple: understand first, change selectively, preserve what still works and build where the constraint actually exists.

AI should compress the entire path from requirement to release.

The real opportunity is end to end. AI can help teams:

• translate business requirements into structured engineering inputs

• explain unfamiliar code and architecture

• identify dependencies and likely change impacts

• generate implementation options and tests

• assist code review and documentation

• analyse failures and support debugging

• support legacy modernization

• prepare deployment artefacts and release evidence

• monitor what happened after release

McKinsey’s 2026 work on AI powered software development argues that the companies capturing stronger value are redesigning how software gets made rather than simply giving developers another tool. AI agents can increasingly support specifications, code, testing and deployment, while people shift toward architecture, validation, prioritization and judgement.

The transformation is therefore bigger than developer productivity. It changes how software moves from idea to operating capability.

More software requires stronger verification, not weaker verification.

There is an obvious risk in making software generation dramatically faster. The organisation can create defects faster too.

AI native software delivery therefore cannot mean removing engineering discipline. It requires stronger automated testing, architecture controls, security checks, code review policies, observability, release controls and rollback mechanisms.

NIST’s Secure Software Development Framework treats secure practices as something that should be integrated throughout the software development lifecycle rather than added at the end. That principle becomes even more important as AI increases the volume and speed of change.

Faster creation increases the importance of fast verification.

The developer should not become the final safety control?

When AI produces more software, relying on individual developers to manually inspect everything eventually becomes another bottleneck. The engineering system itself needs controls.

Generated changes can pass automatically through unit tests, integration tests, security scanning, architecture checks and policy validation before progressing. Higher risk changes can require human review. Low risk and well understood changes can follow a faster path. Sensitive systems can require stricter access and deployment controls.

The objective is not unrestricted autonomy. It is governed acceleration.

Week 5 introduced visibility lag: the time between the market changing and leadership becoming decision ready.

Week 6 introduced execution lag: the time between a decision being made and meaningful work beginning.

Week 7 introduces the third measure: delivery lag.

Delivery lag is the elapsed time between a business requirement becoming ready for implementation and the capability becoming safely available in production.

Choose one meaningful technology change and record six moments: when the business intent became clear, when engineering could actually begin, when implementation was technically complete, when verification was complete, when production release occurred and when the business could genuinely use the capability.

Then look at the gaps. Perhaps development required eight hours. Requirements waited four days. Testing waited two days. Security review waited another day. The release waited until the following week.

The organization does not have an eight-hour delivery capability. It has a two-week delivery capability containing eight hours of development.

That is the BUILD opportunity.

Banking, financial services, insurance, healthcare, government and other regulated environments do not need to choose between speed and governance. A governed ACT model can define who may trigger actions, what data an agent can access, which actions require human approval, what confidence threshold applies, how exceptions are escalated, what is logged and how outcomes are audited.

The future of workflow automation is not uncontrolled autonomy. It is governed autonomy.

AI can generate enormous volumes of software. That does not make volume a useful measure of value.

Leadership should care about whether useful technology reaches production faster, whether change failure remains controlled, whether security remains strong, whether customer or operational outcomes improve and whether teams spend less time on repetitive engineering work.

The best engineering teams may sometimes produce less code because they simplify systems, reuse capabilities or avoid unnecessary development entirely.

The objective is faster business change, not more software.

If every engineering team independently selects models, creates prompts, configures environments, defines security controls and builds deployment workflows, AI can increase fragmentation.

Shared internal platforms can provide approved models, reusable integrations, security controls, testing capabilities, observability, deployment patterns and architecture context.

DORA’s 2025 research highlights platform quality and value stream capabilities as important conditions for turning AI productivity into organizational performance.

The platform should not become another bureaucracy. Its purpose is the opposite: make the safe path the easy path.

AI native start-ups can design around modern architectures from the beginning. Established companies have something different: operating history.

They have customers, regulations, data, established systems, proprietary processes, integrations, control environments and institutional knowledge. That complexity can slow change. It can also become an advantage if the organization learns how to make it usable by both people and AI.

The goal should not be to behave like a start up by pretending the past does not exist. The goal is to create AI native speed without throwing away the assets that made the company valuable in the first place.

That may mean extending an existing platform, building an intelligent layer around a core system, replacing one constrained component, creating APIs around older technology, using AI to understand and modernize selected code, or building a completely new capability where the business case genuinely requires it.

BUILD is about choosing the right intervention.

Malaysia’s Digital Action Plan 2030 describes a national shift from being primarily a technology consumer toward becoming a producer of local innovation. The National AI Action Plan 2026 to 2030 similarly focuses on responsible AI adoption, capability building and globally competitive “Made by Malaysia” AI solutions.

That creates a practical implication for Malaysian enterprises. AI capability cannot stop at purchasing international tools. Companies also need the ability to adapt technology around their own customers, workflows, data, operating models and competitive opportunities.

Not every company needs to become a software company. But increasingly, every competitive company needs the ability to change its software quickly enough when the business changes.

That requires BUILD capability.

The better leadership conversation is not simply “Which AI coding platform should we buy?” Ask instead:

• Where does technology delivery actually wait today?

• How long does a normal business change take from requirement to production?

• How much of that time is engineering and how much is waiting?

• Which systems are genuinely preventing change?

• Where is architecture knowledge missing?

• How quickly can the organization test and verify AI generated changes?

• Which engineering activities require human judgement?

• Which repetitive activities could be accelerated?

• What would the business do differently if software delivery became twice as responsive?

Those questions create a BUILD strategy. A list of development tools does not.

The three capabilities now connect.

1. SEE helps the organisation understand what changed and what deserves attention.
2. ACT turns the decision into coordinated execution.
3. BUILD changes or creates the technology required when the business cannot execute effectively with what it already has.

The sequence matters. If the organization cannot SEE clearly, it may build the wrong capability. If it cannot ACT clearly, technology may automate a confused process. If it cannot BUILD quickly, good decisions remain constrained by what existing systems can support.

That is why AI native speed is not one product. It is a connected operating capability.

SEE what matters. ACT on the decision. BUILD what the business needs next.

Take one technology change the business currently wants. Start when the need became clear. Follow it all the way to production. Measure how much time was actual engineering and how much was waiting.

Then ask one question:

If AI made coding ten times faster tomorrow, what would become the next bottleneck?

That is where BUILD should begin.

Book a free Enterprise AI Opportunity Workshop to identify where software delivery is waiting, where AI can safely accelerate the lifecycle and whether the right answer is integration, modernization, automation or new development.

1. Gartner: Don’t Limit AI in Software Engineering to Coding (9 December 2025). Gartner argues that broader AI use across the SDLC is associated with stronger productivity outcomes than concentrating AI only on coding.

2.Gartner: AI in the Software Development Life Cycle: Technologies Overview (23 January 2026). Covers the shift toward AI agents and context aware tooling across the SDLC.

3. Google Cloud DORA: 2025 State of AI Assisted Software Development. Frames AI adoption as a systems problem and highlights capabilities that help local productivity gains translate into product performance.

4. McKinsey & Company: AI powered software development: How technology is rewriting the rules (24 June 2026). Discusses agentic development and the need to redesign software delivery rather than simply add tools.

5. Boston Consulting Group: How AI Is Paying Off in the Tech Function (6 January 2026). Covers software development, testing, release automation and legacy modernization as AI value areas.

6.NIST: Secure Software Development Framework Version 1.1, SP 800-218. Provides secure software development practices designed to be integrated into SDLC implementations.

7. Malaysia Ministry of Digital: Malaysia Digital Action Plan 2030 announcement (29 June 2026). Describes the shift from technology consumer to producer of local innovation.

8. AI Malaysia: National AI Action Plan 2026 to 2030 fact sheet. Focuses on responsible AI adoption, national capability building and globally competitive Made by Malaysia AI solutions.